AS4 for Dummies - Part II: Messaging Overview

• Part I: Introduction
• Part II: Messaging Overview
• Part III: Reliability
• Part IV: Security
• Part V: Are you ready for AS4?

Messaging Model

The messaging model defines the following components in a message exchange between two parties. A clear separation between business and AS4 components is considered.

• The Messaging Services Handler (MSH) is responsible to establish the AS4 message exchange with the other party on both sending and receiving side. Communication with the other party must be in conformance with the AS4 specifications. The MSH must also be able to communicate with the internal business application. This can be done in an implementation specific way, which is out of scope for the AS4 usage profile. An AS4 MSH typically resides in your integration/middleware layer.

• The Business Application interacts in a loosely coupled manner with the MSH. The message producer initiates the message exchange at sender side, whereas the message consumer processes the message at receiver side. ERP and CRM systems are good examples of business applications within this context.

The interaction between these components is defined in abstract operations, such as Submit, Send, Receive, Deliver and Notify. The Send and Receive operations are governed by a P-Mode configuration, which is an agreement between the parties on how the AS4 message exchange will be applied. The P-Mode configures all areas of the message exchange: the protocol, business info, error handling, reliability and security.

Message Types

The ebMS 3.0 specifications define 4 different message types, which have been given a more specific definition within the AS4 usage profile.

• The User Message contains the actual business payload that is exchanged amongst the business applications of two parties.

• Signal Messages have a supporting role in order to establish message exchange patterns, non-repudiation and reliability. They are restricted to the sending and receiving MSH. There are 3 types of Signal Messages:

  • The Receipt is a positive acknowledgement. It indicates that the receiving MSH was able to parse the incoming message without an exception. This ensures the Receive operations was successful. It’s an implementation choice whether to send the Receipt before or after the Deliver operation towards the message consumer.
  • The Error is a negative acknowledgement. It indicates that the receiving MSH encountered an issue during the parsing of the incoming message. The ebMS 3.0 specifications define a list of standard error codes and their meaning.
  • The Pull Request is in support of the pull message exchange pattern, described in the next topic. It allows the receiving MSH to interrogate the sending MSH for the next available message on a specific queue (MPC).

Message Exchange Patterns

Whereas the ebMS 3.0 specification defines several message exchange patterns, the AS4 usage profile only demands support for two of them. The agreed message exchange pattern is configured within the P-Mode configuration.

• Within the one-way/push pattern, the sending MSH initiates the communication and sends the message to the receiving MSH. This exchange may occur on both one-way and two-way underlying transport channels.

• When applying the one-way/pull pattern, the receiving MSH initiates the communication and sends a request for a new message to the sending MSH. The sending MSH returns the message as the response of the two-way transport channel. In case there’s no message available, an ebMS Error (with warning severity) is returned by the sending MSH. This pulling mechanism is ideal for receiving parties that are not high available and do not have a static address.

Message Packaging

AS4 uses SOAP with Attachments as a message format. This is a MIME payload (multi-part), which contains a SOAP envelope as the first MIME part. This SOAP envelope holds the UserMessage, Receipt, Error or PullRequest. In case of the UserMessage, the business payloads that are exchanged are located in the SOAP Body (only allowed for XML data) or in other SOAP Attachments (read MIME parts). Within AS4, there is support for gzip compression of the payloads in the SOAP Attachments.

A User Message consists of the following segments:

• MessageInfo contains the unique MessageId and the timestamp of the message.
• PartyInfo identifies the sender and receiver of the message.
• CollaborationInfo describes the business context through a service and action parameter
• MessageProperties offer an extension point to add additional business information
• PayloadInfo makes a reference to the payloads in the SOAP Body or Attachments

A Signal Message consists of the following segments:

• MessageInfo contains the unique MessageId, the MessageId of the referenced User Message and the timestamp of the message.
• One of these segments:
  • Receipt which contains the proof of non-repudiation of receipt. This is further explained in the next parts of this blog post series.
  • Error which contains a particular error code and description.
  • Pull Request which contains the queue (MPC) it requests a message from.