Introduction

Web services provide an emerging Service Oriented Architecture (SOA)-based architectural approach for partner integration that is growing in demand. Functional requirements often expose the need to provide direct integration of Web services as a solution framework for business-to-business (B2B) integration. As the development of B2B solutions continues to evolve, Web services will play an increasing role in providing B2B extensions for SOAs. In short, Web services provide key interoperability features and enable a standards-based framework for trading partner and business partner interactions.

The IBM Business Integration portfolio offers extensive support for Web services and the development and deployment of service oriented architectures. WebSphere Business Integration Connect provides Simple Object Access Protocol (SOAP) support as one of the transport solutions for business partner integration in addition to other transport formats, such as FTP, RosettaNet, AS1, AS2, and so forth. On the other hand, WebSphere Application Server (specifically WebSphere Application Server Network Deployment and WebSphere Business Integration Server Foundation V5.1) offer a robust and advanced solution for Web services support.

Both of these solutions provide different levels of services and are appropriate for differing functional requirements.

Back to top

SOAP support

In differentiating between WebSphere Application Server and WebSphere Business Integration Connect in terms of SOAP support, we will look at the following functional areas:

Table 1. Functional areas for evaluation

Back to top

Web services support in WebSphere Business Integration Connect

WebSphere Business Integration Connect provides the partner gateway component within the IBM Business Integration product portfolio. The product is built on an embedded WebSphere Application Server and has three main components:

• Console (J2EE Application): Provides administrative and document management utilities for the business community (both hub as well as partners).
• Target (Servlet and MBean): Provides inbound listener services for transport and document protocols from internal and external endpoints as well as transport-level security functions.
• Document Manager (MBean): Provides document management functions, such as state management, validation, transformation, document-level security services, and so forth.

For more information, please see WebSphere Business Integration Connect documentation.

WebSphere Business Integration Connect provides support for multiple transport and document protocols including FTP, HTTP/HTTPS, AS1, AS2, and others. Support for these protocols includes support for extended validation, protocol specific functions, protocol interactions, state management for business protocols such as AS1/AS2 and RosettaNet, and transport and document-level security features, as specified within the protocol standards. For SOAP integration, WebSphere Business Integration Connect Advanced Edition and WebSphere Business Integration Connect Enterprise Edition provide SOAP pass-through support. (WebSphere Business Integration Connect Express product does not currently provide any SOAP transport support.)

WebSphere Business Integration Connect provides bidirectional proxy support between the enterprise and business partners. WebSphere Business Integration Connect passes Web service requests to the Web service provider and returns the response synchronously from the provider to the requestor. This occurs for SOAP/HTTP requests originating internally to the enterprise or from external sources. Similar to the Web Services Gateway, WebSphere Business Integration Connect provides the ability to import and upload the "private" WSDL that defines the internal registered endpoint for the service. WebSphere Business Integration Connect, in turn, generates a "public" WSDL.

When a WSDL definition of a Web service is uploaded, the original WSDL is saved as a "Validation Map" and is referenced as the private WSDL. The public WSDL is saved with the private URL replaced with the target URL entered in the Document Flow Upload input via the Community Console. The public WSDL is then referenced by the users of the Web service. WebSphere Business Integration Connect routes the request to the original Web service provider's private URL. In this way, WebSphere Business Integration Connect acts as a proxy, forwarding the request to a private provider URL hidden from the actual service consumer.

To enable Web services within WebSphere Business Integration Connect, a WSDL file is imported (uploaded) through the Community Console during the WebSphere Business Integration Connect document definition process. For Web services defined completely within a single WSDL file, the WSDL file can be imported directly. On the other hand, the explicit import of WSDL files within a primary WSDL file normally requires all of the WSDL files to be uploaded in a ZIP archive. One exception to this rule occurs when the URLs in each element's location attribute is reachable from the Community Console's server. In this case, the primary WSDL may be uploaded directly and the imported files will be uploaded automatically during validation.

Administrators can also enter the equivalent Document Flow Definitions manually through the console, as described in the WebSphere Business Integration Connect documentation. In terms of the Document Flow Definition hierarchy, a Web service is represented as:

• Package: None (Name and Code) with Version set to N/A
• Protocol: Web Service (Name and Code), Version 1.0
• Document Flow: {<web service namespace>}:<web service name> (Name and Code). Requirement: This value is required to be unique among document flows for Web Service protocol.
• Activities: One activity for each Web service operation
• Actions: One action for the input message of each operation, with Name and Code: {<namespace of identifying xml element = first child of soap:body>}:<name of identifying xml element = first child of soap:body>

