Isode provides both Gateway APIs and a Client API for use with its server products.

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:

  1. Over X.400 P7, to access the X.400 Message Store. This is useful for client applications that require storage services from X.400.
  2. 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 and 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.

X.400 Client API

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).

X.400 Client API with Store

The core X.400 Client API is a synchronous API, which gives a simple model to the application developer. The API also provides an asynchronous option for P3. 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:

  1. Bind. Application connects securely to MTA or Message Store. For a Message Store, this returns the number of messages waiting.
  2. Unbind. Application disconnects
  3. Create a new message with default settings
  4. Add parameters and content to a message.
  5. Submit message. Application sends a message.
  6. 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).
  7. List messages (P7 only).
  8. Get parameters and content from a message.
  9. Delete message. This deletes the message object, and for a Message Store (P7), optionally deletes the message.
  10. Option to operate over TLS

Building X.400 Web Applications

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.

AMHS Client API

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).

AMHS Client API with Store

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 STANAG 4406 and the P772 as an additional product to the core X.400 offering. More information can be found in the Isode API Extensions document.

Conformance

X.400 Conformance

X.400 conformance is defined for servers and Clients (UAs).

  • Isode's X.400 P3 server conformance (M-Switch) is set out here.
  • Isode's X.400 P7 server conformance (M-Switch X.400) is set out here.

An X.400 client conformance statement may be developed by Isode customers building products using the X.400 Client API. The Isode client APIs expose all of the services provided by the Isode servers. Client conformance will depend on which of these services and associated API features are used.

ICAO SARPS

  • 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.

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 and example programs are available here.
  • Examples of the Tcl language Isode X.400 Client API are in the product release and are describedhere.