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

As an adjacent perspective and perhaps a different one, Id like to point to
a paper that distinguishes webservices from other types of distributed
computing such as CORBA and J2EE but yet seems to suggest the same
ActivityService model from OMG that J2EE's is built upon. Quote:
The flexibility offered by the Activity Service is particularly desirable in
the Web Services world, where the sphere of distribution extends beyond
individual enterprises. This change in scope places additional requirements
on systems used to support these services. In particular, while Web Services
demand reliability, they also require flexibility in how it is attained. We
expect the need to support this flexibility to stimulate new extended UOW
models - models which could be supported by a standard framework such as the
OMG/J2EE Activity Service. Further, we believe that individual Web Services,
and the infrastructure software used to support them, will often rely
heavily on distributed object technology, including the OMG/J2EE Activity
Service. (Many vendors have already extended their existing distributed
object platforms to include support for both Web Services and the Activity
Service). The communication between Web Services (or between an application
and the Web Services it uses), however, will not be based on the distributed
object communication model of CORBA or J2EE. Rather, as existing Web
Services standards define, interactions across the web will be
SOAP/XML-message-based, and instead of a remote CORBA IDL or Java interface,
a WSDL specification is required. Message communication is different from
(distributed) object communication in that a different binding model, a
different timing model (in particular, synchronous versus asynchronous
communication), a different life-cycle dependency model (required
availability versus tolerance of non-availability of an object/service at
connection- and/or run-time), and a different arity in communication
partners (one-to-one versus one-to-many) is possible.

Reliability of Composed Web Services

>From Object Transactions to Web Transactions

Thomas Mikalsen, Isabelle Rouvellou, Stefan Tai

IBM T.J. Watson Research Center, New York, USA

{tommi, rouvellou, stai}@us.ibm.com

The url is:
http://www.research.ibm.com/AEM/pubs/web_services_oopsla2001.pdf

Now, perhaps someone knows of a WSFL-implementation, ready to test?

/Thomas

----- Original Message -----
From: "Edwin Khodabakchian" <edwink@collaxa.com>
To: "'Cutler, Roger (RogerCutler)'" <RogerCutler@chevrontexaco.com>;
<www-ws-arch@w3.org>
Cc: <doron@collaxa.com>
Sent: Thursday, February 21, 2002 11:31 PM
Subject: 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 Tuesday, 5 March 2002 01:08:44 UTC