WebSphere Business Integration Connect uses the Action's namespace and name to recognize an incoming Web service request SOAP message and route it appropriately based on a defined Participant Connection.

Once the Document Flow Definition is established, the administrator can set up a valid interaction for the Web service. The administrator sets the Document Flow Action as both the Source and the Target. As a result, the same Web Service Interface can be used by multiple partners. WebSphere Business Integration Connect makes the Web service available to the Community Manager at the Web service URL that is specified in the console when uploading the Web service. (Pass Through is the only valid option supported in WebSphere Business Integration Connect for a Web service interaction.)

The last steps in enabling partners to utilize SOAP support is to define the source and target participants' B2B capabilities and to set up the participant connection between the source and target participants. This step follows the basic procedure discussed in the WebSphere Business Integration Connect Administrators Guide. Once the B2B capabilities have been enabled for the source and target participants, the document flow will appear as an available choice for connections between the two selected participants. Connections can be created, activated, and deactivated as needed.

At run time, WebSphere Business Integration Connect receives a SOAP message from the participant and determines the appropriate Web service endpoint and invokes the Web service using the same SOAP message. The response returned by the Community Manager is then returned to the participant along with the HTTP 200 message in the same HTTP connection. Error processing can include general security related issues as well as SOAP transport-related issues; for example, Web Service Connection Parse Failed. This error is generated when the system is unable to find connection information for a SOAP message.

Run time authentication for Web services can be via either SSL or basic authentication (userid/password). WebSphere Business Integration Connect does not currently provide WS-Security integration. Additionally, SOAP operations can be restricted to specific partners through the assignment of specific B2B capabilities on a partner-by-partner basis using the administrative facilities within the Community Console as discussed above.

WebSphere Business Integration Connect does provide SOAP transport proxy support through pass-through mediation. As a result, there is no translation and introspection of the SOAP Body during processing. Although validation is not done on incoming SOAP invocations during run time, uploaded WSDL files are validated against specific standard reference schemas (for example, wsdl.xsd, wsdlhttp.xsd, and wsdlsoap.xsd) that contain the schemas describing valid WSDL files. The files are located in the packagingSchemas directory in the WebSphere Business Integration Connect installation directory.

WebSphere Business Integration Connect provides support for SOAP V1.1 and WSDL V1.1 based on WS-I Basic Profile 1.0, and supports RPC-encoded/RPC-literal and Document-literal binding styles. SOAP processing through WebSphere Business Integration Connect has been tested with Interchange Server and should work directly with other WebSphere Business Integration products as discussed earlier.

In terms of the criteria discussed earlier for deployment of Web Services integration, see Table 2 below.

Table 2. Support provided by WebSphere Business Integration Connect

Extended functions, when compared to the traditional WebSphere Application Server solution architecture, include:

• business partner management.
• Non-repudiation via authentication and audit.
• Audit for management, tracking, and reporting.

Current limitations of the WebSphere Business Integration Connect SOAP support include:

• No direct support for SOAP with Attachments (SWA).
• Transport is limited to HTTP and HTTPS (No transport rebinding to JMS).
• No current support for WS-Security extensions.
• No parsing or validation of SOAP Body (pass through action only).

Back to top

Web services support in Web Services Gateway

The Web Services Gateway is part of WebSphere Application Server Network Deployment (ND) (as well as WebSphere Business Integration Server Foundation). The 5.0.2 release of the WebSphere technology platform provides a comprehensive J2EE and Web services technology-based application server solution, continuing IBM' commitment to deliver product improvements at a competitive price/performance ratio.

Web Services Gateway (in conjunction with WebSphere Application Server) provides extensive support for Web services, including Web services Caching, UDDI4J version 2.0 client support, JSR 101 (JAX-RPC) 1.0, SAAJ 1.1 (SOAP with attachments API for Java), JSR 109 1.0 support, WS-I Basic Profile 1.0, WS-Security integration, SOAP/JMS rebinding support, and JMX Web services monitoring support.

WebSphere Application Server ND includes additional support for JAX-RPC handlers and a complete private UDDI registry. Web Services Gateway support for mediation is directly related to the integrated support for JAX RPC to intercept a SOAP message and implement custom handlers to mediate the SOAP requests.

