- ... 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 bothMessage 1 of 91 , Sep 30, 2005View SourceJan 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*.JanI 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.RgdsAshley
- Hi Robin, The discussion thread had inclined me towards layers (not to be confused with tiers, which run at 90 degrees). A layered architecture (orMessage 91 of 91 , Oct 8, 2005View SourceHi Robin,
The discussion thread had inclined me towards layers (not to be
confused with tiers, which run at 90 degrees). A layered
architecture (or meta-architecture, if we are talking about standards
for standards, as in the case of the ISO OSI 7 Layer Model for
comms.) does two things:
Enables certain suggestions to be immediately seen as tunnelling, and
thus deprecated. Tunnelling is always the result of expedience, and
never of strategic design.
Layering facilitates economic vertical disintegration amongst
suppliers, which is a 'good thing'.
In as much as I accept that we are not talking solely about a
software deliverable here (there are also patterns to be fostered,
and culture changes to be evangelised) then I agree with you whole
Also, I think there is always a 'layer view' of things, so in this
case I guess you are answering my rhetorical question in it's own
terms by saying "It doesn't live just there!". Well, I was open to
that answer, as you might have detected from my tone.
It leaves me at a bit of a loss, though. As a designer, I expect to
proceed from knowing what it is people want to be able to do, but
can't do now, to pieces of functionality that need to be provided.
If one such requirement is semantic discovery, then doubts have
already been expressed in this thread about whether that is possible
even in principle. A service in which you can place orders for GPS
guided missiles would no doubt allow you to specify a delivery
address. Indeed such a service might be in every way the 'same
shape' as one used for ordering missile STRIKES. Some very expensive
mistakes could be made if you leave it to your stock control package.
--- In email@example.com, "Robin"
> Hi Nic,
> I would not consider WS, SOA and applications as layers. Those are
> different topics but they have more complex relationships than justmore
> being layers on top of each other.
> WS is a set of standards implemented by products that could help in
> establishing a SOA, some of these standards and products might also
> be used in other applications than just SOAs.
> SOA is at a more conceptual architecture level, while WS is at a
> concrete technical implementation level.