Discussions

News: AJAX and Web services - is there a correlation?

  1. AJAX and Web services - is there a correlation? (37 messages)

    In this article, Mike Meehan looks at some of the benefits and limitations of AJAX (Asynchronous JavaScript and XML) and examines its potential role in service-oriented deveopment. While there may not be an obvious connection, integration vendor Tibco is looking to bring the two together in an new Ajax tool slated for release early next month.

    Read Can Ajax be running partner of Web services?

    Threaded Messages (37)

  2. no, there is not.
    DHTML is quite old, and so is XML-RPC. Nothing to see here.
    Move along.

    .V
  3. This is yet another chapter in client/server programming.

    AJAX is the result of Microsoft's early recognition that updating an entire web page is bad. Add to the browser the ability to dynamically connect to a remote server and update a portion of a web page.

    Applets had similar funtionality, but there was no widely supported mechanism for an Applet to interact with "the rest of the page". Applets could not edit the HTML of the page where they resided.

    With HTMLHttpRequest, JavaScript was given the ability to query the server for additional information, and when added to its pre-existing abilities to edit HTML, programmers were given the ability to create a full-featured cient-side user interface using only two technologies: JavaScript and HTML.

    Now that the client-side of the equation is complete, we turn to the server-side. Web services are server-side... uh... services that Do Not Have User Interfaces.

    Server-side web-based functionality with no user interface, plus client-side web-based user interfaces with no funtionality... Seems like a pretty good mix if anyone can come up with a decent development environment for JavaScript.

    Maybe not a correlation, but definitely an opportunity.

    --John
  4. Applets had similar funtionality, but there was no widely supported mechanism for an Applet to interact with "the rest of the page". Applets could not edit the HTML of the page where they resided.

    I don't think it was ever a standard but the Netscape 4 JSObject interface still seems to be fairly well supported (http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:LiveConnect:JSObject). A swift check, and it still seems to work on Firefox, Konqueror and IE (although IE on XP now pops up a warning about ActiveX controls).

    Using this your applet can do anything with a HTML page that JavaScript can do. It never really caught on, probably because it was never that well publicised, and documentation a bit hard to come by.
  5. JSObject Rocks[ Go to top ]

    Lightweight, cross-platform, lets you code in Java and pass Object not XML - wonder why it never took off?

    Not well publicised/marketed could be true. Could be the penalty of the JVM in a browser, or it could just be too complicated.

    Once you have a suitable JVM installed for the browser, why even code HTML? GUI development is taking a step backwards with AJAX, as is distributed object technology with Web Services, but it keeps us busy and makes us fell important, doesn't it?
  6. AJAX realisation.[ Go to top ]

    In my opinion, AJAX good idea for build really thin client for server application. For this application, direct call of web services not best idea. Best solution - web client show information from special server application, and web-services calls must be done from server part of application. Such solution don't mix view and functionality. We don't go back to pre-MVC solutions.
    I make attempt to create AJAX framework to Java Server Faces.
    As was notice in discussion, create and debug such application difficult task, but JSF good candidate to simplified. Main idea - reflect JSF view tree on server to client DOM tree, and keep it consistency on all requests. Also, for case if XMLHttpRequest don't supported, framework use dynamic scripts and JSON - like data transfer. worked sample - http://smirnov.org.ru/myfaces-ajax/ajax.jsf , some documentation - http://smirnov.org.ru/en/ajax-jsf.html .
    Sorry, it still alpha, but main idea has worked.
  7. AJAX is the result of Microsoft's early recognition that updating an entire web page is bad. ... Applets had similar funtionality, but there was no widely supported mechanism for an Applet to interact with "the rest of the page".
    It's a good thing that AJAX beat applets at rich browsing. ECMAScript, CSS, HTML, and DOM are open standards. Applets isn't.
    Server-side web-based functionality with no user interface, plus client-side web-based user interfaces with no funtionality... Seems like a pretty good mix if anyone can come up with a decent development environment for JavaScript.
    I dig it too, the clean separation, which I think comes from HTTP generally and not necessarily SOAP. The key elements of RIA are HTTP, XmlHttpRequest (or DOM Level-3 Load&Save) , DOM, and JavaScript. Above the DOM can be any dialect: HTML, SVG, VoiceXML. The XmlHttpRequest could transport SOAP, but transporting REST is easier and more prevalent. I suppose JavaScript could technically be replaced with any processing language, though politically unlikely. Anyway, all of this alphabet soup is open standards.
  8. plus client-side web-based user interfaces with no funtionality (sic)

    I thought AJAX allowed us to ADD functionality. JavaScript, extensive use of the DOM, and async. events won't provide a cleaner separation. And while some of the AJAX technologies are open (the primary component, xmlhttp, is not) they are not fun to deal with in a cross browser environment.

    Taylor
  9. In my view, AJAX and Web Services have as much correlation as say JSP/Servlets and SAP, or even mobile phones and databases. AJAX is a UI model, and Web Servceis is a backend functional layer access mechanism. Obviously there may be cases where such data needs to be presented- eventhis is not the primary usecase for Web Services. But that doesnt make AJAX any more "correlated" to Web services than any other UI model is.

    AJAX is about pure presentation, where the source of the data is abstracted behind a url that returns an XML document of some format/schema that is known to the client side script of AJAX. And Web Services, per its original value proposition, is about accessing backend services, primarily from other systems and applications.

    If the idea of this thread is to have a good mechanisms to "view" data returned by Web servceis, then XSLT & CSS probably offer a better solution. AJAX is not necessary for this- though there may be cases where this is needed. The latter would be more an attribute of the data than from the fact that it is coming from a Web Servcice

    AJAX is a general UI paradigm, useful when there is extensive client-side UI manipulation/filtering/mult-view of data involved. Unlike JSP and otehr server side scripting, AJAX like environments offer a good performing alternative for such cases. Now, in Web Services, where is the inherent need for such manipulation. There surely may be usecases of data returned by Web Servceis that fits this model of client side manipulation. But this has nothing to do with Web Services as such.

    Cheers,
    Ramesh
  10. AJAX is about pure presentation, where the source of the data is abstracted behind a url that returns an XML document of some format/schema that is known to the client side script of AJAX.

    Isn't a url that returns an XML document a web service?
  11. If the idea of this thread is to have a good mechanisms to "view" data returned by Web servceis, then XSLT & CSS probably offer a better solution. AJAX is not necessary for this- though there may be cases where this is needed.

    CSS won't help you update a portion of the view. Think of a pages that only need partial update, and pages that are getting data from multiple web services (multiple data sources)... That's where AJAX comes in.
    --John
  12. If the idea of this thread is to have a good mechanisms to "view" data returned by Web servceis, then XSLT & CSS probably offer a better solution. AJAX is not necessary for this- though there may be cases where this is needed.
    CSS won't help you update a portion of the view. Think of a pages that only need partial update, and pages that are getting data from multiple web services (multiple data sources)... That's where AJAX comes in.--John
    Again, this presupposes that "vewiing" the data is the focus. Which is not normally the case. Not within the current applciation architectures atleast. Going forward, if there is service and process centric solutions design, and if the middle-tier is entirely in services (say, Web Services) and a new UI paradigm is needed, then maybe. But surely there is not much need for it tdoay. And probably less needed than most other architectures (say J2EE or .NET), as UI for Web services is normally not a requirement. Given that WS is more about applciations talking to each other. Atleast, it is so today.

    It will be really nice to know if there are solutions out there, that are being designed ground up with Web Servceis as its primary middle-tier (and not as a wrapper around existing middle tier).

    Cheers,
    Ramesh
  13. No pun intended ;-)[ Go to top ]

    plus client-side web-based user interfaces with no funtionality (sic)
    I thought AJAX allowed us to ADD functionality. JavaScript, extensive use of the DOM, and async. events won't provide a cleaner separation. And while some of the AJAX technologies are open (the primary component, xmlhttp, is not) they are not fun to deal with in a cross browser environment.Taylor
    Should I have said "client-side web-based user interfaces with no fun" ;-)

    --John
  14. And while some of the AJAX technologies are open (the primary component, xmlhttp, is not)...
    DOM Level-3 Load&Save is an open standard equivalent to XmlHttpRequest. So AJAX's destiny is to be entirely standardized by W3C and ECMA. Applets have no such future.
  15. Actually, there is[ Go to top ]

    no, there is not.DHTML is quite old, and so is XML-RPC. Nothing to see here.Move along..V
    Actually, there is, as this article dated back to 2000 explains. Some quotes:

    XMLHttpRequest: "This object lets you communicate between HTTP servers through XML ... From the client side of the application you instantiate XMLHttpRequest and, through its methods, issue an HTTP command like GET or PUT to the Web server. If it doesn't sound particularly impressive, consider that you can use GET or PUT to transmit an entire XMLDOM."

    Towards Web Services: "Thanks to the XMLHttpRequest object you can now easily implement a Web service within the Win32 platform, particularly where machines running Windows 2000 are involved. ... With some extra coding you can arrange one or more ASP pages so they act as Web-level libraries of functions. Client code invokes them via HTTP, where they accept and return XML code. On both sides of the connection the XML code is managed and traversed through the XMLDOM."

    XMLDOM Manipulation: "In a typical scenario, what the client and the server exchange is an instance of the XMLDOM of the XML data involved with the HTTP conversation. This means that the ASP page—namely the server page—can retrieve the XMLDOM and modify it, if that's necessary. The changes entered are available to the client as soon as the invocation method terminates. Within the ASP page, the Request method lets you access the input XMLDOM and modify the structure and content of the XML data simply by using the methods of the object."
  16. Wouldn't having your presentation tier invoke Web Services directly be considered tight coupling?
  17. Tight coupling?[ Go to top ]

    Wouldn't having your presentation tier invoke Web Services directly be considered tight coupling?

    Your entire presentation layer is in the browser, and all of your business logic is on the server... that's actually pretty thorough decoupling (client/server).

    Yes, your presentation layer will have to change if the interfaces to your business logic change... but that's innevitable.

    --John
  18. Tight coupling?[ Go to top ]

    As long as it doesn't perform like WSRP :)
  19. Tight coupling?[ Go to top ]

    As long as it doesn't perform like WSRP :)

    We don't need no stinkin performance ;-)

    Point taken, but I think the primary limitation at this point is that it is really, really hard to develop a "rich" user interface using nothing but JavaScript and HTML. We don't have the tools or the frameworks... but perhaps that's where Microsoft's ATLAS will come in?

    --John
  20. Tight coupling?[ Go to top ]

    In fact, there is no reason you can't structure your JavaScript to reduce coupling between it and the DOM.
  21. Tight coupling?[ Go to top ]

    I'd find it very unlikely for MS to provide us with an AJAX framework without any dependency on .Net or IE. AJAX is becoming the next big threat to MS' desktop monopoly: just imagine apps running on any browser on any OS, and it becomes clear MS won't let that go without tying it somehow to their products, as their history has shown. Adopting such a framework would defeat one of the biggest benefits of AJAX, which is platform independence.

    Regards,
    Henrique Steckelberg
  22. Platform independence?[ Go to top ]

    Adopting such a framework would defeat one of the biggest benefits of AJAX, which is platform independence.

    Henrique,

    AJAX isn't platform independent with respect to the browsers. The Microsoft XMLHttpRequest Object and it's Firefox and Opera clones are just similar mechanisms for getting data from a server.

    The JavaScript that processes the returned code is extremely platform (browser) dependent (you have to code for IE or Firefox, etc.) I do know of some cross-browser JavaScript libraries, but these aren't tied to AJAX.

    I do agree that you have server-side "platform independence", but even there you place constraints based on whether you want XML or JASON formatted responses.

    --John
  23. Platform independence?[ Go to top ]

    John

    Yes Ajax is specific but in the same time what most of the application developer expect it frameworks that will give the portability. For example, application developer will use JavaServer Faces components that are AJAX enabled. I donot believe that is the role of the majority of developer to code in HTML and Javascript since for me their role is in most of the case to build business application, not the framework to run it...

    Regards
    Tugdual
  24. Platform independence?[ Go to top ]

    Henrique,AJAX isn't platform independent with respect to the browsers. The Microsoft XMLHttpRequest Object and it's Firefox and Opera clones are just similar mechanisms for getting data from a server.
    A client-side AJAX framework should shield the developer from such differences, it is not rocket science at all. Some FWs don't even rely on XMLHttpRequest and instead can use hidden frames for client-server communication in a transparent way. See DWR for example. (DWR is tied to Java at the server-side, but the same mechanism could be used for other server-side platforms).
    The JavaScript that processes the returned code is extremely platform (browser) dependent (you have to code for IE or Firefox, etc.) I do know of some cross-browser JavaScript libraries, but these aren't tied to AJAX.
    Again, it is possible to have cross-browser scripts, so this should not be an excuse to tie a tool to a specific browser at all. Here's a cross-browser AJAX library as an example: DOJO
    I do agree that you have server-side "platform independence", but even there you place constraints based on whether you want XML or JASON formatted responses.--John
    None of the above justify having your AJAX framework tied either to a specific browser, OS or server-side platform, as many exists today proving that platform independence is possible. I am not saying that it is an easy thing to do, but being it possible, we should demand toolkits to provide us with such needed benefit.

    Regards,
    Henrique Steckelberg
  25. Platform independence?[ Go to top ]

    John, I don't agree with everything you're saying here:
    AJAX isn't platform independent with respect to the browsers. The Microsoft XMLHttpRequest Object and it's Firefox and Opera clones are just similar mechanisms for getting data from a server.

    This is true. Under the hood, Microsoft's XMLHttpRequest object is an ActiveX component, and FF/Safari provide native objects.
    The JavaScript that processes the returned code is extremely platform (browser) dependent (you have to code for IE or Firefox, etc.)

    This is certainly not my experience. Once you'bve got the xhr object, the API's and behaviour are practically identical, and the callback function doesn't need to do any cross-browser shenanigans. I've written plenty of working examples for the ajax book, and plenty of production code. Believe me, this really isn't an issue.

    Ant there are several cross-browser libraries that can gloss over the pain of getting hold of your xhr object too - Sarissa, Prototype's Ajax.Request object, to name but two.
  26. Platform independence?[ Go to top ]

    The JavaScript that processes the returned code is extremely platform (browser) dependent (you have to code for IE or Firefox, etc.)
    This is certainly not my experience. Once you'bve got the xhr object, the API's and behaviour are practically identical, and the callback function doesn't need to do any cross-browser shenanigans. I've written plenty of working examples for the ajax book, and plenty of production code. Believe me, this really isn't an issue.

    That's great to hear Dave... I guess I ought to buy a copy of your book ;-)

    --John
  27. Platform independence?[ Go to top ]

    I agree with John.
    AJAX isn't platform independent with respect to the browsers. The Microsoft XMLHttpRequest Object and it's Firefox and Opera clones are just similar mechanisms for getting data from a server
    becouse, we have a lot of problem with the Browser compatibility.

    Alexis Quirós, (aquiros at cubika dot com)
  28. Wouldn't having your presentation tier invoke Web Services directly be considered tight coupling?

    humm... yes. Prettly much like having your JSP's POSTing to an MVC back-end might be considered tight coulpling your JSP's to the business layer.

    So what? As long as the presentation layer is the one coulple to (and not coupling) the webservices...

    Hugo
    http://jroller.com/page/hugopinto
    http://jroller.com/page/hugopinto
  29. This is really cool[ Go to top ]

    1. No more dealing with HTML unless really required. Hopefully, the GUI component objects encapsulate the HTML and you don't need to deal with things at that level.
    2. The IDE runs right off the browser. How cool is that?
    3. Its event driven. What would be cool is if it generated WSDL for the services the GUI expected from the server.
    4. No more being tied in with the backend server technology, whether it be JSP/ASP/PHP whatever. You are now free to select the backend technology that best suits your needs.
  30. Yes, there is a correlation.
    I'm developing a SOA (XINS), a few months ago I decided to have a look at AJAX and it was very easy to write an AJAX example that calls the web services API. Note that I had the advantage that the communication protocol of XINS is a URL as input and simple XML as output.

    This could be very handy as you just need to deploy your API to invoke your service using the browser or another program (Java, PHP, ...).
  31. No, themidnightcoders.com have not paid me to post -- I am posting because there are diagrams (relevant to this discussion) on this page; moreover, Terry Nisenbaum had a recent posting on TSS about weborb.

    Take a look:
    http://www.themidnightcoders.com/weborb/aboutWeborb.htm
  32. sweet dreams[ Go to top ]

    now that functionality starts to even "officially" migrate back to the client, isn't it time to at least dream of a unified scripting environment for GUI desktops, that would allow applications to be downloaded via the internet and executed as scripts in the context of the regular GUI, as opposed to that outdated browser thing? Do away with back buttons, etc., and along the way provide a nice object-oriented scripting language as well? All that based on a universally accepted standard that is meticulously observed by all vendors..

    ..oops, wakeup. Go back to work..
  33. iframe[ Go to top ]

    I have one question about XMLHttpRequest.
    Why don't we use the classic "IFRAME" to perform AJAX?
    In my projects I don't need the power of XML and the comfort of sync request.
    Therefore, with IFRAME I can make server calls in a browser independent way.
  34. IFRAMES are Evil[ Go to top ]

    If you've ever posted a from containing IFrames, you will quickly find out they disappear from the post. Using <SPAN> elements in the form will post, saving a major hassle. As to AJAX and web services, I would strongly advocate calling the web service from the server and dealing with the complexity there. A fundimental tennat of AJAX in my view is to miminize client side complexity by making server calls very cheap. Passing AJAX requests/responses as JSON objects does this as there is now no need for the X in AJAX whatsoever.
  35. iframe cross host AJAX[ Go to top ]

    Making an AJAX library cross browser feels short sighted. The library needs to be cross host (browser, konfabulator, dashboard, wsh).

    There are many other uses for the techniques and tenets of AJAX than traditional browser based apps which makes an iframe hack completely useless.
  36. AJAX is nicely suited for Web services[ Go to top ]

    JavaScript+XML (AJAX weee!! I hated this word, but now I just go with it, since it's obviously so darn mainstream!) is nicely suited for working with a service oriented architecture. It can be used very efficiently on portals, for making every component handle itself independently, if it's a robust framework, one should never have to think to much about the other components.

    I would be careful about making 'AJAX' a requirement for a large site, but it could easily be implemented to complement the non-AJAX solution, thus bringing the ehancements to life on the browsers that can handle it.

    Many AJAX api's bear some resemblance to Web Services (well, services in general) since each data request is often just a fragment of the enduser experience (Ok I know I'm not being very clear right now, but I hope you get my main points).

    i.e. the service action act_mail_check could perform many smaller actions on the server (last incomming mail, total mails, subscribed folders..), and return the results to the client dispatcher which can then pre-process the result-fragments and hand them over to the various component handlers, which in turn call their desired renderers.

    I am currently working on a new version of my WarpXML AJAX API, stay tuned for nice tutorials, articles and ofcourse open API's.
  37. I have been engaging Websphere Portal server development over two years now. Websphere Portal server is slow like hell if you develop portlet like IBM suggested, unless you have darn good machine. I have to implement AJAX/Portal combine mode to improve the performance. AJAX and Web Service sbould be good fit, does anyone has js library to use WSDL to invoke web service?
  38. AJAX not mature yet[ Go to top ]

    Please read:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp

    http://codeproject.com/useritems/LeakPatterns.asp

    One has really to think about using JavaScript for non-trivial stuff.