The SCA* buses provided

When you create a WebSphere Process Server stand-alone profile or a deployment manager profile, you get an enterprise service bus based on two service integration buses. These buses, with names starting SCA, are for you to deploy SCA modules.

SCA.SYSTEM.cell_name.Bus
This is the bus used to host queue destinations for SCA modules, such as mediation modules that provide service integration logic in the enterprise service bus. The SCA runtime (exploited by mediation modules) uses queue destinations on the SCA.SYSTEM bus as a robust infrastructure to support asynchronous interactions between components and modules.
SCA.APPLICATION.cell_name.Bus
This bus is used to create resources for modules deployed with JMS bindings. This bus is an example of how you might create a service integration bus for use other than to deploy SCA modules.

The SCA.SYSTEM bus provides a scope within which resources, such as queue destinations, are configured for mediation modules and interaction endpoints. The bus enables message routing between endpoints with specific quality of interaction service and can temporarily persist messages if required. You can configure a variety of quality of service from secure, assured delivery (where messages are guaranteed not to get lost and are transported securely) to best-effort (where messages might get lost in case of a system failure). Endpoint implementers choose their desired quality of service by declaring the annotations on SCA module exports and imports. If a quality of service is not specified, WebSphere Process Server applies its defaults.

Figure 1. The SCA.*buses for a stand-alone server profile. The service integration buses created when you install WebSphere Process Server.
The bus environment created when you install WebSphere Process Server with a stand-alone server profile. This environment comprises two service integration buses for you to deploy service applications into. Each bus contains the ESB server named server1 as its only bus member that provides the one messaging engine for the bus.

In a stand-alone profile, there is one bus member that provides the one messaging engine in a bus, a topology that is adequate for some applications.

A single messaging engine might not be adequate if the number of client connections becomes excessive, if the rate of message throughput cannot be sustained by the one messaging engine, or if the size of messages has a detrimental affect on the message buffers used by the messaging engine.

To add more than one messaging engine to a service integration bus, you need to use a profile for a managed node in a deployment manager cell.


Terms of use |

Last updated: Thu Apr 27 14:23:45 2006

(c) Copyright IBM Corporation 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)