Introduction

In the IBM Business Process Manager Advanced V7.5 programming model, Advanced Integration Services (AIS) are used to implement complex integration logic that can be reused in building BPM human-centric processes. Reuse of AISes in BPM applications (Process Apps) is a desirable goal and should always be pursued when designing and packaging AISes. As shown in Figure 1, the Claims Processing BPD reuses the Automated Claim Processing AIS defined in the Services Facade TK Toolkit.

When a Process App reuses an AIS, it must include the toolkit in which the AIS is implemented. Since each Process App deployed to the server will deploy its own copy of the toolkits it includes, including a large number AIS implementations in a toolkit (for reuse) and then reusing the toolkit in multiple Process Apps will result in a large number toolkit copies being deployed to the server. Figure 2 shows that three Process Apps reusing an AIS implemented in a toolkit results in three EARs being deployed to the Process Server. A large number of deployed EARs may negatively impact the server performance and make administration tasks more complex.

This article describes a design pattern for the efficient runtime implementation of reusable AIS implementations that eliminates the deployment of multiple AIS implementations.

Back to top

Creating a Facade Pattern Cookbook Overview

In this article we'll describe a "meet in the middle" approach, in which the business user defines an Automated Claim AIS and the IT developer already has an implementation for the AIS defined by the business user.

We'll cover the following major steps, as shown in Figure 3:

1. Create a Services Facade TK toolkit – The business user creates a Services Facade TK Toolkit and in it defines the Automated Claim Processing AIS. This is the interface that the business user will use to communicate with the service.
2. Create a Service Facade TK toolkit AIS implementation – The IT developer creates a skeletal AIS facade implementation. This is a "logic-free" implementation of the service that will simply proxy invocations to the actual service implementation.
3. Create a Service Implementation PA Process App - The IT developer creates a Service Implementation PA Process App where the AIS implementation logic is defined.
4. Connect the AIS cefinition to the AIS implementation – The IT developer connects the implementation in the Service Implementation PA Process App to the AIS definition in the Services Facade TK toolkit.
5. Reuse AIS – The business user includes the Service Facade TK toolkit in the Service Consumer PA Process App and reuses the AIS from the toolkit.

Back to top

Step 1. Create the Services Facade TK toolkit

In this step, the business user creates the facade toolkit and then defines the business objects that will become part of the AIS interface. This will be the interface that the Service Implementation PA Process App needs to conform to. The toolkit will be shared by the Claims Processing PA Process App and the Service Implementation PA Process App.

1. The business user uses Process Designer to create a new toolkit, using a naming convention that reflects the fact that this is a Service Facade toolkit, as shown in Figure 4.
   
   Figure 4. Create the facade toolkit
   
   
   
2. The business user opens the toolkit in Process Designer, as shown in Figure 5, then creates a business object that will become part of the AIS interface, as shown in Figure 6.
   
   Figure 5. Create business object
   
   
   
   
   Figure 6. Add BO parameters
   
   
   
3. The business user creates the AIS, as shown in Figure 7. In the sample code, the AIS name is AutomatedClaim. The user than adds input and output parameters, as shown in Figure 8.
   
   Figure 7. Create AIS
   
   
   
   
   Figure 8. Add parameters
   
   
   
4. The business user then creates a snapshot, which is required in order to be able to reuse the facade toolkit.

Back to top

Step 2. Create the service façade toolkit AIS implementation

In this step, the IT developer creates the skeleton for the façade AIS implementation. This implementation will eventually invoke the actual AIS implementation.

1. The developer opens the facade toolkit in Integration Designer, as shown in Figure 9.
   
   Figure 9. Open the facade toolkit in Integration Designer
   
   
   
2. The developer then implements the facade AIS, as shown in Figure 10, and selects an empty implementation.
   
   Figure 10. Implement facade AIS as an empty implementation
   
   
   

   The assembly diagram now shows a Sservice Component Architecture (SCA) AIS export, as shown in Figure 11.

   
   
   Figure 11. SCA AIS export in assembly diagram
   
   
   

Later on we'll connect the SCA AIS export to the actual implementation. Remember that the key point of the facade pattern is not to have any implementation logic in the toolkit!

Back to top

Step 3. Create the Service Implementation PA Process App

In this step the IT developer creates a Process App that implements the service defined in the facade toolkit.

1. The IT developer uses Integration Designer to create the Process App for the facade implementation, as shown in Figure 12.
   
   Figure 12. Create implementation Process App
   
   
   
2. The developer opens the Process App in the workspace and then selects Change Toolkit Dependencies, as shown in Figure 13, to make the Process App dependent on the service facade toolkit. The reason for creating this toolkit dependency is to expose the AIS interface to the implementation logic.
   
   Figure 13. Create dependency on service implementation toolkit
   
   
   
