In this section: |
iWay Service Manager 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. In HTTP, this contains the name-value pairs for a GET or POST. More generally in an iWay implementation, it is the formatted data representing the content of the message in a native or XML format, such as in the case of SOAP or an EDI message.
Message headers. In HTTP, these are the HTTP headers. They may also include encoding such as multipart MIME headers. In SOAP, these are the SOAP headers and, in SOAP with attachments, the MIME headers. In MQSeries, such values are in the MQ headers.
Transport. This is the transmission method and protocol used to transfer the message between systems. In HTTP, this is TCP. In SOAP, this can be HTTP, SMTP, or FTP.
An iWay adapter handles all three layers of the message. iWay Service Manager (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 iWay Service Manager is acting as a server) and an emitter (for outgoing messages where iWay Service Manager is acting as a client). Note that iWay Service Manager frequently behaves as a client and a server within a given installation. In almost all cases, the transport components supplied with iWay Service Manager 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 iWay Service Manager 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, iWay Service Manager 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 several 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 iWay Service Manager, 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. For more information, see the iWay Designer User's Guide. Mapping one message type to another can be accomplished in the XML domain through the use of the iWay Transformer. Transformations are created graphically using this tool, and then published to iWay Service Manager for run-time use. For more information, see the iWay 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, ebXML, 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 usually be in XML format. The dispatching step is called for non-XML messages to encode their contents as XML. This is called a preparser because it occurs before the message is parsed from XML into the iWay document tree. On the outbound side, the step called preemitter can encode an XML document into a non-XML format. iWay Service Manager supports many non-XML 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 the iWay Service Manager rules described in the iWay Service Manager Programmer's Guide.
Because an integration application generally requires both an input and output, a typical iWay Service Manager 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:
For an asynchronous protocol listener, such as MQSeries, no acknowledgement is sent.
For a synchronous protocol listener, such as HTTP, an acknowledgement 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 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, iWay Service Manager 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 iWay Service Manager.
In some respects, iWay Service Manager 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.
iWay Service Manager 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 iWay Service Manager 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.
iWay Service Manager provides a wide range of business exits for constructing your custom channels. Exits apply in document parsing, output, validation, transformation, security, and agent execution. For more information, see the iWay Service Manager Component and Functional Language Reference Guide.
Exits are written in Java and can take advantage of standard, core iWay system services during their execution. Services such as document parsing, document transformation, tracing, and use of an internal object store are all made available when appropriate to the task of the exit.
Much of the standard functionality of the system is provided through iWay-supplied code run at the exit points, which may be replaced or supplemented by user-written code for special tasks. Full Javadoc support is available with the installation of the server.
The standard exit points are:
These exits handle the actual payload and are called “business agents.” They are at the application and business level. Business agents execute after all input transformations and represent the turn-around point at which an input document becomes an output document. Business agents usually implement the business logic associated with the document. Business agents are the basis of process flows.
These exits manipulate the input before it becomes a document in the internal iWay format (XML). Usually, preparsers are used to change non-XML into XML, for example, a HIPAA input document in EDI format that is to be processed through the system. Preparsers can be chained so that the output of one preparser can be passed to the next preparser. Input to the first preparser is a byte stream, and output is a string. Subsequent preparsers in the chain accept strings and emit strings. Following the last preparser, the engine normally parses the string as an XML document.
These exits process an output document just before it is emitted. Usually, preemitters turn the XML into a non-XML form, such as EDI. Preemitters can be chained. The first preemitter accepts as input a document and emits a byte stream. Subsequent preemitters accept the byte stream output from the first preemitter and emit a byte stream.
These exits accept and emit byte streams. They are the first and last exits through which the document passes.
These exits receive control through the rules system which checks nodes of the incoming and outgoing document for validity. The rules system is discussed in the iWay Service Manager Programmer's Guide.
Usually the exits are not invoked directly by package name, but by alias. An alias is a short name associated with the exit and stored in the system repository.
| iWay Software |