X.400 Client API

X.400 provides an extensive and powerful set of features, and as a consequence, generic approaches to integrate applications are complex. Many applications built over X.400 have quite simple requirements from the underlying service. Isode's X.400 Client API provides a simple abstraction of the X.400 functionality to meet the needs of client applications. Applications developed over the X.400 Client API can be deployed in two ways:

Over X.400 P7, to access the X.400 Message Store. This is useful for client applications that require storage services from X.400.
Over X.400 P3 to directly access M-Switch X.400. This is useful for client applications that provide their own reliable storage, and wish to transfer messages over X.400 without the overhead of a Message Store.

The X.400 Client API is intended for both standalone client applications, and for Web applications, and offers multiple language bindings (C, Java, and Tcl) to enable this.

Deployment Targets

The Isode X.400 Client API is designed for use by vendors building X.400 client applications, in particular:

AMHS applications (aviation industry)
EDI applications
Military applications using STANAG 4406 (P772)

Key Benefits

The Isode X.400 Client API offers the following benefits:

For developers of X.400 client applications, it provides a very simple abstraction.
Although the X.400 complexity is abstracted, the API is designed so that all X.400 services can be selected and modified if required.
The API is cross platform - available on Windows, Linux, and Solaris.
The same basic API can be used for deployment over either P3 or P7.

Architecture

The X.400 Client API can be used in two distinct ways, as illustrated below. In the first architecture, the library connects the application to M-Switch X.400 using P3. This is appropriate for X.400 applications that need to send and receive messages, and deal with message storage as a part of the application.

The second option, shown below, connects to Isode's X.400 Message Store using P7. In addition to sending and receiving messages, this architecture enables message storage, and is appropriate for applications that need the infrastructure to support message storage (e.g., to permit access to a message by a second terminal, in the event of a hardware failure).

The X.400 Client API is a synchronous API, which gives a simple model to the application developer. The API is designed to be used with a multi-threaded process, and a process may have multiple associations. Each association should only be accessed by a single thread.

Language Bindings

The X.400 Client API offers three different language binding:

'C': Appropriate for use in a wide range of client applications.
Java: Appropriate for use in Java applications, and in Web applications. This includes a low level interface aligned to the ‘C’ API, and a higher level API providing a natural service abstraction.
Tcl: A scripting interface, aligned to the 'C' API, useful for testing and for simple applications.

API Layering

The X.400 Client API provides a core set of functionality, which is useful to all applications. Functionality appropriate for specific markets is offered in addition to the core API, which is a mix of layered functionality and additional supporting routines. Three market specific APIs, which include the core X.400 Client API functionality are identified:

AMHS Client API. For the Aviation industry (AMHS).
MMHS Client API. For Military Message Handling Systems (MMHS).
EDI Client API. For Financial applications, handling EDI over X.400.

Security

Authentication over protocol can use one way or two way password based authentication. When operating over TCP/IP, encryption can be provided by use of IPsec.

The API provides support for X.400 Security features, including those required by the AMHS ATS Extended Service. This include MOAC and MessageToken based security, with support for Content Integrity, Message Origin Authentication and Message Sequence Integrity.

Interoperability

The AMHS integration library has been primarily developed to integrate AMHS applications with the Isode server products. Because of its use of the P3 and P7 protocols, applications developed with this library should also work with other conformant servers.

The P3 and P7 protocols can operate either over TCP (RFC 1006) or over a SARPS conformant OSI stack.

API Functionality

The API provides the following core functionality:

Bind. Application connects securely to MTA or Message Store. For a Message Store, this returns the number of messages waiting.
Unbind. Application disconnects
Create a new message with default settings
Add parameters and content to a message.
Submit message. Application sends a message.
Retrieve message. This retrieves a message, and provides the application with a handle to the message. A P3 variant of this is provided, to allow the message to be secured by the client before transfer is finalized (not needed for P7).
List messages (P7 only).
Get parameters and content from a message.
Delete message. This deletes the message object, and for a Message Store (P7), optionally deletes the message.

