- From: Steve Graham <sggraham@us.ibm.com>
- Date: Wed, 18 Jun 2003 08:02:56 -0400
- To: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
- Cc: public-ws-desc-state@w3c.org, public-ws-desc-state-request@w3.org
Marco:
While I resonate with many of your points (I was co-author on OGSI Spec), I
must agree with Savas on one point. The discussion you raise is best dealt
with on another mailing list such as Savas suggested.
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++
"Savas Parastatidis"
<Savas.Parastatidis@newca To: <public-ws-desc-state@w3c.org>
stle.ac.uk> cc:
Sent by: Subject: RE: Debating on the usefulness of a standard description for stateful service
public-ws-desc-state-requ instances applicability, creation, communication, ...
est@w3.org
06/18/2003 07:51 AM
Marco,
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.
Regards,
--
Dr. Savas Parastatidis
Chief Software Architect, North-East Regional e-Science Centre
School of Computing Science, University of Newcastle upon Tyne, UK
http://savas.parastatidis.name
> -----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
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 08:08:42 UTC