13 min read

Service Invocation

Time for action – creating the book warehousing process

Let’s create the BookWarehousingBPEL BPEL process:

  1. We will open the SOA composite by double-clicking on the Bookstore in the process tree. In the composite, we can see both Bookstore BPEL processes and their WSDL interfaces.
  2. We will add a new BPEL process by dragging-and-dropping the BPEL Process service component from the right-hand side toolbar.
  3. An already-familiar dialog window will open, where we will specify the BPEL 2.0 version, enter the process name as BookWarehousingBPEL, modify the namespace to http://packtpub.com/Bookstore/BookWarehousingBPEL, and select Synchronous BPEL Process. We will leave all other fields to their default values:

Insert image 8963EN_02_03.png

  1. Next, we will wire the BookWarehousingBPEL component with the BookstoreABPEL and BookstoreBBPEL components. This way, we will establish a partner link between them. First, we will create the wire to the BookstoreBBPEL component (although the order doesn’t matter). To do this, you have to click on the bottom-right side of the component. Once you place the mouse pointer above the component, circles on the edges will appear. You need to start with the circle labelled as Drag to add a new Reference and connect it with the service interface circle, as shown in the following figure:

Insert image 8963EN_02_04.png

  1. You do the same to wire the BookWarehousingBPEL component with the BookstoreABPEL component:

Insert image 8963EN_02_05.png

  1. We should see the following screenshot. Please notice that the BookWarehousingBPEL component is wired to the BookstoreABPEL and BookstoreBBPEL components:

Insert image 8963EN_02_06.png

What just happened?

We have added the BookWarehousingBPEL component to our SOA composite and wired it to the BookstoreABPEL and BookstoreBBPEL components. Creating the wires between components means that references have been created and relations between components have been established. In other words, we have expressed that the BookWarehousingBPEL component will be able to invoke the BookstoreABPEL and BookstoreBBPEL components. This is exactly what we want to achieve with our BookWarehousingBPEL process, which will orchestrate both bookstore BPELs.

Once we have created the components and wired them accordingly, we are ready to implement the BookWarehousingBPEL process.

What just happened?

We have implemented the process flow logic for the BookWarehousingBPEL process. It actually orchestrated two other services. It invoked the BookstoreA and BookstoreB BPEL processes that we’ve developed in the previous chapter. Here, these two BPEL processes acted like services.

First, we have created the XML schema elements for the request and response messages of the BPEL process. We have created four variables: BookstoreARequest, BookstoreAResponse, BookstoreBRequest, and BookstoreBResponse. The BPEL code for variable declaration looks like the code shown in the following screenshot:

Insert image 8963EN_02_18b.png

Then, we have added the <assign> activity to prepare a request for both the bookstore BPEL processes. Then, we have copied the BookData element from inputVariable to the BookstoreARequest and BookstoreBRequest variables. The following BPEL code has been generated:

Insert image 8963EN_02_18c.png

Next, we have invoked both the bookstore BPEL services using the <invoke> activity. The BPEL source code reads like the following screenshot:

Insert image 8963EN_02_18d.png

Finally, we have added the <if> activity to select the bookstore with the lowest stock quantity:

Insert image 8963EN_02_18e.png

With this, we have concluded the development of the book warehousing BPEL process and are ready to deploy and test it.

Deploying and testing the book warehousing BPEL

We will deploy the project to the SOA Suite process server the same way as we did in the previous chapter, by right-clicking on the project and selecting Deploy. Then, we will navigate through the options. As we redeploy the whole SOA composite, make sure the Overwrite option is selected. You should check if the compilation and the deployment have been successful.

Then, we will log in to the Enterprise Manager console, select the project bookstore, and click on the Test button. Be sure to select bookwarehousingbpel_client for the test. After entering the parameters, as shown in the following figure, we can click on the Test Web Service button to initiate the BPEL process, and we should receive an answer (Bookstore A or Bookstore B, depending on the data that we have entered).

Remember that our BookWarehousingBPEL process actually orchestrated two other services. It invoked the BookstoreA and BookstoreB BPEL processes. To verify this, we can launch the flow trace (click on the Launch Flow Trace button) in the Enterprise Manager console, and we will see that the two bookstore BPEL processes have been invoked, as shown:

Insert image 8963EN_02_19.png

