1 Interoperability, Compatibility, and System Support
This chapter lists products, standards, and technologies supported by Oracle Service Bus, including Oracle and third-party products, protocols, and web services standards.
This chapter includes information about Oracle Service Bus interoperability. It includes the following topics:
1.1 Supported System Configurations
For support information on vendor operating systems, JDK, hardware, and databases, see Oracle Fusion Middleware Supported System Configurations at http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
.
1.2 Interoperability and Compatibility with Oracle Products
The Understanding Interoperability and Compatibility guide helps you understand how Oracle components work together depending on the same or different versions. It also guides you through the support matrixes.
For more information, see Understanding Interoperability and Compatibility.
1.3 Supported Standards and Implementations
Oracle Service Bus supports these standards and implementations.
Table 1-1 Supported Standards and Implementations
Standard/Implementation | Version |
---|---|
Email Servers |
|
FTP Servers |
|
Web Services |
|
Security |
|
EJB |
|
SNMP |
|
WebLogic JMS |
WebLogic Server
|
Third-party JMS |
Any JMS provider that implements the JMS specification is supported through Oracle WebLogic Server as a foreign JMS provider. |
Microsoft .NET 1.1 with SOAP 1.1 |
Style-encoding: document-literal, rpc-encoded
Note: DIME attachments are not supported by Oracle Service Bus. See also .NET Interoperability Limitations. |
Microsoft .NET 2.0 with SOAP 1.1 and SOAP 1.2 |
2.0, 3.0, and 3.5 with SOAP 1.1 and SOAP 1.2 |
WebLogic JMS Client for Microsoft .Net (for .Net C# client applications) |
See How the WebLogic JMS .NET Client Works in Developing JMS .NET Client Applications for Oracle WebLogic Server. |
Oracle Service Bus interoperates with the platforms described in the following tables.
Table 1-2 Oracle WebLogic Family Platforms
Interoperability | Version |
---|---|
WS-* and JMS interoperability with WebLogic Platform |
|
Web Services for Remote Portlets (WSRP) with Oracle WebLogic Portal |
|
Oracle WebLogic Portal |
|
Table 1-3 Oracle Family Platforms
Interoperability | Version |
---|---|
Oracle Service Bus |
|
Oracle Service Registry |
11.1.1.6 |
Oracle Web Services Manager |
|
Oracle BPEL Process Manager |
|
Oracle JDeveloper |
|
Oracle JCA Adapters |
|
Oracle Data Service Integrator |
|
Oracle Tuxedo/WebLogic Tuxedo Connector |
|
Table 1-4 Third-Party Platforms
Interoperability | Version |
---|---|
IBM WebSphere MQ |
|
IBM WebSphere EJB/RMI |
6.0 |
IBM WebSphere WS |
6.1 (Fixpack 15) Supported with SOAP 1.1, not SOAP 1.2. See WebSphere Interoperability Limitations. |
JBoss Application Server |
|
Tibco Enterprise Message Service |
All versions that meet the JMS 1.2 specification through Oracle WebLogic Server |
Apache Axis |
Supported with SOAP 1.1, not SOAP 1.2. See Apache Axis Interoperability Limitations. |
1.4 Interoperability and Support Limitations
This section describes interoperability limitations with different platforms.
1.4.1 .NET Interoperability Limitations
-
.NET clients that need to communicate with Oracle Service Bus using basic authentication must send the authentication information in the first request. Otherwise, the invocation fails because Oracle Service Bus does not challenge the .NET client for credentials.
-
Oracle Service Bus interoperability with .NET using Basic Authentication works successfully when configured with Windows 2003/IIS 6.0; however, interoperability with .NET using Basic Authentication on Windows XP/IIS 5.1 is not supported.
-
Message-level security interoperability for .NET clients works only with SOAP 1.1. The WSE Soap Protocol Factory does not support security with SOAP 1.2. See "Message-Level Security with .Net 2.0" in Developing Services with Oracle Service Bus.
The following security configurations in the .NET 1.1 framework are not interoperable with the Oracle Service Bus message-level security:
-
Signing the message body from WebLogic to .NET WSE 2.0 (Webservices Security Extension) is interoperable. However, by default, WSE requires additional headers-for example,
WS-Addressing
andtimestamp
. Therefore, to make Oracle Service Bus message-level security for .NET web services interoperable, you must remove all of the message predicate other than the message body from .NET security policy configuration -
To ensure Oracle Service Bus interoperability with .NET, the replay detection attribute,
<replayDetection>
, must be set todisabled
on the .NET side.
1.4.2 Apache Axis Interoperability Limitations
This section describes issues that arise when working with Apache Axis, and also provides ways to address the issues.
1.4.2.1 Unresolved References When Importing RPC-Encoded Axis-Generated WSDL Documents
When you import an RPC encoded WSDL file, generated by Axis, into Oracle Service Bus, you may experience a warning message indicating that the WSDL file contains references that must be resolved.
To work around this issue, open the structural view of the imported WSDL file in the View a WSDL page in the Oracle Service Bus Administration Console to view unresolved schema imports. They appear in the Imports section.
Note that this issue does not affect your ability to use the WSDL file in the Oracle Service Bus environment. You can eliminate the warning by removing unresolved schemas from the WSDL file.
1.4.2.2 SOAPAction attribute in Axis-generated WSDL files initialized to empty string
The WSDL file generated by Axis have the SOAPAction attribute initialized to an empty string. Configuring an Oracle Service Bus business service with this WSDL file, causes invocations to this web service to fail generating a "No SOAPAction" fault.
To work around the issue and ensure successful web service invocations from Oracle Service Bus to Axis, configure a transport header in the pipeline. Add a Set Transport Headers request action in the message flow route and enable the Pass all headers through Pipeline option.
This issue also causes invocations from the Oracle Service Bus Test Console to fail (and generates a "No SOAPAction" fault) even when the workaround is in place. To make Test Console invocations work, set the SOAPAction HTTP
header in the Set Transport Header request action in the message flow route.
1.4.2.3 HTTP Response and Status Code for One-Way Operations
For both document literal and RPC encoded types of web services, on invocation of a one-way operation, Axis is expected to send an empty HTTP response with status code 202 OK to the client. However, Axis sends an non-empty HTTP response with status code 200 OK. The body of this HTTP response contains an empty SOAP envelope. This causes the Oracle Service Bus proxy or business service to send the same 200 OK response code to their clients violating the expected results.
1.4.2.4 HTTP Response and Status Code for One-Way Operations Generate a Fault
For both document literal and RPC encoded types of web services, on invocation of a one-way operation generating a fault, Axis is expected to send an empty HTTP response with status code 202 OK to the client. However, Axis sends a non-empty HTTP response with status code 500 Internal Server Error with an empty SOAP envelope as a body. This causes the Oracle Service Bus proxy or business service to send the same 500 Internal Server Error response to their clients violating the expected results.
1.4.3 WebSphere Interoperability Limitations
For both document literal and RPC encoded types of web services, on invocation of a one-way operation, WebSphere is expected to send an empty HTTP response with status code 202 OK to the client. However, WebSphere sends an non-empty HTTP response with status code 200 OK. The body of this HTTP response contains an empty SOAP envelope.
This causes the Oracle Service Bus proxy or business service to send the same 200 OK response code to their clients violating the expected results.