Build configurable workflows with WS-BPEL and IoC, Part 1: Understanding dynamic business workflows

A two-layer workflow model

Bilal Siddiqui (xml4java@yahoo.co.uk), Freelance consultant

Bilal Siddiqui is an electronics engineer, an XML consultant, and the co-founder of WaxSys, a company focused on simplifying e-business. After graduating in 1995 with a degree in electronics engineering from the University of Engineering and Technology, Lahore, he began designing software solutions for industrial control systems. Later, he turned to XML and used his experience programming in C++ to build Web- and Wap-based XML processing tools, server-side parsing solutions, and service applications. Bilal is a technology evangelist and a frequently-published technical author.

Summary: Inversion of Control (IoC) and Web Services Business Process Execution Language (WS-BPEL) can be effective tools for implementing dynamic business workflows. In this article, the first in a two-part series, Bilal Siddiqui describes business workflows' dynamic nature and proposes a two-layer workflow model that lets you use XML to build configurable and flexible solutions.

View more content in this series

Date: 08 Jul 2008
Level: Intermediate
PDF: A4 and Letter (123KB)Get Adobe® Reader®
Activity: 3160 views
Comments:

Business operations consist of steps or tasks that are performed in a sequence. The sequence of tasks in a typical real-world business workflow is dynamic in nature: the sequence is normally not fixed and depends on factors that can be decided only during execution. This two-article series demonstrates the use of WS-BPEL and IoC in building configurable dynamic business workflows. Part 1 describes the overall architecture of implementing business workflows using WS-BPEL and IoC. Part 2 will demonstrate how you can use WS-BPEL to implement a production-management workflow.

I'll start the discussion by explaining the dynamic nature of business workflows. Then, I'll present a two-layer model for building flexible workflow solutions. Next, you'll learn how to use XML-based IoC to implement one of the two layers. Finally, I'll describe the role of BPEL in building workflow solutions.

Nature of business workflows

I'll demonstrate the dynamic nature of business workflows using manufacturing as an example. Most real-world manufacturing companies produce a large variety of products, some of them in bulk and some in smaller quantities. To do this, they must implement a mix of two relatively simple workflows to form a real-world dynamic workflow.

Simple workflow to manage production

The first simple production workflow would suit a production house that manufactures only a large variety of products:

The production department receives a production order.
The production department extracts a list of items that need to be produced from the production order and fetches process details for each of the required items. The process details include information such as:
- Production tasks that should be executed to produce an item
- Manufacturing resources (such as personnel or machines) that should be deployed
- Applicable manufacturing standards, practices, drawings, procedures, and quality standards
The production department issues work orders for each of the tasks that must be executed to produce the required items. The relevant process details accompany each work order.

To optimize the use of production resources, companies producing a large variety of products commonly use the same production resources (such as assembly lines and machines) to execute a variety of work orders. This is why it is important that relevant process information accompanies each work order. The process information lets the machine operators or software modules executing the work order know exactly what needs to be done.

I'll refer to this three-step sequence of tasks as large-variety production workflow or simply large-variety workflow.

Bulk-production workflow

The second simple workflow applies to manufacturing companies that produces large quantities of a few types of products, rather than a large variety of products. They generally do not need to share manufacturing resources, finding it more economical to dedicate production resources to each product.

Such companies normally deploy extensive production-planning procedures, which result in manufacturing schedules for each of the products they make. They then deploy their manufacturing schedules by issuing work orders to dedicated resources.

If a company dedicates its production resources to produce specific items, it doesn't need to pass along process information with work orders. This production workflow is therefore quite different from the large-variety workflow. Consider its five-step sequence of tasks:

The company's production department receives a production order.
The production department extracts a list of items that need to be produced from the production order.
The production department checks the manufacturing schedule of items that need to be produced and matches the requirements of the production order with the existing manufacturing schedule.
If the production department finds that the existing manufacturing schedule adequately fulfills the new production requirement, it simply reserves the required quantity specified in the production order.
If the existing manufacturing schedule cannot fulfill the new production requirements, the production department issues new work orders to meet the fresh production order's production requirements. These work orders specify only the items to be produced and need not specify process details.

