Over the past few years we have seen many of our customers use a combination of Oracle BPM/Aqualogic BPM and Oracle Service Bus/Aqualogic Service Bus. These two products are very complimentary within a company's SOA environment. OSB can provide the service aggregation, transformation, and security while OBPM can provide the orchestration of the services that OSB exposes. This blog post will describe the different use cases for integrating OBPM and OSB and in follow up posts each integration will be covered in more detail.
There are several ways in which OSB and OBPM can be combined. The basic architecture that represents most of these ways is displayed below. This design consists of an application layer, the service bus layer, the process layer, and a web services layer.
The approaches in which OSB and OBPM can be integrated can be categorized into two categories, OBPM Consuming OSB Services and OSB Exposing OBPM Services.
OBPM Consuming OSB Services
Consuming OSB services via Oracle BPM is the most commonly used integration. This integration approach facilitates the service orchestration use case where you have a set of web services exposed through OSB. These services usually provide an interface to a backend datasource or legacy system. Just like any other web service, OBPM can consume the proxy services that are exposed from OSB by providing the WSDL file to OBPM and having a Web Service object generated in your component catalog. There is also a more direct integration between OBPM Studio and OSB where you can view the list of available services directly from within OBPM Studio and select the service to add to your catalog. Both of these ways of consuming services within OBPM will be covered in more detail in a follow up post.
OSB Exposing OBPM Services
There are 3 ways in which OBPM can expose services to OSB:
- Process Web Services
- JMS Queue
Process Web Services - The ability to expose a process as a web service is a built in capability of OBPM. With this approach, you can expose either Process Instance Creation or Process Notification easily from within Studio.
PAPI-WS - This is a web service version of the Process API (PAPI). This API is much lower level then the Process Web Services but also provides much more functionality such as searching for process instances and executing activities.
JMS Queue - This requires creating JMS based XML Business Services in OSB to post the messages to the JMS Queue. OBPM can then use a Global Automatic activity to listen to the same queue and create process instances based on the incoming messages. It is also possible to have a response queue as well which allows you to simulate a synchronous process. In this case, the web service call does not return to the client until OSB receives a response message on the response queue. Your BPM process would send this response message at the end of the process. However, the synchronous use case is only practical in completely automated processes.
As you can see, there are a number of different ways you can combine Oracle BPM and Oracle Service Bus to provide flexibility within an SOA environment. The combination of OBPM and OSB has been utilized by a number of our clients with great success due to the flexibility provided by both systems.
In the upcoming weeks I will follow up this post with additional details on each of these integrations and will cover consuming OSB services in OBPM, exposing process web services, exposing PAPI-WS, and exposing processes as synchronous web services using JSM.