The messaging engine database specifications lists supported
database type; scripts and their locations; profile creation types;
and necessary user ID privileges.
The messaging engine database is used to store operating information.
Also stored are essential objects that the messaging engine needs
for recovery in the event of a failure.
The messaging engine database is used by the message engines for
Service Component Architecture (SCA) and
Common Event Infrastructure. The default database
name for the SCA messaging engine is SCADB, for the other messaging
engines it is MEDB. For the
Derby Embedded database,
each messaging engine will have its own database or schema. The default
schema name is IBMWSSIB.
Note: Multiple schemas are not supported
by all database types, refer to your database documentation for details.
In a standalone environment, you can configure your SCA messaging
engine using the administrative console Servers -> Application
servers -> server -> Business integration -> Service
component architecture configuration page. In a patterned network
environment, the messaging engines are configured during installation.
However, for a custom network environment, you need to configure the
messaging engines manually. See "Custom deployment environment layout
configuration" for more information.
You have a lot of control over the messaging engine databases,
for example, you can create a database for each messaging engine or
you can use a single database for all the messaging engines. Each
messaging engine must have either its own database or schema.
Supported Database Types
The messaging engine
database can use the following database products:
Table 1. Supported
database productsDatabase Types |
Considerations |
Derby Embedded |
Used
as the default database type for a standalone server. |
DB2 for z/OS v8
DB2 for z/OS v9
|
Important: When creating a profile
for a server that uses DB2 for z/OS v9,
the server must be able to connect to the DB2® database.
Used
as the database in network deployment configurations. Optionally,
can be used as the database in stand-alone server configurations. |
Database Management Service (DBMS) instances
Each
messaging engine has its own database or schema:
- One is used to host each messaging engine for the Service Component Architecture system bus.
- Another is used to host each messaging engine for the Service Component Architecture application
bus.
- Another is used to host each messaging engine for the Common Event Infrastructure bus.
The naming convention for the JDBC data source that the messaging
engine uses to interact with the database is:
- System bus: <node><server>|<cluster>-SCA.SYSTEM.<cell>.Bus
- Application bus: <node><server>|<cluster>-SCA.APPLICATION.<cell>.Bus
- Common Event Infrastructure: <node><server>|<cluster>-CommonEventInfrastructure_Bus
The
Derby database
naming convention is shown below:
- System bus: configuration_root/app_server_root/profiles/profilename/databases/com.ibm.ws.sib/(<node>.<server>|<cluster>)-SCA.SYSTEM.<cell>.Bus
- Application bus: configuration_root/app_server_root/profiles/profilename/databases/com.ibm.ws.sib/(<node>.<server>|<cluster>)-SCA.APPLICATION.<cell>.Bus
- Common Event Infrastructure bus:
configuration_root/app_server_root/profiles/profilename/event/DerbyEventBusDB/(<node>.<server>|<cluster>)-CommonEventInfrastructure_Bus
The default for <cell>
is the cell name.
Database actions invoked by the product
configuration script
Stand-alone profile
The
message engine database is created during the installation and configuration.
Network
deployment
You can configure the message engines for Service
Component Architecture using the Application servers > servername > Service
Component Architecture panel in the administrative console.
The
following administrative tasks are performed when the profile is created:
- Remote Destination Location:
- configSCAAsyncForServer, configSCAJMSForServer (remoteMELocation
is true)
- configSCAAsyncForCluster, configSCAJMSForCluster (remoteMELocation
is true)
- Local Destination Location:
- configSCAAsyncForServer, configSCAJMSForServer
- configSCAAsyncForCluster, configSCAJMSForCluster
For both tasks, the following parameters are handed over:
- busDataSource
- meAuthAlias
- busSchemaName
- createTables
- systemBusId (the default is the cell name)
JDBC provider
Service Component Architecture
The
JDBC provider is reused when the JDBC provider implementation class
has to match with the one chosen in the advanced configuration. This
usually means that if the same database types are used, then the implementation
classes usually match. If no matching JDBC provider is found in the resource.xml file,
then the jdbc-resource-provider-templates.xml file
under templates/system (profiles configuration)
is searched for a matching JDBC provider. The provider is matched
also against the implementation class.
Common Event Infrastructure
The JDBC
provider creation for messaging engine database is similar to the
approach followed in the creation of the CEIDB database. See "Common Event Infrastructure database specifications" for
more details.
Data source names:
- System bus: : _(node.server|cluster)-SCA.SYSTEM.cell.Bus/cel/cluster/server/node
- Application bus: _(node.server|cluster)-SCA.APPLICATION.cell.Bus/cell/cluster/server/node
- Common Event Infrastructure: _(node.server| cluster-CommonEventInfrastructure_Bus/cluster/server/node
Data source JNDI names:
- System bus: jdbc/com.ibm.ws.sib/(node.server|cluster)-SCA.SYSTEM.cell.Bus/cell/cluster/server/node
- Application bus: jdbc/com.ibm.ws.sib/(node.server|cluster)-SCA.APPLICATION.cell.Bus/cell/cluster/server/node
- Common Event Infrastructure: Jdbc/
com.ibm.ws.sib /(node.server|cluster)-CommonEventInfrastructure_Bus/cluster/server/node
Tables
For
information on the tables see the WebSphere® Application Server topic on "Data
stores".