RE: Counting noses on "is SOAP and/or WSDL intrinsic to the def i nition of Web service"

> -----Original Message-----
> From: Cutler, Roger (RogerCutler) 
> [mailto:RogerCutler@chevrontexaco.com]
> Sent: Friday, June 06, 2003 12:33 PM
> To: Hao He; Christopher B Ferris; www-ws-arch@w3.org
> Subject: RE: Counting noses on "is SOAP and/or WSDL intrinsic to the
> defi nition of Web service"
> 
> 
> 
> I agree with Hao -- there are a lot of practical cases where the extra
> features of SOAP are just not necessary, and the SOAP stuff just extra
> overhead, or branding perhaps, that actually has a negative effect
> because you are now forced to use software that understands it.  That
> may be something that looks good to a software vendor, but 
> not really to an end user.

It would be useful to have a usage scenario that illustrates this so we can
really come to grips with it.  I think the +10 advocates would say that SOAP
1.2 can sortof "fade into the wordwork" in situations (e.g. the RESTful GET)
where its format is not necessary but the processing model and *potential*
for headers and intermediaries is present.

The real advantage of putting SOAP into the core definition of the scope of
WSA is that it allows those simple "GET/POST an image" applications to
gracefully accomodate new requirements.  For example, what happens when the
service's requirements/features expand and you need to add transaction
support (e.g., POST a bunch of pictures separately and get them combined
somehow, all or nothing), encryption that works all the way from client to
server, or any of the other features that people are defining SOAP headers
to handle are added?  I suspect we will want to reference the SOAP model of
just adding new headers, not say something vague like "there's all sorts of
things you could do ... SSL ... WS-Security ... blah blah blah".  

So, again I don't want to say that something like photos.yahoo.com with
formally defined interfaces is not a "web service" in some ontological
sense, but I don't want to have to keep waving our hands over every little
thing that comes up and say "you could do this, you could do that, or you
could use SOAP headers."  I want to just say "use the freakin' SOAP headers,
dammit!" :-)

Users can do what every looks good to them, but I think we want to offer
clear architectural advice like "when the going gets tough, the tough create
a TC to define a new SOAP header and applications/intermediaries that
understand them."  That requires us to put SOAP in a very special place in
the WSA, however we weasel-word it.

Received on Saturday, 7 June 2003 00:02:41 UTC