RE: Simple WS Scenarios [Was Counting Noses]

ok, here is our view about XML HTTP service (Mike's language):

A service pattern is classified as simple and complex according to the
degree of complexity of request from the client side. Note that this
classification is relative without any absolute distinction between simple
and complex request. 

From the server side, the service is characterized by the following:
1. The availability of results: synchronous or asynchronous. 
2. Results delivery methods for asynchronous results: push or pull.

With this classification, we classify common service types:
1. Simple query type.  A client sends a simple query, which consists of a
small number of parameters, to a server, which returns query results.  Those
parameters together with their values can be used as a locator of query
result. Such a query does not cause any changes on the server side. This is
a simple-request-synchronous service or a simple-request-asynchronous
service.
2. Complex query type. A client sends a complex query, which consists of a
large number of typed parameters, to a server, which returns query results.
There are additional relationships and constraints among those parameters.
Those parameters may not be used as a locator of query result. Such a query
usually needs additional work on the server side to validate the query. This
is a complex-request-synchronous service.
3. Processing type. A client sends a complex message usually in XML together
with links to other resources, to a server, which needs to process the
message and take other necessary actions in order to return a message. This
MEP usually causes side effects on the server, usually by means of creating
new resources. This is usually a complex-request-asynchronous service. 
4. Notification type.  A server sends notifications to subscribed clients.
This type of MEP is much less frequent than other types.

Hao


-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com]
Sent: Sunday, June 08, 2003 1:54 AM
To: Champion, Mike; www-ws-arch@w3.org
Cc: Hao He
Subject: Simple WS Scenarios [Was Counting Noses]


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.