Service integration bus (SIBus) Web services uses a Service Data Objects (SDO) repository for storing and serving WSDL definitions.
Create and configure your preferred database to store the SDO data,
and create and install the SDO repository application on every standalone server or cluster that is to play an SIBus Web services role.
Before you begin
Why and when to perform this task
Service Data Objects (SDO) is an
open standard for enabling applications to handle data from different data
sources in a uniform way (as DataGraphs). SIBus Web services uses an SDO repository
for storing and serving WSDL definitions.
You
choose the underlying database that the SDO repository uses to store its data.
For a single server configuration you can use your preferred database, or
the default database (embedded Cloudscape) that is supplied with WebSphere Application Server. If you are creating a network deployment configuration
and you want to use Cloudscape, then you must use it with the associated Network
Server application. However, you should be aware of the limitations of Cloudscape Network Server (for example, it does not support transactions).
You install and configure
the SDO repository by using the wsadmin scripting client to run the installSdoRepository.jacl
script.
If you are creating a single server configuration
and you want to use embedded Cloudscape, you run the script with the -createDb switch.
This action creates the Cloudscape database and installs the SDO repository. If
you are creating a configuration that uses a database other than embedded Cloudscape, you install your preferred database product, then create
a JDBC provider and a data source, then run the script twice:
- One time to install the SDO application on the application server.
- One time to set the database type that the SDO repository is to use.
If you are working in a network deployment
environment, you install your preferred database product, then create a JDBC
provider and a data source, then run the
installSdoRepository.jacl script
several times for each cell:
- One time to install the SDO application on the deployment manager.
- One time to set the database type that the SDO repository is to use.
- Several times to install an instance of the SDO application on each server
or cluster that you plan to use for one or more of the SIBus Web services roles.
To install the SDO repository, complete one of the following optional
main steps:
Steps for this task
- Optional: To install the SDO
repository for a standalone server and
use the embedded Cloudscape database, complete the following steps:
- Open a command prompt, then change to the app_server_root/bin directory.
- Enter the following command:
wsadmin.ext -f installSdoRepository.jacl -createDb
Note: The -createDb flag tells the command to create a default (Cloudscape) database. If you
omit this flag, the command still installs an SDO repository that is configured
to use Cloudscape, but the command does not also create the database.
- Optional: To install the SDO repository on a standalone server
and use a database other than embedded Cloudscape, complete the following
steps:
- Create the database for your preferred database supplier using
the Table.ddl file from the relevant app_server_root/util/SdoRepository/database_type directory.
Note: - The Table.ddl file describes the database table that
is needed by the SDO repository.
- Some databases require that a user ID be created and granted permissions
to access the SDO repository database. Create a user ID for user name SDOREP before
you create the tables for Oracle, Sybase, and SQL Server databases. Because
of the way these databases handle user names and table names, the user name
must be SDOREP to enable the SDO repository to access its
table with the fully qualified name SDOREP.BYTESTORE. Make
sure you grant permission for the SDOREP user to read from,
and write to, the database.
- If you use an Informix database do not disable logging.
- You might also choose to perform other steps such as creating an index
of the primary key to improve database performance. Do not change the schema,
table and column names.
For more information, see Deploying data access applications and Recreating database tables from the exported table
data definition language.
- Create and configure a JDBC provider and data source. The SDO repository does not require XA support. In most
cases you can use either an XA or a non-XA data source; however if your database
is Oracle 8 or 9 then you must use the Oracle JDBC driver (non-XA) for the
SDO repository data source. Create a J2C authentication alias, then set
the data source authentication property to use it. Verify that the
authentication alias matches the login details for your database instance,
otherwise a connection is not made. Set the following data source properties:
- Select the Use this Data Source in container managed persistence (CMP) check
box.
- Set the Name field to a name of your own choosing
(for example, SDO Repository DataSource) and the JNDI
name field to a value of jdbc/com.ibm.ws.sdo.config/SdoRepository.
- Complete the data source configuration for your chosen database.
- Optional: Test the data source connection:
- In the administrative console, navigate to your_provider
- Select the SDO repository data source then click Test connection.
Note: The
Test connection option does not work
in all configurations. The availability of this option depends on the scope
at which the data source is defined, and the scope of any WebSphere Application
Server variables that are used in the data source configuration and the data
source JDBC provider configuration. For more information about testing connections
to data sources, see
Test connection service.
- Open a command prompt, then change to the app_server_root/bin directory.
- Install the SDO repository application on the server:
wsadmin.ext -f installSdoRepository.jacl
- Set the database type that the SDO repository is to use:
wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
for example:wsadmin.ext -f installSdoRepository.jacl -editBackendId DB2UDB_V82
- Optional: To configure
the SDO repository for a network deployment cell, complete the following steps:
- Create the database for your preferred database supplier using
the Table.ddl file from the relevant app_server_root/util/SdoRepository/database_type directory.
Note: - The Table.ddl file describes the database table that
is needed by the SDO repository.
- Different repositories must use different databases to ensure they do
not access the same data. You use one SDO repository for each cell, so if
you have multiple cells you use multiple databases, one for each cell.
- Some databases require that a user ID be created and granted permissions
to access the SDO repository database. Create a user ID for user name SDOREP before
you create the tables for Oracle, Sybase, and SQL Server databases. Because
of the way these databases handle user names and table names, the user name
must be SDOREP to enable the SDO repository to access its
table with the fully qualified name SDOREP.BYTESTORE. Make
sure you grant permission for the SDOREP user to read from,
and write to, the database.
- If you use an Informix database, do not disable logging.
- You might also choose to perform other steps such as creating an index
of the primary key to improve database performance. Do not change the schema,
table and column names.
For more information, see Deploying data access applications and Recreating database tables from the exported table
data definition language.
- Create the following node-level WebSphere Application Server
variables on all affected nodes, including the deployment manager node.
Note: You could set these variables at either node or cell scope, depending
upon your configuration. However for multi-platform nodes you cannot usefully
set WAS_INSTALL_ROOT at cell scope, because the nodes have
different installation directories.
- Create and configure a JDBC provider and data source.
Note: The SDO repository does not require XA support. In
most cases you can use either an XA or a non-XA data source; however if your
database is Oracle 8 or 9 then you must use the Oracle JDBC driver (non-XA)
for the SDO repository data source.
Create a J2C authentication alias, then set
the data source authentication property to use it. Verify that the
authentication alias matches the login details for your database instance,
otherwise a connection is not made. Set the following data source properties:- Select the Use this Data Source in container managed persistence (CMP) check
box.
- Set the Name field to a name of your own choosing
(for example, SDO Repository DataSource) and the JNDI
name field to a value of jdbc/com.ibm.ws.sdo.config/SdoRepository.
- Complete the data source configuration for your chosen database.
- Deploy the database client JAR files on each of the host machines
within the cell.
Note: The JAR files must be in an identical directory
structure on each machine, as defined by the your_database_JDBC_DRIVER_PATH cell-level
variable that you declared in a previous step. Otherwise remote nodes cannot
connect to the SDO repository.
- Open a command prompt, then change to the app_server_root/bin directory.
- Install the SDO repository application on the deployment manager
for this cell:
wsadmin.ext -f installSdoRepository.jacl deployment_manager_node_name deployment_manager_server_name
for example:wsadmin.sh -f installSdoRepository.jacl dmgrNode dmgr
- Set the database type that the SDO repository is to use:
wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
for example:wsadmin.sh -f installSdoRepository.jacl -editBackendId DB2UDB_V82
- Install an instance of the SDO repository on each server or
cluster that you plan to use for one or more of the SIBus Web services roles:
You are now ready to
install the service integration technologies
resource adapter.