----- Original Message -----
Sent: Thursday, September 22, 2005 7:27
AM
Subject: RE:
[service-orientated-architecture] Is the WS- vision achievable?
Trying to achieve some synthesis
here:
* the criticism by Restifarians that the WS stack lacks a
coordination model is valid (it also lacks a "programming model" as
CORBA-heads will tell you - but the point with WS is that we do not want a
common programming model - but at the very least we do need a common
coordination model)
* OTOH I share concerns that the REST coordination model
("hypertext as the engine of application state") will not be sufficient for
complex process-oriented business transactions (as stated by Keith
Below)
* But modulo to what Keith says below - if we are to
add a new protocol layer on top of an existing application layer protocol
(HTTP) - at the very least I would say this new layer should not abuse or
contradict the lower layer. This is the point I think that people such as Mark
have eloquently and vociferously argued ("do not tunnel an application
protocol through another application protocol").
Regards,
Murray Spork
WADR, you cannot implement distributed workflow, clinical
decision support or any other such human-oriented, collaborative, dynamic
activities via an architectural style such as REST - its underlying metaphor
(what database folks would call CRUD, Create Read Update Delete) is
information-based. To support such work activities you need an
architectural style that is process-based. Much as I like the
elegance of REST, and appreciate its power, even doing CRUD on commands is
not enough to provide the semantics required.
This is what I meant in
an earlier post about the need for a new protocol layer above both comms and
applications, a "process protocol layer". Such a protocol layer will
look very different from HTTP/SOAP/etc. It will even look
different from the current attempts at such a layer (BPEL + WS-CDL), since
these languages provide no place for human involvement. IMO, a process
layer must be structured around independent process participants (what I
would call Roles, each with a private context that includes constructs of
various kinds) for activity implementation and inter-Role communication via
asynchronous multi-channel "Interactions".
Unfortunately, incumbent
vendors will struggle to support this by the usual route of re-purposing
their existing offerings - which is probably why there is no push from
standards bodies to define such a layer. We need not only a new way of
thinking but also new tools - not the same old stuff in a new box.
--
All the best
Keith
http://keith.harrison-broninski.info
David Forslund wrote:
I would find it very difficult to talk to people if I could only use
nouns. Restricting
communications to nouns seems incredibly restrictive. I know the Web
has been
very successful with a restricted set of "verbs", but the web isn't very
natural
for doing distributed workflow, clinical decision support, etc. I would
like to see
a simple REST "interface" for Workflow with the same functionality that
is in the
existing Internet standards for this service, for example. Something
that I could
send someone (or they could get from a standards body) and know exactly what
the system behavior on the other end is. Behavior doesn't involve
nouns. It involves
verbs and can involve state. If I can't have a machine readable
specification of the
system behavior of some kind, I don't think interoperability is really
achievable.
