W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2003

Simple WS Scenarios [Was Counting Noses]

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Sat, 7 Jun 2003 10:53:54 -0500
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01817E6F@bocnte2k3.boc.chevrontexaco.net>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
cc: Hao.He@thomson.com.au

Glad to try.  This may be particularly useful because getting to
specifics may surface misconceptions on my part.

1 - There is an application resident on a Web server somewhere that I
invoke, from an application on another server, with a simple GET with
some parameters.  The service (or whatever you want to call it) does
something or other and returns a binary image (a png file) as an HTTP
image/png type. That's all it returns -- the image manufactured from
scratch using those parameters -- and that's all I need back.  One of
the two things I had difficulty with in getting this working (the other
is not relevant to this discussion and SOAP certainly would not have
helped that problem) was figuring out how to handle the binary stream of
data.  Eventually I discovered some method in the system library that
would just stream it out to a file on disk, which is what I wanted.  I
believe that my task would have been significantly more difficult if I
had also had to cope with some XML SOAP header that came along with the
image.  That SOAP header would not have done me any good whatsoever, and
I am not interested in any of the addons that it might offer (like
signing the image, for God's sake).  Streaming the header plus the
binary image to a file would definitely not have been what I wanted.

2 - We have an automated XML feed from our Help desk to a service
company.  I'm not positive how it works, but I think it just does a
simple POST and slams the XML into something that stores it as-is.  For
one reason or another that's ALL that is needed.  SOAP headers would
simply be added characters that would be thrown away, and presumably
software would have to be written to strip those headers off.

In both cases, note that the result of the "push" or the "pull" is
simply to take a defined set of data and put it somewhere.  The data are
not processed at that time.  SOAP stuff would require processing to
strip it off.  Cost with no benefit.

It sounds like Hao can probably come up with better scenarios, and I
hope he does so.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Friday, June 06, 2003 11:03 PM
To: www-ws-arch@w3.org
Subject: 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 11:54:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:20 GMT