|
|
This section contains the following topics:
Each Tuxedo buffer type is described using an XML Schema in the generated WSDL document. This means that Tuxedo service request/response data is represented in regular XML format. The XML format input data is automatically converted into Tuxedo typed buffers according to the corresponding buffer type schema definitions.
The converted typed buffers are used as the input of the Tuxedo service. Any typed buffer returned by the Tuxedo service is converted into XML format and returned to the Web service client in SOAP response message.
The GWWS server automatically converts SOAP message into Tuxedo buffer types and Tuxedo buffer types into XML SOAP messages. BEA SALT provides a set of rules for describing Tuxedo typed buffers in an XML document. These rules are exported as XML Schema definitions in SALT WSDL documents. This simplifies buffer conversion and does not require previous knowledge about Tuxedo buffer types.
|
In the SOAP message, the XML element that encapsulates the actual string data, must be defined with xsd:string directly.
|
||||
The CARRAY buffer raw data is carried within a MIME multipart/related message, which is defined in the "SOAP Messages with Attachments"specification.
For more information, see Generating the WSDL Document.
|
||||
|
The CARRAY data bytes must be encoded with
base64Binary before it can be embedded into a SOAP message. Using base64Binary encoding with this opaque data stream saves the original data and makes the embedded data well-formed and readable.
In the SOAP message, the XML element that encapsulates the actual CARRAY data, must be defined with
xsd:base64Binary directly.
For more information, see Generating the WSDL Document.
|
||||
|
The XML Schema built-in type, The GWWS server only accepts "UTF-8" encoded XML documents. If Web service client wants to access Tuxedo services with MBSTRING buffer, the mbstring payload must be represented as "UTF-8" encoding in the SOAP request message.
For any Tuxedo response MBSTRING Typed buffer (with any encoding character set), The GWWS server automatically transforms the string into "UTF-8" encoding and sends it back to the Web service client. |
||||
|
Tuxedo MBSTRING data type can be specified with a max byte length in the Tuxedo Service Metadata Repository. if defined in Tuxedo, the corresponding SOAP message should also be enforced with this limitation.
|
||||
|
The XML Schema built-in type, xsd:anyType, is the corresponding type for XML documents stored in a SOAP message which allows you to encapsulate any well-formed XML data within the SOAP message.
The GWWS server validates that the actual XML data is well-formed, but will not do any other enforcement validation, such as schema validation.
Only a single root XML buffer is allowed to be stored in the SOAP body; the GWWS server checks for this.
Be sure the actual XML data is encoded using the "UTF-8" character set. Any original XML document prolog information cannot be carried within the SOAP message.
XML data type can specify a max byte data length. If defined in Tuxedo, the corresponding SOAP message also must enforce this limitation.
|
||||
Each VIEW or VIEW32 data type is defined as an XML Schema complex type. Each VIEW field should be one or more sub elements of the XML Schema complex type. The name of the sub element is the VIEW field name. The occurrence of the sub element depends on the count attribute of the VIEW field definition. The value of the sub element should be in the VIEW field data type corresponding XML Schema type.
|
||||
For limitations and considerations regarding mapping VIEW/VIEW32 buffers, refer to VIEW/VIEW32 Considerations.
|
||||
FML/FML32 buffers can only have basic data-dictionary-like definitions for each basic field data. A particular FML/FML32 buffer definition should be applied for each FML/FML32 buffer with a different type name.
Each FML/FML32 field should be one or more sub -elements within the FML/FML32 buffer XML Schema type. The name of the sub element is the FML field name. The occurrence of the sub element depends on the count and requiredcount attribute of the FML/FML32 field definition.
|
||||
For limitations and considerations regarding mapping FML/FML32 buffers, refer to FML/FML32 Considerations.
|
Tuxedo STRING typed buffer are used to store character strings that terminate with a NULL character. Tuxedo STRING typed buffers are self-describing buffer.
The following example depicts the TOUPPER Tuxedo service, which accepts a STRING typed buffer. The SOAP message is as follows:
<?xml ... encoding="UTF-8" ?>
......
<SOAP:body>
<m:TOUPPER xmlns:m="urn:......">
<inbuf>abcdefg</inbuf>
</m:TOUPPER>
</SOAP:body>
The XML Schema for <inbuf> is:
<xsd:element name="inbuf" type="xsd:string" />
Tuxedo CARRAY typed buffers are used to store character arrays, any of which can be NULL. They are used to handle data opaquely and are not self-describing. Tuxedo CARRAY typed buffers can map to xsd:base64Binary or MIME attachments. The default is xsd:base64Binary.
Listing 3-1 shows the SOAP message for the TOUPPER Tuxedo service, which accepts a CARRAY typed buffer, using base64Binary mapping.
<SOAP:body>
<m:TOUPPER xmlns:m="urn:......">
<inbuf>QWxhZGRpbjpvcGVuIHNlc2FtZQ==</inbuf>
</m:TOUPPER>
</SOAP:body>
The XML Schema for <inbuf> is:
<xsd:element name="inbuf" type="xsd:base64Binary" />
Listing 3-2 shows the SOAP message for the TOUPPER Tuxedo service, which accepts a CARRAY typed buffer, as a MIME attachment.
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<claim061400a.xml@example.com>"
Content-Description: This is the optional message description.
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@ example.com>
<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<m:TOUPPER xmlns:m="urn:...">
<inbuf href="cid:claim061400a.carray@example.com"/>
</m:TOUPPER>
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: text/xml
Content-Transfer-Encoding: binary
Content-ID: <claim061400a. carray @example.com>
...binary carray data...
--MIME_boundary--
The WSDL for carray typed buffer will look like the following:
<wsdl:definitions ...>
<wsdl:types ...>
<xsd:schema ...>
<xsd:element name="inbuf" type="xsd:base64Binary" />
</xsd:schema>
</wsdl:types>
......
<wsdl:binding ...>
<wsdl:operation name="TOUPPER">
<soap:operation ...>
<input>
<mime:multipartRelated>
<mime:part>
<soap:body parts="..." use="..."/>
</mime:part>
<mime:part>
<mime:content part="..." type="text/xml"/>
</mime:part>
</mime:multipartRelated>
</input
......
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
Tuxedo MBSTRING Typed Buffers are used for multibyte character arrays. Tuxedo MBSTRING buffers consist of the following three elements: code-set character encoding, data length, character array encoding.
| Note: | You cannot embed multibyte characters with non "UTF-8" code sets into the SOAP message directly. |
Figure 3-1 shows the SOAP message for the MBSERVICE Tuxedo service, which accepts an MBSTRING typed buffer.
The XML Schema for <inbuf> is:
<xsd:element name="inbuf" type="xsd:string" />
| WARNING: | BEA SALT converts the Japanese character "—" (EUC-JP 0xa1bd, Shift-JIS 0x815c) into UTF-16 0x2015. |
| WARNING: | If you use another character set conversion engine, the EUC-JP or Shift-JIS multibyte output for this character may be different. For example, the Java il8n character conversion engine, converts this symbol to UTF-16 0x2014. The result is the also same when converting to UTF-8, which is the BEA SALT default |
| WARNING: | If you use another character conversion engine and Japanese "—" is included in MBSTRING, TUXEDO server-side MBSTRING auto-conversion cannot convert it back into Shift-JIS or EUC-JP. |
Tuxedo XML typed buffers store XML documents.
Listing 3-3 shows the Stock Quote XML document.
Listing 3-4 shows the SOAP message for the STOCKINQ Tuxedo service, which accepts an XML typed buffer.
<?xml version="1.0" encoding="UTF-8"?>
<!-- "Stock Quotes". -->
<stockquotes>
<stock_quote>
<symbol>BEAS</symbol>
<when>
<date>01/27/2001</date>
<time>3:40PM</time>
</when>
<change>+2.1875</change>
<volume>7050200</volume>
</stock_quote>
</stockquotes>
Then part of the SOAP message will look like the following:
<SOAP:body>
<m: STOCKINQ xmlns:m="urn:......">
<inbuf>
<stockquotes>
<stock_quote>
<symbol>BEAS</symbol>
<when>
<date>01/27/2001</date>
<time>3:40PM</time>
</when>
<change>+2.1875</change>
<volume>7050200</volume>
</stock_quote>
</stockquotes>
</inbuf>
</m: STOCKINQ >
</SOAP:body>
The XML Schema for <inbuf> is:
<xsd:element name="inbuf" type="xsd:anyType" />
| Note: | If a default namespace is contained in a Tuxedo XML typed buffer and returned to the GWWS server, the GWWS server converts the default namespace to a regular name. Each element is then prefixed with this name. |
| Note: | For example, If a Tuxedo service returns a buffer having a default namespace to the GWWS server as shown in Listing 3-5, the GWWS server converts the default namespace to a regular name as shown in Listing 3-6. |
<Configuration xmlns="http://www.bea.com/Tuxedo/Salt/200606">
<Servicelist id="simpapp">
<Service name="toupper"/>
</Servicelist>
<Policy/>
<System/>
<WSGateway>
<GWInstance id="GWWS1">
<HTTP address="//myhost:8080"/>
</GWInstance>
</WSGateway>
</Configuration>
<dom0:Configuration
xmlns:dom0="http://www.bea.com/Tuxedo/Salt/200606">
<dom0:Servicelist dom0:id="simpapp">
<dom0:Service dom0:name="toupper"/>
</dom0:Servicelist>
<dom0:Policy></<dom0:Policy>
<dom0:System></<dom0:System>
<dom0:WSGateway>
<dom0:GWInstance dom0:id="GWWS1">
<dom0:HTTP dom0:address="//myhost:8080"/>
</dom0:GWInstance>
</dom0:WSGateway>
</dom0:Configuration>
Tuxedo VIEW and VIEW32 typed buffers are used to store C structures defined by Tuxedo applications. You must define the VIEW structure with the VIEW definition files. A VIEW buffer type can define multiple fields.
Listing 3-7 shows the MYVIEW VIEW definition file.
Listing 3-8 shows the SOAP message for the MYVIEW Tuxedo service, which accepts a VIEW typed buffer.
VIEW MYVIEW
#type cname fbname count flag size null
float float1 - 1 - - 0.0
double double1 - 1 - - 0.0
long long1 - 3 - - 0
string string1 - 2 - 20 '\0'
END
<SOAP:body>
<m: STOCKINQ xmlns:m="http://......">
<inbuf>
<float1>12.5633</float1>
<double1>1.3522E+5</double1>
<long1>1000</long1>
<long1>2000</long1>
<long1>3000</long1>
<string1>abcd</string1>
<string1>ubook</string1>
</inbuf>
</m: STOCKINQ >
</SOAP:body>
The XML Schema for <inbuf> is shown in Listing 3-9.
<xsd:complexType name=" view_MYVIEW">
<xsd:sequence>
<xsd:element name="float1" type="xsd:float" />
<xsd:xsd:element name="double1" type="xsd:double" />
<xsd:element name="long1" type="xsd:long" minOccurs="3" />
<xsd:element name="string1" type="xsd:string minOccurs="3" />
</xsd:sequence>
</xsd: complexType >
<xsd:element name="inbuf" type="tuxtype:view_MYVIEW" />
The following considerations apply when converting Tuxedo VIEW/VIEW32 buffers to and from XML.
If an inconsistency is found, the GWWS server cannot start. Inconsistency messages are printed in the ULOG file.
tmwsdlgen also provides strong consistency checking between the Tuxedo Service Metadata Repository VIEW/VIEW32 parameter definition and the VIEW/VIEW32 definition file at start up. If an inconsistency is found, the GWWS server will not start. Inconsistency messages are printed in the ULOG file.
If the VIEW definition file cannot be loaded, tmwsdlgen attempts to use the Tuxedo Service Metadata Repository definitions to compose the WSDL document.
dec_t is not supported, if you define VIEW fields with type dec_t, the service cannot be exported as a Web service and an error message is generated when the BEA SALT configuration file is loading.xsd:long schema type is used to describe 64-bit numeric values.
If the GWWS server runs in 32-bit mode, and the Web service client sends xsd:long typed data that exceeds the 32-bit value range, you may get a SOAP fault.
Tuxedo FML and FML32 typed buffer are proprietary BEA Tuxedo system self-describing buffers in which each data field carries its own identifier, an occurrence number, and possibly a length indicator.
Listing 3-10 shows the SOAP message for the TRANSFER Tuxedo service, which accepts an FML typed buffer.
The request fields for service LOGIN are:
ACCOUNT_ID 1 long /* 2 occurrences, The withdrawal account is 1st, and the deposit account is 2nd */
AMOUNT 2 float /* The amount to transfer */
Part of the SOAP message is as follows:
<SOAP:body>
<m:TRANSFER xmlns:m="urn:......">
<inbuf>
<ACCOUNT_ID>40069901</ACCOUNT_ID>
<ACCOUNT_ID>40069901</ACCOUNT_ID>
<AMOUNT>200.15</AMOUNT>
</inbuf>
</m:TRANSFER >
</SOAP:body>
The XML Schema for <inbuf> is shown in Listing 3-11.
<xsd:complexType name=" fml_TRANSFER_In">
<xsd:sequence>
<xsd:element name="ACCOUNT_ID" type="xsd:long" minOccurs="2"/>
<xsd:element name=" AMOUNT" type="xsd:float" />
</xsd:sequence>
</xsd: complexType >
<xsd:element name="inbuf" type="tuxtype: fml_TRANSFER_In" />
Listing 3-12 shows the SOAP message for the TRANSFER Tuxedo service, which accepts an FML32 typed buffer.
The request fields for service LOGIN are:
CUST_INFO 1 fml32 /* 2 occurrences, The withdrawal customer is 1st, and the deposit customer is 2nd */
ACCOUNT_INFO 2 fml32 /* 2 occurrences, The withdrawal account is 1st, and the deposit account is 2nd */
AMOUNT 3 float /* The amount to transfer */
Each embedded CUST_INFO includes the following fields:
CUST_NAME 10 string
CUST_ADDRESS 11 carray
CUST_PHONE 12 long
Each embedded ACCOUNT_INFO includes the following fields:
ACCOUNT_ID 20 long
ACCOUNT_PW 21 carray
Part of the SOAP message will look as follows:
<SOAP:body>
<m:STOCKINQ xmlns:m="urn:......">
<inbuf>
<CUST_INFO>
<CUST_NAME>John</CUST_NAME>
<CUST_ADDRESS>Building 15</CUST_ADDRESS>
<CUST_PHONE>1321</CUST_PHONE>
</CUST_INFO>
<CUST_INFO>
<CUST_NAME>Tom</CUST_NAME>
<CUST_ADDRESS>Building 11</CUST_ADDRESS>
<CUST_PHONE>1521</CUST_PHONE>
</CUST_INFO>
<ACCOUNT_INFO>
<ACCOUNT_ID>40069901</ACCOUNT_ID>
<ACCOUNT_PW>abc</ACCOUNT_PW>
</ACCOUNT_INFO>
<ACCOUNT_INFO>
<ACCOUNT_ID>40069901</ACCOUNT_ID>
<ACCOUNT_PW>zyx</ACCOUNT_PW>
</ACCOUNT_INFO>
<AMOUNT>200.15</AMOUNT>
</inbuf>
</m: STOCKINQ >
</SOAP:body>
The XML Schema for <inbuf> is shown in Listing 3-13.
<xsd:complexType name="fml32_TRANSFER_In">
<xsd:sequence>
<xsd:element name="CUST_INFO" type="tuxtype:fml32_TRANSFER_p1" minOccurs="2"/>
<xsd:element name="ACCOUNT_INFO" type="tuxtype:fml32_TRANSFER_p2" minOccurs="2"/>
<xsd:element name="AMOUNT" type="xsd:float" />
/xsd:sequence>
</xsd:complexType >
<xsd:complexType name="fml32_TRANSFER_p1">
<xsd:element name="CUST_NAME" type="xsd:string" />
<xsd:element name="CUST_ADDRESS" type="xsd:base64Binary" />
<xsd:element name="CUST_PHONE" type="xsd:long" />
</xsd:complexType>
<xsd:complexType name="fml32_TRANSFER_p2">
<xsd:element name="ACCOUNT_ID" type="xsd:long" />
<xsd:element name="ACCOUNT_PW" type="xsd:base64Binary" />
</xsd:complexType>
<xsd:element name="inbuf" type="tuxtype: fml32_TRANSFER_In" />
The following considerations apply to converting Tuxedo FML/FML32 buffers to and from XML.
FLD_PTR is not supported.If any FML/32 field cannot be found according to the environment setting, or the field data type definition in the field table is different from the parameter data type definition in the Tuxedo Service Metadata Repository, the GWWS cannot start. Inconsistency messages are printed in the ULOG file.
tmwsdlgen command checks for consistency between the Tuxedo Service Metadata Repository FML/FML32 parameter definition and FML/FML32 definition file, but will issue a warning and allow inconsistencies.
If any FML/32 field cannot be found according to the environment setting, or the field data type definition in the field table is different from the parameter data type definition in Tuxedo Service Metadata Repository, tmwsdlgen attempts to use Tuxedo Service Metadata Repository definitions to compose the WSDL document.
xsd:long schema type is used to describe 64-bit numeric value. You should get a SOAP fault in the following case: The GWWS runs with the 32-bit mode, and Web service client sends a xsd:long typed data which exceeds the 32-bit value range.Tuxedo X_C_TYPE typed buffers are equivalent, and have similar WSDL format to Tuxedo VIEW typed buffers.They are transparent for SOAP clients. However, even though usage is similar to the Tuxedo VIEW buffer type, SALT administrators must configure the Tuxedo Service Metadata Repository for any particular Tuxedo service which uses this buffer type.
| Note: | All View related considerations also take effect for X_C_TYPE typed buffer. |
Tuxedo X_COMMON typed buffers are equivalent to Tuxedo VIEW typed buffers. However, they are used for compatibility between COBOL and C programs. Field types should be limited to short, long, and string.
Tuxedo X_OCTET typed buffers are equivalent to CARRAY.
| Note: | Tuxedo X_OCTET typed buffers can only map to xsd:base64Binary type. SALT 1.1 does not support MIME attachment binding for Tuxedo X_OCTET typed buffers. |
BEA SALT provides a plug-in mechanism to support custom typed buffers. You can validate the SOAP message against your own XML Schema definition, allocate custom typed buffers, and parse data into the buffers and other operations.
XML Schema built-in type xsd:anyType is the corresponding type for XML documents stored in a SOAP message. While using custom typed buffers, you should define and represent the actual data into an XML format and transfer between Web service client and Tuxedo Web service stack. Similar to the XML typed buffers, only a single root XML buffer is allowed to be stored in the SOAP body. The GWWS checks this for consistency.
For more plug-in information, see Introduction to Using Plug-ins with BEA SALT.
In order to export Tuxedo services and Web services, Tuxedo service contract information is needed so that it can be converted into a WDSL document. SALT leverages the Tuxedo Service Metadata Repository to access Tuxedo service information.
Converting configuration information into WSDL specification compliant information requires mapping rules. Table 3-2 provides the mapping rules for a generated WSDL document.
The following rules apply for attaching WS Policy files to WSDL documents.
<wsdl:definitions> with the top element as <wsp:Policy>.wsu:id attribute with a unique ID name.<wsp:UsingPolicy> element is mandatory and must be a child element of <wsdl:definitions>. The format of <wsp:UsingPolicy> must be a fixed format as follows: <wsp:UsingPolicy wsdl:required="true" />
BEA SALT supports the following mapping rules for each Tuxedo service type and SOAP Message Exchange Pattern (MEP).
| Note: | BEA SALT does not support the Tuxedo queue service type, even though it is supported in the Tuxedo Service Metadata Repository. |
BEA SALT supports two traditional message encoding styles for SOAP messages:
The generated WSDL document supports the abstract message definition in document message style. Because the document style can represent SOAP messages in various XML document structures, there are many ways to define this document structure.
The following rules apply to SALT-generated WSDL documents to create a fixed-structure message description.
The message name string syntax is as follows:
<Tuxedo service name + "Input|Output">
Use the Input suffix when describing an input typed buffer. Use the Output suffix when describing an output typed buffer
The following format rules apply for <wsdl:part>:
<wsdl:part> instance is associated with each Tuxedo typed buffer.name attribute of <wsdl:part> is hard-coded as parameters.element attribute of <wsdl:part> is specified.If the message indicates a Tuxedo service input buffer, the value is the same as the associated Tuxedo service name.
If the message indicates a Tuxedo service output buffer, the value is constructed with the associated Tuxedo service name, plus a suffix string response.
The schema definition for /wsdl:message/wsdl:part/@element is:
element is <xsd:complexType>. The type name for this complex type is not defined; rather it is described by the type structure. The type name is not defined because the type indicating a particular service buffer is not likely to be reused for other elements, so there is no need to define a type name for reference.<xsd:complexType> includes only one element with a Tuxedo buffer type name, for example, STRING or XML.VIEW/VIEW32 or FML/FML32 or a custom type buffers described parameters, the #bufmappingtype definition includes parameter-specifying elements.The following code listing shows the non-normative grammar:
<xsd:schema ...>
<xsd:element name="#svcname" > *
<xsd:complexType>
<xsd:sequence>
<xsd:element name="#buffertype" type="#bufmappingtype" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="#bufmappingtype"> *
<xsd:sequence>
<xsd:element name="#parametername" type="#parammappingtype" /> *
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=" #parammappingtype"> *
......
</xsd:complexType>
</xsd:schema>
This example in this section depicts the transfer service definitions in the SALT configuration file, the corresponding transfer service contract information from the Tuxedo Service Metadata Repository, the generated WSDL document, and the associated request and response messages for the transfer service.
Listing 3-14 shows an example of a section of the BEA SALT configuration file definition for the service.
<Configuration>
<Servicelist id="bank">
<Service name="transfer" />
</Servicelist>
.......
</Configuration>
The corresponding Tuxedo Service Metadata Repository transfer service contract information is shown in Listing 3-15.
Service=transfer
inbuf=FML
outbuf=STRING
param=ACCOUNT_ID
type=long
access=in
count=2
requiredcount=2
param=SAMOUNT
type=string
access=in
param=result
type=STRING
access=out
BEA SALT generates a WSDL document. Listing 3-16 shows the part of the WSDL document that relates to the transfer service definition.
<wsdl:definition
xmlns:tuxtype="urn:bank_typedef"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
......>
<wsdl:types>
<xsd:schema targetNamespace="urn:bank_typedef" ...... >
<xsd:element name="transfer">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="FML" type="tuxtype:fml_transfer_In" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="fml_transfer_In">
<xsd:sequence>
<xsd:element name="ACCOUNT_ID" type="xsd:long" minOccurs="2" maxOccurs="2" />
<xsd:element name="SAMOUNT" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="transferResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="STRING" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
.......
</xsd:schema>
</wsdl:types>
<wsdl:message name="transferInput">
<wsdl:part name="parameters" element="tuxtype:transfer" />
</wsdl:message>
<wsdl:message name="transferOutput">
<wsdl:part name="parameters" element="tuxtype:transferResponse" />
</wsdl:message>
......
</wsdl:definition>
Listing 3-17 shows the SOAP request message for the transfer service.
<soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
<soap:body>
<transfer xmlns=" urn:bank_typedef">
<FML>
< ACCOUNT_ID >111222</ACCOUNT_ID >
< ACCOUNT_ID >333444</ACCOUNT_ID >
< SAMOUNT > 100.00 </ SAMOUNT >
</FML>
</transfer>
</soap:body>
</soap:envelope>
Listing 3-18 shows the SOAP response message for the transfer service.
<soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
<soap:body>
<transferResponse xmlns="urn:bank_typedef">
<STRING>30010.50</STRING>
</transferResponse>
</soap:body>
</soap:envelope>
The generated WSDL document supports abstract message definitions in RPC message style. The following rules apply to SALT-generated WSDL documents for creating RPC style message definitions.
The string of message name is constructed with the following format:
<Tuxedo service name + "Input|Output">
Use the Input suffix when describing an input typed buffer. Use the Output suffix when describing an output typed buffer
The following format rules apply for <wsdl:part>:
<wsdl:part> instance is associated with each Tuxedo input message. The value of the name attribute of <wsdl:part> is hard-coded as inbuf.<wsdl:part> instance is associated with each Tuxedo output message. The value of the name attribute of <wsdl:part> is hard-coded as outbuf.VIEW/VIEW32 or FML/FML32 or custom type buffers described parameters, the #bufmappingtype definition includes parameter-specifying elements.The following code listing shows the non-normative grammar:
<xsd:schema ...>
<xsd:complexType name="bufmappingtype"> *
<xsd:sequence>
<xsd:element name="#parametername" type="#parammappingtype" /> *
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name=" #parammappingtype"> *
......
</xsd:complexType>
</xsd:schema>
This example in this section depicts the transfer service definitions in the SALT configuration file, the corresponding transfer service contract information from the Tuxedo Service Metadata Repository, the generated WSDL document, and the associated request and response messages for the transfer service.
Listing 3-19 shows an example of a section of the BEA SALT configuration file definition for the service.
<Configuration>
<Servicelist id="bank">
<Service name="transfer" />
</Servicelist>
......
</Configuration>
Listing 3-20 shows the corresponding transfer service contract information retrieved from Tuxedo Service Metadata Repository.
Service=transfer
inbuf=FML
outbuf=STRING
param=ACCOUNT_ID
type=long
access=in
count=2
requiredcount=2
param=SAMOUNT
type=string
access=in
param=result
type=STRING
access=out
BEA SALT generates a WSDL document. Listing 3-21 shows the part of the WSDL document that relates to the transfer service definition.
<wsdl:definition
xmlns:tuxtype="urn:bank_typedef"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
......>
<wsdl:types>
<xsd:schema targetNamespace="urn:bank_typedef" ...... >
<xsd:complexType name="fml_transfer_In">
<xsd:sequence>
<xsd:element name="ACCOUNT_ID" type="xsd:long" minOccurs="2" maxOccurs="2" />
<xsd:element name="SAMOUNT" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
......
</xsd:schema>
<wsdl:types>
<wsdl:message name="transferInput">
<wsdl:part name="inbuf" type="tuxtype: fml_transfer_In" />
</wsdl:message>
<wsdl:message name="transferOutput">
<wsdl:part name="outbuf" type="xsd:string" />
</wsdl:message>
......
</wsdl:definition>
Listing 3-22 shows the SOAP request message for the transfer service.
<soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
<soap:body>
<transfer xmlns:ns="urn:bank_typedef" >
<inbuf xsi:type="ns:fml_transfer_In" >
<ACCOUNT_ID xsi:type="xsd:long">111222</ACCOUNT_ID >
<ACCOUNT_ID xsi:type="xsd:long">333444</ACCOUNT_ID >
<SAMOUNT xsi:type="xsd:float"> 100.00 </SAMOUNT >
</inbuf>
</transfer>
</soap:body>
</soap:envelope>
|