Oracle SALT 11g Release 1 (11.1.1.2) Release Notes
Table 1 Revision History Updated “Oracle SALT 11gR1 Supported Platforms” in the Oracle SALT Installation Guide with: Updated “Oracle SALT 11gR1 Supported Platforms” in the Oracle SALT Installation Guide with: Updated “Oracle SALT 11gR1 Supported Platforms” in the Oracle SALT Installation Guide with: Release 11g R1 (11.1.1.1.0)For more information, see Oracle SALT SCA Programming in the Oracle SALT Programming guide.For more information, see Oracle SALT SCA Programming in the Oracle SALT Programming guide.Release 11g R1 (11.1.1.2.0)Oracle SALT 11g Release 11g R1 (11.1.1.2.0) introduced the following features:Inbound support is not be necessary as SOCKS proxies incoming connections without listening endpoints being aware of it. For more information, see the Oracle SALT Deployment File Reference in the Oracle SALT Reference Guide.The wsdlcvt command is enhanced to connect to a SOCKS proxy server. For more information, see the Oracle SALT Command Reference in the Oracle Salt Reference Guide.Release 11g R1 (11.1.1.2.2)Oracle SALT 11g Release 11g R1 (11.1.1.2.2) introduces the following features:For information on installing Oracle SALT 11g Release 1 (11.1.1.2) on top of a previous SALT release, see the Oracle SALT Installation Guide.For information, see Migrating from Oracle SALT 1.1 Application in the Oracle SALT Configuration Guide.Before installing Oracle SALT 11g Release 1 (11.1.1.2), you must ensure that Oracle Tuxedo 11g Release (11.1.1.2.0) is installed.Oracle SALT 11g Release 1 (11.1.1.2) supported platforms are listed in Appendix A: Oracle SALT 11g Release 1 (11.1.1.1.2) Supported Platforms in the Oracle SALT Installation Guide.Oracle SALT 11g Release 1 (11.1.1.2) is compatible with, and fully supports, most industry-standard Web service development toolkits. For more information, see Interoperability Considerations in the Oracle SALT Interoperability Guide.The following sections describe known problems in Oracle SALT 11g Release 1 (11.1.1.2). Entries include a description of the problem, and a workaround or solution where appropriate.
Problem: GWWS rejects non UTF-8 inbound SOAP request messages when SignBody WS-Security Policy is enabled.When GWWS is configured with multiple encoding support, it can accept non UTF-8 encoded SOAP requests; however, the GWWS internally converts all non UTF-8 encoding messages into UTF-8 encoding messages for later operation.If a service requires <soap:Body> signature verification, the GWWS always verify the signature against the converted UTF-8 encoded <soap:Body> instead of the original <soap:Body> content. Thus the signature verification always failed. Platform: All Web service client programs must initiate SOAP requests using UTF-8 encoding when the WS-Security Policy Assertion SignBody is enabled for the corresponding services. Problem: GWWS may reject valid SOAP requests if the target Tuxedo service consumes XML typed buffer as input and the input buffer is defined with “size” restriction in the Tuxedo Service Metadata definition.GWWS automatically adds an additional ‘\0’ to the end of the converted XML buffer. This additional byte may result the XML buffer length exceed the “size” value, hence reject by later Tuxedo buffer validation routine in the GWWS. Enlarge or remove the “size” restriction for XML typed buffer in the Tuxedo Service Metadata Definition. Problem: Tuxedo service may not receive the exact same non UTF-8 encoding string as the string prepared in the SOAP request message.If multiple encoding capability is turned on for the GWWS, and Web Service client programs written in Java send messages with non UTF-8 encoding, GWWS may not send exact the same string value to the Tuxedo service.This is a general problem if different encoding conversion implementations are used. Java encoding implementation has slight difference from ICU encoding implementation (which is used by Tuxedo and SALT), hence an encoding string prepared by the Java program, after ICU “to UTF-8” and “from UTF-8” conversion, may not revert to the exact original string. Problem: WCF (.Net) C# clients may not handle SOAP 1.2 faults sent back by the GWWS gateway.This is due to the fact that GWWS does not specify an @xml:lang attribute in the /Fault/Reason/Text element returned. Platform: All
Problem: SALT multiple encoding feature does not interoperable with Microsoft .NET WCF 3.0 engine.If SALT enables multiple encoding feature, when the inbound call Tuxedo service returns MBSTRING or XML typed buffer with non UTF-8 encoding, the SOAP response message is encoded the same as the MBSTING or XML buffer. Such SOAP response message cannot be accepted by those Web Service client applications developed using Microsoft .NET WCF 3.0 engine. Third-Party Web Service Toolkit: Microsoft .NET WCF 3.0 Customers may need to develop custom encoder/decoder if the Tuxedo service may return non UTF-8 typed buffers and GWWS multiple encoding feature is turned on.Alternatively, you may explicitly turn off the GWWS multiple encoding feature if you are aware all Tuxedo services in your Tuxedo domain never return non UTF-8 buffers. If the GWWS server returns a SOAP fault message when the HTTP Content-Length exceeds 65536, the .NET WCF 3.0 engine sends an exception to report the response is not well-formed.
Note: If the GWWS server returns a normal SOAP message (non SOAP fault) when the HTTP Content-Length exceeds 65536, the .NET Web service engine can accept. None. Avoid to return big buffer when invoking tpreturn() along with TPFAIL status code in the Tuxedo service. If SwA featured WSDL file is generated by Oracle SALT, Apache Axis2 wsdl2java utility generates Java stub code which is different from Apache Axis. Axis2 generated stub code cannot initiate a successful call to Oracle SALT service. Third-Party Web Service Toolkit: Apache Axis2/Java Third-Party Web Service Toolkit: Apache Axis Oracle SALT supports WS-Addressing feature that conforms to WS-Addressing standard 200408 submission. While initiating an asynchronous outbound call, GWWS always defines a <wsa:ReplyTo> endpoint reference in the WS-Addressing soap header. See the following sample <wsa:ReplyTo> segment:Host name “myhost” and port number “7102” in the above sample indicates the listening endpoint that is created by the GWWS which is used to accept asynchronous soap response messages for outbound calls.But Microsoft .NET WCF 3.0 does not recognize the <wsa:ReplyTo> endpoint in the request, and always returns the synchronous response through the request connection.GWWS then always encounters time out in receiving asynchronous response because Microsoft .NET WCF 3.0 never send the response to GWWS expected endpoint. Third-Party Web Service Toolkit: Microsoft .NET WCF 3.0 None. You should disable WS-Addressing feature when initiating outbound call to external Web Service applications built upon Microsoft .NET WCF 3.0. For more information about configuring WS-Addressing feature, see “Configuring Advanced Web Service Messaging Features” in the Oracle SALT Administration Guide.
1. Platform: All
2. The current implementation of Web services binding only returns the fault string when a SOAP fault occurs. For those services where fault detail may contain additional information or data (as handled by the GWWS SALT gateway), ServiceInvocationException has no place or mechanism to store this data. Platform: All
3. Platform: All
4. Problem: JATMI reference binding does not check the presence of two different serviceType, inputBufferType, outputBufferType and errorBufferType elements without specifying a target attribute. Platform: All
Problem: Shutdown of Oracle Tuxedo applications using tmipcrm cause Apache processes configured with mod_tuxedo to exit.When using tmipcrm to terminate an Oracle Tuxedo application, Apache or Oracle Http Server processes exit, possibly interrupting HTTP traffic. Platform: All Always use tmshutdown to stop the Oracle Tuxedo application. tmipcrm (or removal of Oracle Tuxedo IPC resources using an OS command such as ipcrm) should be used only as a last resort option. Oracle Tuxedo applications improperly shut down if using this method.Apache or Oracle Http Server processes exit because when used with mod_tuxedo become Oracle Tuxedo client programs. Platform: All Documentation for this product is available from the Oracle corporate Web site. From the Oracle home page at http://www.oracle.com.To access the .PDF files, open the Oracle SALT documentation home page, click the PDF files button and select the document you want to view or print. If you do not have the Adobe Acrobat Reader, you can get it for free from the Adobe Web site at http://www.adobe.com.
•
•
•
•
•