Listing 1‑1shows an example of a root composite which contains two components:
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.
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.
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.
Note:
|
The APPDIR environment variable must point to the root.composite file directory.
|
Listing 1‑8 shows the client application root composite file
$APPDIR/root.composite.
The $APPDIR/ECHO directory contains the ECHO application. The directory name, "
ECHO", must match the name specified in
<implementation.composite name="ECHO"/>.
Listing 1‑9 shows the client application composite file.
Note:
|
The client application .jar file must be included in the CLASSPATH. The following .jar files should also be part of CLASSPATH:
|
Listing 1‑10 shows an SCA JATMI client composite file example.
The <interface.cpp> element is required to build the appropriate proxy stub. Also, the client directory should contain the WSDL file where the endpoint specified in
<binding.ws> is located. In addition, the configuration of the Oracle Tuxedo Web services gateway (GWWS) is necessary and requires the following steps:
2.
|
Run wsdlcvt on the WSDL of the service(s) used. This produces a WSDF file, an Oracle Tuxedo Metadata Repository interface definitions file, fml32 field tables and XML schemas.
|
<?xml version="1.0" encoding="UTF-8"?>
<saltdep:Deployment xmlns:saltdep="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saltdep:WSDF>
<saltdep:Import location="calc.wsdf"/>
</saltdep:WSDF>
<saltdep:WSGateway>
<saltdep:GWInstance id="GWWS1">
<saltdep:Outbound>
<saltdep:Binding ref="calc:CalculatorSOAP11Binding">
<saltdep:Endpoint use="CalculatorSOAP11port"/>
</saltdep:Binding>
</saltdep:Outbound>
</saltdep:GWInstance>
</saltdep:WSGateway>
<saltdep:System/>
</saltdep:Deployment>
For an SCA ATMI server, the SCA ROOT is the same as $APPDIR. There should be at least one composite file that describes the SCA application. The SCA runtime searches for this composite file and from there it loads all the
composite and
componentType files for SCA server applications that are hosted in an Oracle Tuxedo environment.
Listing 1‑16 shows a root composite file, named
root.composite contains two SCA applications hosted in an Oracle Tuxedo application domain. The two applications are called Purchase and Finance. There are at least two subdirectories for these two SCA applications. One is called
Purchase.component and the other is called
Finance.component.
Listing 1‑17 shows the
Purchase.component directory contains a composite file for the Purchase application named
Purchase.composite. Similarly, the
Finance.component directory contains a composite file for the Finance application named
Finance.composite.
Listing 1‑18 shows
Purchase.composite contains the
PurchaseImpl.componentType file in the
$APPDIR/Purchase.component directory and uses CPP as its application implementation. When an SCA server using this configuration is built using the
buildscaserver utility, it advertises two SCA services automatically at runtime (
ORDER and
TRACKORDER). The actual CPP implementation of the services is called
Order and
TrackOrder.
Listing 1‑19 shows a root composite file named
root.composite. It contains one SCA component hosted in an Oracle Tuxedo application domain. The two applications are called Purchase and Finance. There are at least two subdirectories for these two SCA applications, one is called
Purchase.component, and the other is called
Finance.component.
2.
|
Run wsdlcvt on the WSDL of the service(s) used. This produces a WSDF file, an Oracle Tuxedo Metadata Repository interface definitions file, fml32 field tables and XML schemas.
|
<?xml version="1.0" encoding="UTF-8"?>
<saltdep:Deployment xmlns:saltdep="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns="http://www.bea.com/Tuxedo/SALTDEPLOY/2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<saltdep:WSDF>
<saltdep:Import location="AccountService.wsdf"/>
</saltdep:WSDF>
<saltdep:WSGateway>
<saltdep:GWInstance id="GWWS1">
<saltdep:Inbound>
<saltdep:Binding ref="AccountService:AccountServiceSOAP">
<saltdep:Endpoint use="AccountServiceSOAP"/>
</saltdep:Binding>
</saltdep:Inbound>
</saltdep:GWInstance>
</saltdep:WSGateway>
<saltdep:System/>
</saltdep:Deployment>
Oracle Tuxedo Application Domain Security is set when the TUXCONFIG file for the Oracle Tuxedo Application Domain contains the
SECURITY keyword in the
*RESOURCES section. There are five levels of application security:
NONE,
APP_PW,
USER_PW,
ACL, and
MANDATORY_ACL. All security levels except
NONE require at least an application password from user to gain access to the Oracle Tuxedo application. At the
USER_PW level and above there is an additional user password to authenticate the user and establish user credentials. In total there are potentially two passwords that need to be configured.
•
|
Maintain the password.store file and set this file up correctly for the client application. The administrator must duplicate the password.store file across different machines if necessary.
|
The <encryptBits> element specifies the encryption strength that this client attempts to negotiate. The syntax for the
<encryptBits> element is
<minimum encryption strength>/<maximum encryption strength>. To configure minimum 56-bit encryption you must add the following to the composite file:
Note:
|
encryptBits specifies the encryption strength that the client connection attempts to negotiate. The format is <minencryptbits>/ <maxencprytbits> (for example, 128/128). Values can be 0 (no encryption is used), 40, 56, 128, or 256. Invalid values result in a configuration exception.
|
In addition to <encryptBits>, to enable Link-Level Security over TLS/SSL you must configure
secPrincipalName,
secPrincipalLocation, and
secPrincipalPassId.
•
|
secPrincipalName - the name of the security principal. It is used for searching the client X.509 certification from the LDAP server.
|
•
|
secPrincipalPassId - the password identifier that is used to retrieve client password used to encrypt the private key file.
|
Listing 1‑25 contains the lines you must add to the client composite file in
/binding.atmi/workStationParameters to configure TLS/SSL.
SCA ATMI servers and clients support the Oracle Tuxedo tmtrace(5)function. All traces generated from
TMTRACE are logged in the ULOG file. Checking the ULOG file trace information helps to determine the cause of a failure. The Oracle Tuxedo
TMTRACE facility is enabled by setting
TMTRACE environmental variable, or by using the
tmadmin chtr sub-command.
•
|
SCACPP_LOGGING: Set to a numeric value and controls the number of trace messages produced.
|
•
|
SCACPP_ULOG: Set to "yes" to send trace messages to the ULOG. If this environment variable is not set or is set to "no", then trace messages are written to standard output.
|
Listing 1‑26 shows a ULOG example containing SCA runtime tracing:
An Oracle Tuxedo SCA server built with the buildscaserver utility can be monitored using the
scaadmin utility. This utility shows service statistics information and helps perform maintenance through dynamic shared library loading and unloading.
Before scaadmin is executed, you must set the
TUXCONFIG environment variable.
Table 1‑2 lists
scaadmin sub-commands.
|
|
|
|
|
|
|
APPDIR environmental variable, if APPDIR is not set uses current working directory
|
|
|
0 ... maximum file size supported by the system
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 1‑3 shows an example of the log file contents.
9/3/08:3:19:14 PM:10:TRACE[TuxedoConversion,processSendBuf]< (10) return 1st args
9/3/08:3:19:14 PM:10:DBG[AtmiBindingInvoker,invoke]ServiceType: requestresponse
9/3/08:3:19:14 PM:10:DBG[AtmiBindingInvoker,invoke]Return Type Class: simpapp.View7Rep
9/3/08:3:19:14 PM:10:DBG[AtmiBindingInvoker,invoke]target service name: RULE7
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]TPURCODE: 0
9/3/08:3:19:15 PM:10:TRACE[TuxedoConversion,processReplyBuffer]> (reply simpapp.View7Rep@191777e:0:null)
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]returnType: simpapp.View7Rep
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]Reply Buffer Class: simpapp.View7Rep
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]Reply Buffer Type: X_COMMON
9/3/08:3:19:15 PM:10:DBG[TuxedoConversion,processReplyBuffer]Reply Buffer Subtype: View7Rep
9/3/08:3:19:15 PM:10:TRACE[TuxedoConversion,processReplyBuffer]< (30) return buffer directly
9/3/08:3:19:15 PM:10:DBG[Accessors,getConventionProperty]Convention Property: CONVENTIONS_TUX
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,invoke]networkAddress: host = STRIATUM, port = 8080
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingInvoker,determineServiceCallParameters]> ()
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isLegacy]> ()
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isLegacy]< (10) return true
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isMap]> ()
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,isMap]< (10) return false
9/3/08:3:19:15 PM:10:DBG[AtmiBindingInvoker,determineServiceCallParameters]Operation name = rule7_OVVO
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getServiceType]> (rule7_OVVO)
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getServiceType]< (10) return null
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getInputBufferType]> (rule7_OVVO)
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getInputBufferType]< (10) return null
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getOutputBufferType]> (rule7_OVVO)
9/3/08:3:19:15 PM:10:TRACE[AtmiBindingImpl,getOutputBufferType]< (10) return null
9/3/08:3:19:15 PM:10:DBG[AtmiBindingImpl,getErrorBufferType]> (rule7_OVVO)