|
Nic, Steve
Thanks for your explanations.
I think I may have caused confusion by using the
term "shared state". I do not mean that the state machines of two collaborating
processes that are operating under a global contract have the same state spaces
-- only that they must both understand the state of the collaboration.
Assuming that a global contract specifies, possibly
implicitly, a state space for the collaboration and that, as Nic suggests, the
two processes are able to "interpret their respective definitions and behave
accordingly" I think that each process must both be able, at any point in
the collaboration, to map its own state onto the collaboration state
space, or at least onto an abstraction of the collaboration state space that is
relevant to it. If the processes are not able to do this mapping in some way,
then I think that the contract would be meaningless to them. I used "shared state" to mean this: that each processes, by
virtue of this mapping, shares an understanding of the current state of the
collaboration as defined in the contract.
On the question of a Use Case (requested by Steve)
for the dynamic approach, I think it has to be based on what
happens when the capabilities of the participants (i.e., their state machines)
changes. Here is a small example:
In an Order handling situation, suppose that the
supplier's systems cannot process a "Amend" of an Order once a "Schedule
Delivery" event has taken place, and that a behavioural contract has
been built to reflect this constraint. However, now suppose that the supplier's
system is upgraded to allow later amendments of an Order and that, because
both parties want to take advantage of this new capability, the
collaboration behaviour needs to be updated to allow this. The approach to
achieving this is different depending on whether the collaboration is contract
based or dynamic:
- With the contract based approach, the
contract would need to be amended to reflect this new capability as it entails a
change to meanings (what can and cannot happen next) of the states in the
collaboration state space. This could, in turn, require changes to both the
processes as it changes the interpretations they need to make of the state
space.
- With a fully dynamic approach the only change is
on the supplier side, which has to expose the new capability in its system's
collaboration interface.
The second seems simpler, because only one party
has to do anything. This just reflects the idea that, in the dynamic approach,
the collaboration is driven by the collaboration interfaces exposed by the
participants and not by any kind of global script.
(This is, of course, subject to our earlier
discussion about the difference between Business and Technical Interoperability.
I am taking this example to be purely about Technical Interoperability.
Assuming, of course, that this distinction is really meaningful.)
It may be that I am being too simplistic in all of
this!
Regards
Ashley
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
