Sun Blueprints starts to address AJAX in J2EE

Discussions

News: Sun Blueprints starts to address AJAX in J2EE

  1. The Sun Blueprints project hosted by Java.net has started to address "Asynchronous JavaScript and XML (AJAX) with Java 2 Enterprise Edition" to enable dynamic web applications. From the Blueprints:
    We have seen that there are many possible problems that AJAX interactions can solve. J2EE technology provides a good base to develop and deploy AJAX based applications with APIs for tying in HTTP processing, databases, web services, XML processing and business objects. With a better understanding of this interaction model, today's applications can become more interactive providing a better experience to the end user.
    Use cases indicating appropriate use of AJAX, according to an explanatory document, include:

    • Realtime form data validation
    • Auto-completion in HTML controls
    • Master/detail page interactions that might not otherwise require complete page redraws
    • Sophisticated UI controls
    • Data refreshes for limited data (i.e., scores, forecasts, or stock prices)
    • Server-side notification polling
    Disadvantages are also detailed, including complexity, standards issues (with XmlHttpRequest not being formally part of Javascript yet), implementation differences in browsers, debugging (since executable code is now on client and server), and exposed source code.

    The blueprints team steps through a detailed analysis of four examples showing how AJAX works, with online examples still forthcoming.

    Have you used AJAX? Do you think the blueprints team represents it properly? What tips do you have for design and integration with J2EE? How do you compensate for browsers that don't work with XmlHttpRequest as expected?

    Threaded Messages (34)

  2. Are there any implications for web-site accessibilty see: Section 508, for visually impaired users with all of this dynamic behavior?

    Mike
  3. There may be some issues initially but there could be benefits as well. For starters with AJAX is used the entire page does not have to reload and re-read everything to the user. Instead you could just have it read the updated region.

    And with proper use of semantic tags you can actually enhance the experience for a visually impaired user. At QuirksMode.org they dynamically build a Table of Contents from the header and subheader (h1 through h6) tags on the page. That sort of techiques will dramatically improve usability over what was common a few years ago. And Ajax encourages the user of properly formed XHTML documents with semantic tags with CSS left to style.
  4. JSF and AJAX[ Go to top ]

    It might be plausible (in my very humb opinion) to create a JSF implementation which uses AJAX to handle comms between the client and server, the server side JSF components would only return the changed data, and the client side JSF component would automatically propogate the changes...

    any thoughts ?
  5. JSF and AJAX[ Go to top ]

    I've read on someone's blog (Ed Burn's?)that Shale project is aiming at having JSF working with AJAX (and with a pure HTML templating mechanism a lá Tapestry too, nice!). I suggest those interested in this to check Shale before starting another open source project and risk duplication of efforts.

    Regards,
    Henrique Steckelberg
  6. AJAX is useful[ Go to top ]

    I've been using this technique for a while now, with very good results.
    One thing that irks me about the article is that the code provided does not encode the request parameters/response in xml. Even though the content-type of the response is set to text/xml, the data consists of a single string value.

    I would suggest looking at Apache XML-RPC in conjunction with jsolait for the javascript bits.

    This combinatino gives you an easy to use solution to perform direct RPC on your java code.
  7. AJAX is useful[ Go to top ]

    been using XMLHttp and i admit it that it is useful indeed. The W3C Consortium should create a standard for this technology.
  8. AJAX is useful[ Go to top ]

    got any code samples for jsolait with apache xmlrpc? it seems that examples of jsolait are pretty thin on the ground :(
  9. s[ Go to top ]

    I would suggest looking at Apache XML-RPC in conjunction with jsolait for the javascript bits.This combinatino gives you an easy to use solution to perform direct RPC on your java code.
    As long as you don't need to return a Date object. The five or so Javascript primitives return fine, but not the Date object.
  10. Be aware of DHTML memory leaks[ Go to top ]

    This is not specifically AJAX related, but since AJAX is most useful in conjuction with DHTML, I thought it worth mentioning. IE leaks memory when you have circular references between JavaScript objects and DOM objects (which are actually COM objects). This happens a lot with sophisticated DHTML applications that are modifying the DOM tree; event handlers are the main culprit.

    For some discussion see:

    http://www.quirksmode.org/blog/archives/2005/02/javascript_memo.html
    http://jgwebber.blogspot.com/2005/01/dhtml-leaks-like-sieve.html
    http://blogs.gotdotnet.com/ericli/PermaLink.aspx/f249659d-a3f1-4f6b-9ca3-3bbcc2df240e

    An example solution to the problem:

    http://novemberborn.net/javascript/event-cache

    I have heard that there may also be similar problems with the event handlers of the XMLHttpRequest object itself.

    Basically, I would not tackle a serious AJAX application without first having a reasonably sophisticated client-side framework for event management. You will need it anyway to hide the differences between the event models of the different browsers.
  11. Be aware of DHTML memory leaks[ Go to top ]

    ... and they are a bugger to track down and fix. Absence of an IDE with JavaScript debug/profile functionality doesn't help. Make sure that page refresh is a regular event in your application to keep these problems to a minimum if you can't fix the code.

    Oh, and you'll find that the Microsoft JavaScript runtime is not performant compared to others like FireFox, so heavyweight processing should remain in the middle tier.

    Finally, avoid an application architecture that need to send lots of information back to the server on a regular basis because HTTP doesn't compress upstream.

    Being in the middle of a project with a significant JavaScript component, I would say be certain that you really need rich client-side interaction before you go this route, and keep it to an absolute minimum.
  12. Have a good framework[ Go to top ]

    Actually Phil, a page refresh does not resolve the memory leak issue. All you will do is make sure the memory is more permanently lost. The only way to loose the memory leaks is to unset the event handlers.

    What you also find is that, although the support for JS debugging/profiling is not as good as can be found for environments such as C and potentially Java, Mozilla provides a very robust set of debugging and profiling tools as a standard part of the browser. These utilities make the process a lot easier.

    Being in the middle of a very similar project, I would say that given a good framework, the use of such an approach can be very rewarding and produce a user interface that compares withs the quality of a swing rich user interface. But it is very important to ensure there is a good framework in place to abstract the difficulties of dealing with the browser.
  13. Have a good framework[ Go to top ]

    And there is the rub IMO. As long as there is enough variance in how IE and the rest of the world implement/not implement certain stds, you will need a very good framework indeed. Its also very difficult I think to find developers who can literally swing (pun intended) and context switch between either java on the client or server to the DHTML/Java Script combination. Even for some very skilled front end developers, their expertise from what I have experienced is very focused and specialized and hard to find. I think that if there were an available (maybe there is, I'd like to know ;-) open source framework that simplified all of this it would be extremely powerful. I'm sure there are but can't think of any off the top of my head. And what's wrong with XUL ;-), I think that what it is trying to achieve is very powerful albeit as someone has mentioned its traction seems weak at least. To take another argument to an extreme, why not just have a native plugin cross browser that renders a nice ui with scripting or a first level language, oh wait, there's flex and Java. Personally, I wish I could code and hook into flex using Java (maybe I can and just not up speed ;-), b/c it does look very nice, but dammit I just can't warm up to having to use action script or pay so much money to buy their communication server that really doesn't communicate asynchronously (sure its asynch to your code, but its really polling). Maybe there needs to be a more evolutionary way to think this rich client on the desktop thing. Eclipse RCP? maybe, maybe not, Webstart? fix it (I mean all of its shortcomings and now already ;-). Personally, being more of a server side developer that just wants the simple things in a UI, I'd love to be able to code a rich client without having to worry about distribution, updates, and the what's on the client's machine to make the thing work and to do it in a way that doesn't break the bank or lock me into a single vendor.

    Jin
  14. Have a good framework[ Go to top ]

    And there is the rub IMO. As long as there is enough variance in how IE and the rest of the world implement/not implement certain stds, you will need a very good framework indeed.

    Actually, depending on which browsers you choose to support, its not that bad. If you stick to the mostly DOM compliant browsers, the only tricky thing you need to deal with is the different event models in IE and DOM. For old browsers, you can fallback to an HTML-only version if necessary.

    DHTML/AJAX is great when you want a rich-ish client but don't need to get too complex. You can generate some pretty nice effects by creating, deleting and moving HTML elements around on the screen. It can be used to add some sizzle to data entry web applications, which cover a lot of business needs.

    Anything more complex, and I would want a more complete UI environment. I would not implement a spreadsheet program or an IDE in DHTML, for example.
  15. Have a good framework[ Go to top ]

    And there is the rub IMO. As long as there is enough variance in how IE and the rest of the world implement/not implement certain stds, you will need a very good framework indeed. Its also very difficult I think to find developers who can literally swing (pun intended) and context switch between either java on the client or server to the DHTML/Java Script combination. Even for some very skilled front end developers, their expertise from what I have experienced is very focused and specialized and hard to find.

    As noted in a subsequent response, the differences in browsers boil down to a very limited, albeit painful set of controllable differences. The secret is to recognise that, if you wish to produce a rich client, you are going to produce a rich client and not a half breed. Place the correct development focus on the problem. Identify the appropriate abstractions and implement them in a manor that ensures a decoupling from the underlying browser.
    With respect to skill, I believe that any competent Java developer is capable of making the transistion to JS (based on experience doing this in the last year or so), though it would be helpful if there were more useful JS books out there beyond the basic API documentation. I would agree though that there are not many competent developers, this is a general problem and not restricted to this type of work.
    I think that if there were an available (maybe there is, I'd like to know ;-) open source framework that simplified all of this it would be extremely powerful. I'm sure there are but can't think of any off the top of my head. And what's wrong with XUL ;-),

    I wish there was a good open source framework available, havn't found one myself. With respect to XUL, I think it is a good step in the right direction, but unfortuantly is not browser independent. This is a minor problem in the commercial world with people hung up on using MS products :)
    why not just have a native plugin cross browser that renders a nice ui with scripting or a first level language, oh wait, there's flex and Java.

    Not all deployment environments allow the use of plug-ins. In those environments JS and DHTML become the only tools available.
    Personally, being more of a server side developer that just wants the simple things in a UI,

    Ah, the easy way out. If only we didn't have users, it would be much better. Server side development is by far the easiest form of development. It is well structured and does not have the same unpredictability introduced by users. Having done a bit of both, I would say the most challenging part to any development is client-side development, users are demanding, upredictable, and writting software for them becomes extremely challenging. The net result is that few front-ends make the grade as either the developers are not up to the task, or the project does not have an infinite amount of time and resources to meet the insatiable desires of the users :)

    I suppose it is also worth stating that I think that there is still a lot of work to do on any user interface toolkit / framework and that the use of web browsers for application front-ends is fundementally wrong. The abstract concept is good, but the spaghetti it is based on is problematic. There is definitely a need for rich user interfaces that are dynamically accessable over a network, in a platform independent fashion, that allows people to perform tasks on arbitrary computers (such as Internet Cafe's etc.) but it would be nice if it could be a more robust environment from a development perspective.
  16. XML and JavaScript[ Go to top ]

    We have just started on a project where we used XML from servlets pushed to the front.

    to aid in the design at the front fof modifying the data (get XML, modify, push back) we used the excellent JS XML library fround at xmljs.sf.net.

    This, amongst other great tools (such as XPath queries on the same XML document).. allows you to load the XML up on the browser side as a JS Object (w3c.dom API) and modify to suit.

    Very handy .. (all this and I didn't even know we were using AJAX ;-)
  17. This was greatly helpful for me. I think its great that SUN took the initiative and did this.
  18. AJAX and Struts[ Go to top ]

    Do you think that an extension for Struts to use AJAX would be interenting?
    Soes this exist?
    Or just AJAX is so simple that it´s not needed?

    I would start a project in sourceforge if you think this can be usefull, as I think we will use it in an Struts application.

    Jose R.
    Modelos de Negocio basados en Software Libre
  19. It came from the forest[ Go to top ]

    I don't understand why people are so excited about Ajax. Which by the way is a stupid name.

    But I guess people living in the Amazon rain forest, isolated from the rest of the world would be excited if they saw an AK-47. The rest of the world would only be impressed if someone detonated a 100 Megaton hydrogen bomb in the atmosphere.

    People should grow up and realize Ajax is just a hack for a crappy HTML standard. They should instead be talking about XUL. And push browser vendors to implement it, instead of XmlHttpRequest. Which is just a simple hack that complicates things even further.

    It seems funny that most people on the Internet seem to be living in the Amazon rain forest.
  20. It came from the forest[ Go to top ]

    They should instead be talking about XUL. And push browser vendors to implement it, instead of XmlHttpRequest.

    Are you living in Amazon too? :)
    You still have to use XmlHttpRequest when you are using XUL.
  21. It came from the forest[ Go to top ]

    They should instead be talking about XUL. And push browser vendors to implement it, instead of XmlHttpRequest.
    Are you living in Amazon too? :)You still have to use XmlHttpRequest when you are using XUL.
    Would you mind telling what flavour of XUL browsers should implement?

    Why do not forget all that and simply demand X-Server being present on clients? I am serious. That solves almost every problem - any kind of UIs and technology will be happily rendered by client.
  22. Konstantin,

    a long time ago (in a far far galaxy :) I worked in a CAD system which ran no unix using Motif and XWindows as its UI framework. The only thing I still remember from those days are the huge volumes (500+ pages each) with references and tutorials explaining Motif and XWindows APIs. VERY scary. It wasn't fun to code to it, and maybe that's why it didn't catch on and ended up being replaced by KDE's and GNOME's APIs on Linux (besides their "closed source-ness"). If their APIs haven't changed from back then (I haven't heard much about them for a long time), I wouldn't imagine anyone crazy enough to build anything using either Motif or Xwindows, not because they lacked features (which they didn't at all!), but because of their great complexity.

    Regards,
    Henrique Steckelberg
  23. Henrique,
    In my far away galaxy it is still well known that XWindow is NOT replaced by whatever API you have mentioned, but those wrap core XWindow.
    And personally, I do not have to remember, but daily enjoy XWindow UIs are working on my workstation for applications which I started on various comps in the network.
    .... Motif and XWindows as its UI framework. The only thing I still remember from those days are the huge volumes (500+ pages each) with references and tutorials explaining Motif and XWindows APIs..... replaced by KDE's and GNOME's APIs ....
    Just for fun try locating and reading direct win32 UI programming guide. Its volume isn't smaller :)
    Pls, compare apples to apples.
  24. Konstantin,

    ok, my bad! Memory must be getting old with the rest of me. :) Yes, Gnome and KDE's APIs (GTK and QT) obviously run on top of XWindows... but my point was that if XWindows where simple in the first place, there wouldn't be need for Motif, GTK or QT. And Motif took too long to become "open source", and now has to fight for its place with those two. For a UI toolkit which dominated unix for so long (besides Sun's ugly OpenWindows), it can be seen as a sign of something gone wrong with Motif.

    PS: running Xwindows apps across a network is immensely easier than actually coding such an app... ;)

    Regards,
    Henrique Steckelberg
  25. running Xwindows apps across a network is immensely easier than actually coding such an app... ;)Regards,Henrique Steckelberg
    Hmm, I did not notice that writing UI code with QT, Swing, or other frameworks is that difficult... And note, no matter what abstractions are used by a particular framework, any XWindow server (which works on client machine btw) happily renders it.

    The beauty: no need to force some predefined set of widgets (HTML, XUL, XAML, whatever) on a developer. QT,Swing, TK and other applications work together on client machine without any problems.

    All that XUL stuff is just an attempt to convert browser into X-Window (UI) server. That is it- wheel reinvention.
    1st attempt - force everybody using HTML widgets only - kind of square wheel;
    2nd attempt - XUL widgets - wheel is polygonal - probably octagon;
    Why do not use round one? - Sure it needs some lubrication, but using square wheels just because round one is a bit squeaky... that is beyond my understanding.
  26. Well, it is not just about code complexity. Xwindows, AFAIK, runs well on local networks, but is too heavy for low bandwidth networks, where browsers shine. There were some time ago an effort to improve XWindows with a lighter protocol aimed at Internet connections, but I dunno if it went forward. Besides, I have also seen some minor compatibility problems between different servers, but that is something we should expect to some extent (the problems were far less than what we have today with browser differences). But yes, I igree that if one day the browser becomes just a "widget server", it will come full circle, almost back where XWindows was more than 10 years ago.

    Regards,
    Henrique Steckelberg
  27. Well, it is not just about code complexity. Xwindows, AFAIK, runs well on local networks, but is too heavy for low bandwidth networks, where browsers shine....
    - We seem to agree that XW programming is easy - good!
    - Yes, VW is heavier on bandwidth, it needs to be ligtened a bit;
    I guess it is too easy and it will just work, which is NoT good for vendors.
  28. We seem to agree that XW programming is easy - good!
    Actually not exactly: coding to some UI toolkit (QT, GTK, Motif) was relatively easy, but going down to coding XWindows was not, as far as I remember. But that may be just my own perception of difficulty back then.

    Regards,
    Henrique Steckelberg
  29. Re: It came from the forest[ Go to top ]

    I don't understand why people are so excited about Ajax. Which by the way is a stupid name.But I guess people living in the Amazon rain forest, isolated from the rest of the world would be excited if they saw an AK-47. The rest of the world would only be impressed if someone detonated a 100 Megaton hydrogen bomb in the atmosphere.People should grow up and realize Ajax is just a hack for a crappy HTML standard. They should instead be talking about XUL. And push browser vendors to implement it, instead of XmlHttpRequest. Which is just a simple hack that complicates things even further. It seems funny that most people on the Internet seem to be living in the Amazon rain forest.

    The AK-47 is the most ubiquitous firearm on the planet for good reason. It's cheap, rugged, reliable and versatile. If you were limited to only one rifle, you could do far worse on many measures than an AK-47.

    JS + DHTML + XmlHttpRequest is the same thing. Cheap, reliable and versatile. We don't have to wait for browsers to support it (they already do), MS has NO intention of supporting it, and I don't see anyone making a "XUL Plugin" for IE. I bet Firefox supports XAML before IE supports XUL.

    For those targeting the Web population At Large, "AJAX" is very workable solution and raises the bar on the user experience in many ways.

    XUL may be the better mousetrap, but it has no momentum at the moment, and may well drift off if we can Make Do with things like AJAX.
  30. Re: It came from the forest[ Go to top ]

    People should grow up and realize Ajax is just a hack for a crappy HTML standard. They should instead be talking about XUL. And push browser vendors to implement it, instead of XmlHttpRequest. Which is just a simple hack that complicates things even further.

    So in this world that you live in, does Microsoft implement XUL for IE? Or does IE lose market-share and become a niche browser?
  31. It came from the forest[ Go to top ]

    They should instead be talking about XUL. And push browser vendors to implement it, instead of XmlHttpRequest.

    W3C's DOM Level-3 Load&Save validates the intent of XmlHttpRequest. In this way Ajax is an international standard, as specified by W3C and ECMA. Internationally standardized XULs (eg SVG and XHTML) are meant to optionally use the Ajax strategy.
  32. AJAX implementation with echo2[ Go to top ]

    If you want to see a kick ass implementation of an ajax web application framework then you have got to check out echo2:

    http://www.nextapp.com/products/echo2/

    Check out the demo app at:
    http://demo.nextapp.com/InteractiveTest/ia

    It is open source and server-side java based. Its debugging capabilities are enough to inspire you. Only changes are sent back to the browser keeping browser/server communcation very nimble.
  33. AJAX Information[ Go to top ]

    For more information related to AJAX go to AJAXMatters.com. Feel free to suggest additional resources.
  34. The AJAX technology approach is a smart way to provide interactive, non-flickering web frontends for business applications.

    Please have a look on http://www.casabac.com/ajaxdemos.html in order to see that there is more behind AJAX than "some fancy controls" - ...and that AJAX does NOT automatically mean that that development has to fight with "ugly" Javascript!

    Being a technology provider in the area of desktop-like web applications we are pleased to see that there is some consolidated addressing of AJAX requirements - and really hope that some of the common problems are addressed, too:

    Maybe stupid, but very concrete example: the back button in the browser is something everyone has to fight with... (I do not want to start discussion on this topic here, though!!!). Same with Refresh. - Or, other example: Intergating AJAX based applications in Portals is possible by embedding them into IFRAMEs but it's not really nice to have an interactive portlet with AJAX inside, which is redrawn every time an other portlet sends a processing request...

    Bjoern Mueller, Casabac Technologies
  35. Why so complicated[ Go to top ]

    Why are we doing all this complicated stuff to support multiple browsers and the HTML/Dom version compliance they have / don't have. Lets be done with it and launch a thin client from a browser doing away with the need for AJAX and allowing us to use a real object orientated language on the client end as well.