Hi Dominik,
I agree with Ian. WS-BA defines how the coordinator deals with participants.
Do not mix up with this with nesting activities and parent - child
relationship. When you are nesting activities, a participant of a top level
activity could be a coordinator of a lower level activity. In that case, the
type of the lower level coordinator (Atomic or mixed outcome) doesn't
matters to the higher level activity. However, the lower level coordinators
who participate in the higher level activity should participate in that
higher level activity according to the activity type (atomic/mixed outcome)
of the higher level coordinator.
In your example, the higher level coordinator A is a Mixed Outcome type
coordinator. Therefore, B, C and D should participate in the higher level
activity in the context of a Mixed Outcome. B, C and D being Atomic and
Mixed Outcome coordinators, does not matter to this high level activity. The
types of B, C and D matters to the participants of the lower level
activities (in you words, the children of B, C and D. However, the word
"child" is not appropriate. They are just participants)
If you don't get confused, following is a little complex scenario. Let's say
one if the participants of B's lower level Atomic outcome activity is "R".
Now, R may participate in the higher level A's activity while participating
in lower level B's activity. B's activity is an atomic one while, A's
activity is a mixed outcome one. This does not make any confusion.
The important thing to realize is the type of activity (Atomic or Mixed)
matters to the coordinator. In fact, that governs the coordinating logic of
the coordinator. For participant, the coordination type really doesn't
matters. What matters to the participants is the participant protocol. i.e.
either "ParticipantCompletion" or "CoordinatorCompletion".
The relationships between nested activities are not defined in the WSBA. As
to my understanding, you may nest your activities in any manner as long
as the coordinator - participant relationship in maintained as defined in
WSBA
regards,
Sanjaya
On 1/17/08, Dominik Heller <
Dominik.Heller@gmx.net> wrote:
>
> Hello Ian,
> first of all thanks for your fast response i really appreciate it. So I am
> a little bit confused right now. If I understood you right then the parent
> and the child activity do not necessarily need to be in a
> coordinator-participant relationship though as an example the parent
> activity could be the participant of a coordinator, having several child
> activitys in the form of fulfilling some sequential work on other WS or
> other entites? in this case one of the childs could be another coordinator
> with a mixedOutcome having some participants, though the whole outcome would
> rely on the final command the parent activity would get from its own
> coordinator, right?
>
> well as I said I am a little bit confused right now, I hope I didn't mess
> up to much. Thanks
>
> Dominik
>
> -------- Original-Nachricht --------
> > Datum: Thu, 17 Jan 2008 13:29:29 +0000
> > Von: Ian Robinson <
ian_robinson@uk.ibm.com>
> > An: "Dominik Heller" <
Dominik.Heller@gmx.net>
> > CC:
ws-tx-comment@lists.oasis-open.org> > Betreff: Re: [ws-tx-comment] WS-BusinessActivity Specification
>
> > Dominik,
> > The WS-BA spec is prescriptive about how a coordinator must manage
> > participants within a business activity scope but is not prescriptive
> > about the relationship between parent and child activity scopes. In your
> > example, activites B, C and D are each sibling child activities of A.
> One
> > way of relating a child activity to its parent is to make the
> coordinator
> > of a child activity a participant in its parent activity, although the
> > specification does not require this. Even though the Coordinator for B
> is
> > an AtomicOutcome coordinator (and the outcome of all participants within
> > the scope of B must be the same), if it were also a participant of A it
> > would be a participant in the MixedOutcome activity A. Continuing this
> > example, the completion of the AtomicOutcome work of B would result in a
> > wsba:Completed protocol message to A (in B's role as a participant of A
> in
> > this example). Once A received all its wsba:Completed signals, it would
> > consult application logic to determine which participants to close and
> > which to compensate.
> >
> > Regards,
> > Ian Robinson
> >
> >
> >
> >
> > "Dominik Heller" <
Dominik.Heller@gmx.net>
> > 17/01/2008 10:08
> >
> > To
> >
ws-tx-comment@lists.oasis-open.org> > cc
> >
> > Subject
> > [ws-tx-comment] WS-BusinessActivity Specification
> >
> >
> >
> >
> >
> >
> > Hello,
> > I am reading through the WS-BusinessActivity Specifiaction right now and
> I
> > am not sure if I understood the concept of the Business Activity scopes
> > correctly. Well to picture the way of my understanding right now I
> > describe a little scenario:
> > the top node of the Business Activity is a MixedOutcome Coordinator A
> > which has three childs say, one AtomicOutcome Coordinator B with two
> > childs and two separate MixedOutcome Coordinators C and D with two
> childs
> > each.
> >
> > So do I guess right that every coordinator is contained in a separate
> Web
> > Service because of separate business logics and then is just plugged
> > together to a Business Activity?
> >
> > The WS-BA spec is talking about nested scopes and that a business
> > application is allowed to select which child tasks are allowed in the
> > overall outcome. So in the end this means that the business logic of the
> > Coordinator C chooses which of his childs has to close and which has to
> > compensate and then notifices the Coordinator A that it is ready for
> > closing or compensation, right?
> >
> >
> > Well thanks in advance for your help
> >
> > Dominik Heller
> > --
> > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> > Browser-Versionen downloaden:
http://www.gmx.net/de/go/browser> >
> > This publicly archived list offers a means to provide input to the
> > OASIS Web Services Transaction (WS-TX) TC.
> >
> > In order to verify user consent to the Feedback License terms and
> > to minimize spam in the list archive, subscription is required
> > before posting.
> >
> > Subscribe:
ws-tx-comment-subscribe@lists.oasis-open.org> > Unsubscribe:
ws-tx-comment-unsubscribe@lists.oasis-open.org> > List help:
ws-tx-comment-help@lists.oasis-open.org> > List archive:
http://lists.oasis-open.org/archives/ws-tx-comment/> > Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf> > List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php> > Committee:
> >
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx> >
> >
> >
> >
> >
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> >
> >
> >
>
> --
> GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
> Alle Infos und kostenlose Anmeldung:
http://www.gmx.net/de/go/freemail>
> This publicly archived list offers a means to provide input to the
> OASIS Web Services Transaction (WS-TX) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe:
ws-tx-comment-subscribe@lists.oasis-open.org> Unsubscribe:
ws-tx-comment-unsubscribe@lists.oasis-open.org> List help:
ws-tx-comment-help@lists.oasis-open.org> List archive:
http://lists.oasis-open.org/archives/ws-tx-comment/> Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf> List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php> Committee:
>
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx>
>