Freigeben über

Ajax and Soap, again

  • Artikel

I'm flattered by all the attention my statements are getting on comparing Ajax with SOA web services.  Another one popped up over night: Dare Obasanjo  with the statement: "This is probably one of the most bogus posts I've ever seen written by a Microsoft employee."

So first off, a disclaimer: I'm an employee of Microsoft, but I do not speak for the company in any official capacity.  That said... my turn...

With all due respect to Mr. Obasanjo, a service that delivers data to a front end (whether it is for use by an Ajax page or a small rich-client app) is not a SOA web service.  I hate to have to point out the obvious, but alas, I must.  That is my point.  The fact that Mr. Obasanjo missed that point is led to the statement above.  I am not saying that Ajax cannot use SOAP.  I am not saying that Ajax should use WS_*.  I am not saying that lightweight services as used by front-ends are "bad" or "not really important."  I am simply saying that they have nothing to do with SOA.

His example is that, on his site, there is a web service that he uses to display movies in the Seattle area.  It returns XML that his Ajax page formats and displays.  Cudos. 

Now let's look at Service Oriented Architecture.  SOA is not really an Application-level concept.  It is an EAI-level concept.  SOA is not used to make front-ends talk to their back ends.  Web services can be used for this, but as I have pointed out before, simply using web services does not mean you are using Service Oriented Architecture.. 

Let's look at Service Oriented Architecture for a moment. Actually read the paper I reference.  You'll notice some statements that completely contradict the view that Ajax plays in the SOA space.  Excerpts below:

  • Precise, published specification functionality of service interface, not implementation.
  • Formal contract between endpoints places obligations on provider and consumer.
  • Functionality presented at a granularity recognized by the user as a meaningful service.

From their description, it is clear that a service that is so finely-tuned as to be useful for a front end is unlikely to be useful as a SOA service.  My statement is that, in fact, it would not be useful.  This is because, in a SOA environment, the transactions that pass between systems need to be encapsulated, fully self-describing, secure, reliable, and related to the business process in which they are involved.  This is simply too much overhead for consumption by a front-end.

Therefore, Ajax interfaces, while useful from the front end standpoint, do not need to be managed from the standpoint of discoverability, transaction management, workflow, business rules, routing, or any of the other aspects of enterprise architecture that must be applied in a SOA environment.  The original post that I objected to maintained that Ajax services would need to be managed in this way and, in fact, would tax IT departments because these services will be frequently used.  That was the disagreement that Mr. Obasanjo failed to recognize.

My position remains unchanged: Ajax interfaces escape from this level of scrutiny because they are not used to connect systems to each other... they are used to connect the front-end to the back-end. 

And that isn't SOA.

Comments

  • Anonymous
    September 09, 2005
    You know it still amazes me how so many take this new Buzzword "Ajax" and think it is some new mystical technology for each and every application. The technology to do Ajax has been around for years. Really it is just another way to dynamically update the client side of a web page. Developers have been using it for years, sometimes it is a good thing sometimes it is not. When people say Ajax I just think of Dhtml because that is all it is really doing for you, it just happens to go back to the server to get the information. I completely agree Ajax is not any way shape or form a SOA technology. Ajax by definition uses xml yes, but the technology behind it doesn't really have to use xml it could use a flat text file or an image, or anything you want really. Web developers like I said have been using this for years. Heck, netflix.com used it years ago on their star rating system on movies. Ajax was only recently coined as a buzz word. Yet nothing has changed with it, it wasn't SOA 5 years ago it isn't SOA now.
  • Anonymous
    September 09, 2005
    I'm going to risk sounding stupid, but isn't saying that "Ajax can be ignored from a SOA environment" kind of like saying that "A restaurant's kitchen can safely ignore all details as to who prints out the menus"

    Ajax is just a presentation layer; it is about making a richer UI experience within what a amounts to a dumb client (i.e. - a web browser). You would not want fancy transactions being intertwined in a Ajax implementation any more than I would want these transactions being intertwined Win32 message passing. Sure, at some level you may have Ajax driving a service, just like you might have VB code invoking SOAP or other MT objects, but it would be very silly to intertwine one's middle tier with one's presentation layer, Ajax or otherwise. The observation that Ajax and SOAP both use XML is about as relevant as the fact that a restaurant's napkins and oven mittens both use cloth (i.e. - not at all)

    Or what this pretty much what you were getting at?
  • Anonymous
    September 09, 2005
    I'd like to say, that I Agree with you that in principal Event Driven interchange patterns like Ajax aren't SOA, because I do agree.

    But more fundamentally, SOA, just like Ajax is a convenient marketing buzzword, it's a non-specific conglomeration of previously existing design principals that laughably includes in its title "Architecture". Saying that a coalition of autonomous “on-request” services is a “Service Oriented Architecture” belies the whole concept of multi-tenant distributed design that’s been around, and in practice for some time now. Architecture is a much higher bar, than using plotted “distributed” computing, to service requests in either an open, or closed framework.

    If you really want to put Ajax in its place by calling an apple an apple, then drop the SOA, and stick with distributed application architectures, and not Marketing driven title inflation.
  • Anonymous
    September 09, 2005
    > SOA is not really an Application-level concept. It is an EAI-level concept. SOA is not used to make front-ends talk to their back ends.

    Another example why SOA is a pretty meaningless buzzword. You've just stated that your personal definition of SOA doesn't include all services that an enterprise may be exposing.

    Well, that's simply your definition and not one that everyone in the industry or even everyone at Microsoft for that matters agrees with.

    By the way, the article at http://msdn.microsoft.com/architecture/soa/default.aspx?pull=/library/en-us/dnmaj/html/aj1soa.asp seemed pretty empty and in contradiction with other stuff I've seen on MSDN.
  • Anonymous
    September 09, 2005
    Hi Dare,

    "You've just stated that your personal definition of SOA doesn't include all services that an enterprise may be exposing. "

    Yep.

    "The article ... seemed pretty empty"
    The statements I quoted were directly pulled from it.

    "and in contradiction with other stuff..."

    OK. I'll bite. Find me a definitive article on SOA that would include Ajax interfaces in it's scope. I'll read it and comment.
  • Anonymous
    September 22, 2005
    "Find me a definitive article on SOA"

    Well, that's exactly the problem. SOA is far from being a technically well defined term. It means different things for different people. See
    http://www.martinfowler.com/bliki/ServiceOrientedAmbiguity.html
    for a good take on this.

    This whole discussion is just a reflection of this ambiguity.
  • Anonymous
    September 22, 2007
    PingBack from http://mai.fci-students.com/?p=4