AMHS Implementer GuideUsing Isode Servers and APIs to build AMHS solutions
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.
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.
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 X.400 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 9880-AN/466 Manual on detailed technical specifications for the Aeronautical Telecommunication Network using ISO/OSI standards and protocols, Part II - Ground-ground applications (ATSMHS) 1st Edition. The descriptions of how the AMHS service works for an end application can be found in this document. The application integrator will need to broadly understand this specification.
The integrator will need a detailed understanding of Isode's X.400 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 X.400 Client API allows AMHS Application integration in two ways:
- 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 X.400 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 provides a Directory Client API to enable this.
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 to M-Switch X.400 (for P3) or M-Store X.400 (for P7).
Gateway Integration: Design
Connecting between AMHS and AFTN requires closer integration with the AMHS Infrastructure than is needed by an AMHS Client application. Isode provides interfaces to achieve this integration.
DOC 9880 referenced above specifies gateway between AFTN and AMHS, which 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 (AFTN) half of the MTCU. It is important to read and understand the MTCU specifications, as working solely from the Isode API definitions is insufficient.
The MTCU connects AFTN and will run on a single system, that contains both Isode components and AFTN 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 X.400 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 documentation.
In order to use Isode's X.400 Gateway API, Isode's Messaging API documentation 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.
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.
A standard aviation M-Switch channel set up by MConsole includes a “gateway” channel configuration suitable for an MTCU.