OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Some more diagrams for the model..


At 09:59 AM 4/23/01 +0100, Peter Furniss wrote:
>Sazi,
>
>Re your simple protocol diagram.  What happens to service2 ? Or is part of
>the diagram missing (for me, at least).

Service 2 also get a terminate message. (It is missing from the diagram)
>

>Is it possible for the work of (on) the two services to get different
>results (confirm one, cancel the other) ?  The original BEA proposal
>inferred this was (I think - remembering, not checking in my haste) , but
>referred to this as withdrawing.
>

The simple diagram just show the actors simply, not the details of the
messages exchanged between. Yes different services may get different
messages (terminate, cancel etc)

>Are your actors (especially the sub-coordinator) representations of the
>static capability to handle the cohesion protocol or the instance involved
>in a particular one. 

Sub-coordinator is an actor who is capable of handling the protocol (note
that in an implementation both service and sub-coordinater may be the same
entity, but as far as the protocol concern there is a sub-coordinator and a
service)

> You have two registrations of sub-coordinator to
>coordinator, but only one terminate reply - is this reply then structured to
>say which of the registrations are cancelled, which confirmed ? Or would
>there be a separate withdraw instruction for a cancelled registration ?  The
>former (at least) would make the coordinator : sub-coordinator protocol
>similar to the cohesion outcome protocol that Alastair's last message talked
>about, rather than the atom-level protocol in our main document. 

Again, the terminate message to the second service is missing in the simple
diagram -- see the larger sequence diagram where each service gets message
from the coordinator.

>The neat
>thing about the atom level protocol is that you can use it to do the
>cohesion things, but the service/participant/sub-coordinator side need know
>nothing about it (more precisely, does not need to implement anything
>special to be involved in all sorts of different cohesion structures).
>

Yes, that is also my point that the service/participant/sub-coordinator do
not know whether they are in an atom or not, they are just part of a
transaction.

>------------------------------------------------
>Peter Furniss
>Choreology Ltd
>
>email:  peter.furniss@choreology.com
>phone:  +44 20 7670 1679
>direct: +44 20 7670 1783
>mobile: +44 7951 536168
>13 Austin Friars, London EC2N 2JX>
>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC