Groupware requires ways to define users and groups, test for membership in groups, and manage users’ preferences and group affiliations. In this chapter we’ll explore these issues while developing a notification system that alerts a group of subscribers to docbase updates. We’ll also build a family of group membership modules that share a common interface but talk to different data stores.
Internet groupware presents special opportunities and challenges,
because it can encompass scopes as narrow as a few individuals and as
broad as the entire wired planet. To build groupware applications for
these environments, you’ll need various kinds of directory
services. A directory can model human resources, such as users and
groups, and other resources, such as a computers, printers, networks,
and offices. Applications that consult a directory don’t have
to create their own directory information or provide their own tools
to manage it. And yet the world is full of applications that do just
that. Why? Even within companies there has never been a single
dominant
standard for directory service. Of course, there are plenty of
standards, including Unix’s /etc/passwd
and /etc/group, NetWare 3’s bindery,
NetWare 4’s NetWare Directory Service (NDS), NT’s
Security Accounts Manager (SAM) database, the Windows 2000 Active
Directory, the VINES StreetTalk service, and many others.
From the perspective of a LAN-based groupware application—cc:Mail, for example—there were three choices:
- Use the native services
Define a directory in terms of a least-common-denominator subset of the native directories on all supported platforms, then implement that directory on each platform.
- Use a metadirectory
Banyan’s Enterprise Network Services (ENS) for NetWare was one of the first notable examples of a metadirectory. When Novell introduced NetWare 4, there was no way for NetWare 3 customers to use the new global directory service without upgrading to Version 4. Sensing correctly that a lot of companies wouldn’t want to do that, Banyan adapted StreetTalk to work as a wide-area synchronization service for the NetWare 3 bindery and brought the highly regarded StreetTalk API to the NetWare environment for use by groupware applications. History repeats itself. Now Entevo (http://www.entevo.com/) has built an Active Directory service for NDS and legacy NT domains.
- Use a proprietary directory
It was a lot of work to use native directories, and the least-common-denominator constraint was severe. Many attributes of individuals and groups that might matter to a groupware application—a person’s photograph, a group’s organizational role—couldn’t be stored in conventional network operating system (NOS) directories. So most groupware applications provided their own directory services. If you were lucky, an application came with a synchronization tool so that you could jump-start the creation of the proprietary groupware directory by filling it with basic information—perhaps just lists of users and groups—drawn from a native directory.
The rise of the Internet made an already hard problem a lot harder. Large internal corporate directories manage tens of thousands or, in a few cases, hundreds of thousands of users. These are big numbers, but they pale in comparison to the throngs that may interact with corporate web sites. At BYTE, for example, the internal network served only 100 users, but the web site attracted over 3 million in its first three years. It’s true that these visitors weren’t known to the site as members of a group. But a subscriber-access version of the site, which I built and was ready to deploy when the magazine was discontinued, did test for membership in a group of over 300,000 subscribers. More than three orders of magnitude separated the 100-user staff directory from the 300,000-user subscriber directory.
In the past, we have simply called the latter kind of directory a customer database and managed it with SQL. That will continue to make sense for transactional data—orders, billing, and the like. But Internet groupware creates new opportunities—most notably in the realm of customer service. Given the choice, many people would prefer to resolve a billing problem by email, rather than by calling an 800 number. Email isn’t nearly as available as the telephone, but it’s headed there fast. As email drives toward universal adoption, the management of customer email addresses is going to look more like a directory problem and less like a conventional database problem. Why? Groupware is about relationships more than it is about transactions. A directory, which is a species of object database, is a good way to define and manage relationships. Communication tools such as mail and conferencing applications work in the context of relationships, so they’re naturally attuned to directories. Groupware applications built on top of these tools (or their underlying protocols) likewise are natural users of directories. A person’s membership in the customer service group, and relationship to a group of customers, are two equally important facts that interactive email users and groupware applications alike should be able to look up in a directory.
The Internet does provide a rudimentary kind of directory in the form of the Domain Name System (DNS), which maps between IP addresses (192.172.248.100) and names (udell.roninhouse.com). But the DNS wan’t designed as a general-purpose directory. More recently, Lightweight Directory Access Protocol (LDAP) has emerged as the standard for accessing full-featured, Internet-oriented directory services. Netscape deserves much credit for popularizing LDAP, which began as a University of Michigan project that aimed to streamline and simplify the Open Systems Interconnect (OSI) X.500 standard. The influence of X.500 pervades Lotus Notes, NetWare’s NDS, Active Directory, several large-scale commercial email systems, and the public-key infrastructure that supports the digital certificates exchanged between browsers and web servers when they establish secure (SSL-encrypted) sessions. What makes LDAP special is that it’s fast becoming the lingua franca of directories. Nearly every major vendor of network software has endorsed LDAP and is building products that work with it.