September 9, 2005
@ 02:54 PM
Comments [5]
The Connection Between XML Web Services, Service Orientation and AJAX

Dion Hinchcliffe wrote a blog entry entitled State of Ajax: Progress, Challenges, and Implications for SOAs  which did a good job of pointing out the [somewhat obvious yet not so obvious] link between web services and AJAX. For those who don't have time to wade through his entire post, the key bit is

Lightweight SOAP and REST services are in and WS-* services may be on the rocks. Since Ajax applications can and will frequently call backend XML web services as the user interacts with the front-end, having lightweight, easy-to-consume, high performance/availability SOAP and REST web services will only become more important. Of course, the implication is that since Ajax applications live in a fairly austere JavaScript sandbox, this means heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers. This doesn't mean WS-* is broken for Ajax, but at this time there are no Ajax frameworks yet that support more than basic SOAP service interaction.

There's some stuff I agree with here but a lot I don't. Personally I think even lightweight SOAP services are out in the AJAX world. As it stands, lots of AJAX developers are trying to eschew the overhead of XML for the simplicity of JSON let alone the overhead and complexity of SOAP. The fact is that most AJAX applications talk to lightweight REST services with either XML or JSON being the wire format.

This is yet another example of the dichotomy between providing services for the Web and building services for using within an enterprise's intranet.

Surprisingly, it seems some people fail to acknowledge this dichotomy. One of these people is Nick Malik who in his recent post On Atlas/Ajax and SOA stated

I ran across a blog entry that attempts to link Atlas/Ajax to SOA.  What absolute nonsense!
...
So what's wrong with having a browser consume enterprise web services?  The point of providing SOA services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application(s).  SOA operates at the integration level... between apps.  To assume that services should be tied together at the browser assumes that well formed architecturally significant web services are so fine-grained that they would be useful for driving a user interface.  That is nonsense.

For an Atlas/Ajax user interface to use the data made available by a good SOA, the U/I will need to have a series of fine-grained services that access cached or stored data that may be generated from, or will be fed to, an SOA.  This is perfectly appropriate and expected.  However, you cannot pretend that this layer doesn't exist... it is the application itself!

In a nutshell, the distinction is in the kinds of services provided.  An SOA provides coarse-grained services that are self-describing and fully encapsulated.  In this environment, the WS-* standards are absolutely essential.  On the other hand, the kinds of data services that a web application would need in an Atlas/Ajax environment would be optimized to provide displayable information for specific user interactions.  These uses are totally different. 

This is probably one of the most bogus posts I've ever seen written by a Microsoft employee. As Nick points out, the point of providing services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application.

For example, my Seattle Movie Finder web page is powered by a RESTful web service which gives it information about movies currently playing in the Seattle area. The URL http://www.25hoursaday.com/MovieFinder/MovieFinder.aspx?showall=1, gives me an XML list of all the movies currently playing in my neighborhood. The web page is an AJAX application that consumes this service. This information could also be consumed by a smart client on a desktop or another service which augments the data (e.g. merges in the movie critic ratings to the various movies before sending to an end user). Claiming that because this service doesn't use the various WS-* technologies and is being accessed from a web browser somehow makes it illegitimate is just plain ridiculous.

Furthermore, it is quite likely that the various services that are used to gather this information aren't RESTful. However what works within the intranet isn't necessarily what works on the Web.

An interesting challenge I've faced at work is convincing some of the developers on my team that just because we use SOAP for the services we use internally, this doesn't mean we may not use alternate appproaches for Web facing services. This issue first came up when we decided to go with the MetaWeblog API as the blog editing API for MSN Spaces and I'm sure it will keep coming up.

When you have a hammer, everything looks like a nail. SOAP/WS-* are not the answer to every problem and just because they can't be used in a particular problem space doesn't mean that problem space any less valid than others. The sooner people understand the dichotomy that is intranet vs. internet service development, the better.


 

Categories: Web Development | XML Web Services

« MSN Sessions at the Microsoft Profession... | Home | More Details on MSN Developer Announceme... »
Friday, 09 September 2005 16:22:17 (GMT Daylight Time, UTC+01:00)
XMLHttpRequest and the "Same Origin Rule" make XML/SOAP and the WS-garbage a NO-NO in AJAX.

It makes absolutely no sense to comunicate XML/SOAP within the boundaries of your own application.

