WebSphere Process Server is a high-performance business engine to help form processes to meet business goals. It allows the deployment of standards-based business integration applications in a service-oriented architecture (SOA), which takes everyday business applications and breaks them down into individual business functions and processes, rendering them as services.
IBM® WebSphere® Process Server is a business process integration server that has evolved from proven business integration concepts, application server technologies, and the latest open standards. WebSphere Process Server is a high-performance business engine to help form processes to meet business goals.
WebSphere Process Server allows the deployment of standards-based business integration applications in a service-oriented architecture (SOA), which takes everyday business applications and breaks them down into individual business functions and processes, rendering them as services. Based on the robust Java EE infrastructure and associated platform services provided by WebSphere Application Server, WebSphere Process Server can help you meet current business integration challenges. This includes, but is not limited to, business process automation.
WebSphere Process Server enables the deployment of processes that span people, systems, applications, tasks, rules, and the interactions among them. It supports both long-running and short-running business processes, providing transaction rollback-like functionality for loosely coupled business processes.
WebSphere® Process Server is a service-oriented architecture (SOA) integration platform built on a uniform invocation programming model and a uniform data representation model. It provides a standards-based business process engine, using the full power of WebSphere Application Server.
The base runtime infrastructure for WebSphere Process Server is WebSphere Application Server. The Service Component Architecture and business objects that are part of the SOA core provide the uniform invocation and data-representation programming models. The SOA core includes the Common Event Infrastructure for generating events for the monitoring and management of applications running on WebSphere Process Server.
Supporting services provide the foundational business object and transformation framework for WebSphere Process Server. Service components represent the functional components required for composite applications.
The combination of a powerful foundation (WebSphere Application Server and the SOA Core) and service components in WebSphere Process Server allows quick development and deployment of sophisticated composite applications that run on WebSphere Process Server.
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 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 is used for this purpose.
Furthermore, the Infrastructure layer provides a variety of messaging resources that are based on Web Sphere’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 is completely hidden by the SCA artifacts. 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, such as Web Services Binding 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 easier.
One of the major components in this layer is the Business Process Choreographer that can be considered the execution container for business processes and human tasks. 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. 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 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.
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, and 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 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.
File Name | Description | Size | Download Link | |
IBM WPS.Pdf | 300 KB | |||
