|
|
ALSB is an Enterprise-class Service Bus designed for connecting, mediating and managing interactions between heterogeneous services. ALSB helps accelerate service configuration, integration and deployment, and simplifies management of shared services across the SOA.
AquaLogic Service Bus supports broad compliance with messaging standards including SOAP 1.1 and 1.2, HTTP, JMS, SMTP/POP/IMAP, FTP, SSL, XML 1.0, XML Schema, WSDL 1.1, WSRP 1.0, and WS-Security.
This section includes information about ALSB interoperability. It includes the following topics:
For support information on vendor operating systems, JDK, hardware, and database suport, see Supported Configurations for BEA ALSB 3.0.
ALSB supports the following standards and implementations.
|
|
ALSB supports a WebLogic Server-proprietary format that is based on the assertions described in the December 18, 2002 version of the Web Services Security Policy Language (WS-SecurityPolicy) specification. For information about supported Web Services Security Policy Assertions and Reliable Messaging Assertions, see the AquaLogic Service Bus Security Guide. |
|
BEA complies with the
Basic Security Profile Version 1.0 specifications from the Web Services Interoperability Organization a (WS-I) and considers it to be the baseline for Web Services interoperability.
However, in some cases, AquaLogic Service Bus does not reject SOAP/HTTP messages that are not WS-I compliant. This enables you to build implementations with service endpoints which are not strictly WS-I compliant.
When you configure a proxy service or business service, you can use the ALSB Console to specify whether you want ALSB to enforce WS-I compliance for the service. When you configure WS-I compliance for a proxy service, WS-I compliance checks are performed when the proxy service receives a message as a response from an invoked service with a Service Callout, a route node, or on a proxy service.
For information about the types of messages to which the compliance checks are applied and the nature of those checks, see “WS-I Compliance” in
Modeling Message Flow in AquaLogic Service Bus in the AquaLogic Service Bus User Guide.
|
|
|
To learn more, see
XQuery Implementation in the AquaLogic Service Bus User Guide.
|
|
The following security configurations in the .NET 1.1 framework are not interoperable with the ALSB message-level security:
|
|
| Note: | See the AquaLogic Service Bus Release Notes for the latest information about patches or updates that may be required to support your interoperability scenarios. |
ALSB interoperates with the platforms described in the following table.
For information about ALSB and JMS interoperability, see AquaLogic Service Bus Interoperability Solutions for JMS.
|
||
For information about ALSB and WSRP interoperability, see AquaLogic Service Bus Interoperability Solutions for WSRP.
|
||
To learn about importing and exporting business services from and to UDDI Registries in general, and AquaLogic Service Registry in particular, see UDDI in the AquaLogic Service Bus User Guide.
|
||
AquaLogic Enterprise Security can be used to manage access control to the ALSB runtime resources, using the ALES WebLogic Server 9.x Security Service Module. For more information, see
Integrating ALES with Application Environments.
|
||
For information about ALSB and BEA Tuxedo interoperability, see AquaLogic Service Bus Interoperability Solution for Tuxedo.
|
||
|
See AquaLogic Service Bus Interoperability Solutions for WebSphere MQ. |
||
When you import an RPC encoded WSDL, generated by Axis, into ALSB, you may experience a warning message indicating that the WSDL contains references that must be resolved.
If you open the structural view of the imported WSDL in the View a WSDL page in the ALSB Console, unresolved schema imports are displayed in the Imports section.
Note that this issue does not affect your ability to use the WSDL in the ALSB environment. You can eliminate the warning by removing unresolved schemas from the WSDL file.
The WSDL generated by Axis have the SOAPAction attribute initialized to an empty string. Configuring an ALSB business service with this WSDL, causes invocations to this web service to fail generating a “No SOAPAction” fault.
To workaround the issue and ensure successful web service invocations from ALSB to Axis, you must configure a transport header in the proxy service message flow Specifically, you must 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 ALSB test console to fail (and generates a “No SOAPAction” fault) even when the workaround is in place. To make test console invocations work, you must set the SOAPAction HTTP header in the Set Transport Header request action in the message flow route.
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 ALSB proxy or business service to send the same 200 OK response code to their clients violating the expected results.
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 ALSB proxy or business service to send the same 500 Internal Server Error response to their clients violating the expected results.
|