Web Services Business Process Execution Language Version 0 Public Review Draft 02, 20 November, 2006

səhifə	5/23
tarix	27.06.2016
ölçüsü	2.65 Mb.

1 2 3 4 5 6 7 8 9 ... 23

6. Partner Link Types, Partner Links, and Endpoint References

An important use case for WS-BPEL is describing cross enterprise business interactions in which the business processes of each enterprise interact through Web Service interfaces. Therefore, WS-BPEL provides the ability to model the required relationships between partner processes. WSDL already describes the functionality of a service provided by a partner, at both the abstract and concrete levels. The relationship of a business process to a partner is typically peer-to-peer, requiring a two-way dependency at the service level. In other words, a partner represents both a consumer of a service provided by the business process and a provider of a service to the business process. This is especially the case when the interactions are based on one-way operations rather than on request-response operations. The notion of
is used to directly model peer-to-peer conversational partner relationships.
define the shape of a relationship with a partner by defining the portTypes used in the interactions in both directions. However, the actual partner service may be dynamically determined within the process. WS-BPEL uses a notion of endpoint reference, manifested as a service reference container , to represent the data required to describe a partner service endpoint.

Introduction of service reference container avoids inventing a private WS-BPEL mechanism for web service endpoint references. It also provides pluggability of different versions of service referencing or endpoint addressing schemes being used within WS-BPEL.

6.1. Partner Link Types

A
characterizes the conversational relationship between two services by defining the roles played by each of the services in the conversation and specifying the portType provided by each service to receive messages within the context of the conversation. Each specifies exactly one WSDL portType. The following example illustrates the basic syntax of a
declaration:

The extensibility mechanism of WSDL 1.1 is used to define
as a new definition type to be placed as an immediate child element of a element. This allows reuse of the WSDL target namespace specification and its import mechanism to import portType definitions. The
definition can be a separate artifact independent of either service's WSDL document. Alternatively, the
definition can be placed within the WSDL document defining the portTypes from which the different roles are defined.

The syntax for defining a

is:

...
?

...

This defines a

in the namespace indicated by the value of the targetNamespace attribute of the WSDL document element. The portTypes identified within s are referenced by using QNames according to the rules in WSDL specifications.

Note that in some cases it can be meaningful to define a

containing exactly one instead of two. That defines a partner linking scenario where one partner expresses a capability to link with any other partner, without placing any requirements on the other partner.

Examples of

declarations are found in various business process examples in this specification.

6.2. Partner Links

The services with which a business process interacts are modeled as partner links in WS-BPEL. Each
is characterized by a partnerLinkType. More than one
can be characterized by the same partnerLinkType. For example, a certain procurement process might use more than one vendor for its transactions, but might use the same partnerLinkType for all vendors.

partnerLinkType="QName"

myRole="NCName"?

partnerRole="NCName"?

initializePartnerRole="yes|no"? />+
Each
is named, and this name is used for all service interactions via that
. This is critical, for example, in correlating responses to different
s for simultaneous requests of the same kind (see section 10.3. Invoking Web Service Operations – Invoke and 10.4. Providing Web Service Operations – Receive and Reply ).

Within a

, the role of the business process itself is indicated by the attribute myRole and the role of the partner is indicated by the attribute partnerRole. When a partnerLinkType has only one role, one of these attributes is omitted as appropriate. [SA00016] Note that a
MUST specify the myRole, or the partnerRole, or both. This syntactic constraint MUST be statically enforced.

The
declarations specify the relationships that a WS-BPEL process will employ in its behavior. In order to utilize operations via a

, the binding and communication data, including endpoint references (EPR), for the
must be available (see also section 10.3. Invoking Web Service Operations – Invoke). The relevant information about a
can be set as part of business process deployment. This is outside the scope of the WS-BPEL specification. Partner link types establish a relationship between WSDL port types of two Web services. The purpose of partner link types is to keep this relationship clear within the process, and make processes with more than one partner easier to understand. No other syntactic or semantic relationships are implied by partner link types in this specification. It is also possible to bind partner links dynamically. WS-BPEL provides the mechanisms to do so via assignment of endpoint references (see section 8.4. Assignment). Since the partners are likely to be stateful, the service endpoint information may need to be extended with instance-specific information.

