Oracle SALT leverages the Oracle Tuxedo Service Metadata Repository to define service contract information for both Oracle Tuxedo legacy services and Oracle SALT proxy services. Service contract information for all listed Oracle Tuxedo services is obtained by accessing the Oracle Tuxedo Service Metadata Repository system service provided by the local Oracle Tuxedo domain. Typically, SALT calls the
TMMETADATA system as follows:
Table 3‑1 lists the Oracle Tuxedo Service Metadata Repository service-level keywords used and interpreted by SALT.
|
|
|
|
|
|
|
|
|
•
|
tuxedo represents a native Oracle Tuxedo service
|
|
•
|
webservice represents an Oracle SALT proxy service, i.e. a service definition converted from a wsdl:operation
|
Do not use “webservice” to define a native Oracle Tuxedo service. This value is always used to define services converted from external Web services.
|
|
|
|
|
|
|
•
|
service corresponds to request-response MEP
|
|
•
|
oneway corresponds to oneway request MEP
|
|
•
|
queue corresponds to request-response MEP
|
|
|
|
STRING, CARRAY, XML, MBSTRING, VIEW, VIEW32, FML, FML32, X_C_TYPE, X_COMMON, X_OCTET, NULL (input buffer is empty)
|
|
|
STRING, CARRAY, XML, MBSTRING, VIEW, VIEW32, FML, FML32, X_C_TYPE, X_COMMON, X_OCTET, NULL (input buffer is empty)
|
|
|
STRING, CARRAY, XML, MBSTRING, VIEW, VIEW32, FML, FML32, X_C_TYPE, X_COMMON, X_OCTET, NULL (input buffer is empty)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 3‑2 lists the Oracle Tuxedo Service Metadata Repository parameter-level keywords used and interpreted by SALT.
Each native WSDF must be defined with a unique
WSDF name. A
WSDF can define one or more <
WSBinding> elements for more Web service application details (such as SOAP protocol details, the Oracle Tuxedo service list to be exposed as web service operations, and so on).
The mapsoapheader attribute is used to configure SOAP headers. It defines an FML32 field that represents the SOAP header. It is
TA_WS_SOAP_HEADER STRING type.
|
Note:
|
The mapsoapheader attribute It is defined in wssoapflds.h file shipped with Oracle SALT.
|
<Property name="mapsoapheader" value="true" />
The mapsoapheader attribute default value is "false" which indicates the GWWS does not execute mapping between the SOAP header and FML fields.
If mapsoapheader is set to
true the mapping behavior is as follows for inbound and outbound services:
Each WSBinding object is defined using the <WSBinding> element. Each WSBinding object must be defined with a unique WSBinding id within the
WSDF. The WSBinding id is a required indicator for the
SALTDEPLOY file reference used by the
GWWS.
Listing 3‑3 shows how SOAP protocol details are redefined using the <
SOAP> sub-element.
Within the <SOAP> element, a set of access endpoints can be specified. The URL value of these access endpoints are used by corresponding
GWWS servers to create the listen HTTP/S protocol port. It is recommended to specify one HTTP and HTTPS endpoint (at most) for each
GWWS server for an
inbound WSBinding object.
Each service object is defined using the <Service> element. Each service must be specified with the “
name” attribute to indicate which Oracle Tuxedo service is exposed. Usually, the “
name” value is used as the key value for obtaining Oracle Tuxedo service contract information from the Oracle Tuxedo Service Metadata Repository.
Listing 3‑4 shows how a group of services are defined for WSBinding.
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" />
<Service name="tolower" />
</Servicegroup>
...
</WSBinding>
</Definition>
Listing 3‑5 shows a service that uses the “
MBCONV” custom plug-in to convert input and “
XMLCONV” custom plug-in to convert output.
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper" >
<Input>
<Msghandler>MBCONV</Msghandler>
</Input>
<Output>
<Msghandler>XMLCONV</Msghandler>
</Output>
</Service>
</Servicegroup>
...
</WSBinding>
</Definition>
To use WS-Policy files, the <Policy> element should be defined in the WSDF to incorporate these separate WS-Policy files. Attribute
location is used to specify the policy file path, both abstract and relative file path are allowed. Attribute
use is optionally used by message level assertion policy files to specify the applied messages, request (input) message, response (output) message, fault message, or the combination of the three.
Listing 3‑6 shows a sample of using WS-Policy Files in the native
WSDF file.
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Policy location=”./endpoint_policy.xml” />
<Policy location=”/usr/resc/all_input_msg_policy.xml” use=”input” />
<Service name="toupper">
<Policy location=”service_policy.xml” />
<Policy location=”/usr/resc/input_message_policy.xml”
use=”input” />
</Service>
<Service name="tolower" />
</Servicegroup>
....
</WSBinding>
</Definition>
|
Note:
|
Before executing tmwsdlgen, the TUXCONFIG environment variable must be set correctly and the relevant Oracle Tuxedo application using TMMETADATA must be booted.
|
Table 3‑3 lists the Oracle Tuxedo definition files generated by Oracle SALT WSDL Converter.
|
|
|
|
|
Oracle SALT WSDL Converter converts each wsdl:operation to a Oracle Tuxedo service metadata syntax compliant service called Oracle SALT proxy service. Oracle SALT proxy services are advertised by GWWS servers to accept ATMI call from Oracle Tuxedo applications.
|
|
|
Oracle SALT maps each wsdl:message to an Oracle Tuxedo FML32 typed buffer. Oracle SALT WSDL Converter decomposes XML Schema of each message and maps each basic XML snippet as an FML32 field. The generated FML32 fields are defined in a definition table file, and the field name equals to the XML element local name by default.
|
|
|
|
|
|
WSDL embedded XML Schema and imported XML Schema (XML Schema content referenced with <xsd:import>) are saved locally as .xsd files. These files are used by GWWS servers and need to be saved under the same directory.
|
Table 3‑4 lists WSDL Element-to-Tuxedo Service Metadata Definition Keyword mapping rules.
Table 3‑5 lists WSDL Element-to-WSDF Element mapping rules.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If namespace prefix “soap” refers to URI “ http://schemas.xmlsoap.org/wsdl/soap/”, the SOAP version attribute value is “ 1.1”;
If namespace prefix “soap” refers to URI “ http://schemas.xmlsoap.org/wsdl/soap12/”, the SOAP version attribute value is “ 1.2”.
|
|
|
|
|
|
|
|
|
|
|
|
|
The keyword tuxservice in the Oracle SALT proxy service metadata definition is the truncated value of the original Web Service operation local name if the operation name is more than 15 characters. The truncated
tuxservice value may be duplicated for multiple Oracle SALT proxy service entries. Since GWWS server uses
tuxservice values as the advertised service names, so you must manually resolve the naming conflict among multiple Oracle SALT proxy services to avoid uncertain service request delivery. To resolve the naming conflict, you should assign a unique and meaningful name to
tuxservice.
|
•
|
Environment variable XSDDIR and XSDFILES are introduced in the SALT 2.0 release. They are used by the GWWS server to load all external XML Schema files at run time. Multiple XML Schema file names should be delimited with comma ‘ ,’. For instance, if you placed XML Schema files: a.xsd, b.xsd and c.xsd in directory /home/user/myxsd, you must set environment variable XSDDIR and XSDFILES as follows before booting the GWWS server:
|
The Oracle SALT Deployment file (SALTDEPLOY) defines a SALT Web service application. The
SALTDEPLOY file is the major input for Web service application in the binary SALTCONFIG file.
Listing 3‑7 shows how to import WSDF files in the
SALTDEPLOY file.
Each GWWS server can be deployed with a group of inbound WSBinding objects and a group of outbound WSBinding objects defined in the imported WSDF files. Each WSBinding object is referenced using attribute “
ref=<wsdf_name>:<WSBinding id>”. For inbound WSBinding objects, each
GWWS server must specify at least one access endpoint as an inbound endpoint from the endpoint list in the WSBinding object. For outbound WSBinding objects, each GWWS server can specify zero or more access endpoints as outbound endpoints from the endpoint list in the WSBinding object.
Listing 3‑8 shows how to configure GWWS servers with both inbound and outbound endpoints.
Properties are configured in the <GWInstance> child element
<Properties>. Each individual property is defined by using the
<Property> element which contains a “name” attribute and a “value” attribute). Different “name” attributes represent different property elements that contain a value.
Table 3‑6 lists GWWS server level properties.
Listing 3‑9 shows an example of how GWWS properties are configured.
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
.......
<Properties>
<Property name="thread_pool_size" value="20"/>
<Property name="enableMultiEncoding" value="true"/>
<Property name="timeout" value="600"/>
</Properties>
</GWInstance>
</WSGateway>
...
</ Deployment>
ASCII, BIG5, CP1250, CP1251, CP1252, CP1253, CP1254, CP1255, CP1256, CP1257, CP1258, CP850, CP862, CP866, CP874, EUC-CN, EUC-JP, EUC-KR, GB18030, GB2312, GBK, ISO-2022-JP, ISO-8859-1, ISO-8859-13, ISO-8859-15, ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, JOHAB, KOI8-R, SHIFT_JIS, TIS-620, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE, UTF-7, UTF-8
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
.......
<Properties>
<Property name="enableMultiEncoding" value="
true"/>
</Properties>
</GWInstance>
</WSGateway>
...
</ Deployment>
Table 3‑7 explains the detailed SOAP message and Oracle Tuxedo buffer encoding mapping rules if the GWWS server level multiple encoding switch is turned on.
Certificate information must be configured in order for the GWWS server to create an SSL listen endpoint, or to use X.509 certificates for authentication and/or message signature. All
GWWS servers defined in the same deployment file shares the same certificate settings, including the private key file, trusted certificate directory, and so on.
Listing 3‑11 shows a
SALTDEPLOY file segment configuring
GWWS server certificates.
<Deployment ..>
...
<System>
<Certificates>
<PrivateKey>/home/user/gwws_cert.pem</PrivateKey>
<VerifyClient>true</VerifyClient>
<CertPath>/home/user/trusted_cert</CertPath>
</Certificates>
</System>
</Deployment
A plug-in is a set of functions that are called when the GWWS server is running. Oracle SALT provides a plug-in framework as a common interface for defining and implementing plug-ins. Plug-in implementation is carried out through a dynamic library that contains the actual function code. The implementation library can be loaded dynamically during
GWWS server start up. The functions are registered as the implementation of the plug-in interface.
In order for the GWWS server to load the library, the library must be specified using the
<Plugin>/<Interface> element in the
SALTDEPLOY file.
Listing 3‑12 shows a
SALTDEPLOY file segment configuring multiple customized plug-in libraries to be loaded by the
GWWS servers.
<Deployment ..>
...
<System>
<Plugin>
<Interface lib=”plugin_1.so” />
<Interface lib=”plugin_2.so” />
</Plugin>
</System>
</Deployment
Listing 3‑13 shows a
SALTDEPLOY file segment enabling WS-Addressing for a referenced outbound Web service binding.
<Deployment ..>
...
<WSGateway>
<GWInstance id="GWWS1">
...
<Outbound>
<Binding ref="app1:app1_binding">
<WSAddressing>
<Endpoint address=”https://myhost:8801/app1_async_point”>
</WSAddressing>
<Endpoint use=" simpapp_GWWS1_HTTPPort" />
<Endpoint use=" simpapp_GWWS1_HTTPSPort" />
</Binding>
<Binding ref="app2:app2_binding">
<WSAddressing>
<Endpoint address=”https://myhost:8802/app2_async_point”>
</WSAddressing>
<Endpoint use=" simpapp_GWWS1_HTTPPort" />
<Endpoint use=" simpapp_GWWS1_HTTPSPort" />
</Binding>
</Outbound>
...
</GWInstance>
</WSGateway>
...
</ Deployment>
|
Notes:
|
In a GWWS server, each outbound Web Service binding can be associated with a particular WS-Addressing endpoint address. These endpoints can be defined with the same hostname and port number, but the context path portion of the endpoint addresses must be different.
|
No matter you create a WS-Addressing endpoint or not in the SALTDEPLOY file, you can explicitly disable the Addressing capability for particular outbound services in the WSDF. To disable the Addressing capability for a particular outbound service, you should use the property name “
disableWSAddressing” with a value set to “
true” in the corresponding <Service> definition in the WSDF file. This property has no impact to any inbound services.
Listing 3‑14 shows WSDF file segment disabling Addressing capability.
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Service name="toupper">
<Property name="disableWSAddressing" value=”true” />
</Service>
<Service name="tolower" />
</Servicegroup>
....
</WSBinding>
</Definition>
Listing 3‑15 shows a Reliable Messaging policy file example.
<Definition ...>
<WSBinding ...>
<Servicegroup ...>
<Policy location=”RMPolicy.xml” />
<Service ... />
<Service ... />
...
</Servicegroup ...>
</WSBinding>
</Definition>
The GWWS gateway supports Oracle Tuxedo domain security configuration for the following two authentication patterns:
The GWWS server passes the following string from the HTTP header of the client SOAP request for Oracle Tuxedo authentication.
Listing 3‑17 shows how to enable HTTP Basic Authentication for the outbound endpoints.
<Definition ...>
<WSBinding id="simpapp_binding">
<SOAP>
<AccessingPoints>
<Endpoint id=”...” address=”...”>
<Realm>SIMP_REALM</Realm>
</Endpoint>
</AccessingPoints>
</SOAP>
<Servicegroup id="simpapp">
....
</Servicegroup>
....
</WSBinding>
......
</Definition>
Once a service request is sending to an outbound endpoint specified with <Realm> setting, the
GWWS server passes the Oracle Tuxedo client
uid and
gid to the authentication plug-in function, so that the plug-in can determine HTTP Basic Authentication
username/password according to the Oracle Tuxedo client information. To obtain Oracle Tuxedo client
uid / gid for HTTP basic authentication
username/password mapping, Oracle Tuxedo security level may also need to be configured in the
UBBCONFIG file. For more information, see
?$paratext>?.
Table 3‑8 lists the default WS-Security Policy files bundled by Oracle SALT.
The above policy files except WS-Security Policy 1.2 UserToken file can be referenced at
<Servicegroup> or
<Service> level in the native
WSDF file. The WSSP 1.2
UserToken file can only be referenced at
<Servicegroup> level. The sample
“wsseapp” shows how to clip the WSSP 1.2
UserToken file used in
<Service> level.
Listing 3‑18 shows a combination of policy assignment making that the service
“TOUPPER” requires client send a
UsernameToken (in plain text format) and an X509v3Token in request, and also require the
SOAP:Body part of message is signed with the X.509 token.
<Definition ...>
<WSBinding id="simpapp_binding">
<Servicegroup id="simpapp">
<Policy location="salt:wssp1.2-Wss1.1-X509V3-auth.xml"/>
<Service name="TOUPPER" >
<Policy location="D:/wsseapp/wssp1.2-UsernameToken-Plain.xml"/>
<Policy location="salt:wssp1.2-signbody.xml" use="input"/>
</Service>
</Servicegroup>
....
</WSBinding>
......
</Definition>
wsloadcf reads a deployment file and all imported WSDF files and WS-Policy files referenced in the deployment file, checks the syntax according to the XML schema of each file format, and optionally loads a binary configuration file called
SALTCONFIG. The
SALTCONFIG and (optionally)
SALTOFFSET environment variables point to the
SALTCONFIG file and (optional) offset where the information should be stored.
wsloadcf validates the given SALT configuration files according to the predefined XML Schema files. XML Schema files needed by Oracle SALT can be found at directory:
$TUXDIR/udataobj/salt.
wsloadcf can execute for validating purpose only without generating the binary version
SALTCONFIG once option “
-n” is specified.
Oracle SALT requires at least one TMMETADATA server defined in the
UBBCONFIG file. Multiple
TMMETADATA servers are also allowed to increase the throughput of accessing the Oracle Tuxedo service definitions.
Listing 3‑19 lists a segment of the
UBBCONFIG file that shows how to define
TMMETADATA servers in a Oracle Tuxedo application.
To boot GWWS instances defined in the SALTDEPLOY file, the
GWWS servers must be defined in the *
SERVERS section of the
UBBCONFIG file. You can define one or more
GWWS server instances concurrently in the
UBBCONFIG file. Each
GWWS server must be assigned with a unique instance id with the option “
-i” within the Oracle Tuxedo domain. The instance id must be present in the XML version
SALTDEPLOY file and the generated binary version
SALTCONFIG file.
Listing 3‑20 lists a segment of the
UBBCONFIG file that shows how to define
GWWS servers in a Oracle Tuxedo application.
|
Notes:
|
Be sure that the TMMETADATA system server is set up in the UBBCONFIG file to start before the GWWS server boots. Because the GWWS server calls services provided by TMMETADATA, it must boot after TMMETADATA.
|
To ensure TMMETADATA is started prior to being called by the
GWWS server, put
TMMETADATA before
GWWS in the
UBBCONFIG file or use
SEQUENCE parameters in *
SERVERS definition in the
UBBCONFIG file.
Oracle SALT configuration information is pre-compiled with wsloadcf to generated a binary version
SALTCONFIG file.
GWWS server reads
SALTCONFIG file at start up. Environment variable
SALTCONFIG must be set correctly with the binary version
SALTCONFIG file entity before booting
GWWS servers.
Option “-c” is deprecated in the current version Oracle SALT. In SALT 1.1 release, option “
-c” is used to specify SALT 1.1 configuration file for the
GWWS server. In SALT 2.0,
GWWS server reads
SALTCONFIG file at start up.
GWWS server specified with this option can be booted with a warning message to indicate this deprecation. The specified file can be arbitrary and is not read by the
GWWS server.
When the GWWS server working in the outbound direction, external wsdl:operations are mapped with Oracle Tuxedo services and advertised via the
GWWS servers. The number of the advertised services by all
GWWS servers must be accounted for in the
MAXSERVICES value.
MAXACCESSERS value is used to specify the default maximum number of clients and servers that can be simultaneously connected to the Oracle Tuxedo bulletin board on any particular machine in this application. The number of
TMMETADATA and
GWWS server, maximum concurrent Web Service client requests must be accounted for in the
MAXACCESSERS value.
When the GWWS server working in the inbound direction, each Web Service client is deemed a workstation client in Oracle Tuxedo system; therefore,
MAXWSCLIENTS must be configured with a valid number in
UBBCONFIG for the machine where the
GWWS server is deployed. The number shares.
When the GWWS servers are specified with certificate related features, they are required to read the private key file and decrypt them using the password phrase. To configure password phrase for each
GWWS server, keyword
SEC_PRINCIPAL_NAME and
SEC_PRINCIPAL_PASSVAR must be specified under each desired
GWWS server entry in the *
SERVERS section. During compiling the
UBBCONFIG file with
tmloadcf, the administrator must type the password phrase, which can be used to decrypt the private key file correctly.
Listing 3‑21 lists a segment of the
UBBCONFIG file that shows how to define security password phrase for the
GWWS servers.
Oracle SALT GWWS servers rely on Oracle Tuxedo authentication framework to check the validity of the Web Service clients. If your legacy Oracle Tuxedo application is already applied with, Web Service clients must send user credential using one of the following approaches:
To obtain Oracle Tuxedo client uid / gid for outbound HTTP Basic Authentication
username /password mapping, you need to configure Oracle Tuxedo Security level as
USER_AUTH,
ACL or
MANDATORY_ACL in the
UBBCONFIG file.
Listing 3‑22 lists a segment of the
UBBCONFIG file that shows how to define security level ACL in the
UBBCONFIG file.
To set up GWWS servers running on multiple machines within a MP mode Oracle Tuxedo domain, each Oracle Tuxedo machine must be defined with a separate
SALTDEPLOY file and a set of separate other components.
You may define two GWWS servers running on different machine with the same functionality by associating the same WSDF files. But it requires manual propagation of the following artifacts:
To run SALT 2.0 GWWS servers with SALT 1.1 Configuration file, you need to perform the following steps:
|
3.
|
Boot the GWWS servers associated with this SALT 1.1 configuration file.
|
When wsloadcf loads a binary version
SALTCONFIG from a SALT 1.1 configuration file, it also convert this SALT 1.1 configuration file into one
WSDF file and one
SALTDEPLOY file.
Listing 3‑23 lists the converted
SALTDEPLOY file and
WSDF file from a given SALT 1.1 configuration file.
|
Note:
|
The APPDIR environment variable must point to the root.composite file directory.
|
Listing 3‑26 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 3‑27 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 3‑28 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 3‑34 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 3‑35 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 3‑36 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 3‑37 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 will attempt 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 3‑43 contains the lines you must add to the client composite file in
/binding.atmi/workStationParameters to configure TLS/SSL.
If a service issues tpforward() instead of
tpreturn(), its reply buffer information will be same with the reply buffer of the service which it forwards to. For example,
|
Note:
|
<SequenceNo> starts from the last <SequenceNo> number already stored in the metadata repository.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FML, FML32, VIEW, VIEW32, STRING, CARRAY, XML, X_OCTET, X_COMMON, X_C_TYPE, MBSTRING or other arbitrary string representing an application defined custom buffer type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
byte, short, integer, float, double, string, carray, dec_t, xml, ptr, fml32, view32, mbstring.
|
|
|
|
|
|
|
|
|
|
|
|
|
Input: service=SVC, request=STRING, reply = TPSUCCESS + STRING
Input: service=SVC, request=STRING, reply = TPFAIL+ STRING
Input: service=FMLS,request=FML32(name,pwd),reply=TPSUCCESS+FML32(id)
A TLOGName element is also be added to allow sharing the same TLog device across GWWS instances.
Figure 3‑1 illustrates the application and protocol flows of a typical WS-AT context service invocation.
The MaxTran element allows you to configure the size of the internal transaction table as shown in
Listing 3‑45. The default is
MAXGTT.
|
Note:
|
The MaxTran value is optional. If the configured value is greater than MAXGTT, it is ignored and MAXGTT is used instead
|
The policy.xml file file includes WS-AT policy elements. WS-AT defines the
ATAssertion element, with an
Optional attribute, as follows:
/wsat:ATAssertion/@wsp:Optional="true" as shown in
Listing 3‑46.
|
•
|
When an ATAssertion with no "Optional=true" is configured, the call must be made in a transaction. If no corresponding XA transaction exists, the WS-TX transaction is initiated but not associated with any Oracle Tuxedo XA transaction. If an XA transaction exists, there is no change in behavior.
|
|
•
|
When an ATAssertion with "Optional=true" is configured, an outbound transaction context is requested only if a corresponding Oracle Tuxedo XA transaction exists in the context of the call.
|
|
•
|
When no ATAssertion is configured for this service, the corresponding service call is made outside of any transaction. If a call is made to an external Web service in the context of an Oracle Tuxedo XA transaction, the Web service call will not propagate the transaction.
|
