> Administration Guide > Configuring BEA SALT

Administration Guide

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring BEA SALT

This section contains the following topics:

 

Creating a BEA SALT Configuration File

The SALT configuration file uses XML format to define necessary deployment information for exporting Tuxedo services as Web services. This deployment information includes the following definitions: a Tuxedo service list, WS-ReliableMessaging Policy information, and SOAP protocol binding information. The deployment information generates a corresponding WSDL document. Multiple GWWS instances enable failover capability and generate multiple port information in the WSDL document.

SALT configuration leverages Tuxedo Service Metadata Repository for Tuxedo service contract information. BEA SALT accesses the Tuxedo Service Metadata Repository system server, TMMETADATA, provided by the local Tuxedo domain and gathers corresponding service contract information to generate the SALT WSDL document.

Sample SALT Configuration File

In Listing 2-1, the namespace of this version configuration XML file is defined with a fixed URL string "http://www.bea.com/Tuxedo/Salt/200606", which is used to identify the SALT version associated with the configuration file.

Listing 2-1 Sample SALT Configuration File 
<? xml version="1.0" encoding="UTF-8"?>
<Configuration xmlns="http://www.bea.com/Tuxedo/Salt/200606" >
	<Servicelist  id="simple">
		<Service name="toupper" />
		<Service name="tolower" />
	</Servicelist>
	<Policy>
		<RMPolicy>RMpolicy.xml</RMPolicy>
	</Policy>
	<System>
		<Certificate>
			<PrivateKey>cert.pem</PrivateKey>
		</Certificate>
</System>
<WSGateway>
		<GWInstance  id="GW1">
			<HTTP address="//my server" />
			<HTTPS address="//my server" />
		</GWInstance>
	</WSGateway>
</Configuration>

SALT Configuration Format

Each BEA SALT configuration file is composed of the following four XML format elements:

The syntax for each of these for elements is listed in Table 2-1.

Configuring Reliable Messaging Policy

BEA SALT supports the WS-ReliableMessaging Policy. The <RMPolicy> sub-element is used to define the policy.

Defining System Parameters

Defining the GWWS Gateway

The GWWS gateway must be defined in the SALT configuration file and defined as a Tuxedo server in the UBBCONFIG file. For more information, see Configuring Security.

After defining the GWWS gateway through the SALT configuration file, boot the GWWS server using tmadmin or tmboot. When the GWWS gateway is initiated, it loads the specified SALT configuration file, validates the XML configuration file, loads corresponding Tuxedo service contract information from Tuxedo Service Metadata Repository, and loads WS-ReliableMessaging policy definition file.

At runtime, the GWWS server reloads the configuration dynamically. You can also download the WSDL document from the GWWS server which is based on the latest configuration file.

SALT Configuration File Element Syntax

Table 2-1 describes the syntax used in each of these four elements.

Table 2-1 SALT Configuration Elements
Element
Description
<Servicelist>
Lists Tuxedo services to be exported as Web services.

Attribute: id

The name of the service list. This name is used in the generated WSDL document to compose the name of the wsdl:PortType object. The value of this attribute must be a [1,32] length string.

Sub-element: <service>

Specifies one Tuxedo service to be exported.
Zero <Service> elements for <Servicelist> is a valid configuration which means no Tuxedo service is exported.
<service> has the following attribute:

Attribute: name

The unique name of a service. This name is the key string inquiry for the service information defined in the Tuxedo Service Metadata Repository. The value of this attribute must be a [1,15] length string. The name attribute must match the Tuxedo Service Metadata Repository service keyword.

Note: Tuxedo Service Metadata Repository provides two system-level keywords, service and tuxservice for Tuxedo service references. This provides the ability to define multiple service contract entries for actual the same Tuxedo service.

The following is an example:
<Servicelist id="simple">
     <Service name="toupper" />
     <Service name="tolower" />
</Servicelist>
<Policy>
Specifies WS Policies applied to the SALT Gateway.

Note: BEA SALT 1.1 can only define the WS-ReliableMessaging Policy.

Attribute: NA.

Sub-element: <RMPolicy>

