Connector processing

The connector includes a protocol listener framework for event processing and a protocol handler framework for request processing. This bi-directional functionality enables the connector framework to:

For further information on the SOAP data handler, see SOAP data handler.

Note:
The connector supports SOAP/HTTP and SOAP/JMS bindings only.

Event processing overview

Connector event processing (or event notification) is used to handle requests from web service clients. This event processing capability encompasses a protocol listener framework, including the following components, which are discussed in greater detail later in this chapter:

The connector uses the listeners to expose collaborations as web services, and to listen on the transport for calls from web services clients to exposed collaborations.

The SOAP/HTTP and SOAP/HTTPS protocol listeners expose a collaboration as a SOAP/HTTP web service. The SOAP/JMS protocol listener exposes a collaboration as a SOAP/JMS web service.

When requests from web service clients arrive, the listener converts the SOAP request message into a business object and invokes the collaboration. If it is a synchronous request, the connector receives a Response business object of the same type as the Request business object. The listener converts the Response business object into a SOAP response message. The listener then transports the SOAP response message to the web service client. Note that event sequencing is not a requirement for this connector; the connector may deliver the events in any order.

The web services connector utilizes the SOAP data handler to convert incoming SOAP request messages into business objects. To aid the data handler in determining which business object to resolve for the incoming SOAP request message, the connector provides meta information regarding its supported business objects to the data handler. From its supported business objects, the connector first makes a list of all business objects that are potential candidates for the conversion. This list may be comprised of both TLOs and non-TLOs. Supported TLO business objects are those that have object-level ASI ws_eventtlo=true.

If TLOs are used, the protocol listener reads the object-level ASI of the TLO as follows:

If non-TLOs, are used, then the protocol listener reads the collaboration and processing mode from the WSCollaborations configuration property values generated by the WSDL Configuration Wizard.

The connector compares and attempts to match the BodyName and BodyNamespace in the SOAP request to the names of potential business objects. In the case of TLOs, this BodyName/BodyNamespace pair is found using the SOAP Config MO properties of the SOAP Request business object. For non-TLOs, the BodyName/BodyNamespace pair is found using the WSCollaborations connector configuration property. (Note that the connector considers only those non-TLOs that have an entry in the WSCollaborations property.) The data handler uses the BodyName/BodyNamespace pair to determine the business object to use for the SOAP request to business object conversion.

The connector inspects the Request business object returned by the SOAP data handler. If this business object has ws_tloname ASI, the connector sets the Request business object in this TLO. This TLO is used to invoke the collaboration. However, if this ASI is not set, the connector invokes the collaboration using the Request business object returned by the SOAP data handler.

For synchronous collaboration execution, the connector utilizes the SOAP data handler to create a SOAP response or fault message to send back to the client. In this case, the connector simply passes either a SOAP business object (child of TLO), or a non-TLO to the data handler. The SOAP data handler returns a SOAP message based on the business object that it is passed to it.

Request processing overview

On behalf of a collaboration, the connector can invoke web services over SOAP/HTTP(S) and SOAP/JMS. This request processing functionality is supported by a WSDL Object Discovery Agent (ODA) and by a protocol handler framework. The WSDL ODA is a design-time tool you use to generate SOAP business objects that include information about the target web services. For further information, see Enabling collaborations for request processing. The protocol handler framework is a configurable run-time module that consists of the following components, which are discussed in detail later in this chapter:

Upon receipt of a collaboration Request business object, which is always (via the WSDL ODA) set in a TLO, the protocol handler framework loads the appropriate protocol handler. The protocol handlers manage transport-level details required for invoking the web service and (optionally) securing a response, performing three main tasks: converting a collaboration Request business object into a SOAP request message, invoking the endpoint web service with the request message, and, if in Request/Response (synchronous) mode, converting the SOAP response message into a business object and returning that object to the collaboration. The connector uses the SOAP/HTTP-HTTPS protocol handler to invoke SOAP/HTTP(S) web services, and the SOAP/JMS protocol handler to invoke SOAP/JMS web services.

The web services connector is always called from a collaboration using TLOs. The connector determines the SOAP Request business object from the TLO, and invokes the SOAP data handler with this business object. The data handler returns a request message which is sent on by the connector to the web service.

For synchronous web service execution, the connector utilizes the SOAP data handler to convert SOAP response and fault messages into SOAP Response and Fault business objects. To aid the data handler in determining which business object to resolve for these SOAP response/faults to business object conversions, the connector provides the data handler with specific meta information. Specifically, the connector makes a list of all Response and Fault business objects that are children of the invoking TLO. There should be only one response business object and, optionally, many Fault business objects. There may also be one and only one defaultfault business object. The connector attempts to match, and then map, the SOAP BodyName and BodyNamespace to a business object name that appears in the list of all Response business objects. In the case of SOAP Response business objects, this pair is found using the SOAP Config MO properties of the SOAP Response business object. In the case of SOAP Fault business objects, this pair is found using the elem_name and elem_ns attribute-level ASI properties for the first child of the detail element. For the defaultfault business object, the connector simply notifies the data handler of the name of the defaultfault business object. The defaultfault business object should be resolved by the data handler as a last resort if no other fault business objects are resolved for this transformation.

Copyright IBM Corp. 2003