Nic,
your point about shared state is entirely correct. In a behavioral
contract
for collaboration (a global model if you will) - expressed in something
akin
to WS-CDL. In WS-CDL there is not shared state. One can align state but
that does not mean it is shared.
Your point about "bowing out" is also entirely correct. A service can
only participate
if it can fulfill the functional and behavioral description projected
out from a global
model. This is not only entirely possible but also realised in the
pi4tech open source
tool suite for WS-CDL.
Thanks for your comments
Steve T
On 20 Oct 2005, at 12:40, Nic wrote:
> 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.
> > >
> > >
> >
>
>
>
>
>
>
>
>
> SPONSORED LINKS
> Service-oriented architecture
> Computer monitoring software
> Computer and internet software
> Free computer monitoring software
>
> 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 --------------------~-->
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/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/
