Oracle SALT Administration Overview

The following sections provide an overview to Oracle SALT administration topics:

•	Administering Oracle SALT

•	Oracle SALT Web Services Administrative Tasks and Tools

•	Oracle SALT Web Application Server Administrative Tasks and Tools

•	Oracle SALT SCA Administrative Tasks and Tools

•	Oracle SALT WS-TX Administrative Tasks and Tools

Administering Oracle SALT

This section explains the following basic concepts for administering Oracle SALT:

•	Oracle Tuxedo Service Metadata Repository

•	Oracle SALT Web Service Deployment Model

•	Oracle SALT SCA Deployment Model

Oracle Tuxedo Service Metadata Repository

The Oracle Tuxedo Service Metadata Repository was developed to facilitate saving and retrieving Oracle Tuxedo service metadata. Oracle Tuxedo service metadata is a collection of Oracle Tuxedo service attributes that are especially useful in describing the request/response details of an Oracle Tuxedo service. The Oracle SALT gateway server (GWWS), relies on the Oracle Tuxedo Service Metadata Repository for conversions between the Oracle Tuxedo request/response format (buffer types) and standard SOAP message format.

When exposing Oracle Tuxedo services as Web services using Oracle SALT, you must define and load your Oracle Tuxedo service metadata in the Oracle Tuxedo Service Metadata Repository. Oracle SALT can then define the corresponding SOAP message format from the Oracle Tuxedo service metadata.

When invoking external Web services from an Oracle Tuxedo application, Oracle SALT provides a WSDL file converter, wsdlcvt. This command utility helps you to define Oracle Tuxedo service metadata from each Web service operation. The converted services are called SALT proxy services and can be invoked as normal Oracle Tuxedo services. Oracle SALT proxy services also need to be loaded in the Oracle Tuxedo Service Metadata Repository.

To retrieve the Oracle Tuxedo service metadata information, you must configure the Oracle Tuxedo Service Metadata Repository system server (TMMETADATA), to be booted in the Oracle Tuxedo application.

Note:

TMMETADATA must be booted prior to using any Oracle SALT gateway GWWS server.

For more information, see “Oracle Tuxedo Service Metadata Repository” and Using Oracle Tuxedo Service Metadata Repository for Oracle SALT in the Oracle SALT Configuration Guide.

Oracle SALT Web Service Deployment Model

Deploying Oracle SALT requires two configuration file types:

•	SALT Web Service Definition File (WSDF)

•	SALT Deployment File (SALTDEPLOY)

SALT Web Service Definition File

The SALT Web Service Definition File (WSDF) is an XML-based file used to define SALT Web service components (Web Service Bindings, Web Service Operations, Web Service Policies, and so on). The WSDF is a Oracle SALT specific representation of the Web Service Definition Language data model. There are two WSDF types: native and non-native.

•	Native WSDF

A native WSDF is created manually. You must define a set of Oracle Tuxedo services and how they are exposed as Web services in the WSDF. It looks similar to the SALT 1.1 configuration file. The native WSDF is the input file for the SALT WSDL generator (tmwsdlgen). For more information, see the Oracle SALT Configuration Guide.

•	Non-native WSDF

A non-native WSDF is generated from an external WSDL file that has been converted using the SALT WSDL converter (wsdlcvt). Basically, you do not need to change the generated WSDF (except to configure advanced features). For more information, see

Configuring Web Services.

Oracle SALT Deployment File

The Oracle SALT Deployment File (SALTDEPLOY) is an XML-based file used to define Oracle SALT GWWS server deployment information on a per Oracle Tuxedo machine basis. The SALTDEPLOY file lists all necessary WSDF files. It also specifies how many GWWS servers are deployed on an Oracle Tuxedo machine and associates inbound and outbound Web service endpoints for each GWWS server. The SALTDEPLOY file contains a system section where global resources are configured (including certificates and plug-in load libraries). For more information, see Creating the Oracle SALT Deployment File in the Oracle SALT Configuration Guide.

