In general, a message entering the server (iSM) has three main parts, as shown in the following diagram.
This diagram shows the message stack organized with the more physical layers of the message at the bottom and the more abstract (business-oriented) layers of the message 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. The payload can be in native (flat), XML, or JSON format. Examples includes EDI and SOAP messages, or an API request. The channel can be configured to parse the incoming payload into an internal format, leave the incoming payload in its current format (no parsing), or use preconfigured or customized preparsers to convert a unique payload format into an internal format.
- Headers. Message 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 to corresponding functions in iSM.
Conceptually, an 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 provided by iSM will be sufficient to construct your channels, since iSM supports all industry standard protocols.
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.
Finally, the message is handled by the application level. This is where iWay process flows are executed, and the level where integration applications are written.
The following diagram illustrates the flow of a message or document through a simplified, single-directional channel.
The phases of working with a message or document can be subdivided further. Various exits are provided for dispatching and routing, which can be configured for your application. The following diagram illustrates a message flow where all of the available exits are shown.
After a message is received, the first step can be to verify the security of the message. This ensures that the sender is authorized, confirms that the message was not changed, and decrypts parts of the message that were encrypted. iSM provides security exits for many common security algorithms, including W3C Digital Signature, Pretty Good Privacy (PGP), among others. From the exit, you can also check credentials using 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 payloads to an internal format. However, process flows can also 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 appropriate internal format. On the outbound side, the corresponding step is called a preemitter, which can encode an internal format such as an XML tree or a JSON object into a format required by the message 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.