Specifies a WS-ReliableMessaging Policy. This element is optional.
Text enveloped with this element indicates a valid file path for a WS-ReliableMessaging policy file on the local file system. The policy definition file must comply with WS-Policy and WS-ReliableMessaging specifications.
The following is an example:
<Policy>
     <RMPolicy>RMpolicy.xml</RMPolicy>
</Policy>
<System>
Defines system-level or global parameters related to Tuxedo and the operating system.
Attribute: NA.

Sub-element: <Certificate>

Specifies certificate information for HTTP over SSL connections. This element has no attribute. Sub elements are needed for necessary SSL certificate settings.
<Certificate> has the following sub-elements:

.../<PrivateKey>
Specifies the PEM format private key file. The key file path is specified as the text value for this element. If the <Certificate> element is present, this element is required.

The server certificate is also in this private key file.

.../<VerifyClient>
Specifies if Web service clients are required to send a certificate through HTTP over SSL connection. This element is optional. The text "true" and "false" are the only valid values for this element. "false" is the default value if not specified.

.../<TrustedCert>
Specifies the file name of the trusted PEM format certificate files. This element is optional.

.../<CertPath>
Specifies the local directory where the trusted certificates are located. This element is optional. If <VerifyClient> is true, or if WS-Addressing is used with SSL, at least one valid file must be specified for this element.

If <VerifyClient> is true, or if WS-Addressing is used with SSL, you must set either <TrustedCert> or <CertPath>.

The following is an example:
<System>
   <Certificate>
      <PrivateKey>cert.pem</PrivateKey>
   </Certificate>
</System>
 

Sub-element: <Plugin>

Specifies SALT plug-in interfaces. In the BEA SALT 1.1 release, plug-in interfaces are only used to extend data conversion between SOAP messages and Tuxedo custom typed buffers. For more information, see Using Plug-ins with BEA SALT in Programming Web Services.
<Plugin> has the following sub-element:

.../<Interface>
Each <Interface> sub-element specifies a separate plug-in implementation. There can be zero or more <Interface> sub-elements for <Plugin> to indicate different plug-in implementations.

<Interface> has the following sub-elements:

.../<ID>
Specifies the identifier of a plug-in interface. The identifier of a plug-in interface indicates the purpose of the plug-in. It can also be understood as the type of a plug-in. Multiple plug-in interfaces can be defined with the same <ID> value. The value of <ID> must be predefined by SALT. This element is required for a plug-in interface.

In the BEA SALT 1.1 release, the only valid identifier value is P_CUSTOM_TYPE, which is used to identify the plug-in interfaces for Tuxedo custom typed buffer data conversion.

.../<Name>
Specifies the unique name of a plug-in interface. The name must be unique among the plug-in interfaces with the same <ID> value. The name may have a different meaning within different plug-in <ID> values. This element is required for a plug-in interface.

In BEA SALT 1.1, for P_CUSTOM_TYPE typed plug-in interfaces, the name value must be the Tuxedo custom buffer type name.

.../<Library>
Specifies the shared library file that has the functions implemented for this plug-in interface. This element is required for a plug-in interface.

.../<Params>
Specifies a string value that can be passed to the initialization function of the plug-in interface. This element is optional for a plug-in interface.

 
The following is an example:
<System>
<Plugin>
<Interface>
<ID>P_CUSTOM_TYPE</ID>
<Name>MYBUFT</Name>
<Library>Mybuft.so</Library>
</Interface>
</Plugin>
</System>
 

Sub-element: <LogLevel>

Specifies the log level for information printing during configuration parsing. The value range is [1-8]:
  • 1-Minimal parsing information printed
  • 2-General error messages printed
  • 4-Warning message printed
  • 8-All parsing information printed
Other numbers are reserved for future release.
If this element is not specified, the default setting is 2.
<WSGateway>
Defines run time parameters for GWWS gateway instances. These instances share the same <Servicelist>, <Policy> and <System> configuration information.
Attribute: NA.

Sub-element: <GWInstance>

Configure runtime parameters for one GWWS gateway. This element can be specified [1, 1024] times for <WSGateway>, in other words, at least one GWWS process and at most 1024 GWWS processes can be specified in one SALT configuration file.
<GWInstance> has the following attribute:

