About this article
This article completes my series on IBM WebSphere Process Server’s operational architecture (you may want to have a look at part 1 as well). It was published on IBM developerWorks in February 2009.
>>> Read the complete article <<<
Introduction
The final installment of this two-part series describes the operational architecture of IBM WebSphere Process Server and explains how its core components work. In this article, you learn about the components that build WebSphere Process Server’s runtime layer and how they work together in an operational environment. You examine SCA modules at runtime and then explore the function layer to understand how WebSphere Business Process Choreographer manages your business processes, what CEI is for, and what you should know about the supporting services.
[…]
SCA Modules
[…]
In terms of Process Server, IBM offers a large variety of SCA Component implementations in the development environment (WebSphere Integration Developer) for use in the runtime.
Commonly used implementation types:
- Process (BPEL). Enables execution of business processes. This implementation involves the use of BPC (see the next section) and Process Server’s data silos (see Resources for Part 1 of this series, section “Database”).
- Human Tasks. Enable human interaction with business processes. This implementation involves the use of BPC (see the next section) and Process Server’s data silos (see Resources for Part 1 of this series, section “Database”).
- Java. Lets Integration Developer’s write custom Java code within a module.
- Rule Group. Provides the ability to define certain business specific parameters (for example, “Buying Approval Cap”), which can be used to change the behavior of business processes at runtime. This involves the use of Process Server’s data silos (see Part 1 of this article series (Database section) in the Resources section of this article). Interface Maps. Enables data and interface transformation.
From an operational point of view, the actual assembly model of an SCA module is almost completely hidden at runtime (see Figure 2). Therefore neither operators nor administrators have a clear visual representation of the SCA components contained in a module. The only person who can provide a visual overview of the module contents is the Integration Developer. At this point, it is important to keep in mind that detailed information on the contained SCA Components and their implementation types is required in a variety of situations: troubleshooting and performance analysis for example.
Recommendation: Therefore, it is important that the development and operation teams extensively share information. Due to the higher complexity of SCA solutions, in comparison with traditional J2EE projects, this aspect is highly critical for the successful operation of a Process Server infrastructure.
[…]