Rakesh Kumar:
Contact No: 0091-9700330693.
001- 3237843863.
001- 3237843863.
WebSphere Process Server operational architecture:
Part 1: Base architecture and infrastructure components:
Introduction
WebSphere Process Server consists of many components that are closely connected and makes use of many different concepts like Service Component Architecture (SCA), Business Process Choreographer (BPC) and Service Integration Bus (SIB). Although these concepts are well documented, it is very difficult to get an overview of how these concepts work together within IBM WebSphere Process Server. Since this knowledge is crucial for the successful operation of business process applications running on WebSphere Process Server, this article provides a detailed and insightful view of the technical coherences of the concepts mentioned above. It describes which resources (for example SIB Destinations) are involved when running SCA modules and how they relate to each other. Moreover, the article covers the technical background of BPC (including execution of BPEL processes) and therein emphasizes the relations to the underlying concepts like SCA. Finally, it highlights the error conditions that can occur and shows how they can be identified (Failed Event Manager, Exceptions Queues, and so forth) from an operational point of view.
This article gives IT architects and WebSphere administrators a great opportunity to understand the operational background of WebSphere Process Server and the relationships between these concepts and technologies to help better manage your SOA infrastructure.
The final article in this series, Operational view on WebSphere Process Server V6.1, Part 2: SCA Runtime, Business Process Choreographer and Supporting Services, further explores the operational architecture of IBM WebSphere Process Server. You'll learn which components build WebSphere Process Server's runtime layer and how they work together in an operational environment from a technical point of view. In this respect, you'll understand how SCA modules look at runtime and how Business Process Choreographer manages your business processes. You'll gain a holistic view of Process Server's operational architecture and moreover you'll get a better understanding of how to establish a successful WebSphere Process Server operation in your organization.
Nowadays every (IT) person, whether you take an IT Specialist or a more business-focused consultant, has a personal definition of what SOA is or is not. This begins with a thousand and one explanations of the term “service” and ends with millions of possible implementation techniques. This article does not attempt to define SOA but instead tries to establish a common high-level understanding of what SOA means and the role WebSphere Process Server plays in a service-oriented world. Finally, you will be introduced to WebSphere Process Server's building blocks and technical details that will help you understand WebSphere Process Server architecture from an operations perspective.
Let us begin with the term SOA. When taking into account that you cannot buy SOA and SOA is not even a product, we can define it as a concept. Conceptually, SOA structures IT infrastructure in a special way where the focus lays on component-orientation, composition, reuse, and flexibility. Moreover, the concept aligns IT infrastructure to business needs, whereas the business itself is the driver for all initiatives. However, this actually means that SOA defines an architectural style, nothing more, nothing less.
From a conceptual point of view, several crucial requirements for the technical implementation of an SOA must exist:
- A common approach, or common language for defining components and interfaces
- Contracts between different components through a common interface definition
- A platform to enable components to work together in a corporate, or even an inter-corporate, environment
- A method to orchestrate components and to foster composition
In addressing these requirements, the Open Service Oriented Architecture (OSOA) initiative has defined a new industry standard called Service Component Architecture (hereafter named SCA), see Service Component Architecture (SCA) specifications in the Resources section for more information. The core idea behind SCA is to establish a common component model for the definition of business services. In this respect, the term service means an abstract service that is provided by a generic service provider; for example, a “bank inquiry” or “loan approval”. From a more technical point of view, SCA defines the frame around business components (via a common interface definition) and enables them to communicate with each other over corporate boundaries. Due to the broad acceptance of SCA by a large number of software manufacturers, it can be considered as the de facto specification for implementing SOA as an architectural style, see larger image Figure 1. Classification and demarcation of WebSphere Process Server.
As already discussed, SCA defines how components and interfaces can be defined and how you can call them. However, the OSOA initiative does not provide any actual implementation that you can use as an execution platform.
At this point, WebSphere Process Server comes into play, since it is IBM's implementation of the SCA (and related) specifications. With its role as an execution platform for SCA applications, WebSphere Process Server is one of the main building blocks in IBM's SOA portfolio. Furthermore, it is the runtime platform for business processes (for example, BPEL processes, Human Tasks, and so forth) developed with WebSphere Integration Developer, and therefore, plays a very important role in the SOA infrastructure of a company.
As mentioned earlier, WebSphere Process Server is IBM's execution platform for so called SCA modules (applications that implement the SCA specification). Due to its central role in a service-oriented environment, it is really crucial to understand the server's main building blocks and how they relate to each other. In this respect, the following illustration introduces an operational reference architecture, which will be used as a starting point. Moreover, it will be used to explain the technical coherencies between the components throughout the entire article, see Figure 2.
The WebSphere Process Server architecture is mainly defined by three layers that build the very basis for business applications:
- Infrastructure layer
- Runtime layer
- Function layer
All of these layers depend on each other from the bottom up.
Infrastructure layer
The components in the Infrastructure layer provide the very basic functionality for all the above layers. One core function is the persistence of business data (from business applications or Business Process Choreographer for example) and runtime data produced by messaging facilities and other components. Since the validity and integrity of this data is really crucial for WebSphere Process Server's role, an enterprise scale database system (see WebSphere Process Server: Detailed list of system requirements in the Resources section for more information) for a detailed list of options) is used for this purpose.
Furthermore, the Infrastructure layer provides a variety of messaging resources that are based on WebSphere's Service Integration Bus technology (also referred to as WebSphere Platform Messaging). On the one hand, these are heavily used by the SCA runtime for asynchronous communication and buffering. On the other hand, the resources are also leveraged by almost all components in the Function layer.
Runtime layer
This layer provides the basic service component functionality from a SCA point of view. It incorporates IBM's implementation of the SCA standard, which is called SCA runtime hereafter. This part of the layer provides the ability to run SCA modules and moreover enables the contained components to communicate with each other. An very important aspect concerning the communication is that the technical foundation (and also the concrete implementation of the functionality) is completely hidden by the SCA artifacts (so a developer just defines “component A makes a synchronous call to component B”). Actually the SCA runtime is responsible for choosing the right communication channel and for doing the actual work. In this respect WebSphere Process Server heavily uses the underlying messaging capability, located in the Infrastructure layer.
Besides the additional functionality provided by the SCA runtime, WebSphere Process Server also includes core WebSphere Application Server capabilities. The application server enables the use of technologies like JMS (including MQ JMS connectivity), Web Services, J2EE Container services, JDBC database access and so forth. These are finally used by the SCA runtime to provide different kinds of binding types (consider a “binding” as the technical realization of SCA-like interface to the outside world; also see (Service Component Architecture (SCA) specifications in the Resources section for more information) for a list of generally possible types), such as Web Services Binding oder EJB Binding, to developers.
In summary, the Runtime layer builds the core of WebSphere Process Server's function as an execution platform for applications which are implemented according to the SCA assembly model.
Function layer
As described in the previous sections, the Infrastructure and the Runtime layer provide core services for running SCA applications. In addition to the actual implementation of the SCA assembly model, WebSphere Process Server features several SCA component implementation types (such as BPEL or Java™), and also many complementary services, that make the integration developer's life much more easier.
One of the major components in this layer is the Business Process Choreographer that can be considered the execution container for business processes (using the SCA BPEL Implementation Model; also see Service Component Architecture (SCA) specifications in the Resources section for more information) and human tasks (see WS-BPEL Extension for People in the Resources section). Since SOA is a rather business-centric approach, many SCA modules tend to make use of the so called Business Process Execution Language (BPEL) to a certain extent and will therefore get in touch with Business Process Choreographer from an operational point of view.
Besides the BPEL component, WebSphere Process Server supports a number of additional components and services that are not directly part of the SCA standard, but however may be leveraged by integration developers. One of the more common ones are Selectors and Business Rules (also see the Resources section for more information, Make composite business services adaptable with points of variability, Part 3: Using selectors and business rules for dynamicity). These components have a certain influence on the overall operational perspective on a WebSphere Process Server environment, since they use the underlying messaging and persistence capabilities, and because they can be relied on by modules in the Business Application layer.
Finally, the Common Event Infrastructure (hereafter called CEI) is located in the Function layer. CEI can be considered as a framework for logging business events, auditing and/or monitoring the execution of SCA components (and even business processes). The framework tightly integrates into IBM's SCA implementation, so that CEI can be used to generate a large variety of events that can furthermore be distributed to a variety of targets. For instance, CEI events may be used by a BPEL developer to report execution statistics of a SCA components to a monitoring console (consider IBM Tivoli Enterprise Portal). However, CEI is not directly related to the SCA standards itself, but it is highly inter operable with other IBM products, such as IBM WebSphere Business Monitor (see Business Activity Monitoring with WebSphere Business Monitor V6.1in the Resources section for more information), to enable Business Activity Monitoring (BAM) solutions.
Business Application layer
The actual SCA modules are closely connected to WebSphere Process Server's Function layer, since they make heavy use of all the capabilities, such as BPEL, human tasks, CEI events and so on, from a operational point of view (this complexity is actually hidden from the developer). All other layers are more or less hidden from the applications.
In summary, WebSphere Process Server's operational reference architecture can roughly be structured in three different layers, whereas the lowest provides basic infrastructure capabilities, such as persistence and messaging. The Runtime layer contains the actual runtime implementation of the SCA assembly model and enables WebSphere Process Server to be an execution platform for SCA modules. Finally, the Function layer exposes several SCA component implementations (such as BPEL, Java, Human Tasks) to be leveraged by business application developers.
In this section, you are introduced to the general concepts behind the Service Integration Bus (SIB) technology that is used for asynchronous communication within WebSphere Process Server. First,ly, the SIB related technical terms are clarified and set in relation to each other by joining them into a layer model. The second part of this section gives an overview over the different SI-Buses that are used in an operational WebSphere Process Server environment and how interaction with them takes place.
SI-Buses were introduced in WebSphere Application Server V6 and replaced WebSphere MQ Series as the former internal platform messaging implementation. The implementation is completely Java based and all objects exist within the WebSphere Application Server runtime.
The following picture provides an overview of the different components that belong to WebSphere Platform Messaging technology. More precisely speaking, it shows four layers that you should interpret top-down (for a better understanding).
Application layer
Java EE applications that make use of asynchronous messaging standards and concepts reside on the Application layer. For example, a Message Driven Bean (MDB) utilizes the Java Messaging Service (JMS) standard to process messages asynchronously.
JMS layer
The JMS layer encapsulates the concrete implementation of a JMS provider by introducing the concept of so called JMS artifacts. A JMS artifact represents a logical object that points to a physical resource. One of these JMS artifacts are so called JMS Destinations. JMS knows two of them: namely JMS Queues and JMS Topics. The former are used for point-to-point messaging and the latter in publish-subscribe scenarios. Other JMS artifacts are JMS Connection Factories that abstract from the connection handling for JMS Destinations, for example, pooling concepts are hidden from the JMS API user. Also, a JMS Activation Specification belongs to the JMS artifacts. Such an Activation Specification is based on the Java Connector Architecture (JCA) that provides a standardized way to communicate with enterprise information systems using Java. JMS Activation Specifications represent a group of messaging configuration properties that could differ for each JMS provider.
Logical SIB layer
The logical SIB layer links the artifacts introduced by the JMS standard to WebSphere-specific resources. Although acting as a JMS provider is only one of many functionalities of the WebSphere Default Messaging, some core concepts of an SIB can be described best as having JMS in mind.
A bus can be seen as an architectural concept that is used by message-based applications and is defined by a set of servers or clusters, that are characterized as Bus Members in general. For the connection between the JMS layer and the SIB a Java 2 Connector Architecture (JCA) compliant Resource Adapter is used. A Resource Adapter implements a standardized way to connect a specific system (in this case the SIB) to a Java-based environment. The only requirement is that the Java environment acts as an JCA provider. In fact, each Java EE compliant application server like WebSphere Application Server does and therefore using a Resource Adapter fits well . Some of the advantages that come out of the box by using a Resource Adapter are transactional integrity and fine grained Quality-Of-Service concepts. The SIB JMS Resource Adapter will be described in more detail below.
On the logical SIB layer, there additionally exist components named Queues and Topics. It is important to keep in mind that these terms mean something different than JMS Queues and JMS topics. Nevertheless, a JMS Queue and an (SIB) Queue feature a one-to-one relationship; they differ with respect to their placement and their technical realization. In the same manner, Destinations are different from JMS Destinations and are only umbrella terms for SIB Queues and Topics. In the model above, it could be seen that a Destination for example, a Queue is uniquely assigned to a Bus Member.
Physical SIB layer
So far, only different abstraction layers have been described in this article. Nothing has yet been said about the physical model of SI-Buses . Obviously, each Destination has to have at least one persistent store in order to save its contents and its context data. Furthermore, a technical component is needed that is used to save this data and get it from that persistent store. The component realizing this requirement in an SIB is called a Messaging Engine (ME). Each ME is related either to a database or a file store to persist its data.
The physical objects representing SIB Destinations are called Message Points. For each kind of Destination, a different term is used for the corresponding Message Point: a Destination of the type "Queue" is represented by Queue Points and a Destination of the type "Topic" is represented by "Publication Points". Each Message Point belongs to exactly one Destination but several Message Points could exist for one Destination (in case of cluster bus members). A Message Point is always assigned uniquely to one ME.
View on the operational Messaging Engine architecture
When talking about WebSphere Process Server reference topologies (as described in Production Topologies for WebSphere Process Server and WebSphere ESB V6 in the Resources section), there will most likely be only one ME running per bus member and bus, which actually is considered as the default behavior. In the case of simpler WebSphere Process Server topologies, like non-clustered ones, this is the only possible scenario. Considering more complex topologies, like the so called “Remote Messaging and Remote Support” topology (speaking of WebSphere Process Server V6.0, this was referred to as Full Support or Golden topology), clusters are used to enable the high availability of the WebSphere Process Server messaging infrastructure.
In this respect, you can use different configurations that can be described best with a cluster consisting of two cluster members assigned to a SIB. The default behavior is that only one ME is active on one cluster member and will only become active on the other cluster member if the first one fails (see Figure 3 above). As stated earlier, this scenario enables messaging high availability and will usually be seen in enterprise scale WebSphere Process Server environments.
When thinking of performance and scalability, another setup is possible where each cluster member hosts its own active ME and each ME owns a Message Point for a Destination assigned to the Bus-Member. Therefore messages on the Destination can be processed by both cluster members. Nevertheless, such a setup has some drawbacks:
- Message order cannot be guaranteed, because each message may be processed by any one of the cluster members.
- With only two cluster members fail over is not possible, because each ME has its own datastore assigned and only one ME per cluster member can be active for one SIB. As a result, data of Message Points cannot be transferred from one ME to another.
The concept of using more than one active ME per Bus Member is referred to as Partitioned Destinations (see figure above). However, the usage of Partitioned Destinations is currently not recommended in terms of WebSphere Process Server reference topologies.
As mentioned above, a JCA Resource Adapter is used to link JMS resources and the SIB. This "SIB JMS Resource Adapter" manages the JMS artifacts and especially the JMS Activation Specifications where properties like the bus, destination name and concurrency information for the processing are stored. It is important to realize that the Activation Specification settings are a focal point for adjusting performance because they influence how many messages may concurrently processed (in the context of their functional role, they are comparable with Thread Pools).
The SCA runtime is not using the SIB JMS Resource Adapter but the "Platform Messaging Component SPI Resource Adapter" where SPI stands for Service Provider Interface. This Resource Adapter hosts the Activation Specifications of SCA Modules that are also important with respect to overall performance and processing in asynchronous communication paths. During the deployment of SCA Modules, no Connection Factories are created explicitly on the SIB SPI Resource Adapter, but instead the SCA runtime creates Connection Factories programmatically using the low level SIB Core API. Therefore the properties of these Connection Factories, such as the Connection Pool settings, are not visible and can't be changed by an administrator for tuning purposes. For the SIB JMS Resource Adapter, this is different because Connection Factories are created explicitly, and therefore all settings can be seen in the WebSphere Admin Console. The following figure visualizes the differences between both Resource Adapters.
The following figure shows the four SI-Buses used within WebSphere Process Server. This section gives only a short overview about the buses. The details of the destinations are discussed in the subsequent sections.
- The BPC Bus is used by the Business Process Choreographer for executing long running processes. Messages on the BPC Bus are so called navigational messages, which hold status and processing information about the corresponding processes. For example, the transition from one activity to another may lead to a navigational message, if each activity participates in its own transaction. The transactional behavior can only be changed during development time and can neither be viewed nor be changed at runtime.
Setting the optimal transaction boundaries may be considered as one of the key performance aspects for process implementations for different reasons. First, transaction context switches are quite expensive operations in terms of computation time. Second, crossing transactional boundaries leads to a navigational message in the case of long-running processes, which is also more expensive than staying within the same transaction. - The SCA System Bus is used by the SCA runtime for asynchronous communication between SCA components and SCA modules. The messages flowing through the Bus contain business data (originated from requests between the different SCA artifacts) and are not used for navigational purposes as with messages on the BPC bus.
- The SCA Application Bus is most commonly used for custom destinations of SCA Modules. For example, the JMS Destinations referred to by an JMS Export should refer to Destinations residing on this bus.
- The CEI Bus is used for asynchronous event transmission. The messages on this bus are the events that are picked up by a special MDB to be transferred for further processing to the so called Event Server application.
This section gives an overview over the database architecture of WebSphere Process Server. The following picture shows a more logical view of the different databases used by WebSphere Process Server.
By default, WebSphere Process Server V6.1 installs all database objects into one single database. However, it is not required to place all database objects of the different data silos into different databases, so a common practice is to place the silos in separately manageable data silos for performance and scalability reasons.
- The WPRCSDB silo contains configuration and cell wide data of WebSphere Process Server. For example data about some SCA components (Business Rules, Selectors, Relationships) is stored here. Furthermore, the data silo contains the Failed Event data. Because Failed Event information is needed in some cases to restart failed SCA flows, the availability of this data is quite important. This database exists just once per WebSphere Process Server cell.
- The MEDB silo is used by the Messaging Engines running in WebSphere Process Server messaging infrastructure (see the previous section for more details) to persist messaging data: transaction context, message payload and administrative information. Each (active) Messaging Engine needs its own Schema within this database.
- The EVENT silo data silo contains the data of the Common Base Event Infrastructure. If the option to persist all event data is selected it will be placed here.
- The BPEDB silo contains Business Process Choreographer data, amongst other things the template data of processes and human tasks, status information of long running processes, and so forth. This data silo can exist several times in a cell if more than one server or cluster is configured for running Business Processes and/or Human Tasks.
Each of the data silos mentioned corresponds to one or more so called Data Sources within the WebSphere Process Server cell. A Data Source provides the connection properties to the underlying database along with connection pooling mechanisms. It is quite important to understand that these settings affect how WebSphere Process Server is performing. A good example to illustrate this is the maximal number of connections to the BPEDB. This value limits the concurrency of long running business processes to that number, because each process needs to write data to the BPEDB data silo.
This article introduced an operational reference architecture for WebSphere Process Server that you can use as a basis for all operational efforts around your WebSphere Process Server enabled SOA infrastructure. In addition, you have learned that WebSphere Process Server makes heavy use of messaging and persistence features and that the proper operation of these plays a significant role on the road to a successful service-oriented environment.
In the final article of this series, Operational view on WebSphere Process Server V6.1, Part 2: SCA Runtime, Business Process Choreographer and Supporting Services, you'll learn about the components located in the Runtime layer and Function layer from an operational point of view.
No comments:
Post a Comment