Attribute: id
The GWWS instance identifier. The ID value must be unique within the Tuxedo domain. The value of this attribute must be a [1,12] length string.

<GWInstance> has the following sub-elements:

...<HTTP> or <HTTPS>

Specifies the HTTP or HTTP over the GWWS listening SSL endpoint address. At least one element, either <HTTP> or <HTTPS> must be specified for <GWInstance>.

<HTTP>or <HTTPS> has the following attribute:

Attribute: address
The network address. The string value can be in one of the following two formats: //<ipaddress>:<portnum> or //<hostname>:<portnum>

 

...<property>

Specifies runtime properties for the GWWS process. This element is optional. Different properties can be set by specifying multiple <property> elements.

<property> has the following attributes:

Attribute: name
The property name.
Attribute: value
The property value.

Valid GWWS properties are:

Property: max_content_length
This property enables the GWWS server to deny the HTTP requests when the content length is larger than this property setting. If not specified, the GWWS server does not check for it. The string value can be one of the following three formats:

  1. Integer number in bytes, no suffix means the unit is bytes
  2. Float number in kilobytes, the suffix must be K
  3. Float number in megabytes, the suffix must be M

    4. The equivalent byte size value must be in [1 byte, 1G byte] range.

    Property: thread_pool_size
    Defines the GWWS process thread pool size. The value must be in [1, 1024]. If not specified, default value 16 is used.

    Property: timeout
    Defines the network time-out value, unit: second. The value must be in [1, 65535]. If not specified, default value 300 is used.

 

Property: max_backlog
Specifies the backlog listen socket value. It controls the maximum length of the queue of pending connections by operating system. The value range for this property is [1-255]. The default value is 16.

Generally no tuning is needed for this value.

The following is an example:
<WSGateway>
<GWInstance id="GW1">
<HTTP address="//myhost:8001" />
<HTTPS address="//myhost:8002" />
<property name=" thread_pool_size" value="40" />
</GWInstance>
</WSGateway>

 

Accessing Service Definitions from the Tuxedo Service Metadata Repository

BEA SALT leverages the Tuxedo Service Metadata Repository to define service contract information for Web Services. Service contract information of all listed Tuxedo services is obtained by accessing the Tuxedo Service Metadata Repository system service provided by the local Tuxedo domain. SALT calls TMMETADATA system server under the following scenarios:

The following topics provide SALT-specific interpretations of the Tuxedo Service Metadata Repository keywords and parameters:

Defining Service-level Keywords for BEA SALT

The following Tuxedo Service Metadata Repository service-level keywords have specific SALT interpretations for handling Web Service processing.

Note: Service-level keywords not specified in Table 2-2 have no special semantics for BEA SALT and are ignored when the Tuxedo Service Metadata Repository is loaded by SALT.

Table 2-2 BEA SALT Handling of Service-level Keywords in Tuxedo Service Metadata Repository
Service-level Keyword
Keyword Abbreviation
BEA SALT Interpretation
service
sv
The unique key value to distinguish one service from another in the Tuxedo Service Metadata Repository. This is the value to reference in the SALT configuration file.
tuxservice
tsv
The actual Tuxedo service name. BEA SALT invokes the Tuxedo service defined with this keyword. If no value is specified in tuxservice, then the value will be the same as the value in the service keyword.
servicetype
st
BEA SALT uses this keyword value to determine the service message exchange pattern for the specified Tuxedo service. BEA SALT maps the service with the Web Service message exchange pattern (MEP).
The following values specify mapping rules between the Tuxedo service types and Web Service MEP:
  • service corresponds to request-response MEP
  • oneway corresponds to oneway request MEP
  • queue corresponds to request-response MEP
export
ex
BEA SALT ignores this value. If the service is specified in the SALT configuration <Servicelist>, it will be exposed regardless of the value specified in export.
inbuf
bt
Specifies the input buffer type. SALT provides default data representation and conversion between SOAP XML payload and the following Tuxedo buffer types:
  • STRING (case sensitive)
  • CARRAY
  • XML
  • MBSTRING
  • VIEW
  • VIEW32
  • FML
  • FML32
  • X_C_TYPE
  • X_COMMON
  • X_OCTET