Building X.400 Web Applications

Some X.400 applications are best developed as Web services, rather than desktop systems. Isode's Java X.400 Client API is ideal to support this. Web applications are written in Java and running in an application server such as Tomcat or Websphere. These applications are integrated using the Java version of Isode's X.400 Client API. This APIs make it straightforward to build a Web application that communicates over X.400.

A Web interface can provide a complete solution for many X.400 applications. A Web interface will often be used by users who only spend a part of their time using Web applications. Such users can access a Web interface when they wish to initiate communication. However, such users may not be looking at the Web when messages arrive, so it is important that the Web application includes an appropriate alert mechanism. This could include:

Printing the message for manual distribution.
Use of conventional alerting tools, such as pager or SMS.
Sending an Internet email alert. This will often be convenient where the user frequently reads email. Because the Web application can render the message in HTML, it will be easy to include a copy of the message in the email alert. This means that the message may be read in a convenient graphical format in any Internet email client. For many messages, particularly non-critical messages which do not need an action, sending the email alert may be used as the message delivery mechanism. Where a message has security implications or only makes sense in the context of the Web application, it may not be appropriate to include the message content in an email alert.

The AMHS Client API

The aviation industry is adopting AMHS (Aeronautical Message Handling Systems) for provision of ground to ground communication. Isode provides a set of ICAO (International Civil Aviation Organization) SARPS (Standard and Recommended Practices) conformant server products (M-Switch X.400, X.400 Message Store, and M-Vault), to provide an AMHS infrastructure. The library supports both the Basic ATS Message Service and the Extended ATS Message Service.

The AMHS Integration Library can be used in two distinct ways, as illustrated below. In the first architecture, the library connects the application to M-Switch X.400 using P3. This is appropriate for AMHS applications that need to send and receive messages, and deal with message storage as a part of the application.

Further practical information for developers using these APIs is given in the Isode AMHS Implementer's Guide.

AMHS Specific Functionality

The API provides various functionality that is specific to AMHS. In particular, it provides support for the ATS Message Service abstraction, so that applications can be built in a manner which is independent of the choice between the ATS Basic Message Service and the ATS Extended Message Service (which use different encodings to achieve the same service functionality). This means that applications can be deployed over the basic service, and will migrate to the extended service without any application changes.

Some aspects of the Extended ATS Message Service require support of directory. These capabilities are provided by Isode's ATN Directory API. This API enables lookup of client parameters, and also enables conversion between eight digit AFTN addresses and X.400 O/R Addresses.

MILITARY Specific Functionality

The Isode X.400 Client API provides supports for P772. This includes support the envelope field, message headings and military body parts. P772 capabilities are sold as an add-on to the core API.

Conformance

X.400 Conformance

Isode's X.400 P3 conformance is set out here.

Isode's X.400 P7 conformance is set out here.

ICAO SARPS

Manual of Technical Provisions for the Aeronautical Telecommunications Network (ATN). IACAO SARPS Doc 9880/AN965:The ATN SARPS, Sub volume 3, Ground to Ground Applications, Fourth edition.

Military

STANAG 4406, Edition 2. "Military Message Handling System", March 2005

API Definition and Documentation

The Isode manual, describing all of the Isode messaging APIs is here.

The 'C' language Isode X.400 Client API definitions are available here and example programs are available here.

The Java language Isode X.400 Client API definitions are available here and example programs are available here.

Examples of the Tcl language Isode X.400 Client API are in the product release and are described here.

Availability

The Isode X.400 Client API is available on Solaris, Windows, Linux and HP-UX. More details on supported platforms and versions can be found here. The X.400 Client API is also supported on Windows XP. Windows Vista and Windows 7.

Isode Products

X.400 Messaging Products

X.400 Client API and Library