Java Tip 36: Share Java objects using e-mail

The Serializable interface, new with JDK 1.1, simplifies object persistence. Here's how to transfer an object to another user via SMTP e-mail

By Tom Daley, JavaWorld.com, 08/01/97

Object persistence and sharing objects between users are fundamental to many business solutions. For example, a company might provide a mechanism for completing time sheets using a Java applet launched from its Web site. Similarly, the company may provide applets for expense reports, travel itineraries, and bug reports. In each of these scenarios, the data obtained from the user of the applet needs to be shared with the people responsible for payroll, accounts payable, travel reservations, and quality assurance. The people who perform these functions may do so in different cities or countries, are likely to work different hours than the night-owl users who tend to fill out such "forms," and should not be forced to retype the information. Enabling them to "save" and deliver pertinent objects to the business would give such applets a clear advantage over others.

There are several mechanisms for achieving object persistence such as object databases and disk files. Similarly, there are many ways to share objects such as writing data to a socket or implementing CORBA- or SOM-compliant models. Each of these alternatives has its merits and should be considered carefully when you are designing your business solution. But there is also an inexpensive-yet-reliable way to deliver copies of objects around the world using technologies and services accessible by all Internet and intranet users. This is Simple Mail Transport Protocol, or SMTP.

E-mail Java objects

A simple approach to storing and saving objects is to serialize the object and e-mail it to the intended recipient. This has the benefits of:

not requiring disk storage on the sending computer or NC
using existing systems to transmit, queue, and deliver the objects
allowing recipients to retrieve objects with their favorite mail client
providing a simple mechanism for distributing copies of the same object to many people

This approach also has its shortcomings. Here are just a few of them:

Delivery may be delayed considerably if an e-mail host is down. This is true of all systems, but e-mail servers often fall behind database servers in terms of priority when repairs need to be made.
Delivery is not actually guaranteed -- you may have to resend your message if your mail server notifies you that the message was not deliverable.
E-mail servers and POP clients may not be able to keep up with very large transaction volumes.

The relevance of these limitations is based on the nature of your application. For many business solutions, these shortcomings may not be important. Part of your job as architect and designer is to determine the best overall mechanisms by taking into consideration price, performance, and need.