1. Introduction
Network applications can be broadly distinguished by five operational
characteristics:
o server push or client pull;
o synchronous (interactive) or asynchronous (batch);
o time-assured or time-insensitive;
o best-effort or reliable; and,
o stateful or stateless.
For example:
o the world-wide web is a pull, synchronous, time-insensitive,
reliable, stateless service; whilst
o Internet mail is a push, asynchronous, time-insensitive, best-
effort (without DSN), stateless service.
Messaging applications vary considerably in their operational
requirements. For example, some messaging applications require
assurance of timeliness and reliability, whilst others do not.
These features come at a cost, in terms of both infrastructural and
configuration complexity. Accordingly, the underlying service must
be extensible to support different requirements in a consistent
manner.
This memo defines a core messaging service that supports a range of
operational characteristics. The core service supports a variety of
tailored services for both user-based and programmatic exchanges.
1.1. Overview
APEX provides an extensible, asynchronous message relaying service
for application layer programs.
APEX, at its core, provides a best-effort datagram service. Each
datagram, simply termed "data", is originated and received by APEX
"endpoints" -- applications that dynamically attach to the APEX
"relaying mesh".
The data transmitted specifies:
o an originating endpoint;
o an opaque content (via a URI-reference);
o one or more recipient endpoints; and,
o zero or more options.
Options are used to alter the semantics of the service, which may
occur on a per-recipient or per-data basis, and may be processed by
either a single or multiple relays.
Additional APEX services are provided on top of the relaying mesh;
e.g., access control and presence information.
APEX is specified, in part, as a BEEP [1] "profile". Accordingly,
many aspects of APEX (e.g., authentication) are provided within the
BEEP core. Throughout this memo, the terms "peer", "initiator",
"listener", "client", and "server" are used in the context of BEEP.
In particular, Section 2.1 of the BEEP core memo discusses the roles
that a BEEP peer may perform.
When reading this memo, note that the terms "endpoint" and "relay"
are specific to APEX, they do not exist in the context of BEEP.
The APEX stack:
+-------------+
| APEX | an APEX process is either:
| process |
+-------------+ - an application attached as an APEX
| | endpoint; or,
| APEX |
| | - an APEX relay
+-------------+
| | APEX services are realized as applications
| BEEP | having a special relationship with the APEX
| | relays in their administrative domain
+-------------+
| TCP |
+-------------+
| ... |
+-------------+
The APEX entities:
administrative domain #1 administrative domain #2
+----------------------------+ +----------------------------+
| +------+ | | +------+ |
| | | | | | | |
| | appl | | | | appl | |
| | | | | | | |
| +......+ +------+ | | +------+ +......+ |
| | | | | | | | | | | |
| |end- | |relay | | | |relay | |end- | |
| | point| | | | | | | | point| |
| +------+ +------+ | | +------+ +------+ |
| | | | | | | | | | | |
| | APEX | | APEX | | | | APEX | | APEX | |
| | | | | | | | | | | |
| +------+ +------+ | | +------+ +------+ |
| || || || | | || || || |
| ============= ================ ============= |
+----------------------------+ +----------------------------+
| <---- APEX relaying mesh ----> |
Note: relaying between administrative domains is configured
using SRV RRs. Accordingly, the actual number of
relays between two endpoints is not fixed.
