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

Marco,

Many thanks for contributing your use case, and a million apologies for the
delay in responding.

We discussed your use case during our telecon on 30th September and I had an
action point from that meeting to follow up with you. We need further
clarification on your use case. We made some interesting observations from
your use case, but we found it hard as a group to work out any precise
requirements on a choreography language. 
It was not clear if the use cases demands certain constructs in a
choreography language, or was merely illustrating some interesting uses and
patterns. So any clarification, esp. w.r.t to our latest use cases
refactoring [1] would be very useful to us.
You can read the minutes at [2] for details of the discussion.

We look forward to any clarification you may wish to provide.

Cheers,
  Martin.



[1] http://lists.w3.org/Archives/Public/public-ws-chor/2003Nov/0004.html
[2] http://www.w3.org/2002/ws/chor/3/09/30-minutes.html 


> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of marcoadr@tin.it
> Sent: Tuesday, September 16, 2003 9:24 AM
> To: public-ws-chor@w3.org
> Subject: Use Case Proposal - Supporting the 
> classifier-instance relationship in Web Services
> 
> 
> 
> 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
> marco.adragna@kellogg.ox.ac.uk
> 
> 
> 
> 1__INSTANCE-SET USE CASE
> 
> 1.1__ACTORS
> 
> Parent 		- A Parent is a Web Service allowing 
> users to perform operations
> that relate to
> a set of Instances.
> Typical operations that a Parent COULD support are: 
> a)the Addition of a new Instance to the set 
> b)the LookUp of an existing instance using business data, 
> primary keys or other meaningul information
> 
> Instance 	- Each Instance belonging to a given set is a 
> web service
> sharing the same service description (WSDL Interface), 
> and maintaining a private state that differentiate it from the others.
> 
> Parent and Instance are two roles a Web Service can play in 
> an Instance-Set Choreography. A Web Service playing the 
> Instance role SHOULD semantically represent an Instance Of 
> its Parent Web Service.
> 
> User 		- a software system that wish to consume web 
> services that are in
> a relationship of 
> classifier/instance with each other.
> 
> 
> 
> 
> 1.2__DESCRIPTION
> 
> This use case allows providers to express and Users to consume 
> two or more web services that are in a classifier/instance 
> relationship with each other.
> 
> Drawing a parallel with object orientation we could associate:
> Parent 						--> Class
> Instance					--> Object
> 
> Parent   WSDL Interface 			--> Class 
> methods  (i.e. Static methods)   
> Instance WSDL Interface 			--> Object 
> methods (i.e. Instance methods) 
> 
> Addition of a new instance to the set 		--> 
> Firing the Constructor method
> of a class
> Parent without support for new instance creation--> Singleton pattern
> 
> 
> 
> 
> 
> 
> 1.3__PRECONDITIONS
> 
> The User MUST be aware of the Instance-Set choreography
> 
> 
> 
> 1.4__TRIGGERING EVENT(s)
> 
> 
> 1.5__POSTCONDITIONS
> 
> 
> 1.6__FLOW OF EVENTS
> 
> 1.6.1__BASIC FLOW
> 
> A user might exchange a sequence of messages that logically 
> begins with obtaining an identifier of a new Instance from 
> its Parent and
> 
> ends either when the private state of that Instance is 
> reclaimed or when the User's copy of the Instance Identifier 
> is destroyed. 
> 
> 
> 
> 1.6.2__ALTERNATE FLOW
> 
> A user might exchange a sequence of messages that logically 
> begins with obtaining an identifier of an existing Instance 
> from its Parent and 
> ends either when the Private State of that Instance is reclaimed 
> or when the User's copy of the Instance Identifier is destroyed. 
> Such existing identifier might be obtained via LookUp 
> operations provided by the Parent.
> 
> 
> 
> 1.7__RELATED USE CASES
> 
> 
> 1.8__NOTES / ISSUES
> 
> With "User's copy of the Instance Identifier" we tipically 
> refer to a local copy of 
> the WSDL document of a remote Instance
> and to any proxy object built using it.
> Other types of instance identifiers could be considered.
> 
> The addition of a Factory role should be considered.
> 
> No assumption are made on how an instance maintain its private state.
> 
> When the "Private State of an Instance is reclaimed" the 
> history of interaction of such Instance is lost. The Instance 
> return to a state that correspond to a newly created 
> instance. The private state of that Instance is lost. Such 
> event might occour to allow resource pooling at the 
> implementation level and to limit resource consumption of the 
> provider.
> 
> A user might possess an Identifier to an Instance of which 
> the private state has been reclaimed. 
> A fault condition MUST be generated by messages being sent to 
> such Instance.
> 
> Users MUST be able to handle such fault.
> Parent and Instances MUST cooperate in avoiding such fault to 
> ever occour
>

Received on Thursday, 13 November 2003 14:09:28 UTC