W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2003

RE: Dubray paper comments + questions [added discussion on SOA]

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>
Message-ID: <00f001c2dded$cf1ee010$0502a8c0@JJD>

>>
>>
>>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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC