OSI/MHS Orientation Guide

Building Your Message Handling System
OSI/MHS Orientation Guide—424829-001
1-37
What You Need to Do
Many EDI implementations in Europe also reflect the recommendations of Trade EDI
Systems (TEDIS), an EDI planning activity for the European Community.
Given the increasing importance of X.400 messaging, networking service providers and
private enterprises alike have sought convergence between EDI and X.400 standards.
This interest has resulted in the X.435 Recommendation; the definition of a specific EDI
protocol for use with X.400. Prior to X.435, organizations adopted interim EDI
solutions, such as the P0 and P2 methods, described later.
What You Need to Do
Many customers choose to integrate existing EDI applications with an X.400 network.
To integrate an EDI application with OSI/MHS, you can develop either a gateway (for
direct access to the Compaq MTA) or an RUA or an LUA (for access through a message
store). Table 1-10 illustrates some of the characteristics of the three interfaces.
A gateway emulates some functions of a 1984 or 1988 MTA. You can develop a
gateway on the NonStop system using the OSI/MHS Gateway Programmatic Interface
(GPI). You can use the GPI to encode individual items of EDI information (attributes)
into an EDI message (EDIM). An EDIM is an X.435 structure that is the most secure
means to transmit EDI information over X.400 networks.
A user agent can run on a remote system and use the OSI/MHS remote operations server
(RS) for P7 access to a message store. Alternately, a user agent can run on the NonStop
system and use the local operations service (LO) and the OSI/MHS P7 API for P7 access
to a message store.
Table 1-10. OSI/MHS Programmatic Interface Characteristic
Gateway Programmatic
Interface (GPI) Remote P7 Interface Local P7 API
Provides high-level interface using
object-oriented data definitions
Interface depends on remote sys-
tem
Requires application to build
protocol data units
Supports X.435
Supports X.435
1
Supports X.435
1
Emulates MTA for access to
OSI/MHS MTA (P1 protocol)
Provides access to OSI/MHS
through message store (via P7 pro-
tocol)
Provides access to OSI/MHS
through message store (via P7
protocol)
Most likely choice for multiuser
connections
Likely choice for single user agent Likely choice for single user
agent
Application must be ready to send
and receive, must ensure data per-
manence and integrity
Application can retrieve when
ready and rely on message store to
ensure data permanence and integ-
rity
Application can retrieve when
ready and rely on message store
to ensure data permanence and
integrity
Places no requirements on a re-
mote device or system and is suit-
able for local applications
Requires full user agent and under-
lying OSI services on remote sys-
tem
Places no requirements on a re-
mote device or system and is
suitable for local applications
Provides procedural interface for
C or TAL applications
Interface depends on remote sys-
tem
Provides procedural interface for
C or TAL applications
1
Can submit and retrieve X.435 messages but cannot retrieve messages based on individual attributes within
those message