- From: Steve Graham <sggraham@us.ibm.com>
- Date: Wed, 18 Jun 2003 08:29:58 -0400
- To: "Jim Webber" <jim.webber@arjuna.com>
- Cc: marco.adragna@kellogg.ox.ac.uk, public-ws-desc-state@w3.org, public-ws-desc-state-request@w3.org
Jim:
Perhaps we should take this off line, but I don't see why stateful
semantics dirties SOA Model.
Further, we should tease apart the notion of stateful services. Stateful
interactions and stateful instances are two approachs. An analogy is
sessionBeans vs EntityBeans in EJB.
Now with regards services vs objects, I see no harm in this analogy.
Services are objects as far as I am concerned.
sgg
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++
"Jim Webber"
<jim.webber@arjuna.com> To: <marco.adragna@kellogg.ox.ac.uk>, <public-ws-desc-state@w3.org>
Sent by: cc:
public-ws-desc-state-req Subject: Re: Debating on the usefulness of a standard description for stateful service
uest@w3.org instances applicability, creation, communication, ...
06/18/2003 08:12 AM
[snip]
Marco:
Stateful semantics don't have to be conveyed at the interface level in the
way you suggest. In fact it really dirties the SOA model if you do. Why not
just use some kind of "activity" context (perhaps a la Web Services
Coordination) to give you "stateful" interactions without knackering the
rest of the architecture. Of course you might want to advertise that you
support these kind of "activities" but WSDL can already cope with that.
As for impedance mismatch, SOA and OO are different, and so of course you
have a mismatch. The skill is in transforming one to the other, not bodging
one to behave like the other. To paraphrase, "If all you have is classes,
everything looks like an object." But of course, now we have services too
and they certainly don't look much like objects.
Jim
Received on Wednesday, 18 June 2003 08:34:21 UTC