An even more interesting view is the flow view, which also shows that both bookstore services have been invoked. Click on BookWarehousingBPEL to open up the audit trail:

Insert image 8963EN_02_20.png

Understanding partner links

When invoking services, we have often mentioned partner links. Partner links denote all the interactions that a BPEL process has with the external services. There are two possibilities:

  • The BPEL process invokes operations on other services.
  • The BPEL process receives invocations from clients. One of the clients is the user of the BPEL process, who makes the initial invocation. Other clients are services, for example, those that have been invoked by the BPEL process, but may return replies.

Links to all the parties that BPEL interacts with are called partner links. Partner links can be links to services that are invoked by the BPEL process. These are sometimes called invoked partner links. Partner links can also be links to clients, and can invoke the BPEL process. Such partner links are sometimes called client partner links. Note that each BPEL process has at least one client partner link, because there has to be a client that first invokes the BPEL process. Usually, a BPEL process will also have several invoked partner links, because it will most likely invoke several services.

In our case, the BookWarehousingBPEL process has one client partner link and two invoked partner links, BookstoreABPEL and BookstoreBBPEL. You can observe this on the SOA composite design view and on the BPEL process itself, where the client partner links are located on the left-hand side, while the invoked partner links are located on the right-hand side of the design view.

Partner link types

Describing situations where the service is invoked by the process and vice versa requires selecting a certain perspective. We can select the process perspective and describe the process as requiring portTypeA on the service and providing portTypeB to the service. Alternatively, we select the service perspective and describe the service as offering portTypeA to the BPEL process and requiring portTypeB from the process.

Partner link types allow us to model such relationships as a third party. We are not required to take a certain perspective; rather, we just define roles. A partner link type must have at least one role and can have at most two roles. The latter is the usual case. For each role, we must specify a portType that is used for interaction.

Partner link types are defined in the WSDLs. If we take a closer look at the BookWarehousingBPEL.wsdl file, we can see the following partner link type definition:

Insert image 8963EN_02_22.png

If we specify only one role, we express the willingness to interact with the service, but do not place any additional requirements on the service. Sometimes, existing services will not define a partner link type. Then, we can wrap the WSDL of the service and define partner link types ourselves.

Now that we have become familiar with the partner link types and know that they belong to WSDL, it is time to go back to the BPEL process definition, more specifically to the partner links.

Defining partner links

Partner links are concrete references to services that a BPEL business process interacts with. They are specified near the beginning of the BPEL process definition document, just after the <process> tag. Several <partnerLink> definitions are nested within the <partnerLinks> element:

<process …>

 

<partnerLinks>

 

<partnerLink … />

<partnerLink … />

       …

 

   </partnerLinks>

 

<sequence>

     …

</sequence>

</process>

For each partner link, we have to specify the following:

  • name: This serves as a reference for interactions via that partner link.
  • partnerLinkType: This defines the type of the partner link.
  • myRole: This indicates the role of the BPEL process itself.
  • partnerRole: This indicates the role of the partner.
  • initializePartnerRole: This indicates whether the BPEL engine should initialize the partner link’s partner role value. This is an optional attribute and should only be used with partner links that specify the partner role.

We define both roles (myRole and partnerRole) only if the partnerLinkType specifies two roles. If the partnerLinkType specifies only one role, the partnerLink also has to specify only one role—we omit the one that is not needed.

Let’s go back to our example, where we have defined the BookstoreABPEL partner link type. To define a partner link, we need to specify the partner roles, because it is a synchronous relation. The definition is shown in the following code excerpt:

Insert image 8963EN_02_23.png

With this, we have concluded the discussion on partner links and partner link types. We will continue with the parallel service invocation.

Parallel service invocation

BPEL also supports parallel service invocation. In our example, we have invoked Bookstore A and Bookstore B sequentially. This way, we need to wait for the response from the first service and then for the response from the second service. If these services take longer to execute, the response times will be added together. If we invoke both services in parallel, we only need to wait for the duration of the longer-lasting call, as shown in the following screenshot:

BPEL has several possibilities for parallel flows, which will be described in detail in Chapter 8, Dynamic Parallel Invocations. Here, we present the basic parallel service invocation using the <flow> activity.

Insert image 8963EN_02_24.png