I'll refer to this five-step sequence as a bulk-production workflow.

Merging large-variety and bulk-production workflows

In typical real-world manufacturing applications, companies normally produce a large variety of products, some of them in bulk. This means that they implement a mix of the two simple workflows I've just described. The following eight-step merged workflow, for example, handles both bulk production and large-variety production:

The company's production department receives a production order.
The production department extracts the list of items that need to be produced from the production order.
The production department checks each of the items in the production order to determine which items are among the large variety of products that need to be produced with shared resources, and which are among the bulk-production items that are produced on dedicated resources.
The production department fetches process details for each item in the large-variety category.
The production department issues work orders for each of the tasks required to be executed to produce items in the large-variety category. Relevant process details accompany each work order.
The production department checks its current manufacturing schedule for each item in the bulk-production category.
If the current manufacturing schedule adequately fulfills the new production requirement, the production department reserves the required quantity for the bulk-category item in the current manufacturing schedule.
If the existing manufacturing schedule cannot fulfill the new production requirements, the production department issues new work orders to meet the new production order's production requirements.

This eight-step merged workflow shows the dynamic nature of business workflows, because the exact sequence of tasks can only be decided at run time. For example, consider Step 3. If the production department finds that there the production order includes no large-variety products, it skips Steps 4 and 5 and jumps directly to Step 6. Similarly, if the production order doesn't include any bulk-production items, Steps 6, 7, and 8 are not to be performed.

A two-layer model for business workflows

The dynamic nature of business workflows can be analyzed in a two-layer model, as shown in the layered hierarchy in Figure 1:

Figure 1. Business workflow shown as a two-layer model
Figure 1. A business workflow shown as a two-layer model

You can see here that the upper layer implements the process-execution logic. This layer:

Controls and executes each task of the workflow one-by-one
Determines the outcome of each task
Decides which task should be executed next

I'll call this layer the process-execution layer or simply the execution layer.

The lower layer consists of classes, each of which implements an individual task's business logic. I'll call this the individual-task layer or simply the task layer.

The major advantage of following this two-layer strategy is its inherent flexibility. It allows you to define highly granular tasks that can be configured and reconfigured to meet changing workflow requirements.

Granularity is important. For example, compare Step 2 of the large-variety workflow with Step 2 of the bulk-production workflow. Step 2 of the large-variety workflow performs two tasks (extracts a list of items from the production order and fetches process details for each item). Step 2 of the bulk-production workflow performs only one task (extracts a list of items from the production order). The better granularity of Step 2 in the bulk-production workflow allows it to fit directly into the merged workflow. This example demonstrates that fine-grained tasks better fit into changing workflow requirements.

Now I'll identify fine-grained tasks that form the individual-task layer of the eight-step merged workflow. Then I'll discuss how the execution layer uses the task layer to implement the complete merged workflow.

Identifying fine-grained tasks

A fine-grained task takes inputs and performs a specific task, as indicated in the following list of fine-grained tasks extracted from the eight-step merged workflow. Each of the following tasks can be implemented by a method of a Java™ class as part of the task layer of Figure 1:

Take a production order as input and return the list of items that need to be produced. Later, in the IoC configurations for the task layer section, I'll configure a Java bean named items2BProduced that implements this task's business logic.
Take a production item's name or identifier as input and return the type of the production item (that is, whether it is a large-variety item or a bulk-production item). A Java bean named typeOfItem will implement this task's business logic.
Take the name or ID of a large-variety item and return its process details. The processDetails Java bean will implement this task's business logic.
Take the name or ID of a large-variety item as input and issue a work order to produce the item. Relevant process details accompany the work order. A Java bean named largeVarietyWO will implement this task's business logic.
Take the name or ID of a bulk-production item as input and return its current manufacturing schedule. The manufacturingSchedule Java bean will implement this task's business logic.
Take the current manufacturing schedule and new production requirements of a bulk-production item as input and return the quantity of new production requirement that cannot be produced under the current manufacturing schedule. The additionalProductionRequirement Java bean will implement this task's business logic.
Take the name or ID of a bulk-production item along with its new production requirements as input and reserve the production requirements in the current manufacturing schedule for the bulk-production item. The productionReservation Java bean will implement this task's business logic.
Take the name or ID of a bulk-production item as input and issue a work order to produce the item in the current manufacturing schedule. The bulkProductionWO Java bean will implement this task's business logic.

