RE: Dubray paper comments + questions

>>I do assume that we're talking about long-running behavior all along
which
>>explains a lot of the complexity of the spec.
[JJ] yes, ;-)

If you consider a model (as in Model-View-Controller). You can typically
do CRUD operations on the model (e.g. insert PO) that I do not consider
long-running and then there are other operations such as "process PO"
that can exhibit a long-running behavior (that I define as cannot meet
the ACID requirements, right or wrong). Typically a Process PO operation
involves talking to the billing component and invoking the insert PO it
if passes the validation rules (could also need approval from a human),
once all this is done, then and only then the ACK_PO can be generated.

I typically view BPEL/BPML as ideal candidate to do this work and
products like Collaxa are a perfect example of a development environment
that greatly facilitate the development of this part of the model. I
would also content that anywhere from 20 to 50% of model-oriented logic
is developed under these principles. 

Does that make the concept more clear?

Of course this is also web service choreography but from a very
"centric" perspective. I am the component and I describe my behavior
from my point of view. Then you have the ether between components and
partners which in my opinion obey different rules (could be proven
wrong) in terms of web service choreography.

JJ-

>>
>>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 17:17:02 UTC