Steve and Ashley,
I won't make a habit of butting in, but Ashley's description seems
clear enough to understand, even if it is his misunderstanding that
needs to be understood.
Briefly, the combination of two interacting state machines is a third
state machine whose behaviour is fully determined. This third
machine is the one that is instantiating the desired solution ("the
collaboration").
In the limit of looseness of design-time coupling, it should not be
possible to deduce the behaviour of the collaboration as a whole from
an examination of either one of the constituent services in isolation.
A global behavioural contract (I think) is implemented by something
which distributes, either at run or deployment time, behavioural
definitions to the two (in this example) constituent services. They
then interpret their respective definitions and behave accordingly
(or more likely, check to see if that is what they would do anyway,
and if not, bow out gracefully).
Shared state which is explicitly represented at both ends simply
doesn't come in to it. Such state being an implicit or emergent
property of the collaboration.
To the extent the above is true, neither the static nor the dynamic
approach is unnecesarily restrictive.
Ashley's concern may be that the global behavioural contract allows
explicitly represented global state to creep in to the design,
whereas the dynamic approach doesn't.
If it creeps in, it amounts to a departure from loose coupling. You
can be sure that commercial application programmers and business
analysts will avail themselves of overcoupling at every opportunity!
Note that it is one thing for the two constituent services to know
each other's state diagrams (or a global one), it is another thing
entirely for them to know each other's state.
Nic
--- In [email protected], Steve Ross-
Talbot <[EMAIL PROTECTED]> wrote:
>
> Ashley,
>
> I'm still looking for a concrete use case. I understand in theory
what
> you are suggesting.
> Without a use case I cannot begin to understand what it is that I
> cannot do without a
> dynamic collaboration. As yet I do not have an example. I have lots
for
> choreographies
> but none for you area. We spent a long time in the WG doing
> requirements based
> on use cases. Not one use case was presented or harvested that
sheds
> light on what
> you are suggesting. So a use case really really would be most
helpful
> in elaborating
> what it really means in real terms as opposed to just a feeling or
> hypothesis.
> If you have a use case I'd love to see it.
>
> Cheers
>
> Steve T
>
> On 15 Oct 2005, at 00:55, [EMAIL PROTECTED] wrote:
>
> > Dear Steve
> >
> > Thanks for your helpful reply on the subject of global
behavioural
> > contracts.
> >
> > Let me try to clarify my position.
> >
> > For me, the key issue here is the extent to which two
collaborating
> > processes have a shared understanding of the state of their
> > collaboration.
> > Here I am taking âstateâ to be a determinant of what can and
cannot
> > happen
> > next in the collaboration.
> >
> > In fully dynamic collaboration there is no shared state at all,
and
> > the
> > collaboration is entirely driven by what each process declares
at run
> > time
> > that is able and willing to do.
> >
> > By contrast, a non-dynamic collaboration is one in which the two
> > collaborating processes conform to a shared behaviour pattern
that is
> > defined beforehand (i.e., separately from the design of the two
> > processes)
> > and forms a specification of the way the processes must behave.
At
> > any point
> > during the execution of a collaboration, both processes must
know the
> > state
> > of the shared pattern and are required to conform to the
behaviour it
> > prescribes. In this sense, the processes share a common state.
> >
> > My question is really about the extent to which the dynamic
paradigm
> > is
> > possible, and the extent to which the âglobal behavioural
contractâ
> > approach
> > precludes it.
> >
> > I hope that helps.
> >
> > Thanks also for the pointers to other work in this area â" I
will
> > certainly
> > follow them up.
> >
> > Rgds
> > Ashley
> >
> >
> >
> >
> >
> > YAHOO! GROUPS LINKS
> >
> > ⪠ Visit your group "service-orientated-architecture"
on the web.
> > Â
> > ⪠ To unsubscribe from this group, send an email to:
> > [EMAIL PROTECTED]
> > Â
> > ⪠ Your use of Yahoo! Groups is subject to the Yahoo!
Terms of
> > Service.
> >
> >
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
