Adapter for Web Services environment

Before installing, configuring, and using the adapter, you must understand its environmental requirements:

Broker compatibility

This adapter runs with the WebSphere Business Integration Adapter Framework, version 2.6, which supports only the following versions of WebSphere InterChange Server:

See the Release Notes for any exceptions.

Software prerequisites

Review the following assumptions and software requirements before you install the connector for web services:

Adapter platforms

In addition to a broker, the adapter requires one of the following operating systems :

Note:
The Tivoli Monitoring for Transaction Performance (TMTP) component of the WebSphere Business Integration Adapter Framework V2.6 is not supported on Red Hat Linux.

Standards and APIs

The Adapter for Web Services (the connector, the WSDL ODA, and the SOAP data handler) is in compliance with the WS-I Basic Profile 1.0 specifications released in August 2003.

A variety of standards and technologies give web services access to their functionality over a network.

The standards used by the adapter are as follows:

The APIs used by the adapter are as follows:

Depending on your configuration, you may need to install additional software. The sections below discuss these contingencies.

JMS protocol

If you are using JMS protocol, you must install a JMS provider and create queues. The queue creation really depends on your requirements. You may use JMS Protocol for both exposing a collaboration as a web service and also for invoking external web services. For further information, see Connector and JMS.

JNDI

You must configure the JNDI and then enter appropriate parameters in the JNDI configuration properties for the connector. You also must ensure that the Connection factory and JMS destination (queue) object are made available in the JNDI. If you want to use JNDI and do not have JNDI implementation, you can download the reference implementation of File System JNDI from Sun Microsystems. For further information, see Connector and JMS.

SSL

If you plan to use SSL, you must use third-party software for managing your keystores, certificates, and key generation. No tooling is provided to set up keystores, certificates, or for key generation. You may choose to use keytool (shipped with IBM JRE) to create self-signed certificates and to manage keystores. For further information, see SSL.

Common Event Infrastructure

This adapter is compatible with Common Event Infrastructure from IBM, a standard for event management that permits interoperability with other IBM WebSphere event-producing applications. If Common Event Infrastructure support is enabled, events produced by the adapter can be received (or used) by another Common Event Infrastructure-compatible application.

For more information, see the Application Response Management appendix in this guide.

Application Response Measurement

This adapter is compatible with the Application Response Measurement (ARM) application programming interface (API), an API that enables applications to be managed for availability, service level agreements, and capacity planning. An ARM-instrumented application can participate in IBM Tivoli(R) Monitoring for Transaction Performance, enabling collection and review of data concerning transaction metrics.

For more information, see the Application Response Measurement appendix in this guide.

Locale-dependent data

The connector has been globalized so that it can support double-byte character sets . When the connector transfers data from a location that uses one character code to a location that uses a different code set, it performs character conversion to preserves the meaning of the data.

This adapter supports the processing of bidirectional script data for languages such as Arabic, Hebrew, Urdu, Farsi and Yiddish. To use the bidirectional capacity, you must configure the bidirectional standard properties. For more information, refer to the standard configuration properties for connectors in Appendix A.

The Java runtime environment within the Java Virtual Machine (JVM) represents data in the Unicode character code set. Unicode contains encodings for characters in most known character code sets (both single-byte and multibyte). Most components in the WebSphere business integration system are written in Java. Therefore, when data is transferred between most integration components, there is no need for character conversion.

Note:
The connector has not been internationalized. This means that the trace and log messages are not translated.

Web services connector

This section discusses localization and the connector.

Event notification

The connector uses pluggable protocol listeners for event notification. The protocol listeners extract the SOAP message from the transport and invoke the SOAP data handler. This section describes how each of the listeners encode SOAP messages over the transport:

Request processing

The connector uses pluggable protocol handlers for request processing. The protocol handlers invoke the SOAP data handler. This section describes how each of the handlers encodes SOAP message over the transport:

SOAP data handler

This section discusses localization and the SOAP data handler.

SOAP character limitations

XML element names and attributes names must be legal ascii characters that are allowed by either business object names, business object attribute names or business object application-specific information.

Internationalized characters are not supported in business object names or business object attribute names. Only attribute values can be internationalized.

SOAP data handler processing

When transforming a SOAP message into a business object, the data handler can receive a string only. The data handler simply populates the business object with string values and returns the business object. Java strings are UCS2, and therefore double-byte enabled characters are transferred without problem. Only XML element and attribute values can be non-ascii characters (see character limitations). When transforming a business object to a SOAP message, the data handler uses the XML4J parser to convert a business object to a string. Java strings are UCS2, so double-byte enabled characters are transferred without problem. Only XML element and attribute values can be non-ascii characters (see character limitations).

WSDL ODA

This section discusses localization and the WSDL ODA.

In the WSDL file, the WSDL ODA supports file names and URLs in any character set. The WSDL file content must be in legal ASCII only, due to the restriction of non-ASCII character sets in business object names and attributes.

Properties in the Configuring Agent table of the WSDL ODA are globalized as follows:

Copyright IBM Corp. 1997, 2004