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

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