RE: attributes & WSDL (was: Re: attributes in CORBA IDL)

Steve,

> 
> 
> FWIW, I do not agree with the statement that "these mechanisms" make
WSDL
> like a C++ header file, nor do I share Jim's concern that this is a
threat
> to encouraging innappropriate "granularity".  Designers will choose
> granularity to suit their problem needs and their personal design
styles.
> Designers will use WSDL 1.1, as it is, without "these mechanisms" to
> produce both fine grained interactions and coarse grained
interactions.
> 
> I do not support the notion of moving WSDL away from the "idl for web
> services".
> 
> Lastly, the notion of using context to "rehydrate state" is
appropriate
> for
> SOME interactions, but not all.  When there is significantly
sophisticated
> state that we are modelling, such as commonly found in "systems
> management"
> or "resource management" then using context to pass this around is NOT
> appropriate.  Stateful entities and stateful interactions both are
> legitimate approaches that we need to celebrate here.  Having only one
> approach or the other is NOT acceptable for all approaches.
> 


As the WS-Arch document discusses, the Web Services architecture is
stateless. Obviously, there is a clear need to model "stateful
interactions" with a _service_ (a software component that according to
the architecture is stateless). In the Web services community this is
done through context exchange (WS-Coordination, WS-Transactions, OASIS
Business Transactions Protocol, or BPEL Correlations). A context does
not carry all the state with it. It's a way for the involved parties to
recreate their understanding of what that state is.

Now, what is a "stateful entity"? If by "stateful entity" you refer to a
service that encapsulates some state and provides an interface to that
state, then why not call it an "object"? If we start talking about
objects, though, then we are in O-O territory and we are diverging from
SOA. In object-orientation architectures, emphasis is on interface
design with no concern on the structure of state (usually private to the
object). I believe that SOA encourages document structure, message
definitions, message exchange patterns, and interface design to be
treated as being equally important. Also, SOA assumes software
components that are not stateful.

So, is it the case that you wish to expose this "sophisticated state"
through a service interface? Does this mean that each time that new
state is created a new service instance will have to be created as well?
(BTW, I believe this is the OGSI model). Again, this is too close to
object-orientation.

Could you, please, provide us with an example where existing Web
Services mechanisms are unable to model the "sophisticated state"?

Regards,
.savas.

Received on Thursday, 17 July 2003 10:18:40 UTC