Download 飛報

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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.
The Isode X.400 Client API is designed for use by vendors building X.400 client applications, in particular AMHS
applications (for the aviation industry), EDI applications and Military applications using STANAG 4406 (P772).
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.
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 and Linux.

The same basic API can be used for deployment over either P3 or P7.
Core 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.

Option to operate over TLS.
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 Directory Client 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 support for STANAG 4406 and the P772 message format as an additional
product to the core X.400 offering.
Architecture
The X.400 Client API can be used in two distinct ways:
1. 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.
2. The library 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 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.
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-Store 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 Doc 9880. Manual of Detailed Technical Specifications for the Aeronautical
Telecommunications Network (ATN) using ISO/OSI Standards and Protocols.
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.

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 described here.