Understanding iWay Channels

Topics: Developing for Your Requirements

iWay Service Manager (iSM) is designed to host channels and their constituent components. In the simplest case, a channel enables a message to be received from one adapter and emitted via another adapter. In general, a message arriving at the server has three main parts as shown below. The diagram shows the stack organized with the more physical layers at the bottom and more abstract, “business-oriented” layers at the top.

Payload. Regardless of the transport protocol on which the message arrives, the payload is the data representing the content of the message. This payload may be in native (flat), XML, or JSON format. Examples of such messages are EDI, SOAP, or an API request. The channel can be configured to parse the incoming payload into an internal format, to leave the incoming payload in its current format (no parsing) or to use supplied or redeveloped preparsers to convert a unique payload format into an internal format.

Message headers. Headers contain contextual information about the payload or protocol interactions, such as encoding information, content type, and so on. In a HTTP transport, these are the HTTP headers. In a MQ transport, these are part of the Message Queuing Message Descriptor (MQMD). Regardless of the transport, the headers are made available to the application in a common manner.

Transport. This is the transmission method by which the message reaches (or is emitted by) iSM. iSM supports a wide variety of transport protocols, such as HTTP(S), many queuing mechanisms (MQ, JMS, Rabbit, etc.), FTP, files, and so on.

An iWay adapter handles all three layers of the message. iSM makes it easy to configure each of these independently. The following diagram shows how these layers map onto functions in iSM.

Conceptually, the inbound message moves up the stack from its physical protocol to where its logic and semantics are handled, and then back down the stack to be emitted. This may occur using a single type of protocol adapter or with the inbound and outbound sides using different protocols.

The transport is handled by a listener (for incoming messages where iSM is acting as a server) and an emitter (for outgoing messages where iSM is acting as a client). Note that iSM frequently behaves as a client and a server within a given installation. In almost all cases, the transport components supplied with iSM will be sufficient to construct your channels since the product’s support of industry standard protocols is complete.

The headers are handled by dispatching and routing. This is the middleware level where much of the added value of iSM resides and where the iWay preparser exits are executed (see Preparsers in Developing for Your Requirements. Although a complete set of exits is provided with iWay, you may be required to create a new exit for security or for formatting a message into XML.

Although a non-XML message can be routed through the system and acted upon by specific exits, iSM operates most effectively with XML documents. If your incoming message is not in XML and if one of the standard preparsers provided by iWay does not suit your requirements, you may want to write a preparser exit. For more information, see the iWay Service Manager Programmer’s Guide.

Finally, the message is handled by the application level. This is where iWay business agents are executed, and the level where integration applications are written. Although many business agents are provided with the product, you may write a custom business agent for specific programming requirements. For more information on the business agents that are supplied with iSM, see the iWay Service Manager Component and Functional Language Reference Guide.

In most cases, you need only assemble the business agents already provided into a process flow using iWay Integration Tools (iIT) Designer. For more information, see the iWay Integration Tools Designer User's Guide. Mapping one message type to another can be accomplished in the XML domain using iIT Transformer. Transformations are created graphically using this tool, and then published to iSM for run-time use. For more information, see the iWay Integration Tools Transformer User's Guide.

The following diagram illustrates the flow of the message or document through a simplified, single-directional channel.

The phases of working with the message or document can be further subdivided. Various exits are provided for dispatching and routing, and may be indicated for your application. If all the available exits are shown, the flow looks like the following diagram.

The first step after receiving the message can be to verify the security of the message, in order to ensure that the sender is authorized, check that the message was not changed, and decrypt parts of the message that were encrypted. iWay has security exits for many common security algorithms, including W3C Digital Signature, and PGP, among others. From the exit, you can also check credentials in an external security manager such as Netegrity, Active Directory, or an LDAP server.

Before their payloads can be handled, all messages must frequently be parsed into an internal format. iSM can automatically parse XML and JSON to internal form. However, process flows can handle flat documents as well. The dispatching step is called for non-parsed messages to encode their contents as required by the application. This is called a preparser because it occurs before the message is parsed from its unknown format into the an appropriate internal form. On the outbound side, the step is called a preemitter, and can encode an internal format such as an XML tree or a JSON object into a format appropriate for its recipient. iSM supports many non-standard XML or JSON formats for preparsing and preemitting, thereby eliminating the requirement to code a specific exit.

Finally, there is an exit to validate the contents of the payload. This validation can use iSM rules as described in the iWay Service Manager Programmer's Guide.

Because an integration application generally requires both an input and output, a typical iSM channel is constructed with at least two adapters. One adapter handles the incoming message and another handles the outgoing message, as shown in the following diagram.

The arrow on the diagram shows a one-way message. This adapter allows messages originating on the left to be delivered to the right. However, this basic configuration may support the following two scenarios:

• A one-way message. If the message is one-way, the listener does not wait for a response from the system that is the target of the emit before completing the listen operation.

  For an asynchronous protocol listener, such as MQSeries or the iSM internal listener, no acknowledgment is sent.

  For a synchronous protocol listener, such as HTTP, an acknowledgment is sent back.

  Note: One-way messages are always asynchronous at the application level even if they use a synchronous protocol at the transport level.

• A request-reply where the reply is received synchronously at the emitter, and the listener holds the request until the reply document is made available and returned.

  A synchronous message, including a reply, is shown in the following diagram.

  

Although the previous diagram shows a single path through the channel, multiple routes, agents, and outlets can be defined in a channel. In that case, there can be multiple outputs for a single input, either to the same adapter or to different adapters as shown in the following diagram.

Channels can be bidirectional. The following diagram shows a bidirectional channel which has a listener and emitter on both sides. Messages can arrive from the right or the left and can be emitted on the left or the right, respectively.

To accomplish its mission, iSM executes a defined flow as each message travels from input to output. The flow is standard for all messages, but the execution steps and the processing at each step vary by message source and type. Each of the steps is performed by an exit, which is a routine invoked to perform the specific action at that step. This is the essence of the modular, pluggable framework, which is the source of the flexibility and simplicity of iSM.

In some respects, iSM can be thought of as simply a platform for the execution of exits. No document processing is performed by the server itself. Instead, the server assembles the appropriate exits to accomplish the business purpose of the document. In this model, building a channel is the selection and ordering of pre-built exit code. The existing exits can be supplemented by application-specific code as necessary to accomplish the interfacing task.

iSM protocol handlers can also be supplemented by new protocols tailored to specific application situations. These protocol handlers, called listeners and emitters, service the input channels and output ports that represent the iSM interface to the outside world. As mentioned earlier, the need for custom protocol adapters is rare given the adoption of standard protocols by most enterprises.

For more information on writing custom exits or protocol handlers, see the iWay Service Manager Programmer’s Guide.