W3C home > Mailing lists > Public > public-ws-desc-state@w3.org > June 2003

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

From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Date: Wed, 18 Jun 2003 12:51:56 +0100
Message-ID: <BC28A9E979C56C44BCBC2DED313A447001D755A6@bond.ncl.ac.uk>
To: <public-ws-desc-state@w3c.org>


Although I strongly disagree with most of your arguments, I feel that
such discussion should take place at a different mailing list (perhaps
www-ws@w3.org or www-ws-arch@w3.org). The WSDL specification talks about
_how_ to write WS interfaces and not about what those interfaces are.
Additionally, the WSDL specification says nothing about the behavioural
semantics of the components for which the interfaces are written.

Perhaps the others in this mailing list have a different view.

Dr. Savas Parastatidis 
Chief Software Architect, North-East Regional e-Science Centre 
School of Computing Science, University of Newcastle upon Tyne, UK 

> -----Original Message-----
> From: marco [mailto:marco.adragna@kellogg.ox.ac.uk]
> Sent: Wednesday, June 18, 2003 11:14 AM
> 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
> 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
> debate best kept in universities or another task force could be fit
> it?
> For example, would it be conceivable to define a standard Set of
> Attributes for describing web service instance applicability,
> 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
> 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
> "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
> 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
> feature would allow web services to support stateful interactions. A
> message sent to a web service stateful instance, would be interpreted
> 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
> request/response, fire-and-forget and so forth.
> With such standard support, stateful interactions and service
> would not need to be implemented with application-specific mechanism
> anymore.
> As a starting point for discussion, one could use the following
> 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"
> REST web services) other might be too complex, with Multiple stateful
> processes inside them.
> 2) instanceIdentifierType
> (ApplicationSpecific, RelativePath, NonApplicable, WSDLelement,
> 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 07:53:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:54 UTC