Each of the Java beans implementing a single process takes its input and executes the process independently of the other beans.

Operations of the process-execution layer

The process-execution layer in Figure 1 uses Java classes that implement individual tasks in a sequence, as shown in Figure 2:

Figure 2. Merged production workflow's process-execution sequence

The sequence in Figure 2 is as follows:

The process-execution layer receives a production order from a client application.
The process-execution layer uses the items2BProduced Java bean to extract the list of items that need to be produced from the production order.
For each item in the production order, the process-execution layer uses the typeOfItem Java bean to check whether the item belongs to the large-variety category or the bulk-production category.
For each item that belongs to the large-variety category, the process-execution layer uses the processDetails Java bean to fetch the process details of the large-variety item.
The process-execution layer issues a manufacturing work order for the large-variety item using the largeVarietyWO Java bean.
The process-execution layer checks the current manufacturing schedule for each bulk-production item using the manufacturingSchedule Java bean.
The process-execution layer uses the additionalProductionRequirement bean to check how much additional production is required (that can't be fulfilled under current manufacturing schedule) to produce the quantity of each bulk-production item in the production order.
If additional production is not required (which means the quantity of bulk-production item required in the production order can be fulfilled in the current manufacturing schedule), the process-execution layer uses the productionReservation bean to reserve the production required for each bulk-production item in the current manufacturing schedule.
If additional production is required, the process-execution layer uses the bulkProductionWO bean to issue additional work orders for bulk-production items.

You should now have a good understanding of the business logic of the individual-task and process-execution layers. Next I'll discuss the implementation strategy for both the individual tasks and the process-execution layer.

Using IoC to implement the task layer

IoC is a concept used to build flexible and loosely coupled modules, such as the individual-task-layer Java beans I described in the preceding section.

XML-based IoC implementations allow you to use XML to specify:

The Java beans used in an application
The names of Java classes for each bean
Other beans on which a bean depends

IoC implementations use the XML configuration to learn which Java classes need to be instantiated, and in what order, before instantiating those classes. This means that if you use XML-based IoC to configure your beans, you don't need to worry about instantiating the beans.

Using IoC to configure Java classes for individual tasks allows you to focus on implementing the business logic of an individual task in a Java class. You need not worry about how the classes of your task layer will be integrated into your business workflow application. You simply configure your beans in an IoC implementation and leave it to the IoC framework to instantiate your beans and make them available for use by the process-execution layer.

This technique has a major advantage. Changing business scenarios sometimes requires adding new tasks to your workflows. If this happens, you must implement new Java classes for the new tasks. XML-based configuration of IoC beans allows easy integration of new classes into your existing workflow application.

This also means that XML-based IoC allows you to implement and test the business logic of each of the tasks of your workflow independently. Once you have tested the business logic, you can integrate your beans into your workflow application by updating the XML configuration file.

For this article, I'll use the Spring Framework, a popular Java- and XML-based open source IoC implementation. (See Resources for links to several articles that describe IoC in general as well as Spring's IoC implementation.)

IoC configurations for the task layer

Listing 1 is a Spring XML configuration file. It shows how to configure the task layer's eight Java beans from the preceding section.

