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

Installing the SDO repository

Use this topic to create and install a Service Data Objects (SDO) repository that the service integration bus Web services enablement (SIBWS) uses for storing and serving WSDL definitions.

This topic assumes that you have already determined the set of standalone servers or clusters on which to install an SDO repository, and added each standalone server or cluster as a member of the bus, as described in SIBWS - Completing the installation.

If the data source already exists, or there is a previous failed or partial installation of the SDO repository, the installSdoRepository.jacl script fails to complete and configuration changes are not saved. In these cases, run the SDO repository uninstall script.

Service Data Objects (SDO) is an open standard for enabling applications to handle data from different data sources in a uniform way (as DataGraphs). The SIBWS uses an SDO repository for storing and serving WSDL definitions.

The SDO repository uses your preferred database to store its data. For a simple configuration, you can use the default database (embedded Cloudscape) that is supplied with WebSphere Application Server. For all other configurations, you use a more powerful database and configure an appropriate data source as part of the SDO repository installation process. The specific conditions under which you can use Cloudscape are as follows:
You install the SDO repository by using the wsadmin scripting client to run the installSdoRepository.jacl script. If you are creating a standalone server configuration for a distributed platform 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 any other configuration, you install your preferred database product, create a JDBC provider and a data source, and 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 application 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 application 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 SIBWS 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 install_root/bin directory, where install_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:
wsadmin.ext -f install_root/bin/installSdoRepository.jacl
where .ext is the file extension .bat for a Windows system, or .sh for a Unix or Linux system, or nothing for an i5/OS system (because iSeries commands do not have a file extension).

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

  1. Optional: To install the SDO repository on a standalone server in environments other than z/OS, and use the embedded Cloudscape database, complete the following steps:
    1. Open a command prompt, then change to the install_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 installs the SDO repository application without creating the database.
  2. Optional: To install the SDO repository on a standalone server, complete the following steps:
    1. Create the database for your preferred database supplier using the Table.ddl file from the relevant install_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.
      Note: Use an "XA" data source if one is available. 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 JNDI name to a name of your own choosing (for example, SDO Repository DataSource) with 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 install_root/bin directory.
    5. Install the SDO repository application on the server:
      wsadmin.ext -f installSdoRepository.jacl
    6. Set the database type:
      wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
      for example:
      wsadmin -f installSdoRepository.jacl -editBackendId DB2UDB_V81
      Note: The -editBackendId flag determines the database type that the repository is to use. The backend ID determines what database-specific rules the application follows when talking to the database. To see the full list of available backend ID values, use the -listBackendIds flag:
      wsadmin -f installSdoRepository.jacl -listBackendIds
  3. Optional: To install 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 install_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 cell-level WebSphere Application Server variables:
      • In the administrative console, navigate to Environment > WebSphere variables.
      • Set the scope to cell level.
      • Create two new variables:
      • If these variables already exist at node level, either remove them or update them to the same values. Any values set at node level override the values set at cell level.
    3. Create and configure a JDBC provider and data source. For both the JDBC provider and the data source, set the scope to cell level. Use an "XA" data source if one is available. 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 JNDI name to a name of your own choosing (for example, SDO Repository DataSource) with 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 install_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 -f installSdoRepository.jacl dmgrNode dmgr
    7. Set the database type:
      wsadmin.ext -f installSdoRepository.jacl -editBackendId database_type
      for example:
      wsadmin -f installSdoRepository.jacl -editBackendId DB2UDB_V81
      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 backend 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 backend 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 SIBWS 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 SIBWS and endpoint listener applications
Starting the wsadmin scripting client
Related reference
SIBWS installation files and locations
Implementing JAX-RPC handlers to access SDO messages

Task topic

Terms of Use | Feedback

Last updated: 5 Oct 2005
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc\tasks\tjw_install_sdo.html

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