Debating on the usefulness of a standard description for stateful service instances applicability, creation, communication, ...

Debating on the usefulness of a standard description for stateful
service instances applicability, creation, communication,
remote-reference, call-back and lifetime.
____________

All,
The Attribute task force was formed to explore how to model a Web
service's state in WSDL. In OGSI, this map to the concept of
serviceData. CORBA IDL has attributes.
Both OGSI and CORBA also have the related concept of stateful instances.
Could it be useful to debate on the possibility of describing a Web
Service in relation to stateful service instances?  Which is the most
appropriate place for such debate?
I understand that the Attribute Task Force has other priorities. Is this
debate best kept in universities or another task force could be fit for
it? 
For example, would it be conceivable to define a standard Set of
Attributes for describing web service instance applicability, creation,
communication, call-back and lifetime management? The web services
community would then be able to specify those features in
non-application specific ways.
IMHO, object-based architecture and stateful interactions are already
used in conjuction with web services, but in custom ways (e.g. OGSI)
The object-oriented world heavily relies on the concept of instances. 
In fact, standard web services don't support:
- The concept of stateful service instance
- Object passing, neither by value nor by reference
This is what I call in my dissertation the Object-Service Impedance
Mismatch. 
Xml web services already support call-based, message-based and
resource-based architectures. Introducing the concept of stateful
service instances would offer support for the all-important object-based
architecture too. 
Stateful interaction would then become an additional web service usage
scenario.
Let me clarify what I mean with stateful interaction.
As a working definition of state of a software system  we could say that
"Is a condition that captures history of the system and influence how
the system behave in specific circumstances."[A.M. Davis - 1993 -
Software requirements]
A generic server supporting stateless interaction, process each message
on its own.
If stateful interaction is supported, each message is interpreted in
relation to a state, in a context. This context is not directly
expressed or not fully written in the message.
A stateful software system can have stateless interactions.
Today, a Web Service might be considered a stateful software system,
that support only stateless interactions. The stateful service instance
feature would allow web services to support stateful interactions. A
message sent to a web service stateful instance, would be interpreted in
relation to that instance specific state. The state of the instance
would provide the context for interpreting the message. Stateful
interactions would become an additional usage scenario, complementary to
request/response, fire-and-forget and so forth. 
With such standard support, stateful interactions and service instances
would not need to be implemented with application-specific mechanism
anymore.
As a starting point for discussion, one could use the following optional
and read-only web service attributes. The name of the property is
followed by example of possible standard values that it might assume.
1) complexityLevel
(Resource, Singleton, SetOfInstances, Multiple, Unknown)
Not all web services have the right granularity to map the concept of
Stateful Service Instances. Some web services might be to "simple" (e.g.
REST web services) other might be too complex, with Multiple stateful
processes inside them.

2) instanceIdentifierType
(ApplicationSpecific, RelativePath, NonApplicable, WSDLelement, Unknown)
3) instanceIdentifier
return the WSDLelement logically acting as instance identifier
(only if instanceIdentifierType is WSDLelement)
4) lifetimeManagementContractOffered
(ExplicitClientTermination, DeadlineWithRenewal, IndefiniteLifetime,
Unknown)
5) serverRightToRefuseNewInstanceCreation
(Yes ,No, Unknown)
6) remoteServiceInstanceReferenceSupport
(Yes, No, Unknown)
7) remoteServiceInstanceReferenceSchema
A complex type that clients can use to reference to remote service
instance (if the feature is supported) 
8) callBackSupport
...

Marco Adragna
Kellogg College
Oxford University
marco.adragna@kellogg.ox.ac.uk

Received on Wednesday, 18 June 2003 06:14:18 UTC