Figure 1‑1 illustrates the Oracle SALT deployment model.

Figure 1‑1 Oracle SALT Deployment Model

Oracle SALT Web Services Administrative Tasks and Tools

Oracle SALT provides a set of command utilities for managing different parts of an Oracle SALT application built on the Oracle Tuxedo system. These utilities can be used for the following tasks:

•	Configuring an Oracle SALT Application Using Command-Line Utilities

•	Administering an Oracle SALT Application Using Command-Line Utilities

Configuring an Oracle SALT Application Using Command-Line Utilities

You can configure your Oracle SALT application by using command-line utilities. Specifically, you can use an XML editor to create and edit the configuration file (WSDF files and SALTDEPLOY file) for your application, and then use the command-line utility named wsloadcf to translate the XML files (SALTDEPLOY file and referenced WSDF files) to a binary file (SALTCONFIG). You are then ready to boot the Oracle SALT gateway (GWWS) servers.

The following list identifies Oracle SALT command-line utilities that you can use to configure your application:

•	wsloadcf(1)

A command that is initiated on each Oracle Tuxedo machine. It allows you to compile your application SALTDEPLOY file and referenced WSDF files into the binary SALTCONFIG file. The wsloadcf command loads the binary file to the location defined by the SALTCONFIG environment variable.

•	wsdlcvt(1)

A command that converts an external Web Service Description Language (WSDL) file into Oracle Tuxedo definition files (WSDF file, Oracle Tuxedo Service Metadata definition file, FML32 field table file and XML Schema file). The generated WSDF file is a non-native WSDF file used for Oracle SALT outbound calls specifically.

Since Oracle SALT built on the Oracle Tuxedo framework, you should also use the following Oracle Tuxedo provided command-line utilities to configure Oracle SALT specific items in an Oracle Tuxedo application:

•	tmloadcf(1)

A command that runs on the master Oracle Tuxedo machine. It is used to compile the Oracle Tuxedo application UBBCONFIG file into the binary TUXCONFIG file. To boot Oracle SALT gateway servers, you must define GWWS servers in the UBBCONFIG file.

•	tmloadrepos(1)

A command that runs on the machine where Oracle Tuxedo Service Metadata Repository System Server (TMMETADATA) is booted. It loads the Oracle Tuxedo service metadata definition text files into the binary Oracle Tuxedo Service Metadata Repository file. You must load all existing Oracle Tuxedo services that are to be exposed as Web service operations in the Oracle Tuxedo Service Metadata Repository. You must also load all wsdlcvt generated Oracle SALT proxy services in the Oracle Tuxedo Service Metadata Repository.

Administering an Oracle SALT Application Using Command-Line Utilities

You can use the wsadmin(1)command-line utility to perform administrative functions for Oracle SALT gateway servers in your Oracle Tuxedo applications. Similar to the tmadmin, dmadmin and qmadmin commands, wsadmin is an interactive meta-command that enables you to run sub-commands.

In an Oracle Tuxedo application, you can run wsadmin(1) on any machine to monitor and manage the Oracle SALT gateway servers defined in the Oracle Tuxedo application.

Oracle SALT SCA Deployment Model

An SCA composite is typically described in an associated configuration file, the file name ends with ".composite". This file uses an XML-based format call the Service Component Definition Language (SCDL) to describe the components this composite contains and specify how they related to one another. Deploying Oracle SALT SCA requires at least one root composite file that is located in $APPDIR.

There are two configuration file types:

•	SCA Composite Configuration File (.composite)

•	SCA Component Configuration File (.componentType)

There can be one or more components configured in the root composite file, and each of these components has its own .composite and .componentType file residing in its own subdirectory.

SCA Composite Configuration File

There can be zero or more component elements within a composite. The root composite files must be stored in $APPDIR in a server environment.

Listing 1‑1shows an example of a root composite which contains two components:

Listing 1‑1 Root Composite with Two Components

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="ECHO.app">
       <component name="ECHO">
              <implementation.composite name="ECHO" />
       </component>
       <component name="TOUPPER">
              <implementation.composite name="TOUPPER" />
       </component>
