|
Jan Algermissen wrote:
> But the question
rally is: does the client have to know
> about
the sequence of state operations in order to enable
> those
complex business processes - I just cannot see
why.
> > All that happens is that the application logic gets > hard-coded in
the client and if the process changes,
> one needs to update
the client. If the client determines
> the sequnce of
operations at runtime, changes to the
> process do not
affect the client *at all*.
Jan
I agree with you
completely. Current ideas on how to manage service choreography are based on the
idea of a "global behavioural contract" to which both service and client have to
conform. This means, as I understand it, that the choreography is hard
coded into the client. A possible alternative, as you point out, is that the client
is able to determine the allowable operations at run time. For the
same reasons as you, I think this would be much
better.
The REST approach
that you described in an earlier post, where a service publishes a dynamically
generated "menu" of available operations based on its current state, is one that
I have used a lot. I have been involved in the development of a behavioural
modelling tool (ModelScope) that is based on this paradigm. ModelScope assumes
that the client of a service is a human (rather than a client process), so that
the menu of possible next operations (events) is displayed on a graphical user
interface.
In ModelScope, the
behaviour of services is modelled using state transition diagrams, and the list
of "what you can do next" displayed to the user is generated on-the-fly by
interrogation of the service metadata (simply a coded representation the state
transition diagram of the service) and the current service state. Neither the
user interface nor the end user need to see or know the whole state transition
diagram, which is effectively private to the service. There is no global
contract to which a user of the service must conform -- the user just selects
the appropriate next operation from the generated
menu.
This paradigm works
well, and seems to me to be scalable to arbitrarily complex interactions. I do
not know why many in the SOA industry seem so keen on "global behavioural
contracts", given the apparent advantages of this kind of dynamic
approach.
You might be interested in
http://www.metamaxim.com/download/documents/DynChor.pdf which discusses some ideas in
this area.
Rgds
Ashley
YAHOO! GROUPS LINKS
|