Note: If inbuf specifies any other type other than the previous buffer types, the buffer is treated as a custom buffer type.
outbuf
BT
Specifies the output buffer type. SALT provides default data representation and conversion between SOAP XML payload and the following Tuxedo buffer types:
  • STRING (case sensitive)
  • CARRAY
  • XML
  • MBSTRING
  • VIEW
  • VIEW32
  • FML
  • FML32
  • X_C_TYPE
  • X_COMMON
  • X_OCTET

Note: If outbuf specifies any other type other than the previous buffer types, the buffer is treated as a custom buffer type.
inview
vn
Specify the view name used by the service if the service buffer type is VIEW, VIEW32, X_C_TYPE, or X_COMMON. BEA SALT requires that you specify the view name rather than accept the default inview setting.
outview
VN
Specify the view name used by the service if the service buffer type is VIEW, VIEW32, X_C_TYPE, or X_COMMON. BEA SALT requires that you specify the view name rather than accept the default outview setting.

Defining Service Parameters for BEA SALT

The Tuxedo Service Metadata Repository interprets parameters as sub elements encapsulated in a Tuxedo service typed buffer. Each parameter can have its data type, occurrences in the buffer, size restrictions, and other Tuxedo-specific restrictions.

Note: Parameter-level keywords not specified in Table 2-3 have no special semantics for BEA SALT and are ignored when the Tuxedo Service Metadata Repository is loaded by SALT.

Table 2-3 BEA SALT Handling of Parameter-level Keyword in Tuxedo Service Metadata Repository
Parameter-level Keyword
Abbreviation
BEA SALT Interpretation
param
pn
Specifies the parameter name. This keyword is required.
  • For VIEW, VIEW32, X_C_TYPE, or X_COMMON, specify the view structure member name in the param keyword.
  • For FML, FML32 typed buffers, specify the FML/FML32 field name in the param keyword.
  • For STRING, CARRAY, XML, MBSTRING, or X_OCTET, BEA SALT ignores the parameter definitions.
type
pt
Specifies the data type of the parameter.

Note: BEA SALT does not support dec_t and ptr data types.
subtype
pst
Specifies the view structure name if the parameter type is VIEW32. For any other typed parameter, BEA SALT ignores this value.

Note: The Tuxedo Service Metadata Repository allows this value to be empty if the parameter type if VIEW32. In this case the Tuxedo Service Metadata Repository uses a fixed value <viewname> as a default. This default value will not work for BEA SALT. You must specify the view name for BEA SALT to have a valid service definition.
access
pa
The general definition applies for this parameter.
count
po
The general definition applies for this parameter. For BEA SALT, the value for the count parameter must be greater than or equal to requiredcount.
requiredcount
ro
The general definition applies for this parameter. The default is 1. For BEA SALT, the value for the count parameter must be greater than or equal to requiredcount.
size
pl
This optional keyword restricts the maximum length of the parameter. It is only valid for parameter types: STRING, CARRAY, XML, and MBSTRING. If this keyword is not set, there is no maximum length restriction for this parameter.
The value range is [0, 2147483647]

 

Creating a Policy File

To use WS-ReliableMessaging functionality, you must create a policy file and specify the policy file in the SALT configuration file. The format of the policy file is defined by the WS-ReliableMessaging Policy specification.

Listing 2-2 shows an RMAssertion syntax example.

Listing 2-2 RMAssertion Syntax 
<wsrm:RMAssertion [wsp:Optional="true"]? ... > 
      <wsrm:InactivityTimeout Milliseconds="xsd:unsignedLong" ... /> ? 
      <wsrm:BaseRetransmissionInterval Milliseconds="xsd:unsignedLong".../>? 
      <wsrm:ExponentialBackoff ... /> ? 
      <wsrm:AcknowledgementInterval Milliseconds="xsd:unsignedLong" ... /> ? 
      <beapolicy:Expires Expires="xsd:duration" ... /> ? 
      <beapolicy:QOS QOS="xsd:string" ... /> ? 
... 
</wsrm:RMAssertion>

Sample Policy File

Listing 2-3 is shows a sample SALT policy file.

