|
|
The following sections provide an overview to Oracle SALT administration topics:
This section explains the following basic concepts for administering Oracle SALT:
Starting with the Oracle Tuxedo 9.0 release, the Tuxedo Service Metadata Repository was developed to facilitate saving and retrieving Tuxedo service metadata. Tuxedo service metadata is a collection of Tuxedo service attributes that are especially useful in describing the request/response details of a Tuxedo service. The Oracle SALT gateway server (GWWS), relies on the Tuxedo Service Metadata Repository for conversions between the Tuxedo request/response format (buffer types) and standard SOAP message format.
When exposing Tuxedo services as Web services using Oracle SALT, you must define and load your Tuxedo service metadata in the Tuxedo Service Metadata Repository. Oracle SALT can then define the corresponding SOAP message format from the Tuxedo service metadata.
When invoking external Web services from a Tuxedo application, Oracle SALT provides a WSDL file converter, wsdlcvt. This command utility helps you to define Tuxedo service metadata from each Web service operation. The converted services are called SALT proxy services and can be invoked as normal Tuxedo services. SALT proxy services also need to be loaded in the Tuxedo Service Metadata Repository.
To retrieve the Tuxedo service metadata information, you must configure the Tuxedo Service Metadata Repository system server (TMMETADATA), to be booted in the Tuxedo application.
| Note: | TMMETADATA must be booted prior to using any Oracle SALT gateway GWWS server. |
For more information, see “Tuxedo Service Metadata Repository” and Using Tuxedo Service Metadata Repository for Oracle SALT.
Deploying Oracle SALT requires two configuration file types:
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.
A native WSDF is created manually. You must define a set of 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 Configuring Native Tuxedo Services.
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 External Web Services.
The SALT Deployment File (SALTDEPLOY) is an XML-based file used to define Oracle SALT GWWS server deployment information on a per Tuxedo machine basis. The SALTDEPLOY file lists all necessary WSDF files. It also specifies how many GWWS servers are deployed on a 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 SALT Deployment File.
Figure 1-1 illustrates the Oracle SALT deployment model.
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:
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 SALT gateway (GWWS) servers.
The following list identifies Oracle SALT command-line utilities that you can use to configure your application:
A command that is initiated on each 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.
A command that converts an external Web Service Description Language (WSDL) file into Tuxedo definition files (WSDF file, 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 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 a Tuxedo application:
A command that runs on the master Tuxedo machine. It is used to compile the Tuxedo application UBBCONFIG file into the binary TUXCONFIG file. To boot Oracle SALT gateway servers, you must define GWWS servers in the UBBCONFIG file.
A command that runs on the machine where Tuxedo Service Metadata Repository System Server (TMMETADATA) is booted. It loads the Tuxedo service metadata definition text files into the binary Tuxedo Service Metadata Repository file. You must load all Tuxedo legacy services that are to be exposed as Web service operations in the Tuxedo Service Metadata Repository. You must also load all wsdlcvt generated SALT proxy services in the Tuxedo Service Metadata Repository.
You can use the wsadmin(1)command-line utility to perform administrative functions for Oracle SALT gateway servers in your Tuxedo applications. Similar to the tmadmin, dmadmin and qmadmin commands, wsadmin is an interactive meta-command that enables you to run sub-commands.
In a Oracle Tuxedo application, you can run wsadmin(1) on any machine to monitor and manage the SALT gateway servers defined in the Tuxedo application.
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:
composite).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.
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:
<?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.
$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 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.
$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. |
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.
<?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 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 Tuxedo server that provides these two services, the Tuxedo UBBCONFIG file should contain information as shown in Listing 1-6.
<?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>
...
*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.
<?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: | Tuxedo SCA only supports "cpp" implementation types. |
Oracle SALT SCA provides a set of command line utilities for managing Oracle SALT SCA application built on top of the 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:
You can configure your SALT SCA security by using the scapasswordtool command line utility. It manages passwords for Tuxedo authentication in the SCA client and populates the password store file (password.store).
When an SCA component makes a reference to a Tuxedo-based service with 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.
To add/create a user ID and password, do the following:
The password is not echoed on the console screen.
To delete a userID and password, enter: scapasswordtool -i userID -d
The userID and associated password are deleted.
Tuxedo SCA components that declare services with ATMI binding are administered as a regular Tuxedo service. The administrator can to boot new instances of these servers, monitor or shut them down using existing 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.
|