First question here so go easy on me.
The producer and endpoints can be sockets/websockets/http(s). These requests will then be processed and sent to subscribed consumers or sent to a queue and routed based on message priority and/or user skill. I would also like to store all the messages and transactions and have options to retry and schedule them.
I know appengine does not support sockets right now, buts its available to trusted testers as of sdk 1.7.5 so that might work in future. This application will not be serving the client pages so the channel api won't work and i don't see any websocket server support, i can work around that i suppose.
On the other hand if i use ec2 then all of those issues go away, but i'll need to scale the application myself, and i'll have to manager the database. I know AWS has other options like SQS, SNS, Beanstalk and simpleDB that could handle the queues, notifications and scaling.
I want to use appengine as it seems like the easier platform to develop for. I know i am not the first person to try to build something like this so i wanted to find out what your experiences were.
Does camel work well with appengine? I know a lot of camel components use threads, jms, jndi which dont work on appengine, were you successful on still using camel on appengine without these. And from my description of what i want the app to do is it possible on appengine or am i better of using ec2. Also has anyone tried doing this with AWS beanstalk.
I have spent a decent amount of time googling around but could not find anything concrete. I have the sample camel app running on appengine, so i know camel works, Just want to make sure the other features i talked about will too. I am new to camel and just learning so sorry if the answer is already obvious or if the questions are vague, any help is appreciated.
Thanks for any insight here!
Related
I am creating an app that involves sending and receiving settings... The desktop application is constantly sending information to a hosted MySQL database, and the Android app will query this same information. It is something similar to the whatsapp web (but in this case, I'll be using a desktop app instead of webpages).
Until this part, everything is working as I need... but, this same Android app will be used to send settings to the desktop app, and the desktop will read and change its settings according to what was just sent.
If I need to constantly query the hosted MySQL database and check if there is any kind of changes sent from the Android, I believe that I'll have a performance drop... each time a query loop is finished, I would have to query, check for any modifications and so on.
Is there a better or correct way to do this kind integration between two apps? I've read something about WebSockets, but I don't have much technical information about this, neither examples that I can use in this case.
Thank you very much for your knowledge sharing.
Here are some useful sites on WebSocket:
http://websocket.org
http://blog.kaazing.com/ [some useful blog posts]
http://www.html5rocks.com/en/tutorials/websockets/basics/
https://goo.gl/5OaJff [mozilla site]
You may want to consider the Observer/Observables pattern. The MYSQL is the Observable and your desktop app and Android app are Observers (and you can add other Observers in the future). Its a common pattern with lots of examples out there. But you'll need a centralized WebSocket server and an Observer/Observable coordination subsystem. You can setup a pub/sub message broker that uses WebSocket with a nice JMS, MQTT, etc, API to make your life easier. ActiveMQ, IBM MQ Lite, Kaazing JMS Edition... lots of options.
full disclosure. I work for Kaazing.
This question is cross-posted on bitcoin.stackexchange, stackoverflow and bitcointalks.
I'm planning to build an application on Google App Engine that will heavily make use of Bitcoin trading. I've been Googling along a little but I couldn't find whether it is possible to run Bitcoin itself on App Engine (with Java). I have some experience with App Engine, but limited to a pure web-app centered usage.
I've read about a few people that have made applications using Bitcoin with App Engine as well that are hosting Bitcoin separately on an Amazon EC2 instance.
So, does anyone here either has experience with running Bitcoin in App Engine for Java or would anyone have an idea how this could possibly be done?
I know there are a lot of Bitcoin applications out there, I'd like to know how these manage their Bitcoin traffic.
I'm trying to avoid needing a separate Amazon service running all the time next to App Engine.
In fact, receiving Bitcoin can easily be done by using passive APIs like blockexplorer or blockchain, so I'm considering to find a reliable API to handle my outgoing payments. But this approach causes extreme dependency on this API service, which I actually want to avoid as much as possible.
I think you summed up the possiblities already.
depend on an external service providing notifications for
transactions and sending them i would advise against this.
have a second server running permanently and connect to it using json-rpc
running any type of p2p node on app engine will fail, because of the threading limitations on GAE.
a third possibility would be to use a stratum/electrum supernode, that way you are dependant on a 3rd party service, but at least it is well documented and you can set up one yourself easily. AFAIK, stratum is based on http.
source: i programmed a GAE app dealing with bitcoins about 6 monts ago. (using the second server approach)
use case: 5 - 30 users simultaniously on a chat.
is it a good idea / is it possible to code this on google app engine?
Until the Channel API is released, you'll have to use polling to do this. When that API is released, App Engine will be (IMO, caveat that I work on the team) a great tool for this.
Note that with 1.3.6 you can use the Channel API for local development so you can at least get started implementing something, though it won't work in prod.
maybe it's a stupid question, but couldn't the GAE Application forward incoming messages to all known clients when they are posted to the server?
Why would that not work?
Laures
Is there any software out there that assists in creating an intranet-style proxy for Google’s AppEngine? The problem I’m trying to solve is to enable corporate users to:
1. Enjoy a more responsive experience when plugged into their LAN,
and
2. Remain productive during Internet outages.
I'm not talking about a simple HTTP proxy server here... but instead something which can serve LAN users on behalf of GAE. Is this sort of thing at all possible?
If you're wanting to run an App Engine app on your own infrastructure, you probably want to check out TyphoonAE or AppScale. It sounds like you're looking for something that does even more than that, though - serving local users when disconnected, while still running on Google's infrastructure as well? I'm not sure how something like that would work, or if it's even possible. It would certainly need to be explicitly dealt with by the app, since there's no general way to handle partitioning in a database in a completely consistent fashion.
I want to implement a web-based IM service on the lines Meebo. Might sound ambitious but that adds to the fun of it.
My research suggests XMPP would be a good protocol for the IM since it can talk to proprietary protocols as well. Am I right? What else would I need to complete this?
Could Google App Engine(GAE) fit in to this project? Can GAE be used to create and host the whole service? That would simplify matters significantly.Also,GAE does support XMPP.
I know what I want to make, need to know the best way to make it.
Thanks!
Suvir
GAE has an XMPP API that lets your app send and receive XMPP messages. The real sticking point with making a real time chat app using only GAE is that you can't push updates to the client. So your client would have to continually poll the server to see if there were any new messages. One way around this is to operate a comet server outside of GAE to forward the pushes to the client.
wikipedia page on comet techniques
Google App Engine allows you to use stateless HTTP requests and XMPP, but not TCP sockets. Thus you're limited to any IM services which use the former.
For an example of using the XMPP service, see Using the XMPP service:
For our example app, we're going to
write the Amazing Crowd Guru. The
Amazing Crowd Guru is a veritable
oracle, who can answer any question
you might pose it over XMPP. Writing
an omniscient computer program is no
small task, but thanks to a little
behind-the-scenes trickery, we're
going to get our users to do all the
work of answering questions for us.