Use of WSDL


A BPEL process can use a WSDL definition as the source of the data types used in variable declarations. (Any missing data types must be provided by a separate XML Schema.) As explained in the next sections, the process also references three WSDL extensions that are specific to BPEL: partner link type, property, and property alias.

  • Each partner link type is the basis of one or more partner links, which each describe the business relationship of the process and a partner service.

  • Each property gives a name to an important subset of business data.

  • Each property alias maps a property to a type of message; that is, the alias identifies where the property data is located in a particular type of message.

Although a WSDL definition may include binding and location detail for a given service or requester, the BPEL process never accesses that detail, which is called an endpoint reference. Instead, the endpoint reference is specified by one of three sources: by the administrator of the BPEL server at configuration time; by an SOA product at run time (as described in our review of Service Component Architecture); or by the BPEL process at run time (as described in our review of the BPEL assign activity).

PartnerLinkType

A partner link type specifies the roles that are enacted during a runtime conversation between the BPEL process and a partner service. The simplest partner link type declares a single role and relates that role to a WSDL port type:

 <partnerLinkType name="ProcessQuotePLT">    <role name="ProcessQuoteRole">       <portType name="ProcessQuote" />    </role> </partnerLinkType> 

A single role is appropriate when only one port type is involved - that is, when every communication between the BPEL process and the partner service starts from the same direction. (In a synchronous communication, the same port-type operation describes the request and response messages.)

A partner link type specifies two roles when two port types are involved - that is, when a callback is in use, as explained in Chapter 2. Here's an example of a partner link type that defines two roles:

 <partnerLinkType name="MotorVehicleRecordsLT">    <role name="motorVehicleRecordsService"          portType="MotorVehicleRecords" />    <role name="motorVehicleRecordsCallback"          portType="MotorVehicleRecordsCallback" /> </partnerLinkType> 

When you create a partner link type, you're not concerned with whether the BPEL process or the partner service fulfills a specific role. If the partner service is also a BPEL process, the two processes can use the same partner link type to describe the relationship between them. When you write a process, however, you use a partner link type to create a partner link (Figure 7.2), which is a kind of variable that (in a sense) "chooses a side" by indicating

  • the role of the process you're creating (in other words, which port type describes the operations provided by the process); or

  • the role of the partner service (in other words, which port type describes the operations provided by that service); or

  • both, but only if the partner link type declares two roles.

image from book
Figure 7.2: Partner link

The BPEL engine uses the partner link to help manage the conversation between the two partners.

Properties and Property Aliases

In Chapter 2, we mentioned use of identifiers (purchase-order numbers, invoice numbers, and so on) that help direct a message to the correct service instance at run time. Those identifiers correlate the processing done by one instance (which receives a purchase order) with the processing done by other instances (which submit an invoice, acknowledge receipt of payment, and so on).

When you work with BPEL, you can define WSDL-based constructs called properties and property aliases to perform the correlation function. The availability of these constructs provides several benefits.

First, as you code a BPEL process, you can use the same name (such as CustomerID) to access the same data in differently structured variables - for example, in a variable that holds a purchase order and in a variable that holds an invoice. This repeated use of the same name lets you focus on the business meaning of the data.

Second, properties make maintenance is easier. If an inbound message includes a customer ID, and a change occurs in the position of that ID, you don't necessarily change the logic in the BPEL process. If you've used properties well, you can simply change the property alias that associates the name CustomerID with a specific position in the variable.

Third, you can define a BPEL correlation set, which is essentially a list of constants (for example, a customer ID followed by an invoice number). Those constants help direct an inbound message to the correct instance of the BPEL process. They also allow automatic validation of positions in an outbound message. If the first element in an outbound message is expected to include a particular customer ID and does not, an error occurs at run time.

Let's consider an example.

Listing 7.2 shows a WSDL definition that describes the message placeQuoteRequestMsg.

Listing 7.2: Message placeQuoteRequestMsg WSDL definition

