|
This topic contains the following sections:
Oracle SALT supports bi-directional data type mapping between WSDL messages and Oracle Tuxedo typed buffers. For each service invocation, GWWS server converts each message between Oracle Tuxedo typed buffer and SOAP message payload. SOAP message payload is the XML effective data encapsulated within the <soap:body> element. For more information, see Understanding Oracle SALT Message Conversion.
For native Oracle Tuxedo services, each Oracle Tuxedo buffer type is described using an XML Schema in the SALT generated WSDL document. Oracle Tuxedo service request/response buffers are represented in regular XML format. For more information, see Tuxedo-to-XML Data Type Mapping for Oracle Tuxedo Services.
For external Web services, each WSDL message is mapped as an Oracle Tuxedo FML32 buffer structure. An Oracle Tuxedo application invokes SALT proxy service using FML32 buffers as input/output. For more information see, XML-to-Tuxedo Data Type Mapping for External Web Services.
Oracle SALT message conversion is the message transformation process between SOAP XML data and Oracle Tuxedo typed buffer. Oracle SALT introduces two types message conversion rules: Inbound Message Conversion and Outbound Message Conversion.
Inbound message conversion process is the SOAP XML Payload and Oracle Tuxedo typed buffer conversion process conforms to the “Tuxedo-to-XML data type mapping rules”. Inbound message conversion process happens in the following two phases:
Oracle SALT encloses Oracle Tuxedo buffer content with element <inbuf>, <outbuf> and/or <errbuf> in the SOAP message, the content included within element <inbuf>, <outbuf> and/or <errbuf> is called “Inbound XML Payload”.
Outbound message conversion process is the SOAP XML Payload and Oracle Tuxedo typed buffer conversion process conforms to the “Tuxedo-to-XML data type mapping rules”. Outbound message conferring process happens in the following two phases:
Table 2-1 compares an inbound message conversion process and an outbound message conversion process.
Oracle SALT provides a set of rules for describing Oracle Tuxedo typed buffers in an XML document as shown in Table 2-2. These rules are exported as XML Schema definitions in SALT WSDL documents. This simplifies buffer conversion and does not require previous Oracle Tuxedo buffer type knowledge.
|
In the SOAP message, the XML element that encapsulates the actual string data, must be defined using
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.
|
||||||
|
The
CARRAY data bytes must be encoded with base64Binary before it can be embedded in 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.
|
||||||
|
The XML Schema built-in type,
xsd:string, represents the corresponding type for buffer data stored in a SOAP message.
The GWWS server only accepts “UTF-8” encoded XML documents. If the Web service client wants to access Oracle Tuxedo services with
MBSTRING buffer, the mbstring payload must be represented as “UTF-8” encoding in the SOAP request message.
|
||||||
|
Oracle Tuxedo
MBSTRING data type can be specified with a max byte length in the Oracle Tuxedo Service Metadata Repository. The GWWS server checks the byte length of the converted MBSTRING buffer value.
|
||||||
|
The XML Schema built-in type,
xsd:anyType, is the corresponding type for XML documents stored in a SOAP message. It 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. It 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.
The actual XML data must be 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 Oracle Tuxedo, the corresponding SOAP message must also enforce this limitation.
|
||||||
Oracle Tuxedo VIEW and VIEW32 typed buffers store C structures defined by Oracle Tuxedo applications.
VIEW structures are defined by using VIEW definition files. A VIEW buffer type can define multiple fields.
|
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 more information, see 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 required count attribute of the FML/FML32 field definition.
|
||||||
For limitations and considerations regarding mapping
FML/FML32 buffers, refer to FML/FML32 Considerations.
|
Oracle Tuxedo STRING typed buffers are used to store character strings that end with a NULL character. Oracle Tuxedo STRING typed buffers are self-describing.
Listing 2-1 shows a SOAP message for a TOUPPER Oracle Tuxedo service example that accepts a STRING typed buffer.
<?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” />
Oracle 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. Oracle Tuxedo CARRAY typed buffers can map to xsd:base64Binary or MIME attachments. The default is xsd:base64Binary.
Listing 2-2 shows the SOAP message for the TOUPPER Oracle 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 2-3 shows the SOAP message for the TOUPPER Oracle 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>
Oracle Tuxedo MBSTRING typed buffers are used for multibyte character arrays. Oracle Tuxedo MBSTRING typed buffers consist of the following three elements:
| Note: | You cannot embed multibyte characters with non “UTF-8” code sets in the SOAP message directly. |
Listing 2-4 shows the SOAP message for the MBSERVICE Oracle Tuxedo service, which accepts an MBSTRING typed buffer.
<?xml encoding=”UFT-8”?>
<SOAP:body>
<m:MBSERVICE xmlns:m=”http://......”>
<inbuf>こんにちは</infuf>
</m:MBSERVICE>
The XML Schema for <inbuf> is:
<xsd:element name=”inbuf” type=”xsd:string” />
| WARNING: | Oracle 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 Oracle SALT default. |
| WARNING: | If you use another character conversion engine and Japanese "—" is included in MBSTRING, Oracle Tuxedo server-side MBSTRING auto-conversion cannot convert it back into Shift-JIS or EUC-JP. |
Oracle Tuxedo XML typed buffers store XML documents.
Listing 2-5 shows the Stock Quote XML document.
Listing 2-6 shows the SOAP message for the STOCKINQ Oracle 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 Oracle 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 an Oracle Tuxedo service returns a buffer having a default namespace to the GWWS server as shown in Listing 2-7, the GWWS server converts the default namespace to a regular name as shown in Listing 2-8. |
<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>
Oracle Tuxedo VIEW and VIEW32 typed buffers are used to store C structures defined by Oracle Tuxedo applications. You must define the VIEW structure with the VIEW definition files. A VIEW buffer type can define multiple fields.
Listing 2-9 shows the MYVIEW VIEW definition file.
Listing 2-10 shows the SOAP message for the MYVIEW Oracle 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 2-11.
<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 Oracle Tuxedo VIEW/VIEW32 buffers to and from XML.
VIEW/VIEW32. This includes setting up a VIEW directory and system VIEW definition files. These definitions are automatically loaded by the GWWS server.VIEW/VIEW32 parameter definition and the VIEW/VIEW32 definition file at start up. 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 Oracle 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 Oracle 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 Oracle 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.
Oracle Tuxedo FML and FML32 typed buffer are proprietary Oracle Tuxedo system self-describing buffers. Each data field carries its own identifier, an occurrence number, and possibly a length indicator.
Listing 2-12 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 2-13.
<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 2-14 shows the SOAP message for the TRANSFER Oracle 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 2-15.
<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 Oracle Tuxedo FML/FML32 buffers to and from XML.
FML/FML32. This includes an FML field table file directory and system FML field definition files. These definitions are automatically loaded by the GWWS. FML typed buffers can be handled only if the environment is set up correctly.FML32 Field type FLD_PTR is not supported.FML/FML32 parameter definition and FML/FML32 definition file during start up.
If an FML/32 field is found that is not in accordance with the environment setting, or the field table field data type definition is different from the parameter data type definition in the Oracle Tuxedo Service Metadata Repository, the GWWS cannot start. Inconsistency messages are printed in the ULOG file.
tmwsdlgen command checks for consistency between the Oracle Tuxedo Service Metadata Repository FML/FML32 parameter definition and FML/FML32 definition file. If inconsistencies are found, it issue a warning and allow inconsistencies.
If an FML/32 field is found that is not in accordance with the environment setting, or the field table field data type definition is different from the parameter data type definition in the Oracle Tuxedo Service Metadata Repository, tmwsdlgen attempts to use Oracle Tuxedo Service Metadata Repository definitions to compose the WSDL document.
xsd:long schema type is used to describe 64-bit numeric value. The following scenario generates a SOAP fault:
The GWWS runs in 32-bit mode, and a Web service client sends a xsd:long typed data which exceeds the 32-bit value range.
Oracle Tuxedo X_C_TYPE typed buffers are equivalent, and have a similar WSDL format to, Oracle Tuxedo VIEW typed buffers.They are transparent for SOAP clients. However, even though usage is similar to the Oracle Tuxedo VIEW buffer type, SALT administrators must configure the Oracle Tuxedo Service Metadata Repository for any particular Oracle Tuxedo service that uses this buffer type.
| Note: | All View related considerations also take effect for X_C_TYPE typed buffer. |
Oracle Tuxedo X_COMMON typed buffers are equivalent to Oracle 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.
Oracle Tuxedo X_OCTET typed buffers are equivalent to CARRAY.
| Note: | Oracle Tuxedo X_OCTET typed buffers can only map to xsd:base64Binary type. SALT 1.1 does not support MIME attachment binding for Oracle Tuxedo X_OCTET typed buffers. |
Oracle SALT provides a plug-in mechanism that supports 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 the Web service client and Oracle Tuxedo Web service stack. As with XML typed buffers, only a single root XML buffer can be stored in the SOAP body. The GWWS checks this for consistency.
For more plug-in information, see Using Oracle SALT Plug-Ins.
Oracle SALT maps each wsdl:message as an Oracle Tuxedo FML32 buffer structure. Oracle SALT defines a set of rules for representing the XML Schema definition using FML32. To invoke external Web Services, customers need to understand the exact FML32 structure that converted from the external Web Service XML Schema definition of the corresponding message.
The following sections describe detailed WSDL message to Oracle Tuxedo FML32 buffer mapping rules:
Table 2-3 shows the supported XML Schema Built-In Simple Data Type and the corresponding Oracle Tuxedo FML32 Field Data Type.
The following samples demonstrate how to prepare data in a Oracle Tuxedo program for XML Schema Built-In Simple Types.
Table 2-7 lists the supported XML Schema User Defined Simple Data Type and the corresponding Oracle Tuxedo FML32 Field Data Type.
<xsd:anyType> |
FLD_MBSTRING |
char [] |
|
Equivalent FML32 Field Type of the primitive simple type (see Table 2-3)
|
Equivalent C Primitive Data Type of the primitive simple type (see Table 2-3)
|
||
The following samples demonstrate how to prepare data in an Oracle Tuxedo program for XML Schema User Defined Data Types:
Oracle Tuxedo FML32 buffer type is always used in mapping WSDL messages.
Table 2-10 lists the WSDL message mapping rules defined by Oracle SALT.
Oracle Tuxedo Request Buffer (Input buffer) |
||
faultcode string - - |
||
|