Implementing the facade pattern using IBM Business Process Manager Advanced V7.5

Maximizing efficiency and reuse

In a recent IBM® BPM Journal article, Best practices when using IBM Integration Designer and IBM Process Designer together, the authors recommend the facade pattern: "A good pattern to avoid excessive or accidental breakages is to 'facade' the data types and the interfaces, isolating the models from changes introduced through the other tool." In this article, we'll explore the facade pattern in more detail. Specifically, we'll show you how you can use IBM Business Process Manager to implement the facade pattern efficiently while maximizing service reuse. This content is part of the IBM Business Process Management Journal.

Paul Pacholski (pacholsk@ca.ibm.com), BPM Technical Sales Lead, IBM

Photo of Paul PacholskiPaul 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 F. Brodeur (dbrodeur@ca.ibm.com), Senior Software Developer, Technical Lead Integration Designer Test Tooling , IBM

Denis Brodeur photoDenis 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.



14 December 2011

Also available in Chinese

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.

Figure 1. Process App reusing AIS implemented in a toolkit
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
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:

  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.
Figure 3. Summary of major development steps
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.

  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
    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
    Create business object
    Figure 6. Add BO parameters
    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
    Create AIS
    Figure 8. Add parameters
    Add parameters
  4. 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.

  1. The developer opens the facade toolkit in Integration Designer, as shown in Figure 9.
    Figure 9. Open the facade toolkit in Integration Designer
    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
    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
    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.

  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
    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
    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
    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
    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
    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
    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
    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
Connect the AIS to the implementation via SCA export
  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
    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
    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.


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
    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
    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
    AIS in service facade toolkit reused in a BPD

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.

Figure 25. Service facade pattern design summary
Service facade pattern design summary

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=779782
ArticleTitle=Implementing the facade pattern using IBM Business Process Manager Advanced V7.5
publish-date=12142011