Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.
This document is designed to help in using the Isode servers and APIs to build AMHS solutions. It does not try to explain what is needed in detail, but rather gives an outline of what the implementer needs to know to achieve various goals, and provides information to help plan the overall structure and approach to an implementation and deployment.
The top level picture of an AMHS system as a communications channel interfaces to applications and gateways is a simple one. However, the detailed specifications in the ICAO SARPs are complex, and the implementer needs to be aware of at least some of this complexity. This document gives pointers to the key information that needs to be understood.
Isode's products provide a flexible solution, designed to operate in demanding and complex environments. While basic deployment can be simple, many of the more complex features will need to be understood for operation in this environment. This document gives an outline of the features that need to be understood, and where to find this information.
X.400 Quick Install: A practical start
A good practical way to start is with an evaluation of the Isode X.400 products. This will enable you to operate all of the necessary Isode server products, and to use and experiment with the associated management tools. This should only take a few hours, and we recommend doing it early.
The Key Tasks
The AMHS Implementer will generally be developing one of two things (or both)
- Integrating an ATC or ATM with AMHS client libraries, to enable this application to communicate using AMHS.
- Building a gateway (MTCU), to enable interconnection of AFTN or CIDIN systems to an AMHS network.
This document describes first application integration, and then building a gateway, looking at design, implementation and testing issues.
Once built, these applications will need to be deployed. Information on deployment is given in the Isode Guide Deploying an Isode X.400 System.
Application Integration: Design
In order to integrate an ATC or ATM application with an AMHS infrastructure, the AMHS Application will act as an X.400 Client or User Agent. In order to achieve this, the client AMHS Application needs to be linked with Isode's AMHS Client API, which will enable the AMHS application to communicate with other applications over AMHS.
AMHS is specified in Manual of Technical Provisions for the Aeronautical Telecommunications Network (ATN). ICAO SARPS Doc 9705/AN965:The ATN SARPS, Sub volume 3, Ground to Ground Applications, Third edition. An online copy can be found here.
The descriptions of how the AMHS service works for an end application are in Sections 3.1.1, 3.1.2.1 and 3.1.2.2 (pages 7-37). The application integrator will need to broadly understand this specification.
The integrator will need a detailed understanding of Isode's AMHS Client API, and should read Isode Messaging API Manual, including the API definition in the implementation language chosen (C, Java or Tcl). Example programs are available, which will help understanding the APIs.
Application Integration: Architectural Choice
Isode's AMHS Client API allows AMHS Application integration in two ways, illustrated above:
- Directly to M-Switch X.400 using X.400 P3.
- Indirectly to M-Switch X.400 via M-Store X.400 using X.400 P7.
The P7 choice should be used where the application needs the AMHS infrastructure to provide reliable message storage. In cases where the application provides reliable storage, use of P3 is generally the better choice, as it eliminates the need to use an X.400 Message Store.
Where message delivery (retrieval) is done using P7, it may make sense to do message submission using P3 to increase performance, unless the client wishes to take advantage of capabilities to submit messages already in the store or to keep a copy of submitted messages in the store.
Isode has a single API which supports both P3 and P7. For message submission, the API works in the same way for both P3 and P7, and supports messaging submission using either P3 or P7. There is a single API for retrieval, but the underlying mechanisms are different, and a robust application will need to be aware of this, particularly if P3 or both P3 and P7 are to be used. For P7, the API provides for simple retrieval of messages from the store and subsequent deletion. For P3, the underlying protocol enables M-Switch X.400 to deliver messages to the client. The underlying system may receive multiple messages. The API causes these messages to be passed to the client and automatically generates a delivery acknowledgement back to M-Switch X.400. The client is then responsible for the received message.
Basic and Extended ATS Message Service and Directory
Isode's AMHS Client API is designed so that there is a single interface to both Basic and Extended services. The client can control whether basic or extended is used. To conform to the Extended service, the client must use the directory to verify the recipient and determine recipient parameters, including whether the Basic or Extended service should be used.
Isode will be providing a directory API to enable this in Q4 2004.
Testing the Integrated AMHS Client Application
The integrated application is quite separate to the AMHS servers, and simply connects using the P3 or P7 protocols, to an AMHS infrastructure.
Basic testing of the integrated application can be done by connecting the application to a configuration generated by X.400 Quick Install, which builds a configuration that includes both P3 and P7 support. The integrated application can be easily added to this infrastructure, following notes in the quick install guide on adding clients.
Gateway Integration: Design
Connecting between AMHS and AFTN or CIDIN requires closer integration with the AMHS Infrastructure than is needed by an AMHS Client application. Isode provides interfaces to achieve this integration.
AMHS Gateways are specified in Manual of Technical Provisions for the Aeronautical Telecommunications Network (ATN). ICAO SARPS Doc 9705/AN965:The ATN SARPS, Sub volume 3, Ground to Ground Applications, Third edition.
A gateway between AFTN or CIDIN and AMHS is defined in this specification as an MTCU (Message Transfer and Conversion Unit). Isode's APIs provide the AMHS half of an MTCU. The implementer will need to provide the other half of the MTCU (the AFTN or CIDIN portion). It is important to read and understand the MTCU specifications, as working solely from the Isode API definitions is insufficient.
The AFTN/AMHS MTCU specification is in Section 3.1.2.3 (Pages 38-145) and the CIDIN/AMHS MTCU specification is in Section 3.1.2.4 (Pages 145-333).
The MTCU connects AFTN and CIDIN, and will run on a single system, that contains both Isode components and AFTN or CIDIN components supplied by the MTCU developer.
MTCU: API Choice
Isode offers two APIs which are suitable for building an MTCU.
- The Open Group X.400 Gateway API.
- Isode's AMHS Gateway API.
The Open Group API has the benefit of being a standard API. Isode generally recommends use of its own API, as it is designed for building an MTCU. For building an MTCU, Isode's API will be quicker to learn and require less code to be written by the MTCU developer.
In terms of overall functionality, either API provides all necessary functions. Isode's API will give better performance, but the difference is not significant overall.
In order to build to the Open Group API, detailed understanding of the Open Group X.400 Gateway API specification is necessary. Use of this API with M-Switch X.400 is described in the Isode Messaging API Manual.
In order to use Isode's AMHS Gateway API, Isode's Messaging API Manual defines the C language interface, explains how the API is used, and provides example applications. Detailed understanding of the API is necessary to build an MTCU.
Address Mapping and Directory
Isode's AMHS Client API gives an interface which expects the MTCU to supply X.400 O/R Addresses. This requires the MTCU developer to generate these addresses, by table lookup, algorithmic conversion or other approach. The SPACE Project has defined an approach to use of directory to perform this mapping.
Isode has demonstrated this mapping, and will be providing a directory API to enable this in Q4 2004.
Testing an MTCU
Testing an Isode MTCU requires a configuration that is not dependent on the API used to build the MTCU. The MTCU is tightly coupled to M-Switch X.400 and runs as a part of it. In terms of the M-Switch architecture, it comprises an passive channel. "Passive" means that the MTCU is run as a separate server which interacts with other M-Switch components. The MTCU can submit messages into the M-Switch queue or retrieve messages from the M-Switch queue.
The X.400 Quick Install configuration includes an MTCU (the "x40088mt" channel). This configuration can be used to test an MTCU.
