As an analyst with 20 years of object-oriented experience, 10 in web and Java technologies, who has worked exclusively with Fortune 200 companies for the last 13 years, I must implore Google to reconsider providing messaging to their App Engine customers. I think Google is the greatest thing to happen to businesses since the 7-layer OSI networking model, but in recent months I've discouraged clients from moving to App Engine because most of their enterprise business logic is triggered by JMS messaging, even from the web interface. It allows seamless integration with automated and manual workflows, such as "People A,B and C want to be notified when X happens and don't trigger Y until B approves" and the like.
I implore the community of App Engine users, developers and customers to assist me in presenting an undeniable business case to Google. As such, I have begun with points from my own experience and analysis: 1. Because of its power and flexibility, messaging has become a critical component of automated inter-business communication. App Engine cannot compete fully in the business hosting sector without a messaging mechanism; and Google has the opportunity to create an implementation which makes all others obsolete. 2. Messaging implementations like JMS already inter-operate seamlessly with other languages. There is no reason Google must implement the server portion in Java or any particular language, and once implemented, can easily be made available to all App Engine hosting environments. 3. Most message-triggered business-logic need no response or just an ACKNOWLEDGE response, saving processing and bandwidth. 4. Multiple-destination deliveries can use UDP, saving bandwidth. 5. It will be a no-brainer for messaging to respect and contribute to engine quotas. 6. Message-processing listeners can be instantiated on demand, shuffled-around, load-balanced, cached and discarded just like servlets and can be included in the web app, or more efficiently deployed, operated and managed in its own name-based mass virtual-hosting environment with far less overhead than an entire servlet engine. 7. The world expects HTTP and HTTPS to be on ports 80 and 443, respectively, but not so for messaging! The implementation can provide a factory for client connections allowing Google to more effectively manage ports on the servers which act as entry points and frees Google from being able to use only DNS-based load balancing mechanisms on its entry-point servers. 8. Google, which is already quite adept at hosting, indexing and providing analytics for the world's standardized representations of information, will be in a stronger position to host, index and provide analytics for the world's disparate mechanisms of communication as well, or even to unify them. and, lastly, you have an intelligent and eager volunteer ready to sign a confidentiality statement and help Google's App Engine offerings to make all others obsolete! -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