3. The developer then selects Open Snapshot in Workspace, as shown in Figure 14, to bring the read-only (hence grayed out, as shown in Figure 15) content of the toolkit into the workspace.
   
   Figure 14. Bring the facade toolkit into the workspace
   
   
   

   Note that this also brings in the AIS interface, as you can see in Figure 15.

   
   
   Figure 15. AIS BO and interface in workspace
   
   
   
4. The developer adds the ServicesFacade Library to the Dependencies of the service implementation module, as shown in Figure 16. This is needed to make the AIS interface accessible to the module.
   
   Figure 16. Make ServicesFacade Library accessible to implementation module
   
   
   
5. The IT developer then creates an SCA export for the service facade implementation using the AIS interface from the service facade, as shown in Figure 17.
   
   Figure 17. SCA export of the implementation
   
   
   
6. The developer provides the service facade implementation logic, as shown in Figure 18. In our example, the implementation already exists but has a different interface, which is typical. The developer provides mediation logic, which could be a BPEL microflow, a WebSphere™ ESB mediation or even, in the simplest cases, an interface mediation component.
   
   Figure 18. Service facade implementation with a mediation
   
   
   

Back to top

Step 4. Connect the AIS to the implementation

The next step is to revisit the service facade toolkit and connect the AIS SCA export to the AIS implementation export defined in the Service Facade Implementation Process App, as shown in Figure 19.

1. The IT developer opens the service facade toolkit in Integration Designer.
2. In the assembly diagram, the developer creates an SCA import with the same interface as the SCA AIS export and connects the AIS export to the SCA import, as shown in Figure 20.
   
   Figure 20. AIS export connected to SCA import of the implementation
   
   
   
3. The developer then configures the ServiceImplementation SCA import binding to invoke the SCA export of the service implementation, as shown in Figure 21.
   
   Figure 21. Provide SCA binding information
   
   
   

   The Module name is the mangled name of the AIS implementation module. In our case, this is Service_Implementation_PA_Implementation prefixed with the acronym and version of the currently deployed Process App, PJP3. Since we have no snapshot of the implementation Process App yet, the version is Tip. Tip is used when first testing the service in the Process Center. When promoting the code to a Process Server, the prefix needs to be changed. For example, if the snapshot name is V1.0.0, then the module name would be PJP3-V1.0.0-Service_Implementation_PA_Implementation. Accomplishing this can be a bit tricky. First, decide what the Process App snapshot name will be and then change the Module name to include that name, such as PJP3-V1.0.0-Service_Implementation_PA_Implementation. Next, take a snapshot of the façade toolkit. Then update the toolkit dependency in the implementation Process App to point to the just created façade toolkit snapshot. Finally, take a snapshot of the AIS implementation Process App with the name referenced from the toolkit (V1.0.0.

Back to top

Step 5. Reuse the AIS

Now that the developer has built the facade for the AIS and created the implementation, the business user can now reference the service facade toolkit in any Process App in which he or she wants to reuse the AIS.

1. The business user creates a Process App using Process Designer.
2. The business user then adds the service facade toolkit and selects the version to include, as shown in Figure 22.
   
   Figure 22. Service facade toolkit is reused in a Process App
   
   
   
3. The AIS can now be used from the service facade toolkit, as shown in Figure 23.
   
   Figure 23. AIS in service facade toolkit is ready for reuse
   
   
   
4. In our example, the AutomatedClaimsProcessing AIS is reused in the Automated Claims Processing step in a BPD, sa shown in Figure 24.
   
   Figure 24. AIS in service facade toolkit reused in a BPD
   
   
   

Back to top

Conclusion

In this article, we described how to implement the service facade pattern. This pattern allows AIS implementations to be referenced from many Process Apps or toolkits, while only being deployed once to the server. Figure 25 recaps the facade pattern design.

Resources

• Best practices when using IBM Integration Designer and IBM Process Designer together
  
  
• IBM Business Process Manager V7.5 Information Center
  
  
• developerWorks BPM zone
  
  
• IBM BPM Journal
  
  

About the authors

Paul Pacholski has been working with IBM for 29 years. First as senior developer at the IBM Canada Laboratory an currently as BPM Technical Sales Leader he is responsible for technical enablement within IBM, helping customers with selecting the BPM tools and runtimes, presenting at technical conferences, publishing technical papers and filing patents and inventions related to BPM.

Denis Brodeur has been working with IBM for 20 years. He is currently is a Senior Software Developer and team lead of the IBM Integration Designer Test Tooling team at the IBM Toronto Lab.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Creating a Facade Pattern Cookbook Overview
• Step 1. Create the Services Facade TK toolkit
• Step 2. Create the service façade toolkit AIS implementation
• Step 3. Create the Service Implementation PA Process App
• Step 4. Connect the AIS to the implementation
• Step 5. Reuse the AIS
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: IBM Business Process Manager
• Demo: IBM Business Process Manager demos
• Buy: IBM Business Process Manager

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers