Issue - 75 - Local partnerlinks and deployment

["Yaron Y. Goland" <ygoland@bea.com>]

The motivation for introducing locally scoped partner links was 
explained in 
<http://lists.oasis-open.org/archives/wsbpel/200310/msg00215.html>.

In discussions on the issue at the F2F there was some concern regarding 
deployment issues. I already touched on those issues in 
<http://lists.oasis-open.org/archives/wsbpel/200311/msg00204.html> but 
there seems to be demand for something a bit more comprehensive.

I therefore put together the following paper to explore the assumptions 
underlying BPEL deployment and how those assumptions would change if 
locally scoped partnerLinks were introduced. I would like to stress that 
deployment is out of scope for BPEL. The only reason deployment issues 
are being discussed is to assure ourselves that locally scoped 
partnerLinks would not hinder reasonable deployment strategies. But the 
actual deployment strategy chosen by a BPEL engine is the exclusive 
domain of that engine and not an issue for standardization within the 
BPEL TC.

I hope this exploration of the issues helps to move the issue along,

	Thanks,

		Yaron

*An Examination of the Ramifications of Introducing Locally Scoped 
partnerLinks to BPEL*
by
Yaron Y. Goland
ygoland@bea.com
4/27/2004

Issue 75 proposes the introduction of locally scoped partnerLinks. Some 
concern has been expressed that this feature could cause problems with 
deployment, specifically; that locally scoped partnerLinks would enable 
BPEL processes to dynamically create new local endpoints, something that 
could potentially turn into an administrative nightmare.

This paper looks at how deployment would likely work with BPEL today and 
what changes would be caused by the introduction of locally scoped 
partnerLinks. The deployed features discussed in this paper are for 
illustrative purposes only and are not meant to state or imply that any 
such features need to be supported by a BPEL engine.

The conclusion of the paper is that locally scoped partnerLinks would 
have no substantive affect on BPEL's existing deployment experience and 
would not introduce the possibility of BPEL processes dynamically 
creating new local endpoints.

* Definitions *

Deployment Admin - The person or persons responsible for taking a BPEL 
executable process and successfully deploying it.

Endpoint - A specific instance of a web service.

Endpoint Reference - The total collection of data including bindings, 
security settings, etc. needed to fully describe a specific end point 
and how to get a message successfully delivered to that endpoint.

Endpoint Reference Template - One or more partial Endpoint References 
that are missing a key piece of data, typically the URL of the endpoint.

Endpoint Reference Validator - A set of functions that can validate if 
an Endpoint Reference meets the system's acceptable configuration policies.

The separation between Endpoint References, templates and validators is 
only conceptual and not intended to imply any particular implementation 
nor to imply that features similar to those described by configurations, 
templates or validators are required or necessary in creating a BPEL 
implementation.

* BPEL as it Exists Today *

An implicit assumption in BPEL's design that it is the job of the 
deployment admin to make all final decisions about which endpoints a 
BPEL instance may expose for others to send messages to and which 
endpoints a BPEL instance may communicate with.

In the case of configuring 'myRole' endpoints the deployment admin is 
free to create a single endpoint for all 'myRole's or they can create 
multiple endpoints. The choice is up to them and invisible to the BPEL 
program.

In the care of 'partnerRole' endpoints there are at least three ways in 
which they can be configured:

1.	The partnerRole can be assigned to a fixed well known web service. In 
that case all instances of the BPEL process will talk to the same 
endpoint and the deployment admin can specify a fixed endpoint reference.

2.	A partnerRole could be used on a receive/pick to initiate a new 
conversation where the partner's endpoint is not known ahead of time. In 
this case the deployment admin can specify a configuration validator on 
the partnerRole endpoint. The validator will examine incoming messages 
and determine if the sender is acceptable. A variant on this scenario is 
the use of assign to copy an existing endpoint reference from one 
partnerLink to another. In that case the validator would still play its 
role.

