Appmail pulls it together
Zaplet Appmail System 2.0 puts a familiar, e-mail face on collaborative business processes
MANY COLLABORATION TOOLS fall short of expectations because they really don’t take into account the way people work. For most distributed organizations, e-mail becomes the de facto tool of choice because of its simplicity and ubiquity. The drawbacks to collaborating via e-mail are the tendency for discussions to fork and the ease with which people can be left out of the loop — and conversely, the likelihood that people will be included in an irrelevant discussion.
A number of tools exist for capturing discussion threads and appear quite trendy in that they borrow from the concept of the Weblog, but Zaplet Appmail 2.0 offers an approach we consider more oriented toward reality. Face it: Most of us are driven by our e-mail inbox. That’s where we go to find out what’s happening in our organization, what we use to prioritize our workload, and — the surge in IM (instant messaging) not withstanding — how we communicate. Appmail provides a way for users to continue using familiar e-mail tools while offering a centralized approach to process management as well as flexibility and a way to “mind the gap” between systems
We found Appmail 2.0 worth considering, although it may be priced beyond the reach of smaller organizations that most desperately need it. Instead of storing multiple threads and duplicate copies of messages on an already overburdened mail server, Appmail messages redirect the user to the Appmail server, which maintains a coordinated view of the business process.
Appmail works with a variety of e-mail clients, including Eudora, IBM/Lotus Notes, Microsoft Outlook and Outlook Express, and Netscape Messenger, or any other mailer featuring HTML support, although default security settings may require tweaking to permit its use. Back-end requirements include BEA’s WebLogic app server and an Oracle8i database; although no commitments exist, we would expect future versions to include other application and database server platforms, if Appmail is to find wide acceptance.
Appmail is built around predefined and custom “building blocks” of reusuable code. These components contain two key parts: business logic in the form of a Java class or an EJB (Enterprise JavaBean) to define what the block does and presentation logic to define the user interface, as set out in a group of JSPs (Java Server Pages).
The building blocks work with an associated Appmail container, which acts as the controller phase of the application. An Appmail container is accessed through a servlet acting as a presentation controller, which interprets HTTP requests, for example, and converts them into an abstract object request. The abstracted request is then passed to the appropriate building block for processing into a presentation data object, which is run through the block’s presentation logic to form an HTML response. The presentation controller combines the HTML responses from each building block to provide the final output to the user. A rules engine and other platform services complete the package.
The building blocks’ connectivity is limited only by the Java language; the J2EE (Java 2 Enterprise Edition) Connector Architecture and JMS (Java Message Service) are fully supported, allowing for asynchronous and synchronous connections. Web services aficionados will find it easy to coordinate processes with existing third-party systems by using the Web services support of Appmail’s SDK (software developer’s kit) to allow receipt of XML messages encapsulated in SOAP (Simple Object Access Protocol) requests, transported over HTTP or JMS.
The part of Appmail we find really nifty is that you don’t need to be a Java developer to create simple Appmail apps, although an SDK is provided for in-house customization to interface with one-of-a-kind and legacy systems. Appmail ships with approximately 20 predefined blocks that represent common functions such as calendaring and project workflow. Hard-core Java developers may sneer at the idea of using canned applets, as will some mail system bigots who are enamored of their package’s native tools. Although it’s true that much of what one can do with Appmail isn’t exactly showstopping, we’d like to point out that even in mid-2002 good developers are hard to find.
Installing Appmail was a cinch, mainly because at this stage of the product’s development, Zaplet recommends that its own engineers or a recommended system integrator handle the setup. Future versions are being designed to be customer-installable; we don’t think that goal is far off, from our over-the-shoulder perspective. Assuming that Oracle and WebLogic are already in place, it may take a half-hour to set up and configure Appmail.
The great part of using Appmail is that it’s easy to maintain simplicity and uniformity, which is important when training budgets keep falling under the ax. Because Appmail incorporates an entire process flow, it provides one-stop viewing of an entire discussion, instead of forcing users to manually organize a series of e-mail messages or submit to an overautomated set of responses that never quite cover every situation. Zaplet Appmail 2.0 isn’t a slam-dunk recommendation but should be considered by any organization seeking to fill in the gaps in its business processes.
