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.
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.
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.
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.
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.
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
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.
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
items2BProducedthat 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
typeOfItemwill implement this task's business logic.
- Take the name or ID of a large-variety item and return its process details. The
processDetailsJava 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
largeVarietyWOwill 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
manufacturingScheduleJava 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
additionalProductionRequirementJava 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
productionReservationJava 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
bulkProductionWOJava 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.
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
items2BProducedJava 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
typeOfItemJava 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
processDetailsJava 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
- The process-execution layer checks the current manufacturing schedule for each bulk-production item using the
- The process-execution layer uses the
additionalProductionRequirementbean 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
productionReservationbean 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
bulkProductionWObean 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.
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.)
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
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
class attribute specifies the Java class for the bean.
Now look back at each
scope attribute. The
scope attribute specifies whether a bean exists in
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.
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.
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 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.
<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.
<process> tag has four attributes:
nameattribute'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.
targetNamespaceattribute specifies the namespace that contains all the names used in this BPEL file. The names include, among others:
- Name of the workflow (
- Name of the partner links used in a BPEL file
- Names of variables used to hold workflow data
- Name of the workflow (
queryLanguageattribute 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.
expressionLanguageattribute 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).
<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.
xmlns:xsdnamespace 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.
xmlns:pmsnamespace 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.
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>
<import> tag in Listing 3 has three attributes:
locationattribute specifies the URL of the document being imported. You can specify a relative URL (such as
Items2BProduced.wsdl) or an absolute URL (such as
namespaceattribute 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.
importTypeattribute 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
importTypeattribute should be
http://www.w3.org/2001/XMLSchema. If you are importing a WSDL document, you should specify
<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.
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: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
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.
<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.
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.
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
<sequence> tags and demonstrate how you can use WS-BPEL to implement your production-management workflow.
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.
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.
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.
Get products and technologies
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.