Listing 2-3 Sample Policy File 
<?xml version="1.0"?>
<wsp:Policy wsp:Name="ReliableSomeServicePolicy"
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:beapolicy="http://www.bea.com/wsrm/policy">
<wsrm:RMAssertion>
      <wsrm:InactivityTimeout Milliseconds="600000" />
      <wsrm:AcknowledgementInterval Milliseconds="2000" />
      <wsrm:BaseRetransmissionInterval Milliseconds="500"/>
      <wsrm:ExponentialBackoff />
      <beapolicy:Expires Expires="P1D" />
      <beapolicy:QOS QOS="ExactlyOnce InOrder" />
</wsrm:RMAssertion>
</wsp:Policy>

All RM assertions are optional, and if not specified, the default value are used. The following definitions describe the RM assertion options.

RM Assertion Option
Description
<wsrm:InactivityTimeout>
Specifies the number of milliseconds, specified with the Milliseconds attribute, which defines an inactivity interval. After time has elapsed, if the destination endpoint has not received a message from the source endpoint, the destination endpoint may terminate current sequence due to inactivity. The source endpoint can also use this parameter.
Sequences never time out by default.
<wsrm:AcknowledgementInterval>
Specifies the maximum interval, in milliseconds, in which the destination endpoint must transmit a stand-alone acknowledgement.
There is no time limit by default.
<wsrm:BaseRetransmissionInterval>
Specifies the interval, in milliseconds, that the source endpoint waits after transmitting a message and before it retransmits the message if it receives no acknowledgment for that message. This value will apply to the GWWS server when it sends a response in an outbound sequence.
The default value is 20000 milliseconds.
<wsrm:ExponentialBackoff>
Specifies that the retransmission interval is adjusted using the exponential backoff algorithm. This value applies to the GWWS server when it sends a response in an outbound sequence.
<beapolicy:Expires>
Specifies the amount of time after which the reliable Web service expires and does not accept any new sequence messages.
This element has a single attribute, Expires, whose data type is an XML Schema duration type. For example, if you want to set the expiration time to one day, use the following:
< beapolicy:Expires Expires="P1D" />
The default value is never expire.
<beapolicy:QOS>
Specifies the delivery assurance. SALT supports the following assurances:
  • AtMostOnce - Messages are delivered at most once, without duplication. There is possibility that some messages may not be delivered.
  • AtLeastOnce - Every message is delivered at least once. There is possibility that some messages are delivered more than once.
  • ExactlyOnce - Each message is delivered exactly once, without duplication.
  • InOrder - Messages are delivered in the order that they were sent. This delivery assurance can be combined with one of the preceding three assurances.
The default value is "ExactlyOnce InOrder".

Specifying a Policy File in the Configuration File

You must reference the WS-ReliableMessaging policy file at the end-point level in the SALT configuration file. The following entry in the SALT configuration file shows how to reference the WS-ReliableMessaging policy file. 

<Policy>
     <RMPolicy>RMpolicy.xml</RMPolicy>
</Policy>
Note: Reliable Messaging in BEA SALT does not support process/system failure scenarios, which means SALT does not store the message in a persistent storage area. BEA SALT works in a direct mode with the SOAP client. Usually, system failure recovery requires business logic synchronization between the client and server.

 

Configuring the GWWS Gateway

The GWWS gateway provides the connection between the Tuxedo service and the Web service client. Two critical configurations must exist for the GWWS gateway process to reliably access the Tuxedo services.

These two configurations provide the gateway connection that allows SALT to access Tuxedo services.

Configuring the Gateway as a Tuxedo System Server

Configure the GWWS gateway in the Tuxedo UBBCONFIG file to run as a Tuxedo system server. You can define multiple GWWS server instances concurrently in a Tuxedo UBBCONFIG file. Listing 2-4 lists part of the UBBCONFIG file showing how to define GWWS instances for a Tuxedo application.

Listing 2-4 GWWS Gateways Defined as Tuxedo Servers in the UBBCONFIG File *SERVERS Section 
......
*SERVERS
GWWS SRVGRP=GROUP1 SRVID=10
CLOPT="-A -- -c saltconf_1.xml -i GW1"
GWWS SRVGRP=GROUP1 SRVID=11
CLOPT="-A -- -c saltconf_1.xml -i GW2"
GWWS SRVGRP=GROUP2 SRVID=20
CLOPT="-A -- -c saltconf_2.xml -i GW3"
......

