Loading ...
Sorry, an error occurred while loading the content.

Re: [service-orientated-architecture] Is the WS- vision achievable?

Expand Messages
  • Ashley at Metamaxim
    ... 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
    Message 1 of 91 , Sep 30, 2005
      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*.
      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.
    • Nic
      Hi Robin, The discussion thread had inclined me towards layers (not to be confused with tiers, which run at 90 degrees). A layered architecture (or
      Message 91 of 91 , Oct 8, 2005
        Hi 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 service-orientated-architecture@yahoogroups.com, "Robin"
        <it@m...> wrote:
        > Hi Nic,
        > I would not consider WS, SOA and applications as layers. Those are
        > different topics but they have more complex relationships than just
        > 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.
        > Robin
      Your message has been successfully submitted and would be delivered to recipients shortly.