|
Messaging
is not just about e-mail these days, but includes a
variety of analogue, digital and wireless platforms.
A look at the basics. by Graeme K. Le Roux
Messaging
needs have grown tremendously, and it is no longer enough
to rig a messaging system around a single platform.
The messaging answer for many enterprises today is integrated
messaging, which can extend your company beyond any
one type of messaging client.
| Basic
Message System Architecture |
|
There are a number of messaging systems on the
market with various differences in their architecture,
but all of them have four basic elements:
- User
Agents (UAs): Responsible for turning a message
in an arbitrary format into a standard object
and passing it to a Message Transfer Agent (MTA),
and vice versa. UAs typically handle specific
types of message formats. For example a Windows
PC which is part of an Exchange-based messaging
system will have, logically speaking, an UA
for e-mail, an UA for files and so on. The e-mail
UA will not handle files (except as attachments)
and the UA for files will not handle e-mail,
but both will pass standard objects to and from
the MTA to which they are bound.
- Message
Stores (MS): Responsible for storing standard
format objects and selecting suitable MTAs to
forward them, based on rules contained in the
Directory Service.
- Message
Transfer Agents (MTA): Responsible for taking
an object in a single standard format from one
UA, MTA or MS, and forwarding it reliably to
another. These standard objects may contain
anything in any format. Objects are 'standard'
within a given system, but there are several
standards such as MIME, X.400, etc. An X.400
MTA will not understand a MIME object, but all
MTAs which comply with X.400 will handle an
X.400 object for any UA, MTA or MS.
- Directory
Service (DS): Contains records for each known
user or remote network. Each record contains
addresses, phone numbers, etc., for the user,
along with relevant properties for each and
the forwarding rules.
The functions of some of these elements can overlap
to some extent, however they are usually distinct
because this makes it easier to implement the
base system and expand/modify it later. In any
message system there will be one DS, at least
one MS, at least one MTA and two UAs. Compatible
messaging systems communicate via MTAs. UAs and
MSs communicate with each other via MTAs. MSs
communicate with each other via MTAs. UAs usually
don't communicate with each other. One MTA can
service many UAs and/or MSs. This is usually the
case when both the UA and the MS are running on
the same host. If you were to look at Internet
e-mail between users at two different sites, in
terms of basic message system elements, the process
would be something like this:
-
The sender's UA takes a text message and encodes
it as a MIME format object, then passes to the
local MTA.
-
The local MTA uses SMTP to transfer the object
to the MTA at the local MS.
- The
MTA at the local MS passes the object to the
local MS which stores it in a file.
-
The local MS uses the local DS to work out how
to forward the object, then uses an appropriate
MTA to forward the object to an MTA at a remote
MS (the addressee's mail server).
-
The remote MS then queries its local DS to find
out how to forward the object.
-
The addressee's MS then selects an MTA, which
then uses POP3 (or IMAP4 or something else)
to transfer the object to a suitable UA.
-
This UA then decodes the MIME object and presents
it to the user.
Note that "presenting it to the user"
can mean turning it into a fax and sending it
to the user's fax machine (i.e. the UA could be
a fax gateway), just as it can mean showing it
in a PC e-mail client. The MTAs may not be simple
forwarding engines either; they can incorporate
virus scanners or some sort of security policy
enforcement.
|
If you compare between phone and computer messaging
systems, you'll see a key difference that the former
uses the network to report and handle errors rather
than, as in Web page look-ups, the client interface.
The
phone network has the capacity to detect and report
errors, and it can also provide an alternative to simply
display a "Sorry Dave I can't do that" message.
For instance, mobile phone systems typically offer to
record and store a voice message.
Let's say you want to send a voice message from a telephone
to someone who is currently only available on an e-mail
client. First, you'll need some way of equating a person's
phone number to their e-mail address. Then you need
to know that they are currently available via e-mail
but not on the phone.
Having
figured out where you can send a message to, you'll
now need a system which can cope with storing and forwarding
both audio files and text messages. You will also need
rules about what types of messages can be forwarded
to what type of clients.
Let's assume you have a database which equates an addressee's
e-mail address, voice phone number, fax number and pager
number, and you send that person a voice message from
your phone.
If
the addressee is available via phone, the messaging
system can forward the message via the voice phone number.
If the addressee is available via e-mail the message
can be forwarded via e-mail as an attached file.
So which method does the system use first? What if the
addressee is only available via fax or pager? You can't
send a voice message to a fax machine or a pager, so
you'll need to find a way to send a notification message
telling the person they have voice mail. Other rules
can include notification based on priority, and the
source of the message. We can also add rules about defaults,
notification and set permissions on who can modify what.
For
example, we may prevent a user from altering their phone
numbers, e-mail addresses and the rules associated with
them, but we will almost certainly want them to be able
to decide which, via numbers/addresses, they can be
reached at a given time.
A sophisticated directory service is thus necessary,
but not the only thing we need. Think about the collection
of message formats we are dealing with in the above
example. A voice message is some sort of audio file
(.avi, .wav, .mp3, etc). An e-mail message could be
plain text, rich text, MIME encoded, something proprietary,
or encrypted.
A
fax has no electronic form at all, but they most commonly
get stored as TIFF files. Then there is the chance that
the fax machine is fully ITU-T3.0E compliant, in which
case you may have to cope with the possibility that
a fax may be in color rather than the traditional black
and white.
Even the pager may not be simple, since it can come
in many flavors (SMS, SMS address, extended SMS format,
etc). Here, we'll need a storage system—a message
store—which can extract all these individual message
formats to some generic form of object which has a number
of properties, and to which a number of conversion rules
can be applied.
Agents
Having worked out a way to store these generic data
objects, we will need individual "agents"
to convert and display them appropriately and to forward
them between message store and conversion agents, or
between message stores.
The really nice thing about this architecture is that
we can add any kind of user agents (UA) as required.
For example, we can add an UA which looks like a host
file system element, i.e. a folder. When we put a file
in this 'folder', it is stored in the message system's
message store and it can then be forwarded as required
to other UAs.
This
is how, for example, a network of Microsoft Exchange
servers replicates files and manages to synchronize
its folder contents, which in turn provides the system's
basic collaboration features.
You can also add an UA which sits between the data entry
interface of a client and its server in a client-server
database system. While the network and the database
engine is running, the messaging system forwards data
entries immediately to the database engine, and when
the database engine is inaccessible the messaging system
stores data entries.
This means that the data entry operator can continue
to enter data into the system while the server is unavailable,
rather than having to resort to paper alternatives and
then enter the data when the system is available again.
Integrating your messaging system gives you the ability
to store and forward many different types of data simultaneously.
We need this capability in situations where we must
deal with a number of disparate data types in one system.
This usually occurs when we have to convert data objects
in a way which varies, depending on factors over which
we have limited control, such as when an individual
is available to receive a message via phone, fax, pager
or e-mail.
Graeme K. Le Roux is the director of Moresdawn (Australia),
a company which specialises in network design and consultancy.
He can be reached at graemel@moresdawn.com.au
|
|| Feedback
|| Subscribe-
