- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Wed, 26 Feb 2003 18:21:05 -0500
- To: <jdart@tibco.com>, "'Assaf Arkin'" <arkin@intalio.com>
- Cc: <public-ws-chor@w3.org>
>> >> >>I think a lot of this may be necessary, but (to revisit an earlier issue >>raised on the list) I'm not sure that the requirements for choreography >>necessitate a full-blown workflow modelling language. In fact, I have >>some concern that the existing proposals may be overly complex for >>modelling useful types of WS interaction (especially in a B2B context), >>while being less than adequate for more general worklow purposes, in >>which not everything is directly in service of a WS message exchange. >>Which is why the proposal to separate specification of message flow from >>control flow was attractive, at least IMO. [JJ] Beyond that I think that it is also necessary to make this distinction to reach the point of a "true SOA". The systems components that I was talking about are the services in the SOA. These services can be combined at will, the system is tolerant to replacing these system components by equivalent components. You can also utilize something like WSIF to optimize the interactions between these system components. I bet that a lot of application would benefit from being built that way. If all applications were built that way you could also imagine a very efficient "plug & play" architectures. JJ- >> >>--Jon >> >>Assaf Arkin wrote: >> >>> >>> I do assume that we're talking about long-running behavior all along >>which >>> explains a lot of the complexity of the spec. >>> >>> In a long-running behavior you would have complex flows that are chained >>to >>> each other. You can capture a simple flow with something like a >>sequence, >>> but that doesn't extend well. You will probably want to break the >>complex >>> flow into smaller flows and chain them together, which is where we >>introduce >>> spawn and call*. >>> >>> In a long-running behavior you would also have flows that repeat >>multiple >>> times within some state and that may be subject to how many messages are >>> exchanged (or in reverse, capture the message exchange), which explains >>the >>> need for nested processes. >>> >>> And of course you need to address the time issue, whether you want to >>> express a minimal passage of time (e.g. delay) or put a time constraint >>on >>> the completion of a flow (e.g. onTimeout). >>> >>> And probably some other requirements. Anything specific? >>> >>> arkin >>> >>> * The notion of recursive composition which is captured in this way and >>also >>> with nested processes is very interesting, since it allows you to draw >>> conclusions about a fine grained entities, then about a composition >>> including multiple entities, and a composition including multiple >>> compositions, and so forth. Seeing how formal process models do it, >>we've >>> structured the language in a similar manner to allow the same form of >>> recursive composition/analysis. >>> >>> >>> >>>>JJ- >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >>
Received on Wednesday, 26 February 2003 18:25:01 UTC