Listing 1. Spring XML configuration for IoC

                
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
    http://www.springframework.org/schema/aop
    http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
    http://www.springframework.org/schema/tx
    http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">

    <!--Business objects for production management-->

    <bean id="items2BProduced"
        class="sample.wf.Items2BProduced" scope="application" />

    <bean id="typeOfItem"
        class="sample.wf.TypeOfItem" scope="application" />

    <bean id="processDetails"
        class="sample.wf.ProcessDetails" scope="application" />

    <bean id="largeVarietyWO"
        class="sample.wf.LargeVarietyWO" scope="application" />

    <bean id="manufacturingSchedule"
        class="sample.wf.ManufacturingSchedule" scope="application" />

    <bean id="additionalProductionRequirement"
        class="sample.wf.AdditionalProductionRequirement" scope="application" />

    <bean id="productionReservation"
        class="sample.wf.ProductionReservation" scope="application" />

    <bean id="workOrderForBulkProductionItem"
        class="sample.wf.WorkOrderForBulkProductionItem" scope="application" />

</beans>

This listing contains a <beans> tag, which wraps a number of <bean> tags, each representing a Java bean. Each <bean> tag's id attribute specifies the bean's name. You can find all eight of the task layer's Java beans in Listing 1.

For example, look at the first <bean> tag. Its id attribute has a value of items2BProduced, which implements the first task of the individual-task layer.

You can see that the class attribute of the items2BProduced <bean> tag has a value of org.manufacturing.Items2BProduced, which is the fully qualified name of the Java class for the items2BProduced bean. Similarly, each <bean> tag's class attribute specifies the Java class for the bean.

Now look back at each <bean> tag's scope attribute. The scope attribute specifies whether a bean exists in application scope, request scope, or some other scope. If a bean exists in the application scope, the Spring framework instantiates the beans during application startup. If a bean has a request scope, it is instantiated on receipt of every request.

All beans have application scope, so Spring will instantiate them all during application startup. Part 2 of this article will explain in depth how Spring manages to instantiate each bean in its respective scope.

I've shown the configuration of all the eight beans in a single XML configuration file only for simplicity. In actual practice, each bean can be configured in a separate configuration file representing the service provided by the particular bean.

Implementing the process-execution logic

You have seen how to configure the classes used to implement individual tasks in a business workflow. Now I'll describe how to implement the process-execution layer of Figure 1.

Spring's IoC framework works well inside a servlet context, which means any servlet can use the IoC beans configured in Listing 1. You can implement your process-execution layer as a separate Java class, which any servlet can use to control the sequence of individual tasks according to workflow requirements.

However, implementing (hardcoding) your process-execution layer in a Java class defeats the purpose of using IoC to implement the task layer. Recall that the major advantage of using XML to configure IoC beans is that IoC allows easy integration of new classes into your existing workflow applications. If you hardcode your process-execution layer in a Java class, your workflow is no longer configurable, whether or not you use IoC to configure the task layer.

The solution is to use XML at the process-execution layer as well. I'll use Business Process Execution Language (WS-BPEL) to build configurable process-execution layer. WS-BPEL is an XML-based standard defined by Organization for the Advancement of Structured Information Standards (OASIS) used (as its name indicates) to define the execution of business processes (see Resources).

The next section describes the architecture of a workflow application that uses WS-BPEL as the process-execution layer and IoC at the individual-task layer.

Using WS-BPEL to build configurable workflows

Figure 3 shows an architecture that uses WS-BPEL and IoC together in a workflow application:

Figure 3. Architecture using WS-BPEL and IoC in a workflow application

See the full figure here.

You can see various components in Figure 3:

Requesting client: The requesting client is any application that sends a production order to your workflow application and expects that the production order will be executed according to production requirements. Such client applications can exist in different places in the manufacturing company. For example, a company's sales department can act as a requesting client when it receives an order from a customer and issues a production order to produce the items the customer purchased.

