W3C home > Mailing lists > Public > public-ws-chor@w3.org > September 2003

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

From: Marco Adragna <marco.adragna@kellogg.oxford.ac.uk>
Date: Tue, 16 Sep 2003 09:09:34 +0100 (BST)
To: public-ws-chor@w3.org
Message-Id: <E19zAty-00032V-00@wing6.herald.ox.ac.uk>
('binary' encoding is not supported, stored as-is) I have a Use Case to propose for consideration. Regards Marco Adragna 16 September 2003 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. 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. A Parent might refuse to create new Instance for lack of resources or lack of User priviledges. Users MUST be able to handle such refusal. Received on Tuesday, 16 September 2003 04:11:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:30 GMT