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

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

From: Assaf Arkin <arkin@intalio.com>
Date: Wed, 26 Feb 2003 15:31:47 -0800
To: "Jean-Jacques Dubray" <jjd@eigner.com>, <jdart@tibco.com>
Cc: <public-ws-chor@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNOEDNDEAA.arkin@intalio.com>

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

+1

arkin

> 
> 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:33:57 UTC

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