Archives ||  About Us ||  Advertise ||  Feedback ||  Subscribe-
-
Issue of September 2002 
-
  -  
 
 Home > Focus
 Print Friendly Page ||  Email this story

Focus: Integrated Messaging
Integrating Messaging

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

 
     
- <Back to Top>-  

Copyright 2001: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in Mumbai by The Business Publications Division of the Indian Express Group of Newspapers. Site managed by BPD