3.	The partnerRole could be configured at runtime with a dynamically 
generated endpoint reference. For example, a process could receive a 
list of suppliers, select a supplier, use assign/copy in a proprietary 
way to set the endpoint reference of the partnerRole and then execute an 
invoke using that partnerRole. Minimally one would imagine that the 
deployment admin would use an endpoint validator to make sure that the 
dynamically specified endpoint is acceptable. But it seems more likely 
that the BPEL process would not specify the entire endpoint reference at 
runtime. Rather, the BPEL process would depend on the deployment admin 
to provide an endpoint reference template with the BPEL process most 
likely just filling out a tiny piece of information, in most cases no 
more than just a URI. In any case this means that the deployment admin 
would be expected to provide at least an endpoint validator and possibly 
one or more endpoint templates. How the information needed to fill out a 
template would be provided is currently unspecified in BPEL.

Putting all the previous together the deployment experience one would 
expect under BPEL as it is currently designed is that when a BPEL 
executable process is submitted to a BPEL deployment tool the deployment 
tool will list all the partnerLinks with all the roles and let the 
deployment admin specify whatever endpoint references, validators or 
templates are needed.

* BPEL with Locally Scoped PartnerLinks *

The introduction of locally scoped partnerLinks does not cause much of a 
change to the deployment experience.

The first change is that the list of partnerLinks, instead of being a 
flat list, is likely to be a hierarchy that reflects the scoping 
hierarchy in which the partnerLinks are declared. But, just as with BPEL 
today, the list of possible partnerLinks is still known at deployment 
time and so can be fully configured using the same mechanisms discussed 
in the previous section.

It is tempting to argue that locally scoped partnerLinks are different 
because its possible that some of the locally scoped partnerLinks may 
never be created because their scope may never be run where as with 
today's BPEL all partnerLinks are always created. But this is a false 
difference. It is trivially possible in today's BPEL to declare a 
partnerLink and then never use it in the code. There does not appear to 
be any substantive difference between declaring a partnerLink and never 
using it and not declaring a partnerLink at all.

It is equally tempting to argue that locally scoped partnerLinks would 
enable one to dynamically create new 'myRole' endpoints. This would 
enable a BPEL process to open up new ports on demand, which could be an 
administrative nightmare. However it is worth pointing out that BPEL 
provides no mechanism by which a BPEL process can set its myRole 
endpoint reference. The assign syntax intentionally prevents the 
programmer from using a 'to' that points at myRole. Therefore when a 
locally scoped partnerLink is created the myRole for the partnerLink is 
whatever the deployment admin decides it should be. In the simplest case 
all myRole endpoints will be identical so that no matter how many 
partnerLinks are dynamically created no new endpoints on the local BPEL 
server will be created.

The real difference between BPEL as it exists today and BPEL with 
locally scoped partnerLinks is what happens if the scope that the 
partnerLink is defined on is inside of a while activity.

 From a runtime perspective there are no issues, each new instance of 
the partnerLink would be completely independent of all other instances 
and the usual name scoping rules would prevent any confusion as to which 
partnerLink is being referred to.

 From a deployment perspective there would be a difference since the 
deployment UI will most likely only be able to provide a single 
configuration point that would have to be re-used for each instance of 
the partnerLink. In other words, only a single 
configuration/validator/template(s) will be specified for the 
partnerLink and then the specified configuration/validator/template(s) 
would be re-used by each partnerLink instance.

One would imagine that the deployment system would allow the deployment 
admin to decide if they wanted each new 'myRole' to share a single 
endpoint, create new endpoints or use some other endpoint creation 
strategy. For 'partnerRole' the same options as previously discussed 
would be available, that is, either specifying a static endpoint 
reference or providing some kind of endpoint reference validator and/or 
template.

Given the nature of iterating over a scope it seems reasonable that the 
same endpoint configuration/validator/template(s) would be used for each 
iteration.

* Conclusion *

