- From: <marco.adragna@virgilio.it>
- Date: Fri, 7 May 2004 15:35:31 +0200
- To: steve@enigmatec.net
- Cc: public-ws-chor@w3.org
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 09:38:20 UTC