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

('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.