- From: marco <marco.adragna@kellogg.ox.ac.uk>
- Date: Wed, 18 Jun 2003 12:14:06 +0200
- To: <public-ws-desc-state@w3.org>
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