7.8. Solution Analysis
The application is currently quite simple. However, the development team designed the application using object-oriented approaches to provide an intuitive migration path once utilization grows. This approach will pay off as eTapestry begins to modify the deployment of the system as traffic to the suite grows.
7.8.1. Servlets and Java Server Pages
The goal of eTapestry's application designers was a highly dynamic, data-driven application that provides access to fully functional business applications through standard Web browsers. Almost every Web page sent back to the user is dynamic, containing customer-specific data.
The initial approach involved deploying Java applets, which provided limited application logic and graphics processing on the client. However, this architecture encountered performance problems for customers accessing through slower modem connections, using older desktop PCs or Macs—or both. (In some cases, the Java applets encountered problems passing through customer firewalls.)
Instead, the production version uses thinner, HTML clients, with all processing performed on the server. Java servlets are deployed at runtime. Based on user input, the servlets generate Java ServerPages, which in turn send HTML and JavaScript via HTTP back to the user.
7.8.2. Java Mail API
The eTapestry application bundles an IMAP (Internet Message Access Protocol) e-mail server to relieve customers of the need to implement their own e-mail servers. The Java Mail API was used to build eTapestry's e-mail modules, which handle custom and mass e-mailings to donors.
By relying on a standard API, eTapestry focuses on developing enhanced functionality, such as the ability to send mass-customized e-mails (mass e-mailings that are individually addressed to each donor) and the ability to store the contents of e-mails into each donor's journal. Without the JavaMail API, eTapestry would have to write individual low-level socket communications with SMTP, POP, and IMAP mail servers, a task that would have required extensive custom programming. “The JavaMail functionality allowed us to put together the whole e-mail package in just a few weeks, without forcing us to learn the innards of every kind of mail server,” says Ganyo. Currently, eTapestry supports outgoing mail via SMTP and POP3, with incoming mail IMAP support scheduled for release in Q1 2001. “This will provide our clients full round-trip e-mail, allowing incoming mail to be automatically routed to the proper IMAP mail server,” Ganyo continues.
7.8.3. Java Naming and Directory Interface (JNDI)
With the Gemstone/J application server, objects are retrieved using naming services via the JNDI API. In the future, eTapestry plans to use JNDI to add directory services to its basic e-mail functionality. With directory service integration, e-mail can be more tightly interwoven into other core eTapestry functions and modules.
For instance, this would allow the e-mail system to integrate with the donor journaling feature (a form of contact management that tracks all interactions with the donor). With this integration, the donor journaling would have records of all e-mails associated with the contact. Other possibilities include the ability to conduct targeted mass mailings to different donor segments based on past activity (for example, send reminders to all donors who haven't made contributions in the past six months) or specific demographics (all donors in a certain census tract or membership level).
The use of standard interfaces, such as JNDI, eliminates the task of developing APIs from scratch. The benefits have allowed eTapestry to focus on developing functionality rather than inventing and maintaining custom interfaces.
7.8.4. Java Secure Sockets Extension (JSSE)
As a mission-critical transaction system for its customers, maintaining security is business-critical for eTapestry. The identities and activities of donors and all financial data are extremely sensitive.
Therefore, virtually all transactions are encrypted, using 128-bit secure socket layer (SSL) encryption. JSSE provides a standard API that allows Java applications to use SSL connections. JSSE provides eTapestry a far more economical alternative to buying proprietary, third-party algorithms for accessing SSL sessions.
7.8.5. Object-Oriented Database
As noted earlier, eTapestry relies on an object database as the sole data cache, an architecture that is fairly unusual. The rationale is that keeping the data represented as objects avoids the complexities of object/relational mapping, and it avoids the need for deciding which form of persistence to deploy—bean- or container-managed.
In taking this strategy, eTapestry weighed issues such as the availability of professionals skilled in object databases in a world dominated by SQL relational architectures, as well as data integration issues with customers and business partners who might otherwise use relational or flat-file data sources. eTapestry concluded that, as a small, Web-based application service provider, it did not require large teams of database administrators. Furthermore, when it came to data integration, because the data structures themselves were hidden from customers and business partners, there was little issue over whether eTapestry's data was object-oriented or relational.
The only issue here was that some customers, who already had rudimentary applications, might already have some data in relational form. Naturally, when migrating data between one database and another, conversions are always necessary. If the source data is relational, having an object database requires an extra conversion step. Considering the nature of eTapestry's customer base, these problems are fairly rare.
The issue, however, might become more relevant if eTapestry adds future integration with business partners whose systems are likely to be more sophisticated, and whose data is likely to be in relational form. As a bridge strategy, the Gemstone/J object cache does support SQL 92 query and indexing capabilities, which will allow business partners with relational systems to access data using familiar SQL calls.
Furthermore, because eTapestry's customer base is not computer-savvy, queries are made, not with SQL commands, but with a query and reporting facility that was custom built into the application itself.
Naturally, scalability is an issue, for application and database architectures alike. Given the market dominance of SQL databases, large transactional object databases are rare. However, at current levels of utilization, that is not an issue for eTapestry. Nonetheless, the development team is keeping its design options open, however, as utilization levels rise.