If your server needs to connect to the outer world, then yes, use XML/SOAP, REST, CORBA, CSV or EDI, who cares?
But once the server gets the data, massage it and make it easier for the javascript client to consume it.

In that territory, nobody beats JSON and eval(). Maybe E4X will make it easier for XML adoption, but make no mistake, JSON r00lz.


GeorgeN
Friday, 09 September 2005 22:02:18 (GMT Daylight Time, UTC+01:00)
Hmm, but what is in and what is out? After all, the browser isn't even the only Javascript container around. I could easily use Konfabulator or something like that to frontend the services that was originally written for another client.

I agree with Dare, there will be different classes fo services, that are implemented using different stuff, but the distinction will have less to do with where you put them on your map of applications (which will be an increasingly irrelevant view over time) and more to do with the qualities that you desire in that connection. It is true that the qualities and the architectural position are related, but the real issues are things like what security model, how reliable, how much shared state... etc.
dsholler
Saturday, 10 September 2005 00:56:47 (GMT Daylight Time, UTC+01:00)
Complex SOAP and WS-* based web services aren't out, for the record, but I don't think that was anyone's point. I agree with yourself and Nick that they're at odds with Ajax though. They're simply too overly complex for the requirements of Ajax as it exists today, although as we see more enterprise-level frameworks automating low-level Ajax development and allowing for greater feature support with less plumbing effort, that may start to change.

I do believe there is a distinction though between enterprise web services and it's more casual cousins. Enterprise-level services that take full advantage of technologies such as WS-* are meant to be integrated into likewise enterprise-level applications, which may in turn expose a simplified web service for Ajax-based interfaces.

Examples of the former may include services that provide warehousing operations for a world-wide freight provider. Such an implementation is very targeted, has specific requirements, and will could make full use of WS-* services. I see the latter as more of a translation layer in large applications or as a means to provide lightweight functionality to off-hours development projects and other solutions that are either small-scale or broad in context, as opposed to being consumed by properly authorized and secured business layers in the enterprise space. Of course I'm stereotyping, as there's lots of grey area, and it comes down to intent.

I don't think you're arguing with Nick on the same level that he's speaking, and I think Nick is using some definitions that, if not definied similarly by a reader, could lead to argument. It's not so much that Ajax and SOA are at odds, but that Ajax and enterprise-level SOA are at odds, given certain definitions of "enterprise-level SOA". Service orientation for general consumption is different than service orientation for enterprise consumption, and I don't think anyone is arguing that. You both seem to make statements to support that view. You both seem to support the view that Ajax is trending toward (your view) and more applicable to (Nick's view) fundamentally simpler protocols. You both seem to understand the difference in the various implementations of web services based on services being rendered and the intended consumers.

I think the original blogger (Dion) needs to rethink his view on the relationship between Ajax and SOA. But as to you and Nick, maybe you're arguing the same thing in different contexts?
Michael
Monday, 12 September 2005 23:33:35 (GMT Daylight Time, UTC+01:00)
Could explain when SOAP is actually prudent? Everyone seems to argue that SOAP is good for "enterprise level" applications. What is it about enterprises that they prefer complexity?
pwb
Friday, 23 September 2005 00:09:28 (GMT Daylight Time, UTC+01:00)
They don't "prefer complexity", but they often require it. For those who want to reinvent the wheel when it comes to building a foundation of services such that SOAP and WS-* provide, tailored to your specific enterprise needs, that's great. But SOAP, WS-*, and other technologies provide a well-known, standards-based framework that both ISV's and corporate app developers can design and code against. They certainly doesn't make things plug-and-play all by themselves, but they allow teams to focus on interoperability issues at a level some degree closer to the domain of the business. They also allow for a new generation of development and EAI tools that have an amount of interoperability built-in.

Another point... I don't ever want to implement SOAP or WS-* myself, but I think it's awesome that Indigo does. This ties back to the discussion in favoring simplicity in services designed for AJAX, since I might actually have to figure out how to parse that myself, and the communication between a UI layer and a service is generally pretty light on advanced feature needs. But in enterprise web service environments, where you're implementing a complex web service that will connect to an apps domain layer, complexity is great, since the framework I'm coding with (Indigo, for example), will parse all that stuff for me and expose it more coherently through the framework's API.

I guess my second point there is that there's a key difference between "parse it yourself" JSON and XML-RPC, and "pipe it through a tool or framework" SOAP and WS-*. Again, I'm stereotyping, but it's an insightful way to look at it.
Michael
Comments are closed.