OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Doing Web services right

[ Lists Home | Date Index | Thread Index ]

Mike Champion wrote:

>> CGI defines an interface between applications/scripts and websevers. 
>> It has nothing to do with the Web's client/server contract; that's 
>> defined already by HTTP/SMTP/FTP and so on.
> 
> 
> Sorry, I just don't buy that.  For GET (and PUT/DELETE in theory but not 
> widespread practice) HTTP defines a reasonable and useful contract.  But 
> much of the real Web that really works is a bunch of arbitrary stuff 
> POSTED from HTML forms or whatever, and the "CGI" details are the 
> interface that matters if you are writing a form to work with existing 
> back end code or back end code to process a form. My point was that this 
> interface is no more late bound than a "Web service".

I'm not saying CGI isn't real or important. Just that it's 
incidental to client server contract (POST is not incidental). Where 
CGI matters, 'architecturally', is hooking up back-end apps and 
scripts to web servers, not clients to back end apps.


>> The difference is that most (all?) successful Internet systems are 
>> keyed off protocols. As protocols they have semantics that make them 
>> distinct from the 'protocol neutral' architecture implied by 
>> SOAP/WSDL; something imvho needs to downgraded to 'transport neutral' 
>> in the long term - there ain't no getting away from protocols if we're 
>> serious about interoperating applications.
> 
> That is the REST dogma, and I buy it as far as the synergy between HTML 
> links and HTTP GET is concerned.  

I don't think it's REST dogma (but I may be wrong there). All I'm 
suggesting is that it's (imho) good that SOAP gets you transport 
neutrality. I'm less sure about protocol neutrality (being that it's 
true for SOAP, or desirable for SOAP based apps).


> And as far as 'transport neutral' is concerned, I very strongly suspect 
> that many successful websites are forwarding that information collected 
> over HTTP (by GET, POST, or whatever) to backoffice systems that are 
> linked by all sorts of proprietary protocols that most of us have only 
> the dimmest awareness of. 

Sure. But it's a good thing that the details of people's backend 
systems are hidden by behind protocols and shared data formats 
rather than API gateways, because it drives you towards dataflow 
architectures.

You wouldn't want to go from this:

client [--protocol --] server [-- gateway --] backend


where there are preserving transformations of data along the way, to 
this:

client [--] [------------ gateway -------------] backend


in other words, what we want are dataflow architectures to work 
their way in from the Internet to the systems code, not for the 
systems code and associated idioms (including object oriented 
programming) to spill out across the Internet. Think of it as the 
retreat from Moscow after a few terrible winters in the API wars - 
working from code outwards is what we know doesn't work so well for 
application integration and is precisely backways methodologically.

Integration becomes more a matter of data and transformations, and 
less a matter of APIs and function calls.

  Especially so in a world where the backend and the clients are own 
by different people. For n-tiered system we now have to push the 
code back to where it belongs

What SOAP seems to offer that is valuable, is a way for web servers 
to act as connectors for backend systems. So this:

client [---------protocol ----------]  server [--] backend


might be a better description of its practical if not quite 
architectural significance.

In other words using SOAP gets us two (at least) useful things. 
First it can help eradicate bogus exposures of code-faces in check, 
second it allows a dataflow to move across different transports. But 
it does not remove the need for protocols, data, and transformations.

Note that we still want all the OO and procedural goodness when it 
comes to building the applications themselves and extending them 
(via plugins and whatnot).

Where clients are other backends, you have:

[backend-] ws client [--- protocol ---] ws server [-backend]


Thus my issue with comparing SOAP with CGI as in the same style 
architecturally, sorry it's not shorter.

The dogma I see comes in two forms. One, when people say you don't 
need SOAP/WSDL at all, that it has no architectural value or 
significance for application integration over an d above the Web. 
Two, when people say you can blow out the data formats from the 
code, the tools will take care of it. (there's a huge amount of 
misunderstanding on the ground on how to use and build a WS. WS are 
not about sending a Java linked list to a Perl script using SOAP as 
a serialization and HTTP POST as the delivery mechanism, but you 
wouldn't know that from some fora).


> The whole point of SOAP for many such users is 
> indeed to "get away from the protocols" and just ship the data around 
> without regard to language, platform, or vendor, or the underlying 
> protocol.  That's what XML is good for, and why the Web services people 
> latched onto it. [much to the annoyance of Mr. St. Laurent and Mr. 
> Harold :-) ]

The thing is, to do anything interesting, are the users being 
burdened with reinventing protocols? As Geoff Arnold pointed out 
recently, API and protocol design require very different mindsets 
and approaches. Just shipping data around, really means just 
shipping data around /with/ service level agreements. For example 
reliable delivery is becoming a hotspot where WS vendors are happy 
to compete on specs+tools (granted it's a step up from apis+tools), 
for now. Maybe it's too early to standardize, or maybe the thinking 
is that layers over SOAP/WSDL are valuable enough not to 
commoditize. But I do feel claims about protocol neutrality are 
borrowing trouble.

Bill de hÓra





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS