Event processing

During event processing, the connector uses protocol listeners and the configured data handler(s) to convert request messages from HTTP service clients to business objects that can be manipulated by collaborations. Protocol listeners play a crucial role in event processing.

Protocol listeners

HTTP requests may come over HTTP or HTTPS transports. The listener monitors the arrival of such requests on its transport channel. There are two protocol listeners and corresponding channels:

Each of these consists of a thread that listens on its transport. When it receives a request message from a client, the listener registers the event with the protocol listener framework.

The protocol listener framework manages the protocol listeners, scheduling requests as resources are available. You configure the listeners and aspects of the protocol listener framework when you set values to connector-specific properties. Among the protocol listener framework properties you can configure are the following:

These two connector-specific properties control memory allocation in a way that prevents protocol listeners from clogging the connector with infinite events. The allocation algorithm is as follows: At any time, the connector can receive a total number of events equal to WorkerThreadCount + RequestPoolSize. It can process WorkerThreadCount number of requests in parallel.

You can plug additional protocol listeners into the protocol listener framework. For further information, see Creating multiple protocol listeners andConnector-specific configuration properties.

HTTP and HTTPS protocol listener processing

The HTTP(S) protocol listener consists of a thread that continuously listens for HTTP(S) requests from clients. The listener thread binds the host and port that are specified in the Host and Port connector-specific configuration (listener) properties. Another configuration property--RequestWaitTimeout--defines the interval during which the listener waits for a request before checking whether the connector has shut down.

Figure 14 illustrates HTTP protocol listener processing for a synchronous operation.

Figure 14. HTTP protocol listener: synchronous event processing

Figure 15 shows HTTP protocol listener processing for an asynchronous operation.

Figure 15. HTTP protocol listener: asynchronous event processing

When a client initiates a HTTP or HTTPS request, it posts a request message to the HTTP or HTTPS listener. The client should use the HTTP POST method to invoke the protocol listener URL.

When an HTTP(S) request arrives, the listener registers the request with the protocol listener framework, which schedules the event for processing as resources become available. The listener then extracts the protocol headers and the payload from the request.

Table 25 summarizes the order of precedence of rules used by the listener to determine the Charset, MmeType, ContentType and Content-Type header for inbound messages.

Table 25. HTTP(s) protocol listener processing rules for inbound message

Order of Precedence Charset MimeType ContentType Content-Type header
1 Charset parameter value from the incoming HTTP message Content-Type header value URLsConfiguration connector property value for this listener Incoming HTTP message type/subtype value from the Content-Type header value Incoming HTTP message Content-Type header
2 URLsConfiguration property value for this listener


3 If the type of the request message ContentType is text with any subtype (for example, text/xml, text/plain, etc.), default to ISO-8859-1. Otherwise, charset will not be used. Default to ContentType

As shown Table 25:

If the collaboration is invoked asynchronously, the listener delivers the request business object to the integration broker and responds to the client with the HTTP status code 202 Accepted. This concludes listener processing.

If it is a synchronous invocation, the listener invokes the collaboration synchronously. The collaboration responds with a response business object.

Table 26 summarizes the order of precedence for rules used by the listener when determining the Charset, MimeType, ContentType, and Content-Type header for response messages.

Table 26. HTTP(s) protocol listener processing rules for outbound synchronous response message

Order of Precedence Charset MimeType ContentType Content-Type header
1 Protocol ConfigMO Content-Type Header MimeType property in the TLO Protocol ConfigMO Content-Type header Protocol ConfigMO Content-Type header
2 The Charset property value in the TLO The request message MimeType, but only if the request and response ContentType match. Request message ContentType Construct Content-Type Header using ContentType and Charset
3 The request message Charset, but only if the request and response ContentType match. Use ContentType value as the MimeType

4 If the ContentType is text/*, default to ISO-8859-1. Otherwise, charset will not be used.


As shown in Table 26,

The listener processes the HTTP Protocol Config MO. It is the responsibility of collaboration to ensure that the header values passed in the HTTP Protocol Config MO are correct in the context of the request-response event. The listener populates standard headers and custom properties according to the following rules:

  1. The listener will investigate each item of the HTTP Protocol Config MO in order to ignore special attributes (such as ObjectEventId).
  2. Each non-empty header will be put on the outgoing message and additional processing (for example, the Content-Type header) may take place.
  3. Please note that with the above approach, the listener may set non-standard headers on the message, but will not check that the message is logically or semantically correct.
  4. If there are one or more custom properties in the HTTP Protocol Config MO UserDefinedProperties attribute, the listener will add them in the Entity Headers Section (the last headers section). For more on custom properties, see User-defined properties for event processing.
Note:
Specifying any of the following headers in the HTTP Protocol Config MO is very likely to result in an incorrect HTTP message: Connection, Trailer, Transfer-Encoding, Content-Encoding, Content-Length, Content-MD5, Content-Range.

The listener then invokes the data handler to convert the response business object returned by the collaboration into a response message.

The listener delivers the response message to the client and includes a 200 OK HTTP status code. If the collaboration returns a fault business object, it is converted to a fault message. This fault message is delivered to the client with a 500 Internal Server Error HTTP code.

The listener then closes the connection and the thread that processed the event becomes available.

Unsupported HTTP protocol listener processing features

The HTTP protocol listener does not support the following:

HTTPS listener processing using secure sockets

HTTPS protocol listener processing is the same as that described in the HTTP protocol listener processing section except that HTTPS uses secure sockets. For further information, see SSL.

Event persistence and delivery

Event persistence is protocol contingent:

Event sequencing

The connector may deliver events in any sequence.

Event triggering

The event triggering mechanism depends on how the protocol listener is configured.

Note:
The connector does not distinguish between Create or Update or Retrieve or Delete. All such events follow the same approach.

Event detection

Event detection is performed by each protocol listener. The event detection mechanism depends utterly on the transport and how you configure the connector-specific properties for each listener. For more on these properties, see Connector-specific configuration properties.

Event status

Event status is managed by the protocol listener and depends on the transport and also on how you configure the listener.

Event retrieval

Event retrieval is managed by the protocol listener and depends on the transport and also on how you configure the listener.

Event archiving

Event archiving is managed by the protocol listener and depends on the transport and also on how you configure the listener.

Event recovery

Event recovery is managed by the protocol listener and depends on the transport and also on how you configure the listener.

Copyright IBM Corp. 1997, 2003