Ease the integration of Ajax and Java EE

Discussions

News: Ease the integration of Ajax and Java EE

  1. Ease the integration of Ajax and Java EE (11 messages)

    Patrick Gan has written an article for IBM-Developerworks that provides an overview of how Ajax can be integrated into a Java EE Web application. Part of the integration is trying to reconcile the differences in the communication models used by Java EE and Ajax. To help reduce complexity Patrick points to Apache Shale and DWR as showing promise. Patrick is quick to praise the efforts of Web developers in their efforts to develop frameworks and techniques to ensure that different concerns are separated from each other. The implementation of the model/view/controller pattern in frameworks such as Struts is cited. However, the introduction of Ajax threatens all of the good work.
    Introducing Ajax into a Java EE Web application has implications for separation of concerns (and therefore separation of developer roles).
    More specifically, Patrick points out that Ajax may require one to introduce large amounts of JavaScript which tends to mix concerns by introducing monolithic JSPs. In doing so developers are drawn back into the Model 1 approach and all of its pitfalls. Other pitfalls include:
    • Client side scripting may not be enabled
    • Cross browser support increases code requirements
    • Security
    • Difficulties integrating with Web frameworks
    • Use of taglibs that don't support asynchronous communications
    • Threading and other browser-related features
    • Impact on performance
    • Testing
    On the last point the problem is related to the amount of in-browser JavaScript that tests need to deal with. This requires that one be able to use a solid framework such as JUnit or HttpUnit. If you've been using Ajax maybe you'd like to share some of your experiences.
  2. Okay, why? Yes, I understand if you're using the traditional MVC pattern where the controller in on the server, this is true. What I'm about to propose doesn't have any magic well-formed frameworks, owing to the infancy of enterprisey-style AJAX and the shortcomings of Javascript in general. Basically, push the majority of the controller's logic to the client's machine in Javascript. The goal is to vastly simplify the web tier, by chucking out racks of servers to process complex web tiers like JSF and tapestry, that have to dynamically compile and store JSP pages and tags refs, and store data in user sessions. The client will get a more responsive web app, and as a byproduct, won't have arbitrary session timeout (unless they close the browser). 1) If you have a very simple applet that maintains session state on the client in the browser, rather than the server, you can remove maintenance of the session state from the server, and probably save oodles of money since you are distributing this computational/memory resource to the client machines. 2) If you architect your data services properly (this will require good security diligence), then AJAX pages (using something like DWR) can directly invoke the data services. Again, any decision for data requests can be moved to the controller 3) Views can be generated using templating techniques similar to Velocity and the like on the client side with a JavaScript templating library (see TrimPath). In general, because AJAX can update/transform/generate a page from a skeleton, all that horsepower and logic to generate HTML on the server side should be largely discardable, if again, we push/distribution this processing to the client machines. I think articles like this are symptomatic of people trying to pound a square peg into a hole that isn't square anymore. I think we now know how the new hole is shaped, and we need a new peg.
  3. The problem with Patrick Gan's lamenting of how AJAX spoils the MVC party that development, frameworks, tools, and project methodologies have been devised around all these years, is that he is expressing angst from a developer's perspective. Yet the proper perspective to take is that of the customer and customer experience. For customers, AJAX portends the possibility of WEB 2.0 Rich Internet Applications (RIA), whereas WEB 1.0 has been centric to content presentation web applications. The problem is that there is a fundamental break between the WEB 2.0 RIA versus WEB 1.0 web content apps - and all the MVC web framework stuff that exist has been conceived around the WEB 1.0 web content app. If there is indeed a market for WEB 2.0 RIA, then developers are going to have to learn how to engineer this new style of Internet application. They will need to unlearn all their MVC web framework mind set and embrace approaches that are more based on technologies of GWT, Echo2, etc. As to integration of AJAX to JEE? There is one obvious way to proceed to integrate AJAX RIA with JEE. Simply drop in a front-end socket server (or specialized Tomcat container) that serves as a bridge between the AJAX RIA client and the JMS message broker of the JEE server-side world. Then developers can simply write message driven beans to process the interactions with the AJAX RIA client. Indeed, they will even be able to now easily publish notification messages to these clients via JMS publish/subscribe topics. A model for this AJAX-to-JMS bridge container is the SIP Servlet containers that can be dropped into Tomcat and that enable processing of the UDP datagrams of SIP VoIP traffic. SIP Servlet containers are very different than the typical HTTP servlet container. That is the BIG mistake of most AJAX solutions is that they continue to try to shoe horn HTTP servlets into a mode of communication that they're not a very good match for. Also, this AJAX-to-JMS bridge needs to be implemented on top of Java NIO so that a single physical server can easily scale to serving many thousands of connected AJAX RIA clients (these connections need to be persistent TCP/IP-based so that JMS messages can be pushed to the AJAX RIA client from the server-side - hence the necessity for an NIO approach). Well, it turns out there is one JEE server that stands to be in good stead to be the basis of implementing this AJAX-to-JMS bridge. The Sun Glassfish JEE application server is built on top of the Grizzly NIO framework. If the Sun engineers were to get off their butts, they could be way ahead in the game on this WEB 2.0 AJAX RIA concept by building out the infrastructure to fully integrate AJAX RIA clients with the JEE app server. You're welcome Sun.
  4. A benefit of the AJAX RIA client and the AJAX-to-JMS bridge approach that I described in prior posting is that this architecture model is essentially a RIA/SOA approach. This is in stark contrast to all MVC web frameworks that are in popular use these days where no one using them is building anything near SOA. A messaging based server-side implementation is inherently SOA whereas the MVC web frameworks are practically non-SOA (certainly that's the way they play out in practice). If you want to start building a reusable engine for your middle-tier that will have a long life time, then you need to get off the crappy MVC web frameworks and start building SOA engines that are interacted with via asynchronous messaging. I've been building this style for several years now and am into a third generation of middle-tier apps that are reaping the benefits of the SOA approach. It's quite real dudes. The magic resides in the loose coupling that is intrinsic. Everybody I know doing MVC web frameworks are joined at the hip to these monstrosities and are thus stuck with a dated WEB 1.0 technology approach - which they struggle to shoe horn AJAX into (and still don't arrive a true RIA experience for the customer/user).
  5. For customers, AJAX portends the possibility of WEB 2.0 Rich Internet Applications (RIA), whereas WEB 1.0 has been centric to content presentation web applications.
    Hyperlinks do not go anywhere nor document-oriented websites/webapps. So Google demonstrated to the masses how to use XMLHttpRequest introduced by Microsoft in MSIE 5.0, kewl. How this makes Javascript + XMLHttpRequest more Web 2.0 than an XML file processed on a client-side with XSLT stylesheet and prettyfied with CSS?
    Then developers can simply write message driven beans to process the interactions with the AJAX RIA client.
    Why do you think that Ajax requesst should always be ordered?
  6. For customers, AJAX portends the possibility of WEB 2.0 Rich Internet Applications (RIA), whereas WEB 1.0 has been centric to content presentation web applications.
    Hyperlinks do not go anywhere nor document-oriented websites/webapps. So Google demonstrated to the masses how to use XMLHttpRequest introduced by Microsoft in MSIE 5.0, kewl. How this makes Javascript + XMLHttpRequest more Web 2.0 than an XML file processed on a client-side with XSLT stylesheet and prettyfied with CSS?
    An AJAX RIA created with a tool like GWT is more akin to how a Swing GUI app is built. What you describe, though, leads to this scenario: my AJAX web app experience in the early days of DHTML
    Then developers can simply write message driven beans to process the interactions with the AJAX RIA client.
    Why do you think that Ajax requesst should always be ordered?
    A JEE MDB pool does not process received queued messages in strict sequence order. If the pool is configured to be able to instantiate multiple bean instances, then the messages will be processed concurrently by the pool. If the client needs strict ordering of processing, then it can queue outgoing messages on its side in a suitable collection object and only publish out-bound messages to the server once it knows that a just-prior message processing has been completed. The pooled MDB approach remains an advantage because it will concurrently service many connected clients (so obviously it would be a disadvantage for scaling and performance reasons to enforce strict serialized processing of queued messages over on the server-side). Also, if the server-side is clustered, then the message processing will be round-robin load balanced by the message broker against the MDB pools per each cluster node. A further advantage is that a client does not connect directly to the JEE server process, so any node can drop out of the cluster at anytime and not cause disruption from the clients' point of view - messages will continue to be load balanced against surving cluster nodes.
  7. Building on what Roger Voss has to say, I think AJAX applications are a perfect fit for event driven architectures. They react to asynchronous events posted from the server(reverse AJAX) or traditionally polled and pulled from the client. What we would need would be: 1. Event smart components on the browser end 2. Some sort of event management framework on the browser 3. Concurrent state management on the server (on the lines of Spring Webflows) 4. Some sort of standard communication which takes care of marshalling and unmarshalling. An initial version would be Google Web Toolkit ? I have not looked at it, may be someone wants to comment?
  8. In general, I thought the article made alot of sense. It highlighted several points which are real issues in development with AJAX. As for the RIA comments, I think we are loosing grip of reality here. Whether or not RIA is the way of the future in web development is left to be seen. The truth is for a while now MVC has been heavily used. For several years now, the de-facto web framework is based on MVC. In addition, chances are, an application looking to leverage AJAX isn't going to re-architect the entire web layer (to be centered on RIA). Next time you work on a large application, try convincing business stakeholders of this). Most times, the approach is a meet in the middle. As for RIA being closely aligned to SOA and Web 2.0. Remember, just because we get a new approach (SOA), it does not necessarily mean that that new approach renders all previous approaches obsolete. Let's not forgot, SOA approach is determined by the business need (and last I checked all businesses were not created equal).
  9. I think many on this thread may have mis-read/misunderstood this article. The sub-title of the article specifically states "successfully mix asynchronous and synchronous communication models". For those that have been conscious in the past several years, there is a good amount of Java EE web applications which have been written using completely synchronous interactions and MVC architecture. In this regard, I think this article touches on several good points (and offers up realistic ways to cope). Personally, the IT shop which I belong to has signed up for early AJAX adoption. Consequently, we have endured growing pains related to AJAX (some of which is detailed in this article). The article's discussion points will be of great use for those contemplating the usage of AJAX.
    As to integration of AJAX to JEE? There is one obvious way to proceed to integrate AJAX RIA with JEE. Simply drop in a front-end socket server (or specialized Tomcat container) that serves as a bridge between the AJAX RIA client and the JMS message broker of the JEE server-side world. Then developers can simply write message driven beans to process the interactions with the AJAX RIA client. Indeed, they will even be able to now easily publish notification messages to these clients via JMS publish/subscribe topics
    As for the gentleman with this JMS comment, I have seen a similar response regarding the AJAX-JMS in a thread about JSF-AJAX I'm not exactly sure that we want all of our applications (which will leverage AJAX) to use JMS on the backend. Not saying it's a bad thing .. but the statement sounds rather restrictive and seems that we are letting technologies used on the Web layer dictate our business layer implementation (yay !!). And what happens to all of the applications which are not written that way? Are you suggesting a massive re-write of all these applications (this is a good way to kill your ROI). Also, try convincing a room full of architects that they have to strictly abide by this architecture in order to use AJAX. Ideally AJAX should be able function with implementations which are asynchronous or mixture of asynchronous and synchronous and regardless of the backend business logic implementation.
  10. Basically, push the majority of the controller's logic to the client's machine in Javascript. The goal is to vastly simplify the web tier, by chucking out racks of servers to process complex web tiers like JSF and tapestry, that have to dynamically compile and store JSP pages and tags refs, and store data in user sessions.
    It's the next cool thing to say it's a waste to use a framework that works on the server. But it's not. Depending on what your application looks like, moving your logic to the client might or might not be a good idea. If you're doing *a lot* of data access and work with a complex OO model (read OO, not just a flat stupid domain model), you're gonna benefit enormously from developing on the server side with the full power of Java, direct access to your other layers (e.g. no translation of models), strong typing, etc. Otoh, if you're developing a complex UI where the backing isn't that spectacularly complex (e.g. a mail client or photo service), bringing your logic to the client might be a very good idea. Morale: keep some breathing air instead of proposing a quasi hard-and-fast rule.
    The client will get a more responsive web app
    It is rarely the web framework that is the reason for having an unresponsive UI. Usually it's the DB and load etc. Certainly with AJAX such a 'server side' web framework doesn't do a lot more than e.g. DWR does.
    , and as a byproduct, won't have arbitrary session timeout (unless they close the browser).
    That is a design decision that would easily be accomplished with all the frameworks I know off.
    In general, because AJAX can update/transform/generate a page from a skeleton, all that horsepower and logic to generate HTML on the server side should be largely discardable
    Use a profiler and find out how much 'horse power' that web framework is really eating and how much goes to things like database access etc. You're only right if you're talking about really large scale, in which case you should ask yourself if you should use any generic framework or rather code something very specific and scalable.
  11. Oh boy, moving controller logic to the client machine (via javascript). IMO, even with "security diligence", you are exposing quiet a bit for potential malicious hacking. In addition, while this may work for small to mid-size apps which serves up a manageable amount of fields (and logic tied to them). This approach can bring an application's performance to its knees (if the pages are large). Maintenance may also be a challenge. I can see where controller logic on the server-side presents its own set of challenges .. but controller logic in the client is not going to fly with a majority of commercial apps.
  12. The article itself is nice written etc, but it is sad to see that some of the worst mistakes - like coming up with Model 2 and also calling it 'MVC' - are taken for granted as a basis to build upon. This article would have looked completely different if it was written from the perspective of using Ajax with frameworks like Wicket, Echo or Tapestry, where encapsulation and reuse is a reality, and hardly any of the issues outlined in the article are an actual problem.