Mail-Enabled Applications

Token Ring, Ethernet, FDDI. It's all basically plumbing, and once it works, you give the network-access method about as much thought as you give to the copper pipes that bring hot and cold water when you turn on the tap. TCP/IP, IPX/SPX, and NetBEUI are the valves that control the flow of data. Copper pipes and flow-control valves interest only plumbers and architects . What the average person really needs is the end result of the plumbing system-the dishwasher, the showerhead, the lawn sprinkler system.

There's a new appliance on the horizon that is going to change how we view networking and networked applications, and that's mail-enabled applications. Mail-enabled applications deliver a new type of network appliance and new level of functionality. Mail will evolve from messaging to a complete communications medium.

Mail-enabled applications will deliver the infrastructure for e-mail management applications, workflow automation applications, document distribution, and forms processing. The groundwork is beginning to be laid, with mail engines from Novell, Lotus, Microsoft, and others.

Applications that take advantage of these mail engines are in their earliest stages. And from the looks of applications such as Beyond's BeyondMail for rules-based mail management and Reach Software's MailMan for workflow automation and eventually forms processing, the progress of mail-enabled applications seems quite promising .

Today's E-Mail Is Messaging

Right now, electronic mail is little more than an elaborate messaging scheme. Users on a network can send and receive messages, which are usually short and text-based, and sometimes have files attached. Users can ask for return receipts, send registered mail, forward messages to other users using the same e-mail program, and find out what time the recipient has read the mail. They can construct mailing lists from an address book or directory of e-mail users. With the right software, users on dissimilar computers, say a Macintosh user and an IBM PC user , can exchange messages with relative ease.

Despite the sophistication, e-mail systems remain fundamentally interpersonal communication. One person sends mail to another or to a group of people. The recipient or recipients read the e-mail, perhaps with a file attached, and respond to the message, usually by sending another e-mail message.

This isn't to disparage e-mail's power. E-mail can significantly increase an individual's productivity. It allows people to work offline, as it were, responding to messages on their time and their terms, rather than answering a phone call or having a face-to-face meeting. E-mail has been proven to increase workers' productivity, at least until the onslaught of messages becomes so great that any time savings is eroded by the time taken to manage the volume of messages.

Mail Bonding

E-mail has the potential for becoming more than a method of interpersonal communication. It can become the platform upon which many other forms of communication occur and can serve as the skeleton for other applications. Mail-enabled applications are the merging of messaging with other application software.

The problem lies in the fact that most people do their work in one set of applications-WordPerfect, 1-2-3, and Paradox-and then want to communicate their ideas and share that work with their coworkers. However, messaging is not inherently part of a word processor, a spreadsheet, a database, or most other applications. Messaging is not even a part of most applications that could easily accommodate messaging, such as purchasing systems or contact management systems.

Most applications do not include mail or messaging capabilities for some very simple reasons. First, when these packages were conceived of and written, the concept of mail-enabling didn't exist or make sense. Many of these packages were written before networks became widespread.

Second, for those software publishers who do want to move toward mail-enabling, some roadblocks are in the way. There's no standard, de facto or otherwise . Each e-mail vendor implements a different scheme for mail-enabling, requiring applications vendors to choose among the options. This setup requires the application developers to choose correctly, or potentially lose business.

Also, many companies use more than one electronic mail system. For example, the mainframe terminal users may use PROFS, the VAX users may use All-In-One, and the PC LAN users may use any one of dozens of packages, but probably use Notes or Microsoft Outlook. To use a mail-enabled application, the interface must be able to work with all of the company's existing mail systems.

Any application that uses document routing or communication can become a mail-enabled application. Whether mail-enabled applications become widespread is a matter of how easily the problems can be solved , how easily existing applications can be adapted , and how easily new applications can be written. And that's a function of the available tools.

Making It Happen

Mail-enabled applications, although in their embryonic stages, have great potential. Take for instance, a consulting engineer whose client, a hospital, wants to purchase a boiler. Maybe the engineering firm has an old catalog lying around from one of their suppliers. Maybe an administrative assistant has to call the supplier's salesperson to send a new catalog to both them and their client. Either way, the engineers have to leaf through the catalog, looking for the specifications they need. Then they have to call the salesperson and ask for more detailed spec sheets on the various models and manufacturers.

Now consider the boiler manufacturer, who has to handle inquiry calls from customers across the country. The manufacturer is using a lot of resources in presale and postsale support calls. The company probably has an entire department set up to deal with simple calls, preventing their employees from resolving the more complex issues.