Your workflow application exposes a Web services interface to accept production orders. In this article, I use Web Service Definition Language (WSDL) and SOAP-based Web service interfaces. (See Resources for links to articles on WSDL and SOAP.)
BPEL engine: The BPEL engine implements your process-execution layer's execution logic. I'll use a Java-based open source BPEL engine called Apache ODE (see Resources). Part 2 will demonstrate how to host your merged production management workflow on Apache ODE.
BPEL file and partner links: The BPEL file is an XML file in which you configure the business logic of your process-execution layer. (The next section will start discussion of how to write XML configurations in a BPEL file.) The BPEL file contains links to partner services that implement the task layer. BPEL refers to these links as partner links. I'll discuss partner links in detail later, in Linking to your service partners.
WSDL file: You'll find a WSDL file in Figure 3 for each of the beans in Identifying fine-grained tasks. WSDL files simply define XML-based interfaces for the beans implementing the task layer.
IoC framework and IoC beans: Spring acts as the IoC framework on which you'll host each of the beans implementing the task layer.

You are now all set to start learning how to configure your merged production workflow in a BPEL file.

A BPEL file implementing process-execution logic

A BPEL configuration file can define a workflow application's process-execution logic. For example, consider the BPEL file in Listing 2, which implements the process-execution logic that you saw in Operations of the process execution layer:

Listing 2. A BPEL file executing merged production workflow's process-execution logic

                
<?xml version="1.0" encoding="UTF-8"?>
<process name="MergedProductionWorkflow"
    targetNamespace=http://fictitiousManufacturingEnterprise.com/pms
    queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
    expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
    xmlns=http://docs.oasis-open.org/wsbpel/2.0/process/executable
    xmlns:xsd=http://www.w3.org/2001/XMLSchema
    xmlns:pms="http://fictitiousManufacturingEnterprise.com/pms">

  <import />

  <import />

  <!--other import tags--/>

  <partnerLinks />

  <variables />

  <sequence />

</process>

You can see in this code that the root tag in the BPEL file is <process>, which represents the entire production workflow. The <process> tag has a number of attributes, namespace declarations, and child tags, which collectively define the MergedProductionWorkflow's process-execution logic. I've shown children of the <process> tag as empty tags in Listing 2. Later I'll show full details of each tag.

The <process> tag has four attributes:

The name attribute's value determines the name of the workflow you are going to configure (MergedProductionWorkflow). You'll refer to this name in Part 2 when you write a deployment descriptor for your workflow.
The targetNamespace attribute specifies the namespace that contains all the names used in this BPEL file. The names include, among others:
- Name of the workflow (MergedProductionWorkflow)
- Name of the partner links used in a BPEL file
- Names of variables used to hold workflow data
The queryLanguage attribute specifies the query language used in the BPEL file. You need the query language to extract and use workflow data coming from partner services (for example, items to be produced in a production order). In Part 2, I'll explain how to use XPath (a popular query language) in a BPEL file.
The expressionLanguage attribute specifies the expression language used in the BPEL file. You need the expression language in order to express logical and mathematical operations on your workflow data (for example, to check whether the quantity of items in a production order is greater than zero).

The <process> tag in a BPEL file also contains several namespace declarations:

The first namespace declaration represents the BPEL namespace. You need this namespace in order to use the BPEL vocabulary defined by OASIS.
The xmlns:xsd namespace declaration specifies the XML Schema namespace, which you need in order to use schema features in your BPEL file. The most important schema feature that you need in your production management is the ability to define customized data structures.
The xmlns:pms namespace declaration represents the namespace of your production-management system. You need to define your own namespaces in XML applications to be able to define custom elements and attributes. You also need custom namespaces to use WSDL definitions and port types in your BPEL file. (See Resources for links to articles that explain the use of WSDL definitions in BPEL.)

Now I'll discuss the child tags of the <process> tag, one by one.

Importing external namespaces

WS-BPEL provides an element named import, which allows you to import external namespaces and WSDL files into your BPEL file. You import them before using elements defined in your WSDL or XML schema documents.

Listing 3 shows Listing 2's <import> tags in expanded form. Here you can see from that I am using 10 <import> tags in the merged production workflow's BPEL configuration.

