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.
Figure 1. Process App reusing AIS implemented in a 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.
Figure 2. Each deployed Process App instance results in a new Toolkit implementation EAR
This article describes a design pattern for the efficient runtime implementation of reusable AIS implementations that eliminates the deployment of multiple AIS implementations.
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:
- 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.
- 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.
- Create a Service Implementation PA Process App - The IT developer creates a Service Implementation PA Process App where the AIS implementation logic is defined.
- 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.
- 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.
Figure 3. Summary of major development steps
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.
- 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
- 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
- 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
- The business user then creates a snapshot, which is required in order to be able to reuse the facade toolkit.
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.
- The developer opens the facade toolkit in Integration Designer, as
shown in Figure 9.
Figure 9. Open the facade toolkit in Integration Designer
- 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!
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.
- 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
- 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
- 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
- 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
Figure 16. Make ServicesFacade Library accessible to implementation module
- 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
- 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
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.
Figure 19. Connect the AIS to the implementation via SCA export
- The IT developer opens the service facade toolkit in Integration Designer.
- 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
- 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
Tipis 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 (
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.
- The business user creates a Process App using Process Designer.
- 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
- The AIS can now be used from the service facade toolkit, as shown in
Figure 23. AIS in service facade toolkit is ready for reuse
- 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
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.
Figure 25. Service facade pattern design summary
- 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