In the UBBCONFIG file *SERVERS sections, you must specify the SALT configuration file and the ID of the GWWS instances defined in the SALT configuration.

For more information, see GWWS.

Note: Each Web service client is deemed a workstation client in Tuxedo; therefore, MAXWSCLIENTS must be configured with a valid number in UBBCONFIG for the node where the GWWS server is deployed.
Note: 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.
Note: 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 UBBCONFIG file.

 

Configuring Security

BEA SALT provides point-to-point security using SSL link-level security and uses the Tuxedo security framework for authentication. User profiles are passed via HTTP basic authentication specifications.

Setting Up SSL Link-Level Security

To set up link-level security using SSL, you must specify <Certificate> elements in the <System> parameter in the SALT configuration so that the GWWS gateway can handle HTTPS request. You can enable link-level security by specifying the HTTPS:// address in the SALT configuration file. For information about how to define <Certificate>, refer to SALT Configuration Format.

If the GWWS is configured to use SSL, SEC_PRINCIPAL_PASSVAR and SEC_PRINCIPAL_NAME must be configured for GWWS in the *SERVER definition in the UBBCONFIG file.

Setting Up HTTP Basic Authentication

BEA SALT uses the Tuxedo security framework for system authentication. The GWWS server supports Tuxedo user profile throughput from the Web service client via HTTP basic authentication protocol.

The GWWS gateway supports 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 Tuxedo authentication. 

Authorization: Basic <base64Binary of username:password>

The following is an example of a string from the HTTP header: 

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

In this example, the client sends the Tuxedo username Aladdin and the password open sesame, and uses this paired value for Tuxedo authentication.

 

Validating the Configuration

BEA SALTcomponents validate the given SALT configuration according to the predefined XML Schema file. A valid SALT configuration file is a prerequisite for the GWWS server to start and for tmwsdlgen to generate the WSDL document file.

The SALT configuration schema file can be found at $TUXDIR/udataobj/saltconfig_200606.xsd.

BEA SALT uses the schema file to validate the SALT configuration file when:

 

Dynamically Loading the Configuration

You can dynamically reload the BEA SALT configuration file by using the wsadmin command. For more information, see the BEA SALT Reference Guide.

Dynamically Reloading the SALT Configuration File

At runtime, the GWWS server can dynamically reload the configuration file. You can also download the WSDL document file from the GWWS server (which is based on the latest SALT configuration file).

Use the following command with wsadmin to reload the configuration: 

configreload(creload) -i InstanceID1

This sub command is used to trigger configuration runtime reloading for the specified GWWS process. Option -i must be specified to indicate one GWWS server for reloading.

Troubleshooting Reloading Configurations Dynamically

Possible reasons for configuration reload failure are:

 

Generating the WSDL Document

A Web service is usually defined using a WSDL document and made available via SOAP. WSDL, Web Service Descriptive Language, is an XML format used to describe network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.

Before generating a WSDL document for the Web client to access services, be sure you complete the following tasks:

When the GWWS server is booted, it loads the specified SALT configuration file, which includes: reading the configuration XML file, validating the XML file, loading corresponding Tuxedo service contract information from Tuxedo Service Metadata Repository, and loading WS-ReliableMessaging policy definition file. The GWWS server can also dynamically reload the BEA SALT configuration file at runtime.

The GWWS process also automatically generates a WSDL document to reflect the latest configuration information so that it can be downloaded from the GWWS server via HTTP GET method. To generate a WSDL document file, use tmwsdlgen.

For more information, see tmwsdlgen.

For information about WSDL mapping rules for Tuxedo buffer types, see Data Mapping and Conversions.

Viewing the WSDL Document

The GWWS gateway server, maintains the most recent auto-generated WSDL documents. The GWWS server supports a specific HTTP GET request from any HTTP client to download WSDL documents. The GWWS server can accept the SOAP version and encoding style indication for different formatted WSDL documents.

You can download the latest WSDL document using the following URL: 