</composite>

 

Based on the configuration in Listing 1‑1, Listing 1‑2 shows the implied the directory hierarchy.

Listing 1‑2 SCA Composite Directory Hierarchy

$APPDIR/ECHO.app.composite
$APPDIR/ECHO
$APPDIR/ECHO/ECHO.composite
$APPDIR/ECHO/ECHO.componentType
$APPDIR/TOUPPER
$APPDIR/TOUPPER/TOUPPER.composite
$APPDIR/TOUPPER/TOUPPER.componentType

 

This example is a typical server configuration. The Oracle Tuxedo SCA client also has a similar application topology meaning that the client application is located in a subdirectory of the root composite file. Listing 1‑3 lists the directory structure for a client named EchoClient that uses the ECHO1 service provided by ECHO.

Listing 1‑3 Directory Structure

$APPDIR/root.composite
$APPDIR/EchoClient/EchoClient.composite
$APPDIR/EchoClient.composite
$APPDIR/EchoClient/EchoClient.dll
$APPDIR/EchoClient/EchoClient.exe

 

Note:

One slight difference between an SCA server environment and an SCA client environment is that there is no need to have a component configuration file in the client environment.

SCA Component Configuration File

Components are the basic elements of business function in an SCA assembly, which are combined into complete business solutions by SCA composites. Components are configured instances of implementations. Components provide and consume services. More than one component can use and configure the same implementation, where each component configures the implementation differently.

Components are declared as sub-elements of a composite in an xxx.composite file. A component is represented by a component element that is a child of the composite element. Using the composite from Listing 1‑1, the 2 components (ECHO and TOUPPER), contains specific information. For the ECHO service ($APPDIR/ECHO/ECHO.composite), the ECHO.composite information is shown in Listing 1‑4.

Listing 1‑4 ECHO.composite

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
       name="ECHO">
       <service name="ECHO">
              <interface.cpp header="ECHO.h" />
              <binding.atmi requires="legacy">
                     <map target="EchoString1">ECHO1</map>
                     <map target="EchoString2">ECHO2</map>
              </binding.atmi>
              <reference>EchoServiceComponent</reference>
       </service>
       <component name="EchoServiceComponent">
              <implementation.cpp library="ECHO" header="ECHOImpl.h" />
       </component>
</composite>

 

The ECHO service provides two Oracle Tuxedo services: ECHO1 and ECHO2. ECHO1 executes CPP function “EchoString1”. ECHO2 executes CPP function "EchoString2". The existence of $APPDIR/ECHO/ECHOImpl.componentType and $APPDIR/ECHO/ECHO.so. are implied. Listing 1‑5 shows information that may be contained in ECHOImpl.componentType.

Note:

On some Unix systems the suffix is .so.71 or .sl.

ECHO.so (or ECHO.dll Windows), is the shared library that contains the actual implementation of EchoString1 and EchoString2 and is loaded into memory when the service is initialized. ECHO1 and ECHO2 are dynamically advertised at server initialization. For example, if EchoServer is the Oracle Tuxedo server that provides these two services, the Oracle Tuxedo UBBCONFIG file should contain information as shown in Listing 1‑6.

Listing 1‑5 ECHOImpl.componentType

<?xml version="1.0" encoding="UTF-8"?>
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0"
       xmlns:xs="http://www.w3.org/2001/XMLSchema">
       <service name="ECHO">
              <interface.cpp header="ECHO.h"/>
       </service>
</componentType>

 

Listing 1‑6 UBBCONFIG File Example

...
*SERVERS
DEFAULT:
       CLOPT="-A"
EchoServer SRVGRP=GROUP1 SRVID=1001
...

 

For the TOUPPER service, the existence of $APPDIR/TOUPPER/TOUPPER.composite is also implied by the ECHO.app.composite file. Listing 1‑7 shows information that may be contained in TOUPPER.composite file.

