WebSphere WebSphere Application Server Network Deployment, Version 6.0.x Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Installing and configuring the SDO repository

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

Determine the standalone servers or clusters for which to install and configure an SDO repository as described in Planning your SIBus Web services installation, and add each server or cluster as a member of a bus as described in Configuring the members of a bus.

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:

  1. One time to install the SDO application on the application server.
  2. 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:
  1. One time to install the SDO application on the deployment manager.
  2. One time to set the database type that the SDO repository is to use.
  3. 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.
Note:
  • The SDO repository dictates the schema and table names it uses, so 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 must use multiple databases, one for each cell.
  • The installSdoRepository.jacl script is provided in the app_server_root/bin directory, where app_server_root is the root directory for the installation of IBM WebSphere Application Server. If you choose to run the wsadmin scripting client from another directory, specify the full path to the installSdoRepository.jacl 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 installSdoRepository.jacl script:
    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 or Linux system.
  • If the data source already exists or there is a previous failed or partial installation of the SDO repository application, then 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.

To install the SDO repository, complete one of the following optional main steps:

Steps for this task

  1. Optional: To install the SDO repository for a standalone server and use the embedded Cloudscape database, complete the following steps:
    1. Open a command prompt, then change to the app_server_root/bin directory.
    2. 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.
  2. Optional: To install the SDO repository on a standalone server and use a database other than embedded Cloudscape, complete the following steps:
    1. 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.

    2. 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.
    3. Optional: Test the data source connection:
      1. In the administrative console, navigate to Resources > JDBC providers > your_provider > Data sources
      2. 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.
    4. Open a command prompt, then change to the app_server_root/bin directory.
    5. Install the SDO repository application on the server:
      wsadmin.ext -f installSdoRepository.jacl
    6. 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
      Note:
      • The -editBackendId flag 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
  3. Optional: To configure the SDO repository for a network deployment cell, complete the following steps:
    1. 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.

    2. 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.
      • In the administrative console, navigate to Environment > WebSphere variables, then set the scope to node level.
      • Check that the WAS_INSTALL_ROOT variable exists, with a value of the root directory for the installation of IBM WebSphere Application Server.
      • Create a new variable your_database_JDBC_DRIVER_PATH, with a value of the location under which your database JAR files are stored.
    3. 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.
    4. 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.
    5. Open a command prompt, then change to the app_server_root/bin directory.
    6. 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
    7. 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
      Note:
      • The -editBackendId flag determines the database type that the repository is to use. Because the SDO application is installed at the cell level, the back end ID setting is the same for all servers and clusters in the cell. If you subsequently change the database that you are using with the SDO repository, rerun this step with the value of -editBackendId set to match your new database type.
      • To see the full list of available back end ID values, use the -listBackendIds flag. For example:
        wsadmin -f installSdoRepository.jacl -listBackendIds
    8. 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:
      • For each server that is not part of a cluster, repeat the following command:
        wsadmin.ext -f installSdoRepository.jacl node_name server_name
      • For each cluster, repeat the following command:
        wsadmin.ext -f installSdoRepository.jacl -cluster cluster_name

You are now ready to install the service integration technologies resource adapter.
Related tasks
Installing the service integration technologies resource adapter
Installing the SIBus Web services and endpoint listener applications
Starting the wsadmin scripting client
Related reference
SIBus Web services installation files and locations
Implementing JAX-RPC handlers to access SDO messages

Task topic

Terms of Use | Feedback

Last updated: 15 Mar 2007
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc\tasks\tjw_install_sdo.html

© Copyright IBM Corporation 2004, 2007. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)