The initializePartnerRole attribute specifies whether the WS-BPEL processor is required to initialize a

's partnerRole value. The attribute has no affect on the partnerRole's value after its initialization. [SA00017] The initializePartnerRole attribute MUST NOT be used on a partner link that does not have a partner role; this restriction MUST be statically enforced. If the initializePartnerRole attribute is set to "yes" then the WS-BPEL processor MUST initialize the EPR of the partnerRole before that EPR is first utilized by the WS-BPEL process. An example would be when an EPR is used in an activity. If the initializePartnerRole attribute is set to "no" then the WS-BPEL processor MUST NOT initialize the EPR of the partnerRole before that EPR is first utilized by the WS-BPEL process. If the initializePartnerRole attribute is omitted then the partner role MAY be initialized by a WS-BPEL processor.

When initializePartnerRole is set to “yes”, the EPR value used in partnerRole initialization is typically specified as a part of WS-BPEL process deployment or execution environment configuration. Hence, the initializePartnerRole attribute may be used as a part of process deployment contract.

A
can be declared within a
or element. [SA00018] The name of a
MUST be unique among the names of all partner links defined within the same immediately enclosing scope. This requirement MUST be statically enforced. Access to a
follows common lexical scoping rules. The lifecycle of a
is the same as the lifecycle of the scope declaring the
. The initial binding information of a
can be set as a part of business process deployment, regardless of whether it is declared on the
or element level.

6.3. Endpoint References

WSDL makes an important distinction between port types and ports. Port types define abstract functionality by using abstract messages. Ports provide actual access information, including communication service endpoints and (by using extension elements) other deployment related information such as public keys for encryption. Bindings provide the glue between the two. While the user of a service must be statically dependent on the abstract interface defined by port types, some of the information contained in port definitions can typically be discovered and used dynamically.

The fundamental use of endpoint references is to serve as the mechanism for dynamic communication of port-specific data for services. An endpoint reference makes it possible in WS-BPEL to dynamically select a provider for a particular type of service and to invoke their operations. WS-BPEL provides a general mechanism for correlating messages to stateful instances of a service, and therefore endpoint references that carry instance-neutral port information are often sufficient. However, in general it is necessary to carry additional instance-identification tokens in the endpoint reference itself.

Endpoint references associated with partnerRole and myRole of
s are manifested as service reference containers (). This container is used as an envelope to wrap the actual endpoint reference value. The design pattern here is similar to those of expression language, also known as open-content models, for example:

...

The has an optional attribute called reference-scheme to denote the URI of the reference interpretation scheme of service endpoint, which is the child element of .

The URI of reference-scheme and the namespace URI of the child element of will not necessarily be the same. The optional reference-scheme attribute SHOULD be used when the child element of the is ambiguous by itself. This optional attribute supplies further information to disambiguate the usage of the content. For example, if wsdl:service is used as the endpoint reference, different treatments of the wsdl:service element may occur.

If that attribute is not specified, the namespace URI of the content element within the wrapper MUST be used to determine the reference scheme of service endpoint.

If the attribute is specified, the URI SHOULD be used as the reference scheme of service endpoint and the content element within the wrapper is treated accordingly.

When a WS-BPEL implementation fails to interpret the combination of the reference-scheme attribute and the content element or just the content element alone, a standard fault "unsupportedReference" MUST be thrown.

The element is not always exposed to WS-BPEL process definitions. For example, it is not exposed in an assignment from the endpoint reference of myRole of partnerLink-A to that of partnerRole of partnerLink-B. On the contrary, it is exposed in an assignment from a messageType or element based variable through expression or from a literal .

1 2 3 4 5 6 7 8 9 ... 23