Listing 1‑7 TOUPPER.composite file Example

<?xml version="1.0" encoding="UTF-8"?>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
       name="TOUPPER">
       <service name="TOUPPER">
              <interface.cpp header="TOUPPER.h" />
                     <binding.atmi requires="legacy">
                            <map target="UpperString1">TOUPPER1</map>
                            <map target="UpperString2">TOUPPER2</map>
                     </binding.atmi>
              <reference>ToupperServiceComponent</reference>
       </service>

       <component name="ToupperServiceComponent">
              <implementation.cpp library="TOUPPER" header="TOUPPERImpl.h" />
       </component>

</composite>

 

This composite file also implies the existence of $APPDIR/TOUPPER/TOUPPERImpl.componentType and $APPDIR/TOUPPER/TOUPPER.so.

Note:

Oracle Tuxedo SCA only supports "cpp" implementation types.

Oracle SALT Web Application Server Administrative Tasks and Tools

Oracle SALT provides the following Web application server administration tools:

•	Web module mod_tuxedo (for Apache or OHS), and tux_nsapi (for iPlanet). The configuration elements are located in the respective configuration files (httpd.conf or magnus.conf).

•	The WEBHNDLR system server which serves HTTP requests proxied from mod_tuxedo or tux_nsapi. This system server is configured in the UBBConfig file and administered using regular Oracle Tuxedo commands.

For more information, see Oracle SALT Installation Guide, Administering Oracle SALT at Runtime and Configuring an Oracle SALT Application.

Oracle SALT SCA Administrative Tasks and Tools

Oracle SALT SCA provides a set of command line utilities for managing Oracle SALT SCA application built on top of the Oracle Tuxedo system. The majority of these utilities are geared toward application development but two of them are for administrative purposes. For more information, see the Oracle SALT Reference Guide.

The administrative tools can be used for the following tasks:

•	Configuring a Password for an SCA Client

•	Administering an Oracle Tuxedo SCA Application

Configuring a Password for an SCA Client

You can configure Oracle SALT SCA security by using the scapasswordtool command line utility. It manages passwords for Oracle Tuxedo authentication in the SCA client and populates the password store file (password.store).

When an SCA component makes a reference to an Oracle Tuxedo-based service with Oracle Tuxedo security set to APP_PW or higher, the SCA component searches the password.store file to find the matching password and userID in the configuration composite file. The password is encrypted with the userID in plain text.

Creating a Password

To add/create a user ID and password, do the following:

1.	prompt > Enter scapasswordtool -i userID -a

2.	prompt > Enter password: password

3.	prompt > Confirm password: password

The password is not echoed on the console screen.

Deleting a Password

To delete a userID and password, enter: scapasswordtool -i userID -d

The userID and associated password are deleted.

Administering an Oracle Tuxedo SCA Application

Oracle Tuxedo SCA components that declare services with ATMI binding are administered as a regular Oracle Tuxedo service. The administrator can to boot new instances of these servers, monitor or shut them down using existing Oracle Tuxedo commands such as tmadmin, tmboot, tmshutdown.

The Administrator can monitor activity or availability of specific methods by using tmadmin and selecting the services declared in the ATMI bindings defined in the SCDL file.

Each SCA server built using the buildscaserver command will also have administrative functionality that can be invoked using the scaadmin command line utility.

Oracle SALT WS-TX Administrative Tasks and Tools

Oracle SALT provides a set of command utilities for managing and supporting WS-TX transactions.The names and usages of these utilities are the same as Oracle SALT Reference Guide.

For more information, see WX-TX Support in Oracle Tuxedo Interoperability and Configuring Oracle SALT WX-TX Support in the Oracle SALT Configuration Guide.

See Also

•

scaadmin

•	scapasswordtool

•	buildscaclient

•	buildscacomponent

•	buildscaserver

•	Oracle SALT Installation Guide

•	Oracle SALT Programming Guide

•	Oracle SALT Reference Guide

•	Oracle SALT Interoperability Guide