Based on the evidence at hand it does not appear that locally scoped 
partnerLinks introduce any significant complications to BPEL's existing 
deployment model nor do locally scoped partnerLinks appear to offer any 
new challenges in terms of allowing BPEL process instances to create 
undesired endpoints.

* Appendix A - A BPEL Correlation Grey Area *

Today BPEL correlation requires that all outstanding pick/receive 
activities must be unique across the triplet of partnerLink, 
portType/operation and correlation set. But this triplet is not 
sufficient to guarantee uniqueness. For example, imagine a system that 
decides to use a single endpoint for all myRoles. Now imagine that a 
BPEL program has two partnerLinkTypes PLT1 and PLT2. PLT1 points at 
portType PT1 that contains operation Foo with messageType MT. PLT2 
points at portType PT2 that also contains operation Foo in the same 
namespace and with the message messageType MT. The WSDL also contains a 
property P with a propertyAlias PA that applies to messageType MT.

At run time one can imagine having two partnerLinks PL1 and PL2 where 
PL1 is of type PLT1 and PL2 is of type PLT2. However it turns out that 
both partnerLinks are pointing at the same partnerRole. Furthermore the 
correlation set used on a pick involving partnersLinks PL1 and PL2 uses 
a correlation set that consists of property P. In this case if a message 
comes in there is no way to tell if the message is intended for PL1 or 
PL2 since, on the wire, the message that is received could match either one.

The question then is - what should a BPEL engine do in this scenario?

There appear to be two reasonable options:
1) Randomly assign the incoming message to the pick option for either 
PL1 or PL2.
2) Require static analysis to determine when this scenario is possible 
and mark the process as being in error.

I'm partial to option 1 so long as we put in an implementer's note 
pointing the situation. Adopting option 2 would mean that certain edge 
case web services could not be implemented in BPEL.

* Appendix B - What about WSDL specified services/bindings? *

The paper makes the assumption that it is up to the deployment admin to 
decide what service/bindings to use for each and every endpoint within a 
BPEL process instance. But this assumption begs the question of - what 
happens if a BPEL process definition includes a WSDL with a 
service/binding definition for the portTypes used in the BPEL?

Near as I can tell the answer is - nothing.

While a WSDL service/binding defines a possible endpoint for one or more 
portTypes there is no mechanism currently provided to directly tie a 
particular partnerLink to a specific service. Therefore any 
service/bindings submitted in a WSDL as part of a BPEL executable 
process for deployment cannot be considered anything more than hints or 
suggestions to the deployment admin.

At a minimum it would seem appropriate to put in at least an 
implementer's note in the spec pointing out the undefined relationship 
between a service/binding in a WSDL and the portTypes used by BPEL.

* Appendix C - When is a partnerLink initialized? *

In the scenarios described previously in this paper it is possible for 
the deployment admin to initialize the roles for a partnerLink 
themselves. In the case of 'myRole' the deployment admin must initialize 
the endpoint references because there is no way for the BPEL process to 
do it. But this leaves the initialization of 'partnerRole' ambiguous. 
When a BPEL process starts, depending on what the deployment admin does, 
a partnerRole may or may not already be initialized to a particular 
endpoint reference.

Currently there is no way for a BPEL process to know if the partnerRole 
on a particular partnerLink is initialized. This can lead to situations 
where a BPEL process may try to use a partnerLink whose partnerRole has 
not been initialized because the BPEL process assumed the deployment 
admin would set the endpoint reference during deployment. The situation 
could be especially confusing if some systems run static checking before 
deployment settings are provided and others after the deployment 
settings are provided. In the first case an attempt to use any 
partnerLink without first explicitly initializing the partnerRole will 
always fail. In the second case an attempt to use a partnerLink without 
first explicitly initializing the partnerRole will only fail if the 
deployment admin doesn't provide a static endpoint reference.

A simple way to resolve this confusion is to provide a setting on 
partnerLinks that specifies if the programmer expects the partnerRole to 
be initialized by the deployment admin.