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

Marco,

The Use Case you describe sounds like something that could also be
addressed by the Web Services Resource Framework (recently submitted to
OASIS - see
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf ). Do
you happen to know the WS-RF specs? If you do, do you still think there
are reasons for preferring the WS-CDL approach?

Thank you,
Ugo

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of 
> marco.adragna@virgilio.it
> Sent: Friday, May 07, 2004 6:36 AM
> To: steve@enigmatec.net
> Cc: public-ws-chor@w3.org
> Subject: Re: Re: Use Case Proposal - Supporting the 
> classifier-instance relationship in Web Services
> 
> 
> 
> Steve,
> 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.
> 
> 
> 
> USE CASE - LEVERAGING ON EXISTING INVESTMENT ON OO COMPONENTS
> 
> 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.
> 
> Typically:
> - a ComponentParent WSDL for creating, finding and lifetime-related
>   operations.
> - 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
> marco.adragna@virgilio.it 
> 
> 
> ________________________________________________________
> (Steve's email...)
> 
> >Marco,
> >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.
> >
> >http://www.w3.org/TR/2004/WD-ws-chor-reqs-20040311/
> >
> >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
> >www.enigmatec.net
> >
> >
> >On 16 Sep 2003, at 09:23, marcoadr@tin.it wrote:
> >
> >>
> >> I have a Use Case to propose for consideration.
> >>
> >> INTRODUCTION
> >> 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 18:52:37 UTC