Web Services Gateway provides multiple Web services bindings for service requests and service responses, including SOAP (both over HTTP and JMS), EJB (i.e. RMI over IIOP), JCA, native JMS and Java. The most common bindings are SOAP/HTTP and SOAP/JMS. SOAP/JMS supports one-way and request/response SOAP Web service invocations over JMS. This function enables higher end-to-end reliability via the availability provided by JMS and WebSphere MQ.

The Web Services Gateway provides for the management and configuration of services and support for multiple channels (SOAP/HTTP, SOAP/JMS etc). Channels are provided to service new requests from requestors. Bindings, on the other hand, enable Web Services Gateway to call Service Providers and receive responses from the provider, which it then returns using the channel to the requestor. With the 5.1 release, the enhancements to the Web Services Gateway include support for SOAP/HTTP, SOAP/JMS channels, and enhanced performance through selective parsing. Web Services Gateway supports discovery through WSDL and UDDI, and publication through WSDL, WSIL and UDDI. From a security standpoint, Web Services Gateway offers basic userid/password and SSL transport-level security, as well as more granular security by service and/or operation.

The Web Services Gateway provides a highly flexible architecture, as shown in the Figure 1. More importantly, it can be directly extended with filters and data handlers to enable custom service behaviors.

One important differentiator of the Web Services Gateway solution architecture for Web services is performance. The support for selective parsing enables the selective parsing of the header of a SOAP message; the body is left unparsed. This function requires that the JAX-RPC handlers in Web Services Gateway only use fields in the header and not directly access the SOAP body. This results in significant performance gains. In addition to continuing to optimize the WebSphere Application Server code for performance, the Web Services Gateway tooling provides performance monitoring for Web services as well as a JMX-based bean, which can be used directly with the Tivoli Performance Viewer.

The WebSphere Application Server ND solution architecture offers strong support for UDDI and full support for UDDI4J v2.0 in WebSphere Application Server V5.1. A private UDDI Registry is shipped as part of WebSphere Application Server ND and supports UDDI version 2.0 with persistence enabled via JDBC to both DB2 and Cloudscape®. WebSphere Application Server 5.1 is also provides a number of new UDDI Utility Tools to assist in the administration of UDDI (including search, copy, delete, paste, persist functions for registry entities).

Both WebSphere Business Integration Connect and Web Services Gateway support the storing of service definitions and updating the actual endpoints across UDDI instances on the Internet and on an intranet. Using this functionality, the UDDI in an intranet has the 'real' Web services provider endpoint, and the service definition is then published to a UDDI instance on the Internet, where the service endpoint is correlated to the Web Services Gateway service entry.

From a development and build-time standpoint, the new tooling enabled for Web services development within WebSphere Studio V5.1 is impressive. In addition to basic support for JDK 1.4 (5.1.1), the new WebSphere Studio tooling provides numerous Web services wizards to support document literal and RPC SOAP-encoded services. The tooling additionally provides support for SOAP over JMS for EJB-based Web services and integration of WS-Security options. In addition, there is a new WSDL Editor and Validator providing a panel based component for viewing and administering WSDL ports, binding, messages, and services, as well as WS-I conformance tools.

In terms of the criteria discussed earlier for deployment of Web services integration, here is how the WebSphere Application Server ND with Web Services Gateway solution stacks up:

Table 3. Support provided by the WebSphere Application Server Network Deployment with Web Services Gateway

Overall, the Web Services Gateway solution provides a framework for invoking Web services between both Internet and intranet environments with the additional benefit of WS-Security protection. The Web Services Gateway solution architecture provides support for the ability to "externalize" Web services as part of a services-oriented approach to application development and business integration.

Back to top

Using the right tool for the right job

In looking at the relative strengths of the WebSphere Business Integration Connect and WebSphere Application Server ND (Web Services Gateway) approaches, it is clear that the two products excel in two different areas. Essentially, the decision to use one over the other can be analyzed based on the responses to a number of questions:

Table 4. Which is the optimal solution

WebSphere Business Integration Connect enables the implementation of Web services solutions via basic SOAP pass-through support. Normally, this SOAP integration solution would be developed as part of a broader B2B initiative with additional requirements for:

• Comprehensive partner management.
• Transport and document security (HTTPS and Basic Authentication).
• Out-of-the-box tracking and visibility into transaction detail and audit trails.
• Support for non-Web services transport and document protocols including electronic data interchange (EDI).

