Service Data Objects (SDO) is an open standard for enabling applications to handle data from different data sources in a uniform way, as data graphs. Service
integration bus-enabled web services use an SDO repository for storing
and serving WSDL definitions. Use this task to create and configure
your preferred database to store SDO data, and to install and configure
an SDO repository on each server that you plan to use for bus-enabled
web services.
Before you begin
Determine the servers or
clusters on which to install and configure an SDO repository
as described in Planning your bus-enabled web services installation, then add each server or cluster as a member
of a bus as described in Configuring the members of a bus.
An
SDO repository can work with most database products. For specific
information about choosing and configuring your preferred database,
consult your database administrator or database product documentation,
and read the notes in this topic on database usage.
About this task
To install and configure an SDO repository, complete the
following steps:
- Install your preferred database product.
- Create a JDBC provider and a data source for your database.
- Run the installSdoRepository.jacl script one
or more times, to install the SDO application on each server and to
set the database type that the SDO repository is to use.
For more information about how to do this, first read
the following notes on database usage and on the
installSdoRepository.jacl script,
and then complete the steps for one of these configurations:
Notes on database usage:
-
For a single server configuration,
you can use either your preferred database or the embedded Apache
Derby database that is supplied with
WebSphere® Application Server. In a z/OS® environment you cannot use the embedded Derby database, because this database can be accessed by only one process at a time and even a single server on z/OS can run in multiple processes.
- For a network deployment
configuration you can use either your preferred database or the supplied
Derby database and associated Network Server application. However,
be aware of the limitations of Derby Network Server. For example,
it does not support transactions.
- The SDO repository dictates the schema and table names that it
uses, so different repositories must use different databases to ensure
that they do not access the same data. Use one SDO repository for
each cell, so that if you have multiple cells you use multiple databases,
one for each cell.
-
DB2® on z/OS does
not have the concept of multiple databases. On z/OS systems,
each SDO repository must use a different DB2 instance
to ensure that different repositories do not access the same data.
-
Create the database for your preferred database supplier by using the Table.ddl file from the relevant
app_server_root/util/SdoRepository/database_type
directory. The Table.ddl file
describes the database table that is needed by the SDO repository.
-
The -editBackendId flag on the installSdoRepository.jacl script determines the database type that the repository is to use. The back end ID determines what database-specific rules the application follows when talking to the database. See the associated
note on the installSdoRepository.jacl script.
- Some databases require a user ID that has been 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 that 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.
- 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, you must use the Oracle JDBC driver
(non-XA) for the SDO repository data source.
- You might also choose to complete other steps such as creating
an index of the primary key to improve database performance. Do not
change the schema, table and column names.
- If you are configuring this
SDO repository for use with a cell that contains a mixture of
WebSphere Application Server Version 6.0, Version 6.1 and later application
servers, you must use a database that is compatible with all these
versions.
Notes on the installSdoRepository.jacl script:
- Use the wsadmin
scripting client to run the script.
-
Run the script from within QShell.
-
The script is provided in the
app_server_root/bin directory, where app_server_root is the root directory for the installation of
WebSphere Application Server
. If you choose to run the wsadmin scripting client from another directory, specify the full path to the script on the command option. For example to work with a profile other than the default profile, change to the
app_server_root/profiles/profile_name/bin directory then specify the following path to the script:
wsadmin -f app_server_root/bin/installSdoRepository.jacl
wsadmin.ext -f app_server_root/bin/installSdoRepository.jacl
where
.ext
is the file extension .bat for a Windows® system, or .sh for a UNIX®, Linux® or z/OS system.
-
The -editBackendId flag on the installSdoRepository.jacl script determines the database type that the repository is to use. The back end ID determines what database-specific rules the application follows when talking to the database. To see the
full list of available back end ID values, use the -listBackendIds flag:
wsadmin -f installSdoRepository.jacl -listBackendIds
All
the back end ID values in the list can be used when the SDO repository
is installed on one or more
WebSphere Application Server Version 7.0 application servers.
Values marked with (*) cannot be used when the SDO repository is installed
on Version 6.0 servers. Values
marked with (**) cannot be used when the SDO repository is installed
on Version 6.0 or Version 6.1 servers.
-
If the data source already exists, or there has been a previous broken or partial installation of the SDO repository application, the installSdoRepository.jacl script fails to complete and configuration changes are not saved. In these cases,
run the SDO repository uninstall script, fix the
problem, then rerun the installSdoRepository.jacl script.