"http(s)://<host>:<port>/ wsdl[?[SOAPversion=<1.1 | 1.2> ] [&encstyle=<doc | rpc > ][&mappolicy=<pack|raw>][&toolkit=<wls|axis>]]"

SOAPversion=<1.1|1.2>

Specifies the SOAP version for the generated WSDL document. If a version is not specified, the default is value 1.1.

encstyle=<doc|rpc>

Specifies the encoding style for the generated WSDL document. If a style is not specified, the default value is doc.

mappolicy=<pack|raw>

Specifies the data mapping policies for certain Tuxedo Typed buffers for the generated WSDL document. Currently, this option impacts CARRAY typed buffers only. If the argument is not specified, pack is used as the default value.

toolkit=<wls|axis>

Use this argument only if you have previously defined mappolicy=raw. Specify the client toolkit used so that the proper WSDL document description for a CARRAY typed buffer MIME attachment is generated. BEA SALT supports WebLogic Server and Axis for SOAP with Attachments. The default value is wls.

Sample WSDL Document

Using the following sample BEA SALT configuration file, a corresponding WSDL document can be generated. 

<Configuration xmlns="http://www.bea.com/Tuxedo/Salt/200606" >
  <Servicelist id="sample">
     <Service name="TOUPPER" />
  </Servicelist>
  <Policy />
  <System />
  <WSGateway>
     <GWInstance id="GW1">
        <HTTP address="//webservice.com.abc:8080" />
     </GWInstance>
  </WSGateway>
</Configuration>

The following WSDL document is generated when the previous SALT configuration is used.

Listing 2-5 Sample WSDL Document 
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tuxtype="urn:pack.sample_typedef.salt11" xmlns:tns="urn:sample.wsdl" xmlns:soap11="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsrp="http://schemas.xmlsoap.org/rp/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetNamespace="urn:sample.wsdl">
       <wsdl:documentation>Generated from conf.xml at 05-22-2006 14:27:26:773</wsdl:documentation>
       <wsdl:types>
              <xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="urn:pack.sample_typedef.salt11">
                     <xsd:element name="TOUPPER">
                            <xsd:complexType>
                                   <xsd:sequence>
                                          <xsd:element name="inbuf" type="xsd:string"></xsd:element>
                                   </xsd:sequence>
                            </xsd:complexType>
                     </xsd:element>
                     <xsd:element name="TOUPPERResponse">
                            <xsd:complexType>
                                   <xsd:sequence>
                                          <xsd:element name="outbuf" type="xsd:string"></xsd:element>
                                   </xsd:sequence>
                            </xsd:complexType>
                     </xsd:element>
              </xsd:schema>
       </wsdl:types>
       <wsdl:message name="TOUPPERInput">
              <wsdl:part element="tuxtype:TOUPPER" name="parameters"></wsdl:part>
       </wsdl:message>
       <wsdl:message name="TOUPPEROutput">
              <wsdl:part element="tuxtype:TOUPPERResponse" name="parameters"></wsdl:part>
       </wsdl:message>
       <wsdl:portType name="sample_PortType">
              <wsdl:operation name="TOUPPER">
                     <wsdl:input message="tns:TOUPPERInput"></wsdl:input>
                     <wsdl:output message="tns:TOUPPEROutput"></wsdl:output>
              </wsdl:operation>
       </wsdl:portType>
       <wsdl:binding name="sample_Binding" type="tns:sample_PortType">
              <soap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"></soap11:binding>
              <wsdl:operation name="TOUPPER">
                     <soap11:operation soapAction="TOUPPER" style="document"></soap11:operation>
                     <wsdl:input>
                            <soap11:body use="literal"></soap11:body>
                     </wsdl:input>
                     <wsdl:output>
                            <soap11:body use="literal"></soap11:body>
                     </wsdl:output>
              </wsdl:operation>
       </wsdl:binding>
       <wsdl:service name="TuxedoWebService">
              <wsdl:port binding="tns:sample_Binding" name="sample_GW1_HTTPPort">
                     <soap11:address location="http://webservice.com.abc:8080/sample"></soap11:address>
              </wsdl:port>
       </wsdl:service>
</wsdl:definitions>

 

See Also


  Back to Top       Previous  Next