Listing 3. Expanded form of BPEL file in Listing 2

                
<?xml version="1.0" encoding="utf-8" ?>
<process name="MergedProductionWorkflow" xmlns:...>

  <import location="ProductionManagementSystem.xsd"
      namespace="http://fictitiousManufacturingEnterprise.com/pms/"
      importType=" http://www.w3.org/2001/XMLSchema" />

  <import location="ProductionManagementSystem.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms/"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="Items2BProduced.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="TypeOfItem.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="ProcessDetails.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="LargeVarietyWO.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="ManufacturingSchedule.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="AdditionalProductionRequirement.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="ProductionReservation.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="BulkProductionWO.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <partnerLinks />

  <variables />

  <sequence />
</process>

Each <import> tag in Listing 3 has three attributes:

The location attribute specifies the URL of the document being imported. You can specify a relative URL (such as Items2BProduced.wsdl) or an absolute URL (such as http://fictitiousManufacturingEnterprise.com/Items2BProduced.wsdl).
The namespace attribute specifies the namespace of the WSDL or XML schema being imported. Namespace attributes of all <import> tags in Listing 3 have the same value (http://fictitiousManufacturingEnterprise.com/pms), because XML schema and WSDL files for the production-management system belong to the same namespace.
The importType attribute refers to the type of document being imported. WS-BPEL supports importing two types of documents. If you are importing an XML schema, the value of the importType attribute should be http://www.w3.org/2001/XMLSchema. If you are importing a WSDL document, you should specify http://schemas.xmlsoap.org/wsdl/ as the importType attribute's value.

The first <import> tag in Listing 3 imports the production-management schema (an XML schema file). The second <import> tag imports a WSDL file named ProductionManagementSystem.wsdl, which represents the complete merged production workflow. The other eight <import> tags represent the eight tasks that you saw in Identifying fine-grained tasks.

Part 2 will discuss the production-management schema and the WSDL that you require to implement your merged production workflow.

Linking to your service partners

Recall from the discussion in Using WS-BPEL to build configurable workflows that your BPEL application requires partner services that implement the task layer. Each partner service exposes its functionality using a WSDL interface. Therefore, you need to define partner links (BPEL-WSDL links) in your BPEL file and in WSDL files for each partner service.

First, I'll explain how to define a BPEL-WSDL link in a WSDL file. Consider the WSDL file shown in Listing 4, which exposes the Items2BProduced partner service's functionality:

Listing 4. Defining BPEL-WSDL links in a WSDL file

                
<?xml version="1.0" encoding="utf-8" ?>
<wsdl:definitions ...... >

    <wsdl:message name="ProductionOrderMessage" />

    <wsdl:message name="ProductionItemsMessage" />

    <wsdl:portType name="Items2BProducedPortType">
       <wsdl:operation name="getItems2BProduced">
          ......
       </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="Items2BProducedBinding">
        ......
    </wsdl:binding>

    <wsdl:service name="Items2BProducedService">
          ......
    </wsdl:service>

    <plnk:partnerLinkType name="Items2BProducedLinkType">
        <plnk:role name="Items2BProduced_Role"
            portType="list:Items2BProducedPortType"/>
    </plnk:partnerLinkType>

</wsdl:definitions>

The WSDL file here maps to the items2BProduced bean introduced in Identifying fine-grained tasks. Listing 4 defines an operation named getItems2BProduced using the WSDL tags such as <wsdl:types>, <wsdl:message>, <wsdl:portType>, and <wsdl:operation>. Note that I left out the details of these WSDL tags. (See Resources for links to articles that cover WSDL tags in detail.)

Look at Listing 4's <plnk:partnerLinkType> tag, which belongs to the partner-link namespace defined by OASIS. The <plnk:partnerLinkType> tag's name attribute defines name of the partner link (for example, Items2BProducedLinkType in Listing 4). The same name will be used in the BPEL file to use this partner service.

The <plnk:partnerLinkType> tag has a child named <role>, which specifies the partner service's business role. In Listing 4, I have used name of the partner service with the suffix _Role as name of the business role.

The <role> tag's portType attribute specifies the WSDL port that exposes the functionality of this partner service.

The same partner link also needs to be defined in your BPEL file, as shown in Listing 5:

Listing 5. Partner-link tags in a BPEL file

                
<process xmlns="..">

   <import />

   <!--Other import tags--/>

   <partnerLinks>
       <partnerLink name="mergedProductionWorkflowPartnerLink"
          partnerLinkType="pms:MergedProductionWorkflowLinkType"
          myRole="MergedProductionWorkflow_Role"/>

       <partnerLink name="items2BProducedPartnerLink"
          partnerLinkType="pms:Items2BProducedLinkType"
          partnerRole="Items2BProduced_Role" initializePartnerRole="yes"/>

       <partnerLink name="typeOfItemPartnerLink"
          partnerLinkType="pms:TypeOfItemLinkType"
          partnerRole="TypeOfItem_Role" initializePartnerRole="yes"/>

       <partnerLink name="processDetails"
          partnerLinkType="pms:ProcessDetailsLinkType"
          myRole="ProcessDetails_Role" initializePartnerRole="yes"/>

       <partnerLink name="largeVarietyWOPartnerLink"
          partnerLinkType="pms:LargeVarietyWOLinkType"
          partnerRole="LargeVarietyWO_Role" initializePartnerRole="yes"/>

       <partnerLink name="manufacturingSchedulePartnerLink"
          partnerLinkType="pms:ManufacturingScheduleLinkType"
          partnerRole="ManufacturingSchedule_Role" initializePartnerRole="yes"/>

       <partnerLink name="additionalProductionRequirementPartnerLink"
          partnerLinkType="pms:AdditionalProductionRequirementLinkType"
          partnerRole="AdditionalProductionRequirement_Role" initializePartnerRole="yes"/>

       <partnerLink name="productionReservationPartnerLink"
          partnerLinkType="pms:ProductionReservationLinkType"
          partnerRole="ProductionReservation_Role" initializePartnerRole="yes"/>

       <partnerLink name="bulkProductionWOPartnerLink"
          partnerLinkType="pms:BulkProductionWOLinkType"
          partnerRole="BulkProductionWO_Role" initializePartnerRole="yes"/>

    </partnerLinks>

    <variables />

    <sequence />

</process>

This code shows an expanded form of the <partnerLinks> tag in Listing 2. The <partnerLinks> contains nine <partnerLink> child tags. The first <partnerLink> tag in Listing 5 represents the partner link with the ProductionManagementSystem.wsdl file (which represents the complete merged production workflow). The rest of the <partnerLink> tags represent the partner links with each of the partner services.

Conclusion to Part 1

In the first part of this series, I have discussed the overall architecture of implementing a business workflow using BPEL and IoC. I've presented a two-layer model to analyze dynamic business workflows and also discussed all the major components of a configurable workflow application.

In Part 2, I'll expand Listing 5's <variables> and <sequence> tags and demonstrate how you can use WS-BPEL to implement your production-management workflow.

Resources

Learn

Spring Framework: Visit the Spring site.
WS-BPEL: The WS-BPEL specification and related resources are available from the OASIS site.
Apache ODE: ODE (Orchestration Director Engine) executes business processes written following the WS-BPEL standard.
"Understanding Web Services specifications, Part 2: Web Services Description Language (WSDL)" (Nicholas Chase, developerWorks, July 2006) and "Understanding Web Services specifications, Part 7: WS-Business Process Execution Language" (Hernan Silberman and Manas Mandal, developerWorks, May 2007): These tutorials, part of a series on Web services specifications, discuss WSDL and WS-BPEL in detail.
"The Spring series, Part 1: Introduction to the Spring framework" (Naveen Balani, developerWorks, June 2005): Read this introduction to Spring's IoC container.
"Design Better Software with the Inversion of Control Pattern" (Mani Malarvannan, DevX.com, March 2005): This article describes IoC design patterns.
"Deploying Web services with WSDL" (Bilal Siddiqui, developerWorks, November 2001): Learn how to author Web services interfaces using WSDL.
Browse the technology bookstore for books on these and other technical topics.
developerWorks Java technology zone: Find hundreds of articles about every aspect of Java programming.
developerWorks SOA and Web services zone: Find hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.