Hi all,
> We thought of giving that responsibility to the
> user through an interface but have a vague idea of how to identify those
> participants.
Simply don't.
The decision whether the business goals can be reached with the
COMPLETED participants can only be made by the business logic, be it a
user or whatever else.
The WS-BA implementation needs to offer the business logic an interface
to communicate what it expects the transactional layer to do next,
nothing more.
Let's take an business activity with two participants (Pa & Pb) as an
example. The business layer sends business messages(together with
coor. context header) to both of the participant services. Then both
services gets registered with the coordinator. Issue is identifying
which register message belongs to Pa.. Business layer decides that the
activity is unsuccessful if Pa fails.. In this case it's not possible
for the coordinator to simply distinguish the two participants to
check their outcomes.
One solution which comes to my mind is to provide an unique
registration epr's (addition of a unique string by use of wsa
reference parameters) to each and every participant. Then the
coordinator can distinguish the participants based on that. May be we
can let the business author to provide that identifier for the web
service call.. Then simply returning the participant state together
with that identifier will enable the business logic author to decide
the overall outcome of the activity.
Hannes,
I'm curious to know how the solution in your implementation to this problem...
Note that there is a race condition built into the protocol, as the
participant could report "Completed" before the Cancel command reaches it.
According to the state chart given in the spec, participant should
resend completed.. Then the coordinator should take appropriate action
to that based on business logic authors decision on that..
> Is it possible to handle it
> like "abort" in Atomic transactions?
> And the "Exit" message if an exit
> message received by the coordinator is there anything to be done other
> than sending "Exited"?
Georg and I were also unsure how Cancel and Exit would affect atomic
outcome. Thomas Freund from IBM clarified that for us by defining that
"Exit" may be seen as "Read-only". "Canceled" could be treated as
Read-Only in WS-AT speak, but that may depend on the actual application.
Since the "cancel" was sent by the coordinator with business layers
decision, IMHO we can forget that in the outcome processing phase..
When a participant Exits, it has not performed any work and appears
similarily as if the business logic had canceled the participant.
As you mentioned earlier, if it is expected to see "Exit" as
"Read-only" then it IMO it means that the participant has completed
the job and it does not worry to know the outcome of the activity. In
other words participant treats it as a zero cost request process which
does not need any compensation...
In either case, the participant never reported Completed so the
application needs to check if it can reach the business goal with the
remaining participants.
Georg and I put a Swing demo application together that allows you to
rent cars with a demo web service. The application does not contain
business logic, but provides the buttons "Complete", "Cancel", "Close",
"Compensate" to the user.
The user selects any number of participants,
Can we select exactly one identified participant..
then the message and the coordinator sends the selected message to them.
(Its a bit more complicated since both the coordinator and the
participant ensure that the selected message is applicable in the
current state, but more or less it's that. It is exactly what I would
expect from a WS-BA coordinator.)
It will be available in the upcoming WS-BA enabling patch against
Kandula. We're still working on the docs...
great :)....
Cheers,
Thilina
Best regards,
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