image from book
 <wsdl:message name="placeQuoteRequestMsg">    <wsdl:part name="placeQuoteParameters"               element="placeQuote" /> </wsdl:message> <xsd:element name="placeQuote">    <xsd:complexType>       <xsd:sequence>          <xsd:element             name="quoteInformation"             type="CustomerQuoteInformation"/>       </xsd:sequence>    </xsd:complexType> </xsd:element> <xsd:element name="placeQuote">    <xsd:complexType>       <xsd:sequence>          <xsd:element             name="quoteInformation"             type="CustomerQuoteInformation"/>       </xsd:sequence>    </xsd:complexType> </xsd:element> <xsd:complexType name="CustomerQuoteInformation">    <xsd:sequence>       <xsd:element name="applicant" type="NameAddress"                    minOccurs="0" />       <xsd:element name="dependents" type="NameAddress"                    minOccurs="0" maxOccurs="unbounded"/>       <xsd:element name="auto" type="Auto"                    minOccurs="0" maxOccurs="unbounded"/>       <xsd:element name="applicantEmailAddr"                    type="xsd:string" minOccurs="0" />       <xsd:element name="desiredPolicyInfo"                    type="PolicyQuoteTerms"                    minOccurs="0" />    </xsd:sequence> </xsd:complexType> 
image from book

As shown, the message (placeQuoteRequestMsg) references an XSD element (placeQuote), which in turn references a type (CustomerQuoteInformation). The type has a field for an email address (applicantEmailAddr).

In another WSDL definition, you declare a property (emailAddr):

 <property name="emailAddr" type="xsd:string" /> 

The property is of the same type (xsd:string) as the email address.

In this WSDL definition, you also declare a property alias:

 <propertyAlias    propertyName="emailAddr"    messageType="placeQuoteRequestMsg"    part="placeQuoteParameters" >    <query>       /quoteInformation/applicantEmailAddr    </query> </propertyAlias> 

The alias declaration ensures that you can use the property name to refer to the appropriate field in a BPEL variable such as this one:

 <variable name="quoteRequest"           messageType="placeQuoteRequestMsg" /> 

The important point about this variable declaration is the messageType element, which indicates that the structure of the variable reflects the same message definition as the one referenced in the propertyAlias element. By the way, the variable is declared in a BPEL process, not in WSDL.

The propertyAlias element's messageType and part attributes refer by name to the message and part elements in the WSDL message definition. The query element identifies a search string, which is in a query language (XPath 1.0, by default). At run time, the BPEL engine uses the search string (hereafter called a query) to access the email address that resides in an appropriately structured variable.

You could have included other property aliases for the same property, in each case referring to a different WSDL message definition.

Assume that in the BPEL process, you declare these two variables:

 <variable name="quoteRequest"           messageType="placeQuoteRequestMsg" /> <variable name="theAddress" type="xsd:string" /> 

The process later receives a message into quoteRequest:

 <receive name="processQuoteRequest"          createInstance="yes"          operation="placeQuote"          partnerLink="ProcessQuote"          portType="ProcessQuote"          variable="quoteRequest"> </receive> 

You can access the email address from quoteRequest by invoking the function getVariableProperty, which is in a BPEL-specific namespace and takes two arguments (the variable name and the property name):

 theAddress = bpel:getVariableProperty              ("quoteRequest", "emailAddr") 

You can benefit from the convenience of properties even when your BPEL process accesses a variable that contains data other than a message. For example, after retrieving values from different online stores, you might

  • retain a list of product names and, for each product, the prices in all stores

  • calculate the average price of each product

  • use a variable to hold a table, each row of which holds a product name and the average price for the named product

You can refer easily to the product name in every variable that you use in processing. The steps for establishing a property and a set of property aliases are similar to the steps described earlier. In this case, however, each property alias refers to an XML Schema element or type rather than to a WSDL message definition.




SOA for the Business Developer. Concepts, BPEL, and SCA
SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)
ISBN: 1583470654
EAN: 2147483647
Year: 2004
Pages: 157
Authors: Ben Margolis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net