This paper uses a specific Order to Manufacturing Processing System (OTMPS) scenario, which was presented in the first paper in this series (see Resources), to describe how to integrate multiple artifacts that are input to IBM® WebSphere® Studio Application Developer Integration Edition (Application Developer) for the development of an executable application of an on demand business process.
Figure 1. Executable on demand business process development
Figure 1 illustrates the development of an on demand business process. Assets such as existing XSD schemas can be imported into WebSphere Business Integration Modeler. After the analyst creates a model using WebSphere Business Integration Modeler (for details see Part 3 in this series -- see Resources), the resulting artifacts are exported to be later used for the development of an executable implementation. An architect uses IBM Rational XDE for use case modeling of the scenario and to develop an object model for the process and services. Java classes are generated from the object model using the XDE code generation facilities. The exported object model is then converted to XML schema elements using Application Developer. The development team uses Application Developer to integrate the Java code and the XML schema elements with additional components and services to complete an executable implementation. The resulting application (EAR file) is then deployed on WebSphere Business Integration Server Foundation.
Figure 2. The OTMPS High-level Interaction
Figure 2 illustrates the high-level architecture for the OTMPS, with one process (Order process subsystem) and three services: 1) validation & topology generation, 2) manufacturing plant, and 3) rule façade. Client applications send orders through the service interface of Order process Subsystem to invoke the process. The process receives input as a group of customer orders from the client applications and forwards valid, translated orders to manufacturing. The Validation & Topology Generation service validates orders by interacting with external validation services. Data sent to this service is wrapped as Validation Info. The Manufacture Plant service is responsible for sending the validated orders to the appropriate manufacturing plants as a bill of materials. Data sent to this service is wrapped as Manufacturing Info. Both services provide wrappers over existing legacy or business partner applications and use protocols, such as WebSphere MQ, to interact with the external applications. To facilitate customization, the process components base many of their decisions on external rules. We used the Business Rule Beans (BRBeans) framework for creating, modifying, and invoking rules. As shown in Figure 2, the rules are defined in BRBeans and are accessed through a rule service façade.
You can use Rational XDE to model the objects in the Unified Modeling Language (UML) and to generate the necessary Java code. For our scenario we modeled objects like Orders, OrderItem, and OrderSubItem. These objects are used as part of the messages exchanged between process components and services. We also modeled additional objects, such as ExceptionInput to be used as input in exception handling, and utility objects like LogUtil for logging.
To create the above objects in Rational XDE, you need to first create a new Java modeling project with the specified name and default directory, as shown in Figure 3.
Figure 3. Create a new Java modeling project
In the Model Explorer View, add a Java package under the model where you will store the objects.
Open the Main diagram under the above Java package. In the Main diagram, use UML notations to create objects with attributes and the relationships between them. In our example, we created objects Orders, OrderItems, and OrderSubItems. The Orders object has an aggregation relationship with OrderItem, and OrderItem has an aggregation relationship with OrderSubItem, as shown in the datagraph in Figure 4.
Figure 4. Datagraph for Orders, OrderItem and OrderSubItem objects
After the model is done, you can generate Java code from the model by selecting the menu option, as shown in Figure 5.
Figure 5. To generate Java code
Listing 1 is the generated Java code from the object Orders.
Listing 1. Generated Java code from object Orders
package OrderItem;
/** @modelguid {69ABC89D-F18E-402D-9A61-D08451525E2C} */
public class Orders {
/** @modelguid {16A7446B-B7C8-44B9-B258-F0455190D1D1} */
private Boolean valid;
/** @modelguid {6C9862A0-8143-4E98-BB3C-896FD8C29DB5} */
private String mfgNum;
/** @modelguid {6F1E2C0A-D44C-483C-96BB-3142012825A5} */
private Boolean lastMileStone;
/** @modelguid {FBDFC07E-FA81-44C0-AF6F-3084457FBA6E} */
private OrderItem[] orderItems;
/** @modelguid {57915FCB-161C-41E0-B570-D59AA36CCF03} */
private OrderItem_OrderItem;
}
|
Integration of process model and object model into Application Developer
Application Developer provides a development environment for workflow-based applications. This includes the following:
- A service project wizard for creating an initial workflow project
- A BPEL editor for choreographing workflows through BPEL elements
- An XSD schema editor for XML schema editing
- Wizards for Web services creation and for XML schema generation from Java classes
An executable workflow application is composed of the following:
- BPEL workflow (BPEL files)
- Web services (WSDL, service interface/implementation classes)
- XML schema (XSD files) for messages passed between service elements
- Java classes used as BPEL variables
An analyst can specify requirements for the executable workflow from WebSphere Business Integration Modeler through the exported artifacts (BPEL, XSD, and WSDL). You need to import these model artifacts into Application Developer for further development.
Import the BPEL/XSD/WSDL artifacts exported from WebSphere Business Integration Modeler
Figure 6. OrderProcessSystem process model
Figure 6 shows the OTMPS OrderProcessSystem process model exported from WebSphere Business Integration Modeler. This workflow process implements various activities, decision points, sequencing, loops, business rule enforcement points, and access to services.
When you import the WebSphere Business Integration Modeler-exported artifacts into Application Developer, import the folder structure that was generated by exporting from WebSphere Business Integration Modeler, because the generated files use that structure to reference one another.
There are two ways to export process model artifacts (BPEL/XSD/WSDL) from WebSphere Business Integration Modeler (for details see Part 3 in this series):
- Export files to an existing Application Developer service project.
- Export files to any directory in the file system.
If you are using an existing Application Developer service project, we recommended that you first complete the following steps:
- While exporting from WebSphere Business Integration Modeler, select as the export directory the location of the Application Developer Service Project.
- After you have finished exporting, start Application Developer. In the Services navigator, refresh the project. The exported files (BPEL/XSD/WSDL) are automatically imported into the service project. Application Developer uses the files to generate other elements required, such as Java implementations of each XSD complex type, and additional WSDL files.
However, if you are exporting WebSphere Business Integration Modeler process model artifacts to a specific directory, you must complete the following steps to import these artifacts into Application Developer:
- In Application Developer, create a new service project in the Business Integration perspective. This is the service project to which you are planning to import the WebSphere Business Integration Modeler-exported artifacts.
- Import into the service project as File System the directory where you exported the files from WebSphere Business Integration Modeler. The files are imported into the project you selected.
A Application Developer service project includes Web services, objects, and processes artifacts arranged in specific packages.
After importing the WebSphere Business Integration Modeler-exported artifacts and refreshing the service project, you will see the BPEL process (for example, OrderProcessSystem) in the service project folder. Figure 7 shows the service project OrderProcessSystemWorkflow with the OrderProcessSystem.bpel and other imported files.
Figure 7. OrderProcessSystemWorkflow service project with imported files
After importing the WebSphere Business Integration Modeler artifacts into the service project, open the BPEL file in the BPEL editor. Figure 8 shows the BPEL process for the OrderProcessSystem.
Figure 8. BPEL editor with opened OrderProcessSystem workflow
All the BPEL validation errors should now be corrected in the BPEL editor. For example, if the WebSphere Business Integration Modeler model contains a staff role and the model is exported as micro flow rather than long running process (macro flows) then there will be some staff variables (such as staff input, staff output) automatically generated during the WebSphere Business Integration Modeler export. This is not valid for a BPEL micro flow because staff activities can only be associated with macro flows. The developer will see the errors in the BPEL editor, and should correct them, for example, by deleting the associated staff variables.
Incorporate additional data model
The processes and services in the system use the data elements as part of their message exchange. The business objects are exported as XSD files from the WebSphere Business Integration Modeler.
Additional Java classes and corresponding XML schema artifacts are needed for the execution of the workflow. Examples of these extended objects include the following:
- Internal objects such as workflow state manager objects
- Custom context data for events
- Objects used for business rules execution
- External service messages
- Objects used by internal service implementations
We use Rational XDE to create these additional objects and their Java code. The modeling project created in Rational XDE is a Java project with extra artifacts (such as model files) that is imported into Application Developer.
If the Java objects imported from Rational XDE are used as part of the message exchange (input/output/error messages) then the corresponding XSD elements need to be created with Application Developer. These objects and XSD elements are included as part of the service interface generation and process state objects which are used while accessing the partner services; in other words, the partner operations include them as part of their messages.
You can introduce these objects through Java global or XML schema elements. To use an object as a Java global, add the object in the "imports" property in the process property sheet by clicking on the title of the process, for example, OrderProcessSystem, as shown in Figure 9.
A Java global can be accessed in all activities inside the process where the object is imported, but it is not accessible in the sub-processes of the process.
Figure 9. Adding Java global variables
The addition of a Java global variable in the imports section results in the creation of a javaGlobals element inside the OrderProcessSystem process BPEL file, as shown in Listing 2.
Listing 2. Usage of Java Global
<process expressionLanguage="Java" name="OrderProcessSystem" … >
….
<wpc:javaGlobals>
<wpc:import packages="com.ibm.coats.logging.LogUtil"/>
………………………………..
</wpc:javaGlobals>
<process/>
|
An XSD file is generated for each object, and this XSD is used in the WSDL file referenced by messages. Figure 10 shows how the the handleExceptionRequest message references the XSD schema generated from object ExceptionInput.
Figure 10. Object ExceptionInput used as a XML schema element
Business objects can be modeled using WebSphere Business Integration Modeler or Rational XDE. In Rational XDE business objects are modeled and exported as Java classes. These Java classes can later be converted to XML schema elements to be used as message parts in the WSDL definition of the corresponding Web services. Afterward, if you generate Java proxies or stubs for these services (from WSDL files), a new set of data objects will be generated with the necessary serialization/deserialization operations and classes.
We have two different sets of data objects for the same business objects -- one imported from Rational XDE, and the other generated from the WSDL file. For example, in the data objects generated by Rational XDE there are no methods to support the specific serialization/deserialization required for Web services (such as arrays). This could cause run-time data serialization errors when used with service implementations and client proxies. Here are some recommendations to help avoid this problem:
- Use WSDL-generated data objects for Web services messaging and use Rational XDE-generated data objects for internal operation of services and workflow and add the necessary data transformations needed. Developers must use a proper packaging structure (such as custom namespace mapping while generating objects from WSDL) while creating these objects to avoid overwriting existing classes.
- Use Rational XDE to model business objects, export them as Java classes, convert them to XML schema elements, and import them into WebSphere Business Integration Modeler. Then all business objects will be exported from WebSphere Business Integration Modeler.
After importing all the necessary artifacts, (that were exported from Rational XDE and WebSphere Business Integration Modeler), the developers add specific needed extensions to these artifacts, including the following:
- Fault handlers to capture system level exceptions
- Java snippets to execute data transformation/event generation
- Externalization of business rules using rule engines
- Generation of bindings to service endpoints
These development extensions will be covered next in this series.
The authors described the architecture of an OTMPS scenario, and the use of Rational XDE for business object modeling in UML. They described how to integrate the WebSphere Business Integration Modeler and Rational XDE-exported artifacts for further development in Application Developer. The next topic in this series is the development of an executable application for an on demand process as performed in WebSphere Studio Application Developer Integration Edition.
The authors would like to thank Martin Keen, Naveen Sachdeva, and Catherine Rivi for their contributions, suggestions, and assistance with this content.
-
Read all parts of the On demand business process
life cycle, and keep track as we add new installments.
- Read the IBM Redbook BPEL4WS Business Processes with WebSphere Business Integration: Understanding, Modeling, Migrating (IBM, December 2004).
- Get the BPEL for Java (BPEL) whitepaper and the BPEL for Web services (BPEL4WS) specification on developerWorks.
- Access the OASIS Web Services Business Process execution language technical committee.
- Research the technical details for the Process Choreographer in WebSphere Business Integration Modeler.
- Check out the Websphere Application Server Information Center.
- Find information on the Web Services Addressing specification from developerWorks.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Wei Liu is a Software Engineer from IBM Software Group. She is currently working with IBM On Demand development team. Her area of expertise includes application server, web service and workflow development.
Dr. German Goldszmidt is a Senior Technical Staff Member working in the IBM Software Group, with focus on architecture of an integrated platform for delivering, customizing, and deploying on demand solutions. Previously, he was a researcher at the IBM T.J. Watson Research Center, and led the design and implementation of several technologies, including Oceano, the first prototype autonomic computing eUtility, and Network Dispatcher, the load balancer component of WebSphere.

Joshy Joseph is a Software Engineer working with the IBM On Demand development organization. He is an architect and programmer with primary skills and expertise in the areas of distributed computing, grid computing, Web services, Business Process, and workflow development. He is the author of the book Grid Computing from Prentice Hall, 2003. In addition, he has written numerous technical articles about Grid computing, Business Process development, and Web services.
Comments (Undergoing maintenance)





