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

Ugo,
Thank you for your reply.
I didn't know that the ws-resource approach had been submitted to OASIS,
but I have been following the evolution of Grid Services. In early 2003
I
was working on my dissertation on the relationship between OO design and
Web Services. On June 2003 I was exchanging views in the WS Architecture

group mailing list on what "Stateful Web Service Instance" and OGSI should

mean to the web service community. 
Later I was following the work of the Attribute task force. In the last
few
months I was unable to continue following those events due to 
an increased work pressure.

I still think that WS-CDL should be the right place to address such Use
Case,
because supporting it relates to the general concept of Abstraction,
of "X is instance of the classifier Y". This is a fundamental Requirement

Engineering concept, that doesn't belong only to OO.

Have a truly nice day,
Marco

>-- Messaggio originale --
>Subject: RE: Re: Use Case Proposal - Supporting the classifier-instance
relationship
>in Web Services
>Date: Fri, 7 May 2004 15:51:58 -0700
>From: "Ugo Corda" <UCorda@SeeBeyond.com>
>To: <marco.adragna@virgilio.it>
>Cc: <public-ws-chor@w3.org>
>
>
>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 Saturday, 8 May 2004 04:02:19 UTC