The pattern provides a sample message flow which behaves as a MATIP client application. The aim is to provide a development accelerator for the purpose of helping application developers to quickly create programs which need to integrate with Server applications hosted on MATIP networks. The pattern ensures that the requirements of the MATIP and BATAP protocols are taken care of, bridging between the TCPIP socket communications used by these standards and WebSphere MQ queues.
The pattern provides:
The pattern does not provide (yet!):
The above functions could be added as a possible extension by the reader, or they may be added in future by the author. If you are interested in discussing future functionality please get in contact with the author at <bthomps@uk.ibm.com>
The Air Transport Industry uses the MATIP (Mapping of Airline Traffic over Internet Protocol) communication standard to receive and transmit messaging traffic over TCPIP networks between many kinds of application such as airline reservation and ticketing systems. Adoption of MATIP is widespread both internally on company intranets and in Business-to-Business integration scenarios linking private networks and partner extranets. The most frequent types of messages to flow using the MATIP standard are IATA / SITA teletype messages and EDIFACT messages. IATA (The International Air Transport Association), is an international trade body representing the airline industry in general and the vast majority of international airline operators. SITA (originally short for "Société Internationale de Télécommunications Aéronautiques" - but nowadays the abbreviation is used standalone!) is a company which serves the airline industry with network solutions.
Typically, WMB's routing and transformation capabilities are used to bridge applications operating between TCPIP endpoints and WMQ queues. This extends the reach of applications in the airline industry sector beyond their usual boundaries - such as the private SITA network or the StarNet infrastructure which links together the networks of the Star Alliance partner airlines. MATIP support is provided for the communication of two main types of airline traffic, one known as Transactional and the other known as Messaging:
Actual data messages (normally containing teletype or EDIFACT - but the flows don't care) are transported through the message flow unchanged. In other words the application layer of the protocol stack is left as the responsibility of the application to interpret, without needing to be concerned about the handshake messages which establish and maintain the communication sessions. The diagram below shows the ordering of the protocol stack and the purpose of each layer:
To understand the role that WebSphere Message Broker can play in MATIP scenarios, let us consider the typical interactions which occur when communicating with a MATIP application, shown below in the diagram. The passage of time runs vertically downwards in the figure, and the horizontal red lines show data transmission between the MATIP application and the Broker message flow. It is possible for the message broker to act as a TCPIP client or as a TCPIP server, when interacting with a MATIP application. The sample message flow in this pattern as the client, which means that it is responsible for sending a Session Open message to initiate the session. Once an Open Confirm message has been received by the flow in response, data can begin to be exchanged.
The message flow is capable of receiving data messages over TCPIP from a MATIP application and securing them on a WMQ queue. Likewise it can receive messages from a WMQ queue and transmit them over TCPIP. These two directions of data flow can be seen by the two main horizontal branches of the message flow, shown in the Solution section below.
The purpose of the BATAP envelope which is used when communicating with MATIP applications is to assign a three digit sequence number to every message which is transmitted, known as an SRLN (SeRiaL Number). When a message has been safely received and secured, the receiving application will send a BATAP acknowledgement message, commonly known as an IMA. This message contains the BATAP sequence number. An application is also allowed to use a single IMA message to acknowledge the safe arrival of multiple inbound data messages (as implied by the IMA for messages 002, 003 and 004 which is shown in the earlier diagram). When exchanging messages and IMA acknowledgements, the sending side of a pair of MATIP applications, will also maintain what is known as a window. The window size determines the number of messages which have been sent but are currently outstanding, waiting for an acknowledgement to be received. Each time an IMA is received, a space in the window becomes available allowing another data message to be sent. A timer is started when each message is sent. If a pre-defined time is exceeded, then the data should be re-transmitted. This kind of message is known as a Possible Duplicate Message (PDM). The MATIP and BATAP protocols do not specify a maximum number of retransmissions (to protect against the possibility of infinitely repeating a message), but MATIP applications might choose to implement their own policy. All of these behaviours are catered for by the message flow, so that someone wanting to integrate a WMQ based application with a MATIP network can do so quickly without having to worry about some of the protocol's finer points of detail.
This pattern generates a message flow (shown above) which receives data over TCPIP, parses it using a JavaCompute node and finally writes it to a WMQ queue. The TCPIPClientInput node receives 4 bytes of data from the input stream. This data contains the length of the message, which is calculated and placed in the Local Environment by the JavaCompute node, named LengthProcessing, This specification dynamically controls the following TCPIPClientReceive node which receives the required number of bytes following the header.
The subflow named MATIP_Processing_Inbound checks that a valid session is established, and if so detrmines whether the inbound message was a valid data message or command message. If the data message was an IMA (acknowledging a previously sent message) then the in memory window is updated.
The subflow named BATAP_Processing_Inbound constructs an IMA acknowledgement if the inbound message was a data message. This is sent back to the MATIP Server application.
The subflow named BATAP_Processing_Outbound is passed a message from the WMQ input queue. If there is a free slot in the in-memory window and a session is established, then the data is passed on to the MATIP_Processing_Outbound subflow ready for transmission over TCPIP.
The subflow named MATIP_Processing_Outbound constructs the MATIP header.
This pattern also generates a Java project which contains a small easy to use application which can be used to communicate with the message flow, behaving in the same way as a MATIP Server. Exchanging messages using this application is an excellent way to learn how the flow works. The application acts as a MATIP Server where as the message flow is the MATIP Client. So, first start the Java application, as shown in the screenshot below:
As you can see, some brief instructions are included when the application is launched. Once the application is started, deploy the MATIP Client message flow. As soon as the flow is deployed, a propagation through the Open terminal of the TCPIP Client Input node will cause the message flow to send an Open Session message to the Java application. To receive the Open Session message, you should type READ when given the option. This will cause the application to display the data which has arrived from the message flow. The flow expects to receive an Open Confirm message in response, so next you should type WRITE (or in fact the application will give you the chance to send data if you type anything other than READ!) and then type OC1. This will establish a MATIP session and allow messages to be sent into and out of the flow. The screenshot below shows the receival of the Open Session and the sending of the Open Confirm which we've just discussed:
With the MATIP session established, you can begin sending messages in both directions...
First, try placing a WMQ input message onto the queue named MATIP.IN (default name). The screenshot below shows the receiving of a very simple message which contains the text "Hello World". The message flow expects the Java application to send an IMA acknowledgement which contains the SRLN number in the original message. This can be done by typing the IMA message text into the application as shown. If you do not send an acknowledgement from the Java application, then the message flow will attempt to resend the original message 3 times (by default). The resends occur every 30 seconds (by default).
You can also use the supplied Java application to send a data message to the MATIP message flow, as shown below. Once you have sent the message, then tell the application to READ and you should pick up the response IMA which the message flow sends in acknowledgement.
You should also check the WMQ queue named MATIP.OUT (by default) and you should find the message has been successfully saved by the flow.
Once you feel like you understand the basic operations of the message flow, you are invited to try experimenting with the timeout functionality of the MATIP standard which has been built into the flow.
When testing, particularly if using the WMB debugger, remember the timeouts you have selected. Also, remember you will need to re-establish the MATIP session if either end is disconnected for any reason (e.g. due to an exception in the message flow, or due to a redeployment of the flow, or due to a restart of the testing application). The MATIP session is established using the Session Open and Session Confirm exchange of messages which were described above.