This article describes how to separate the business and technical concerns in a typical business process management (BPM) solution implemented in IBM Business Process Manager Advanced (hereafter referred to as BPM Advanced). It first describes the logical architectural layering, where processes executing in a BPM orchestration layer consume provided business services, which in turn aggregate various lower-level technical services. It then uses a scenario to illustrate how to achieve the goals of the architectural layering using BPM Advanced, focusing on the Advanced Integration Services (AIS) capability.
We tested the scenario described in this article on both the V7.5.1 and V8 versions of BPM Advanced. The article refers to the steps used in V8, but the code is also provided for V7.5.1. The sample solution is included in AISExemplar.zip which is available for download with this article. For best results, we recommend that you install the code sample and follow the article by referring to your own installed copy of the sample.
A common rule of thumb to distinguish between a business process and a business service is to assess how the business views the activity. Asking "would the business ever be interested in monitoring the steps involved in this activity?" can help define whether the activity should be considered a process or a service. If the business has no desire to understand the mechanics of the activity, that suggests it should be defined as a service. If the business wants to monitor or drive the individual steps involved in the activity, that is an indicator of a process rather than a black-box service. In addition, the granularity of a service that is used by a business process should be something that has meaning in business terms. There may be many lower levels of granularity that expose technical functions necessary to contribute to a business service, but these are not of interest to the business and therefore should not be referenced by a business process.
Following the advice above, there is a logical layering in a BPM built on service-oriented architecture (SOA) in which each layer has defined responsibilities and consumes the services provided by layers below it. Figure 1 shows an example of an SOA-layered architecture. At the Consumers layer, a client channel interacts with a business process or, if appropriate, directly consumes business services in the Services layer (green indicates business services as defined above while orange denotes lower level of granularity technical services).
Figure 1. SOA layered architecture
Taking this architecture in the context of BPM Advanced, business processes (and linked sub-processes) are implemented as business process diagrams (BPDs) and any business services that are to be consumed by BPDs should be exposed as AIS services, as shown in Figure 2. The example business service shown is directly consumed by the channel and does not need to be exposed as an AIS; instead it might be exposed as a SOAP-based web service or a RESTful web service.
Figure 2. Role of AIS in architecture
Now let's look at the lower-level technical services that are composed in order to expose the business service. These technical services (Figure 3 shows an example of one such service) should be implemented in Integration Designer and are not exposed to the business process (BPD) and therefore do not need to be associated with the Process Center.
Figure 3. Example of a technical service
In the rest of this article, we'll look at how to achieve this separation of concerns in BPM Advanced through an illustrative scenario.
We've already discussed the differentiation between business and technical services. This section shows you how to define an AIS that complies with the recommended approach described previously. Note that an AIS is a bit of a misnomer – what it is really providing is an Advanced Integration Service Operation because it provides the ability to define a single operation of a service. Having followed a service design exercise, a logical service may then result in a number of related AIS definitions, one for each operation.
As the AIS is a service with relevance to the business, the business author is likely to define the service interface in Process Designer, potentially taking input from a technical integration specialist about recommended practices for good service design. The mapping between this business-level service and the lower-level technical service implementations will be performed later by the integration specialist using IBM Integration Designer.
If you haven't already done so, you should go ahead and import the relevant .twx file into your environment so that you can examine the referenced components described in this section (either Order_Facade_TK 8.0 – v1.1.twx or Order_Facade_TK 7.5.1 –v1.0.twx depending on the version of BPM Advanced you're using).
For the example scenario, the business author has specified the AIS
interface contract (
Get Customer Invoice AIS),
as shown in Figure 4.
Figure 4. AIS definition
The interface represents the retrieval of an invoice for a customer where
the customer number and the order number are supplied and the returned
data is modeled in the data structure
Figure 5 shows the detail of the data structure. The fields added are those the business author has identified as being necessary based on the requirements of the business process that will make use of these fields downstream of the call to the backend systems. You'll see later that this structure will be constructed by making various calls to existing services and mapping from this business-relevant data to the existing data structures provided. You'll also see that there are additional data elements provided in existing technical services that are not needed by the business service and so do not need to be mapped.
Figure 5. Business object referenced by AIS
This section covers in detail the technical services that are used to implement the AIS. In order to follow the description, you should import the relevant Project Interchange file into a new Integration Designer workspace and then associate the Order Façade Toolkit with the components imported into Integration Designer. Depending on your environment the file to use will either be AISExemplarPatternPI_8_0.zip or AISExemplarPatternPI_7_5_1.zip. Figure 6 shows how your workspace should look after importing the Project Interchange zip.
Figure 6. Integration Designer after PI import
You need to associate the Order Façade Toolkit with the workspace (first make sure that you have added the necessary access rights to the toolkit using the Process Center Admin console). In Integration Designer, switch to the Process Center perspective and then select to Open in workspace as shown in Figure 7.
Figure 7. Associate toolkit with Integration Designer workspace
After Integration Designer completes the build process, you should have the Order Façade Toolkit along with the other previously imported modules. You can now publish to the Process Center, as shown in Figure 8.
Figure 8. Publish to Process Center
There are many possible technical approaches to expose existing functionality as services available in BPM Advanced. A range of add-on adapters are available for exposed packaged application logic (such as SAP® or Oracle® E-Business Suite, as well as technical adapters for connecting to existing operational systems exposed via, for instance, JDBC or JMS messaging. You could also consume existing SOAP-based web services either internal or external to the organization. For this scenario, we'll show how to expose existing functionality defined in Java™ Enterprise Edition (JEE) Enterprise Java Beans (EJBs) using an intermediary composite service defined as a Business Process Execution Language (BPEL) micro-flow (the BPEL micro-flow will effectively provide the implementation for the AIS and hide the lower-level details of the individual EJBs).
The AIS service contains a mixture of business data related to both a
customer and to orders the customer has placed. In order to provide the
necessary data to construct
there will need to be operations invoked on two EJBs – one related to
Customer and the other related to Order. Figure 9 shows the UML diagram of
CustomerService session EJB with a number
of operations exposed on the remote / local interface. You'll need to
switch to the JEE perspective in Integration Designer to view the class
diagram in the CustomerEJB project.
Figure 9. Customer Service EJB
OrderService EJB provides
operations for interacting with an Order, as shown in Figure 10.
Figure 10. Order Service EJB
In normal circumstances, the session EJBs would use a persistence framework
such as Java Persistence Architecture 2.0 (JPA). In that case, the session
EJBs would call various JPA entity beans that would interact with a
persistent store like a DB2® database. However, for the purposes of
simplicity in this demonstration scenario, I've just modeled the data as
plain old Java objects (POJOs). The Order POJO seen in Figure 11 shows a
more detailed structure, including a contained array of
ProductItem business objects than is needed at
the business level as described previously. It's common to find that the
technical service implementations provide more detail than services at the
business level really need, so mediation is required between the business
and technical views.
Figure 11. EJB referenced POJO
In order to make a clean separation between the business-level services that are required to be surfaced in the BPM layer and the more technical services in the SOA layer, we'll use a façade pattern to hide the more technical detailed services from being exposed to the business process in the form of an AIS.
You've already seen the toolkit design in Process Designer where the AIS interface was specified by the business author. The toolkit is opened in Integration Designer in order to make it visible to the integration specialist working in the tool. The service is exposed in a toolkit so that it can be reused by multiple process applications that have a need to access the Customer Invoicing service. Note that in this example scenario a very simplified BPD is also included in the toolkit for the purpose of illustrating how to use the AIS service, but in reality the consumer of the AIS would be a BPD inside a process application that includes the toolkit as a dependency.
The important aspect of implementing the façade pattern is that the toolkit itself only effectively contains the AIS interface, which in turn delegates to the real implementation that resides in an SCA module that is not managed as part of Process Center. This SCA module therefore provides the bridge between the business service defined in the AIS and the lower-level technical services that have been exposed.
We've created an SCA module that will integrate with the EJBs and orchestrate the logic of the individual EJBs using a short-running BPEL process (micro-flow). Because that SCA module will ultimately be used to provide the AIS implementation it needs to have the AIS interface made available to it. In order to achieve that, we added the toolkit library as a dependency of the SCA module as shown in Figure 12.
Figure 12. SCA module dependency on toolkit library
In the implementation SCA module once the toolkit library has been added
the AIS interface is then visible and can be referenced. The AIS interface
is added as an SCA Export (it will later be consumed from within the
Toolkit) as shown in Figure 13. The two EJBs have been made available in
the assembly diagram by importing them. For illustration here we have
decided to orchestrate the calls to the EJBs with a BPEL process
(“OrchestrateInvoiceData”). In order to compose the data structure needed
for the AIS response some additional logic is required in addition to the
EJBs. In this example we have implemented the additional logic as a simple
local Java component within the SCA module
ShippingService) – however it could well have
been an SCA import from some further module that may have had a Mediation
flow calling out to one or more other endpoint services. The important
point is that the BPEL process is surfacing our AIS service by providing a
new composite service made up of many existing lower level technical
Figure 13. SCA assembly diagram
The BPEL implementation itself is a relatively straightforward micro-flow that involves a sequence of calls to the various provided services, as shown in Figure 14.
Figure 14. BPEL sequencing of calls to EJB operations
Figure 15 shows the detail of one of the calls to the EJB services. In this
case, we're using the
getOrder operation of the
OrderService EJBM (earlier you saw that the EJB
exposed several operations; however this is the only one we need for our
purposes). Notice also how the operations parameters on the EJB are mapped
to variables within the BPEL process (for instance the Order POJO return
type is mapped to a corresponding variable).
Figure 15. BPEL example of Invoke partner service
In the next step in the BPEL process, shown in Figure 16, an Assign is used to map some parameters that are going to be needed in a subsequent Invoke of another partner service.
Figure 16. BPEL Assign
In the next step, a Java snippet, shown in Figure 17, is used to perform
some simple mapping and data manipulation in order to complete the
population of some specific data fields that are needed in the response
InvoiceDetails business object that
was defined in Process Designer by the business author).
Figure 17. BPEL Java snippet
The last step in the process involves using another Assign to map the
various data fields from various sources into the target
InvoiceDetails structure, which will then be
returned to the invoking service in the
Figure 18 shows the Assign.
Figure 18. BPEL assign to construct AIS response
Note that we've used combinations of Java snippets and Assigns in the BPEL in this example for expedience. For a more reusable approach you would normally use data maps or even a call out to a mediation flow where the data mapping is visually constructed.
Let's turn again to the toolkit that is now visible in the Integration Designer workspace. The Assembly Diagram in Figure 19 shows that the AIS Export is connected directly to an SCA Import, which corresponds to the Export previously shown in the SCA module.
Figure 19. Toolkit implementation delegates to SCA module
The toolkit implementation is extremely lightweight – effectively delegating to the real implementation in the separate SCA module. This reduces the overhead of Process Center having to manage a lot of technical detail in the implementation module that is not appropriate to be surfaced to the BPM layer.
In order to demonstrate that all the pieces work together, in Process Designer a simple illustrative BPD has been provided in the toolkit, as shown in Figure 20. The BPD provides a human service to allow a user to enter the data to search against, then it calls the AIS as the implementation of a system lane service, and finally a further human service is used to display the resulting invoice that is returned from the AIS.
Figure 20. Example BPD invoking AIS in system lane
In order to test the solution we've implemented, you now need to install the various components on the runtime environment. In this example, all components including the EJBs are installed on BPM Advanced; in a production environment the EJBs are more likely to be installed separately onto a WebSphere Application Server node and called using their remote interface from the SCA module running on BPM Advanced.
Because the EJBs and SCA module are to be managed outside of the Process Center, they to be explicitly installed into the runtime server (as opposed to the toolkit, in which the current or version is active and ready to be tested on the Process Center server). First you can install the EARs containing the EJBs using the WebSphere administrative console (you could also use the wsadmin command scripting environment if you prefer). The EAR files would have been exported out of the Integration Designer workspace in order to allow them to be installed onto the server (versions of the EAR files for both V8 and V7.5.1 of BPM Advanced are provided for download in the zip file included with this article).
Figure 21 shows the Enterprise Applications section of the administration console, where existing enterprise applications are listed and you can install additional ones.
Figure 21. Administration console showing enterprise applications
Figure 22 shows the summary of the installation wizard before installing the first EAR file (in this example, the CustomerEJB EAR file).
Figure 22. Example of an enterprise application installation wizard
After installing the enterprise application containing an EJB, the console output should look similar to Figure 23. Next you can start the enterprise application so that the EJB contained in it is available to receive requests. For the example scenario, you need to repeat the process to install the other enterprise application (OrderEJB EAR).
Figure 23. Console showing enterprise application successfully installed
The SCA module is also exported from Installation Designer and you should install it into BPM Advanced using the WebSphere administration console. Figure 24 shows the output from the console when the installation has succeeded (the supplied EAR is OrderSCAClient_8_0.EAR or OrderSCAClient_7_5_1.EAR depending on your product version).
Figure 24. Console showing SCA module successfully installed
Start this SCA module as you did with the enterprise applications so that it is available to serve requests. You can either start the EAR in the enterprise applications or you can access the SCA module and start it as shown in Figure 25.
Figure 25. Start SCA module
Now that all the back-end components are installed and started, you can run an end-to-end test to prove the AIS connects to the EJBs via the SCA module and BPEL micro-flow. Figure 26 shows the Process Inspector view of Process Designer, showing the completion of the first human service with some sample values.
Figure 26. Process Inspector view showing search criteria provided
After completing the initial human service, the process then invokes the AIS and provides the result data to the next human service. The Coach displays the results of the invoice data that was fetched from the BPEL (and in turn the EJBs), as shown in Figure 27.
Figure 27. Process Inspector showing data returned from AIS call
You've now successfully executed the end-to-end scenario for a BPD process through an AIS to a BPEL micro-flow orchestrating calls to some EJBs.
This article described a logical architectural layering and separation of concerns between business processes in the BPM layer and provided SOA services. It introduced how to implement such an architecture in BPM Advanced, focusing on managing the correct level of detail in the correct tool using Process Designer and Integration Designer.
The article presented a detailed working scenario supported by an executable solution that demonstrated the role of AIS in providing the link between business processes and aggregations of lower-level technical services.
The author would like to thank Andy Garratt for his valuable review and contributions to this article. Andy is a Certified Consulting IT Specialist and the United Kingdom and Ireland BPM Practice Lead in IBM Software Services for WebSphere.
|Sample solution files||AISExemplarSource.zip||1.6MB||HTTP|
- Implementing the facade pattern using IBM Business Process Manager
- Best Practices when using IBM Integration Designer and IBM Process
Business Process Manager V8 Information Center
Get the latest technical resources on IBM BPM solutions, including
downloads, demos, articles, tutorials, events, webcasts, and
Journal: Get the latest articles and columns on BPM solutions in
this quarterly journal, also available in both Kindle and PDF versions.
Fintan McElroy is a senior consultant for IBM Software Services for WebSphere (ISSW), whose mission is to assist IBM’s customers in their adoption of WebSphere products. Fintan has 18 years IT experience in a variety of roles including Infrastructure Architecture and Design, Application Architecture, Business Analysis, and Application Development. He has been a leading proponent of BPM with SOA since its inception and before that had been a practitioner of object-oriented architecture and design methods. He currently provides consultancy to IBM's customers on enabling agility in their enterprise through the adoption of IBM Business Process Manager and related products.