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


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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

Subject: Issue - 75 - Do we need locally declared partnerLinks?

Executive Summary: In the examples below I show how the inability to declare
partnerLinks inside of scopes causes a lot of grief and therefore propose
that we allow partnerLinks to be declared as scope local variables. But I
suspect there was a good reason why partnerLinks were restricted to only
being declared globally, I just don't remember what that reason is.

Long Winded Version:

My working assumption is that it will be very common for compensation
handlers to send and receive messages.

The problem is that partnerLinks are only defined at the global scope.

So, for example, if a compensation handler is depending on the fact that the
endpoint reference for a partnerLink will have the same value when the
compensation handler runs as it did when the scope successfully exited then
the compensation handler can get into serious trouble as anyone, anywhere in
the BPEL process who executes after the scope successfully completes could
change the value of the Endpoint reference.

In general the way to persist values so they will be available to
compensation handlers is to create a scope local variable that persists the
value that needs to be maintained. That scope local variable is then
persisted in the scope's context and available, in its original form, when
the compensation handler runs.

Since partnerLinks can only be declared at a global scope it isn't possible
to store them in a scope local variable. The closest one can get is to try
and store the contents of the partnerLink into a temporary variable and then
restore the value when the compensation handler is run. E.g. something like:

			<from partnerLink="A"
			<to variable="StoreEndPointReference"/>

A major problem with this approach is that BPEL does not define the schema
for an Endpoint reference (see issue 34) so there is no way to know what XML
schema type the StoreEndPointReference variable should take.

Assuming the BPEL TC decides to resolve this problem and define a schema for
endpointReferences there is also the problem of what the semantics are for:

			<from variable="StoreEndPointReference"/>
			<to partnerLink="A"/>

For example, what if the original Endpoint reference pointed to a specific
HTTP connection that is no longer around? What fault is supposed to be
thrown? The key here is that assigning a value to a partnerLink has side
effects and those side effects need to be defined and when problems ensue
appropriate faults need to be defined.

To make matters even more complicated it is quite possible that more than
one member of the BPEL process may be trying to use the partnerLink at the
same time as the compensation handler and the competing code may have its
own desired setting for the Endpoint reference value for that partnerLink.
Because partnerLinks are global there is no good way to prevent simultaneous
access short of requiring every compensation handler to be written inside of
a serializable scope.

Another approach is to require every compensation handler to define its own
unique partnerLink but this would cause an explosion of partnerLinks at the
start of the process whose only purpose would be to work around the fact
that partnerLinks can only be defined globally. This would also get messy
because if someone deletes or somehow changes a compensation handler they
have to remember to go back and change the global partnerLink(s) associated
with that compensation handler.

A simple way around all of this mess is to allow partnerLinks to be declared
inside of scopes. I suspect there is a very good reason why we don't allow
this but I must admit I don't remember what it is.


<<attachment: winmail.dat>>

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