If customers could dial into the manufacturer's computer system, search the documents for answers to simple queries, and download the right specifications sheets and other documentation, then the sales support desk wouldn't have to spend its time manually sending out these packages, and they could spend their time on more meaningful calls. Once at the customer site or even at the manufacturer, the electronic documents could simply be forwarded from one person to another.

While it would seem that this scenario calls for an ordinary document management system, the key is document transport, which can be done via electronic messaging. Put the spec sheet-or any other type of file-in an envelope, and send it. But the forms and routing aspects that simple e-mail systems lack must be solved. The forms can be merely another user interface talking to a mail engine, and the routing can be a rules-based system directing messages to the right people.

Such mail-enabling is appropriate for any application that requires forms distribution. A purchasing system is another example, where one group of managers must approve a requisition if the purchase is below a certain dollar amount, and another set of managers must sign off if the purchase is over a certain amount.

If the requisitions were in the form of e-mail messages, and the system had the built-in intelligence to route the documents to the proper people, a mail-enabled application would be born. Ideally, the people wouldn't even have to use the same front-end mail applications as long as they subscribed to a standard back-end engine or a common interface.

Power In The Back End

Like databases, the new generation of mail applications follows the client-server architecture. Once considered a single application, mail has since been split into its many component parts : the core engine, the user interfaces, message storage, transport layer, gateways to other e-mail systems, and directory services.

As with databases, this client-server architecture allows each group of developers to concentrate on their strengths. For example, the engine manufacturers can concentrate on better message handling services, while the gateway manufacturers work to write faster and more functional gateways between dissimilar mail systems. Front-end application vendors, in the meantime, can offer e-mail interfaces and then build on top of them.

And like databases, no one mail engine has emerged supreme. Today, four groups are vying for the top spot: Novell, Microsoft, Lotus, and OSI. No clear winner has emerged. Message Handling System (MHS), which has been around since the mid-1980s, is the most mature. Originally developed by Action Technologies, MHS was sold to Novell. At one time, the majority of PC LAN mail applications used the MHS interface. Microsoft will outline its messaging strategy for its applications and network users. [Note: Microsoft ultimately announced its Messaging Applications Programming Interface (MAPI), which has been accepted by Lotus and other important messaging developers.] Lotus has announced the Open Messaging Interface (OMI), plus mail-enabled applications can be built using something as simple as the import/export function in its cc:Mail. [Note: OMI was the forerunner of Lotus's Vendor Independent Messaging (VIM) interface, which has failed to gather industry-wide support.] OSI's X.400 standard offers an internationally recognized method of store-and-forward messaging.

No standard communications language exists for mail-enabled applications in the same way that Structured Query Language has become the accepted method of querying relational databases, even though some differences exist among the implementations .

Instead of supporting each vendor's engine directly, developers could write to a common interface, which talks to the different engines. Developers would not have to write the core mail engine themselves nor would they have to worry about choosing the "right" engine. And developers would not have to spend their resources supporting different engines. Now, if only there were such an accepted, industry-standard interface.

[Note: the next three paragraphs are included for historical reference only-OMI became VIM, which is itself well along the way to the old standards' graveyard.] Lotus has proposed that OMI be that common layer and has placed the specification in the public domain. OMI is an Applications Programming Interface (API) that is published by Lotus, IBM, and Apple, and it offers a common interface for different vendors' mail engines, including directory, transport, and message storage functions. OMI will be available for a variety of platforms, including DOS, Windows, OS/2, Unix, and the Macintosh.

Applications make calls to the OMI interface to send and receive messages and for services such as looking up user names in the directory or storing messages in folders. OMI also provides developers the ability to access e-mail services in a modular fashion, such as directory, message storage, and transport. This way, developers and users can pick and choose services. For example, they may choose to use the network operating system's directory service instead of the mail systems'. This setup prevents developers and end users from being locked into using a particular service or vendor.

So far, Lotus has pledged to use OMI to mail-enable all its applications, including 1-2-3, AmiPro 2.0, and Freelance. IBM says it will include OMI technology in a future OS/2-based offering, and OfficeVision/2 will use OMI. Apple will support OMI in future versions of System 7. Still, OMI is a brand-new specification, and only time will tell if it is adopted. [Editor's note: Time has told-it wasn't.]

This tutorial, number 42, by Patricia Schnaidt, was originally published in the January 1992 issue of LAN Magazine/Network Magazine.