RE: Web Service Definition [Was "Some Thoughts ..."]

Roger,

I think that you are bringing up a very good point, which has also been
highlighted in previous emails through the need for asynchronous
messaging and conversational web services.

Here is a simple use case:
Dell exposes a web service that allows partner to purchase computers.
The service is expose through a port that accepted an order document as
input and returns an invoice document at output.

That service is long-lived in the sense that it might take 4 weeks
between the time the order  received and the time dell generates and
return the invoice.

For scalability and reliability reasons, dell decides to expose that
service through both HTTP, SMTP and JMS bindings.

Also, every week, dell want to fire a progress notification requests to
the initiator/observer of this request.

For the purpose of definition, what I have described in the earlier part
of this email is called the public interface of the process/service: as
a consumer of the dell service, I do not care about the private
implementation of the process. 

This example highlights the need for the web service architecture to
support conversational semantics implemented through asynchronous
bindings.

Unfortunately, the current version of WSDL and SOAP, SOAP-RP to not
support this type of interactions and leave to much room for
interpretation and proprietary implementation of this  loosely coupled
model.

I think that it would be very useful for this group to clarify this
point. It would also be a solid foundation for standards like WSFL and
XLANG that try to standardize the private implementation of
service-oriented processes.

Edwin



-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Cutler, Roger (RogerCutler)
Sent: Thursday, February 21, 2002 1:53 PM
To: www-ws-arch@w3.org
Subject: RE: Web Service Definition [Was "Some Thoughts ..."]


It seems that people are agreeing that web services are the atomic
components from which orchestrations are made -- but that a web service
might under the covers involve the aggregation of other services as long
as it is providing a single "answer" to a single "question",  I suppose
that answer might come next Thursday or be composed of several decoupled
transmissions of information (e.g. confirmation of receipt now, detailed
response next Thursday).

That's fine, but it seems to me that the issues of orchestrations or
work flows should rear it's head somewhere in this.  The reason I say
this is that I think that there are probably desirable requirements for
web services that one may only find by considering them in the context
of such processes. For example -- and I don't claim that this is a very
good one, but I am just trying to suggest a style -- if you are talking
about a purchase process that has things like purchase orders and
invoices going back and forth, each component web service is going to
have various familiar security requirements like identification and
authorization.  "Am I really who I say I am and am I authorized to
purchase something?"  But in the context of a purchase process I think
that there is probably also a requirement that a message be unassailably
tied to a particular transaction, so that one cannot somehow pay for a
Yugo and get shipped a Cadillac.

Received on Thursday, 21 February 2002 17:32:11 UTC