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

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

From: <marcoadr@tin.it>
Date: Tue, 16 Sep 2003 10:23:45 +0200
Message-ID: <3F646FC700001928@ims3b.cp.tin.it>
To: public-ws-chor@w3.org

I have a Use Case to propose for consideration.

Composition languages allow the creation a new web service from existent
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.

Marco Adragna



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


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


The User MUST be aware of the Instance-Set choreography





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. 


A user might exchange a sequence of messages that logically 
begins with obtaining an identifier of an existing Instance from its Parent
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.



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
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 Tuesday, 16 September 2003 04:24:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:12 UTC