[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 75 - Local partnerlinks and deployment
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]