- From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Date: Wed, 18 Jun 2003 09:15:08 -0700
- To: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
- CC: public-ws-desc-state@w3c.org
- Message-ID: <3EF0900C.50807@oracle.com>
Savas Parastatidis wrote: >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. > > +1 --umit >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 >> >> >> >> > > > > > -- Umit Yalcinalp Consulting Member of Technical Staff ORACLE Phone: +1 650 607 6154 Email: umit.yalcinalp@oracle.com
Received on Wednesday, 18 June 2003 12:15:26 UTC