When IBM BPM was announced in 2011 with Version 220.127.116.11 one of the key value propositions centered on the combined capabilities of both business process diagrams (BPDs) based on BPMN (Business Process Modeling and Notation) and business processes described in BPEL (Business Process Execution Language). Advanced Integration Services (AIS) provided a high fidelity bridge for getting from BPDs to BPELs as well as a way to get at other powerful integration capabilities that come with the full IBM BPM Advanced offering. Since those early days of IBM BPM patterns of use and best practice have emerged related to this topic of AISes.
Technically, AISes can consist of almost anything that can be authored using IBM Integration Designer. This includes BPELs, MFCs (mediation flow components), POJOs (plain old Java objects), and adapters. These are authored and tested as SCA components in IBM BPM in the same manner as the business and integration components were back in the WPS (WebSphere Process Server) and WID (WebSphere Integration Developer) days. Packaging guidance for these components when they are accessed from Process Designer-created BPMN processes is provided below. There are essentially three packaging approaches to be considered.
- AIS Façade 1 – This is where the advanced integration service is packaged in a process application that is separate from the application calling the AIS with a façade toolkit between the two process applications. See Figure 2 for an illustration.
- AIS Façade 2 – This is where the advanced integration service is packaged in a classic EAR file.
- AIS Embedded – This is where the advanced integration service is embedded in the primary process application.
Each of these packaging options each has their own pros and cons which must be considered. AIS Façade 1 allows for good separation of business and integration logic while also providing separate life-cycle management of the various parts of the solution, all within a single repository which is that of the Process Center. However, the addition of another process application will generate more process applications in your Process Center than the basic AIS Embedded approach. AIS Façade 2 provides separation and offers a way for AIS developers to leverage the more classic, WPS-style, EAR approach to packaging. This approach reduces the number process applications snapshotted and managed by the Process Center but creates a different set of artifacts which must be life-cycled and managed outside the Process Center repository. Deciding which approach to use may also be influenced by the type of advanced integration service being created and the rate and pace at which those services will evolve. The following figure offers an approach for selecting the right AIS packaging model and pulls together this topic in general:
Figure 1 - Decision Tree for Advanced Integration Services
Starting from the top left the first question is around whether or not there is already an SOA or existing set of services inside the enterprise. If so, these services might be available via an ESB but perhaps were not constructed using a schema that matches what is appropriate for the business process realm and thus some mediation or transformation may be needed. If an AIS is needed then one of the façade patterns outlined above should be used. In this case the pattern used, either AIS Façade 1 or AIS Façade 2, will depend on the nature of the team providing the AIS and how these services will be managed.
The other branch from the starting point tackles advanced integration services that will not live on the corporate ESB or come from other existing assets. The first question here is aimed at figuring out the development team and life-cycle approach which will be leveraged. If the same folks are delivering both the services and the business processes then the AIS Façade 1 path for packaging is appropriate and service implementations can be constructed with any of the editors that IBM Integration Designer offers up for capturing business logic. If there are different teams or organizations doing new integration services that support a BPM program and these services will live in a corporate SOA layer, then another set of decisions is needed. If those service interfaces are built bottom-up in a technical way then a facade will be needed inside the BPM program, as discussed earlier. These services could even be web services implemented in java that run in another instance of IBM BPM Advanced. If the services being built are customized to run in IBM BPM Advanced and have WSDL interfaces compatible with the current XML schema support in IBM BPM, then AIS Façade 2 can work nicely as well.
The summary is that there are two AIS Façade patterns recommended for use, depending on the situation being presented. Seldom would the AIS embedded pattern be leveraged.
Both of the AIS Façade patterns involve a version aware linkage between the calling process application and the AIS implementation. This is graphically shown for AIS Façade 1 in the following figure:
Figure 2- AIS Facade 1 detailed linkage
Additional information on AIS Façade 1 can be found at http://www.ibm.com/developerworks/websphere/bpmjournal/1106_taylor/1106_taylor.html and http://www.ibm.com/developerworks/websphere/bpmjournal/1112_pacholski/1112_pacholski.html .
It is also recommended that thorough unit testing of AIS implementations be done using the IBM Integration Designer test environment before publishing them to the Process Center via a process application. This reduces load and contention on the Process Center environment. Deployment times of process applications containing advanced integration services depend on the resources available to the Process Center’s deployment manager and can take a few minutes. This is yet another reason why having AISes separate from process applications going through rapid playback cycles (and frequent changes) is recommended.
This topic so far as focused on BPDs talking to services. In the case of a BPEL calling a BPD human-centric process a slightly different path is followed. In this case, the BPD and BPEL processes are always packaged in the same process application. Perhaps more on this subject is an appropriate topic for a future blog entry.
Hopefully this quick summary shows how our thinking has evolved around how to best drive service calls from BPDs in IBM BPM. Thanks to Ryan Claussen and David Booz for helping me with this blog entry.