|
Signs of Change
Of course, the need for directory and naming services goes back as far as computing itself. Naming files and organizing them into a directory structure is a basic part of every OS. For many years, files were all that needed to be named. Then with the advent of the LAN, other entities--computers, printers and users, for example--needed names.
The naming and directory services that evolved are incomplete, ad hoc and proprietary: NDS, Microsoft's NT Directory Service, Banyan's StreetTalk. They're incomplete because they're oriented toward only a few types of named entities (computers, users, files, printers), when, in fact, a host of entities--applications, components, system configurations, database schemas, Internet addresses, Web pages and so on--are in need of a more systematic naming
scheme. Also, they are arbitrarily divided into separate cataloging subsystems, each with their idiosyncratic APIs and formats.
Recently, however, more comprehensive and consistent approaches to cataloging services have begun to take hold. LDAP is rapidly becoming the de facto standard API for accessing catalog services ranging from traditional file and print services to e-mail addressing services to middleware naming services. Whether LDAP is in the right place at the right time or whether its trade-off of power for simplicity strikes just the right balance, LDAP is succeeding where its progenitors DCE and X.500 failed.
A common API for clients to access catalog services is a great leap forward. Now developers need only learn one API to look up any kind of information or entity--be it a Web page, file, computer or user. However, LDAP says nothing about how such information should be stored or how it should be organized in the catalog. Furthermore, LDAP does not establish how to organize information.
However, progress is occurring on those fronts. Although we will never have a universal catalog storage standard, a number of vendors, including ISOCOR and RedBox Technologies, are providing catalog-synchronization products that let information be replicated among catalogs. Both Microsoft and Novell have committed to including such capabilities in upcoming versions of their directories. Microsoft has gone one step further with ADS, which will be able to synchronize with DCE (Distributed Computing Environment)-based directory services.
Similar catalog "bridging" approaches are beginning to appear within the object repository (read "catalog") space. With Visual Edge's Object Bridge, objects stored in a CORBA (Common Object Request Broker Architecture) repository can be accessed by ActiveX clients and vice versa. There's even talk of enabling similar object sharing among APE repositories, perhaps with SAP's BAPI (Business API) becoming a de facto standard.
Future Directions While vendors and developers a
like are beginning to appreciate the fundamental importance of catalog services, much remains to be done to make catalog services truly first-class, interoperable and distributed. Catalog services must be interoperable because vendors will not agree on a universal catalog/repository/directory standard. Catalog services must be distributed because they're used to enable and interconnect distributed applications. And catalog services must be capable of organizing content as distributed as the Internet itself.
Unfortunately, the Internet has made little progress in cataloging standards. A pre-Web initiative, Z39.50, appears to be moribund outside the library card-catalog domain. A newer initiative, XML, enables channel/category annotation for pseudo-pushing Web pages by content/category, but it's limited in scope and support. We still have a long way to go before the wealth of content available on the Internet is organized and accessible via catalog services.
Although no universal catalog service will emer
ge, Microsoft is positioning ADS and its OLE DB as parts of its "universal" solution (it's universal as long as it's Windows). ADS will combine several traditionally disparate catalog services into a unified service: file and print naming and directory services; repository services for DNA/ActiveX; configuration management services for ZAW; address book services for e-mail; user access information for security. All of this information will be accessible in a uniform format using OLE DB rowsets as the universal representation format (relevant information will be available via LDAP as well). Microsoft is even planning to incorporate database metadata repositories into this grand scheme. Of course, ADS is Windows-only and it won't ship until NT 5.0 (which could slip to the year 2000).
Unfortunately, no serious competitor to ADS is on the horizon. Unix vendors have no comparable standard for interoperable catalog services. CORBA ORB vendors have little in the works beyond CORBA's Name Service. The only signifi
cant alternative is JavaSoft's NDIS (Naming and Directory Information Service), which is an LDAP-based standard for enabling catalog services for Java-based components. Of course, it only works in a Java-centric world.
The wild card here is ISV (independent software vendor) support. Unless ISVs open up their application-specific catalogs using one or more of the above approaches, nothing is going to change. Catalog services cannot be bolted on. So far, lukewarm attempts by organizations like the OMG (Object Management Group), the OAG (Open Applications Group) and the Metadata Council have not produced much. But then again, never has the need for robust, interoperable, distributed catalog services been more obvious. I'm about to bite the bullet and catalog the mess in my office (I hired a temp); maybe ISVs will get together and do the same.
Nick Gall is a program director with the META Group's Open Computing & Server Strategies service. He can be reached at nick.gall@metagroup.com.
|
REPORTS
ANALYTICS
Follow 
