It is a fact, web applications become asynchronous. AJAX maked end of long response time due to the old practice of response-loop request to load a whole page. Before AJAX this technique was already used with a hidden Applet which accessed to a MOM (Message Oriented Middleware). Do the MOM become itself as the exchange architecture the most appropriated for web applications ?
Currently in a few case it’s a response to a need of web applications for managing differents aspects :
- synchronization (between clients),
- response time,
- reliable data.
The MOM is used mainly for the first two aspects and least for the next two. Most of time it is a dedicated server where messages are transmitted. If the server go down or the network go down the application show transfer error. This is typically the case in Life Cycle Data Service: the messaging mode lets you synchronize and improve response time, but if the network go down, messages sent by the client are lost. In addition, the application I currently developing, uses Eclipse RCP and embed a Web application that communicates with messaging but with a local queue, make sure of message delivering. The solution is based on IBM MQSeries and MQ Everyplace and implementation is complex but it responds to the 4 aspects.
Is this the end of HTTP ? This is the disadvantage of asynchronous architecture as the value of HTTP is to pass throw firewalls, using another protocol limit visibility of a web application. To resolve this problem MOM have to use HTTP and this is already done.
Don’t forget that this model implies that user is not dependent of response, or most of request are in this case. Hence the need for a local database allowing offline mode. The exchange client / server is then reduced to synchronize database to database. Is this becomes too heavy in terms of deployment and management ? not really because databases are already on board (Java DB via Java Plugin, SQLite via Google Gears). Yes, but what about the database loading ? Indeed it’s necessary to load the database once and it could be long but it depends of the expected need.
This architecture represented in the diagram cons is surely ideal for certain types of Web applications that require autonomy. It’s still difficult to implement because it requires a complicated setup and tools are not intuitive. Eventually this should become completely masked to developers, using methods send / receive without worrying about the rest. Messaging is a proven technology we just need tool or framework to realize such architecture in a simple way.