To invoke services in parallel, or to perform any other activities in parallel, we can use the <flow> activity. Within the <flow> activity, we can nest an arbitrary number of flows, and all will execute in parallel. Let’s try and modify our example so that Bookstore A and B will be invoked in parallel.

Time for action – developing parallel flows

Let’s now modify the BookWarehousingBPEL process so that the BookstoreA and BookstoreB services will be invoked in parallel. We should do the following:

  1. To invoke BookstoreA and BookstoreB services in parallel, we need to add the Flow structured activity to the process flow just before the first invocation, as shown in the following screenshot:

Insert image 8963EN_02_25.png

  1. We see that two parallel branches have been created. We simply drag-and-drop both the invoke activities into the parallel branches:

Insert image 8963EN_02_26.png

That’s all! We can create more parallel branches if we need, by clicking on the Add Sequence icon.

What just happened?

We have modified the BookWarehousingBPEL process so that the BookstoreA and BookstoreB <invoke> activities are executed in parallel. A corresponding <flow>activity has been created in the BPEL source code. Within the <flow> activity, both <invoke> activities are nested. Please notice that each <invoke> activity is placed within its own <sequence> activity. T his would make sense if we would require more than one activity in each parallel branch. The BPEL source code looks like the one shown in the following screenshot:

Insert image 8963EN_02_27.png

Deploying and testing the parallel invocation

We will deploy the project to the SOA Suite process server the same way we did in the previous sample. Then, we will log in to the Enterprise Manager console, select the project Bookstore, and click on the Test Web Service button.

To observe that the services have been invoked in parallel, we can launch the flow trace (click on the Launch Flow Trace button) in the Enterprise Manager console, click on the book warehousing BPEL processes, and activate the flow view, which shows that both bookstore services have been invoked in parallel.

Understanding parallel flow

To invoke services concurrently, we can use the <flow> construct. In the following example, the three <invoke> operations will perform concurrently:

<process …>

   …

<sequence>

<!– Wait for the incoming request to start the process –>

<receive … />

 

<!– Invoke a set of related services, concurrently –>

<flow>

<invoke … />

<invoke … />

<invoke … />

</flow>

     …

<!– Return the response –>

<reply … />

</sequence>

</process>

We can also combine and nest the <sequence> and <flow> constructs that allow us to define several sequences that execute concurrently. In the following example, we have defined two sequences, one that consists of three invocations, and one with two invocations. Both sequences will execute concurrently:

<process …>

   …

<sequence>

 

<!– Wait for the incoming request to start the process –>

<receive … />

 

<!– Invoke two sequences concurrently –>

<flow>

<!– The three invokes below execute sequentially –>

<sequence>

<invoke … />

<invoke … />

<invoke … />

</sequence>

<!– The two invokes below execute sequentially –>

<sequence>

<invoke … />

<invoke … />

</sequence>

</flow>

 

     …

<!– Return the response –>

<reply … />

</sequence>

</process>

We can use other activities as well within the <flow> activity to achieve parallel execution. With this, we have concluded our discussion on the parallel invocation.

Pop quiz – service invocation

Q1. Which activity is used to invoke services from BPEL processes?

  1. <receive>
  2. <invoke>
  3. <sequence>
  4. <flow>
  5. <process>
  6. <reply>

Q2. Which parameters do we need to specify for the <invoke> activity?

  1. endpointURL
  2. partnerLink
  3. operationName
  4. operation
  5. portType
  6. portTypeLink

Q3. In which file do we declare partner link types?

Q4. Which activity is used to execute service invocation and other BPEL activities in parallel?

  1. <receive>
  2. <invoke>
  3. <sequence>
  4. <flow>
  5. <process>
  6. <reply>

Summary

In this chapter, we learned how to invoke services and orchestrate services. We explained the primary mission of BPEL—service orchestration. It follows the concept of programming-in-the-large. We have developed a BPEL process that has invoked two services and orchestrated them. We have become familiar with the <invoke> activity and understood the service invocation’s background, particularly partner links and partner link types.

We also learned that from BPEL, it is very easy to invoke services in parallel. To achieve this, we use the <flow> activity. Within <flow>, we can not only nest several <invoke> activities but also other BPEL activities.

Now, we are ready to learn about variables and data manipulation, which we will do in the next chapter.

 

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here