As an example, one of IBM's transportation and logistics customers currently uses WebSphere Data Interchange for EDI transformation and routing. The customer is extending their integration architecture to include AS1/AS2 as well as additional EAI components in the WebSphere Business Integration product portfolio. Additionally, the customer is interested in supporting the ability to provide SOAP/HTTP integration with external agencies for information exchange. The performance requirements for the proposed integration architecture are in alignment with the WebSphere Business Integration Connect performance profile, and the additional transport requirements suggest the need for WebSphere Business Integration Connect. As a result, WebSphere Business Integration Connect was proposed as the B2B solution architecture.

On the other hand, the use of the Web Services Gateway (via the WebSphere Application Server ND) is normally found in organizations with a focus on application development. Additionally, other factors would suggest this approach given support for additional requirements including:

• Support for Web services standards including WS-Security standards.
• Direct support for message mediation and transport rebinding.

During an engagement last year, a large content provider asked IBM to propose a B2B solution architecture for a new project to offer premium services for their base of over 15 million subscribers. The services were already enabled via a WebSphere Application Server J2EE environment and the customer was interested in SOAP/HTTP transport solution exclusively. In this case, the high interactive performance requirements and the lack of requirements to support other transport protocols resulted in the recommendation to use Web Services Gateway as the underlying Web services solution.

Hybrid solutions

In many cases, both solutions can be used in unison. WebSphere Application Server ND can be used to support high volume, interactive ("anonymous") Web services requests and WebSphere Business Integration Connect can be used to handle B2B interactions requiring other transport protocols or out-of-the-box visibility and management.

As an example of this hybrid solution requirement, a large manufacturer is moving towards deployment of a Web services-based architecture for both Internet and intranet integration. Additionally, the customer has requirements to support legacy B2B integration requirements (EDI as well as FTP). As a result, the need to support emerging standards (such as WS-Security) as well as the requirement to support traditional integration resulted in the recommendation of a hybrid solution as shown below:

Additionally, the release of WebSphere Business Integration Connect (Version 4.2.2) can be used to enable the following solution.

Back to top

Conclusion

The decision to use Web Services Gateway (via WebSphere Application Server ND) or WebSphere Business Integration Connect to support Web services B2B interactions should be evaluated based on several factors:

• WebSphere Business Integration Connect provides comprehensive out-of-the-box capabilities for partner management and document tracking.
• WebSphere Business Integration Connect provides support for traditional B2B transports and document formats, and extended built-in support including validation, state management, and security extensions.
• Web Services Gateway provides direct support for Web services standards including support for WS-Security.
• Web Services Gateway enables higher performance and provides additional extensions for increased performance where required.
• Web Services Gateway provides mediation support for Web services via JAX-RPC handlers. WebSphere Business Integration Connect can be augmented with WebSphere Business Integration Server solutions to provide extended mediation services.
• Both products provide a high level of integration with WebSphere Business Integration Server.

Most B2B requirements will strongly suggest one of these two alternatives to be optimal for the requirements, as well as the skill profile of the necessary IT staff. In some cases, WebSphere Business Integration Connect and WebSphere Application Server can provide a hybrid solution architecture to satisfy overall requirements.

Back to top

Acknowledgements

This paper would not have been possible without the assistance and ongoing support from Rachel Reinitz in the area of Web services. Additionally, I extend my thanks to Raja Das for the diagram showing the WebSphere Business Integration Connect 4.2.2 architecture solution.

Reference material sources for this article includes white papers by Kyle Brown, and presentations by Rob High and Eric Herness. Finally, thanks to all of my reviewers their assistance.

Resources

• Web Services Architecture and Design Best Practices, Kyle Brown and Rachel Reinitz, WebSphere Technical Developers Journal October, 2003
  
  
• Redbook: Web Services Wizardry with WebSphere Studio Application Developer (SG246292)
  
  
• Redbook: WebSphere Version 5 Web Services Handbook SG24-6891-00
  
  
• Redbook: Using Web Services for Business Integration SG246583
  
  
• WebSphere Business Integration Connect documentation
  
  
• developerWorks Web services zone
  
  
• alphaWorks
  
  
• Emerging Technologies Toolkit (ETTK)
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• SOAP support
• Web services support in WebSphere Business Integration Connect
• Web services support in Web Services Gateway
• Using the right tool for the right job
• Conclusion
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server Network Deployment
• Demo: WebSphere Application Server demos
• Buy: WebSphere Application Server Network Deployment

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers