W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2004

Re: Re: Use Case Proposal - Supporting the classifier-instance relationship in Web Services

From: <marco.adragna@virgilio.it>
Date: Fri, 7 May 2004 15:35:31 +0200
Message-ID: <408712C90001F18F@ims6b.cp.tin.it>
To: steve@enigmatec.net
Cc: public-ws-chor@w3.org

Thank you for letting me know abouth the new requirement document.
Sorry for responding with such delay, I wish this was part of my job but
it isn't, so a brief morning session was all I could dedicate to it.
On the other hand, it was a job-related need that first got me thinking
to a Classifier-Instance choreography. Here I shortly describe such
common business situation.
I have read the new requirement document: my Use Case might contain
some additional requirements. Unfortunately I am unable to formally
express such reqs. All I have is a gut feeling that something might
still be missing, but I am unable to point my finger to it.
Thank you for taking the time of examining my not-so-clear Use Cases(!)

Marco Adragna
Senior Consultant
ItaliaLavoro, the technical agency of the Italian Ministry of Work.


A Company wants to make it easier to expose the functionality of
existing OO components as XML web service.
The goal is to minimise the need of writing component specific code,
whilst still exposing fully functional and truly standard web services.
Those components have been developed using different technologies,
purchased from different vendors.
Some OO components offer a very coarse grained functionality and are
relevant to business processes carried out both internally and
externally to the Company.
Vendors provide tools capable of creating a WSDL remote interface from
OO components written following certain rules. (e.g. a properly written

stateless session bean in J2EE or 
System.Web.Services.WebService class in .Net)

The problem is that a generic (vendor-neutral) web service client is
unable to get complete information on how to use those components merely
by reading such WSDL document.Furthermore, too many components can't be
exposed as web services or need a lot of custom coding to do so.
Components are not web services: they typically need to be instantiated
before they can be used, instances need to be addressable via a form of
remote reference, instances have lifetime.
It is impossible to express such needs using WSDL, hence generic web
service clients can't know how to correctly use those
OO-component-powered Web Services.

The solution is writing vendor-specific tools that can "process"
a generic OO component, creating 2 WSDL and a WS-CDL.
Those act as a "more intelligent" remote interface.
An instance of a WS-CDL described choreography provides the context
in which a transient ComponentInstance can begin, do stuff and end.

- a ComponentParent WSDL for creating, finding and lifetime-related
- a ComponentInstance WSDL with the business logic.
- a WS-CDL specifying in which sequence the two should be used by one
  or more Users.

The basic steps of the interaction are listed below:
1- 	User requests ComponentParent a channel to a new ComponentInstance.
	(This is marked as Choreography Initiator in the WS-CDL)

2- 	User interacts with ComponentInstance via the channel.

3- 	Other Users might join in, obtaining the channel of the existing
	ComponentInstance via lookup services provided by ComponentParent,
	and then interacting with such ComponentInstance.

4-	Users stop interacting with the ComponentInstance. Such specific
	ComponentInstance is no longer useful. (The complete condition of
	the WS-CDL evaluates to true. The Choreography ends.)

Marco Adragna

(Steve's email...)

>We have a new requirements document on the W3C website and wanted to
>check if this covered you requirements in the use case you submitted
>sometime ago.
>Could you take a look and let us know.
>Best Regards
>Steve Ross-Talbot
>Chair W3C Web Services Coordination Group
>co-Chair W3C Web Services Choreography Working Group
>O: +44 207 397 8207
>C: +44 7855 268 848
>On 16 Sep 2003, at 09:23, marcoadr@tin.it wrote:
>> I have a Use Case to propose for consideration.
>> Composition languages allow the creation a new web service from
>> existent
>> ones.
>> This define an aggregation/part relationship between the new
>> composition
>> and the individual web services that compose it.
>> In requirement engineering both the aggregation/part and the
>> classifier/instance
>> relationships are fundamental "tools"
>> in structuring Problem Analysis and Behavioural requirements.
>> The process of turning a problem analysis into a working software
>> solution
>> can be simple only if the
>> software technology used to implement such solution supports the
>> fundamental
>> "tools" of problem analysis.
>> Web services arguably lack of a complete support for expressing
>> classifier/instance
>> relationship among them.
>> With the following use case, I hope to contributes to the support for
>> the
>> classifier/instance relationship in Web Services.
>> Regards
>> Marco Adragna
>> ......
Received on Friday, 7 May 2004 09:38:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:24 UTC