Thus, middleware often misses out on location transparency or maintainability. A good naming service lets services be moved to new machines, and IP addresses, without your having to change the name or any large number of desktop-based mapping files. This keeps application maintenance costs under control. In contrast, IBM's MQSeries requires very manually intensive queue routing configuration with files on every server. By the way, this means that--unlike Internet URLs--detailed application component names should not have device names in them.

Moreover, even middleware that does implement naming services often repeats the mistakes made by NetBIOS and pre-DNS host files for resolution and registration of names. PeerLogic PIPES has a dynamic name service: Clients and servers can register their services at run-time. But, like NetBIOS, it is broadcast-based and won't scale across routed networks without manually setting up server-to-server pointers to unicast from subnet to subnet. Applications designed on such platforms might work well on a single subnet (a bridged or switched network would work: anything within the same broadcast domain). Even the publish/subscribe vendors like Tibco and Talarian with their more complex subject-based addressing have to multicast or server-to-server unicast their naming data throughout the network.

Naming services do not usually indicate if a device or service is up and running. Availability is often highly probable if the entry is in the name service, though immediate failures by networks or servers could be more recent than an entry in even a dynamic name service. DCOM has a naming service, but it tries too hard to mai ntain the availability data consistently by pinging from the server across the network for listed resources on a regular basis. This won't scale.

Extensibility: Going Beyond the Address Naming service extensibility is another requirement for adaptive middleware infrastructure. DNS , for all its proven performance as a single Internetwide naming service, has very little extensibility. You get the DNS name (with hierarchy), the IP address, and maybe an MX record (actually a pointer to another name). There's no searching, just lookup (and reverse lookup).

Unlike DNS, the PeerLogic PIPES naming service has a preset number of buckets or fields to fill in. You can put in anything you want, but you can only put in so much. While earlier LAN e-mail systems offered only simple address book entries, newer client/server products like Microsoft Exchange function similarly for user addresses (until it transitions sometime in the second half of 1998 to supporting the forthcoming NT Active Directory)--you ca n search them on any attribute.

More Names Coming One thing is for sure: Middleware, particularly ORBs with their greater quantity of smaller components, will drive naming services beyond DNS and do it differently from user-centric directory service approaches. There will be lots of little items. A company with 5,000 employees could have millions of components to track, particularly if multiple applications are enabled or when using publish/subscribe middleware.

I expect externalized directory services, particularly Lightweight Directory Access Protocol (LDAP)-accessible services like X.500, Novell NDS and Microsoft NT Active Directory, with much deeper data on devices and services will take over much of the naming service duties.

But developers are only beginning to utilize such emerging standards-based products, since they may lack the performance, dynamism and programmatic control that advanced network applications may need. This is especially true since LDAP is taking a long time to m ature. DNS is inadequate, yet it's the only currently externalized naming service of value. The IETF Service Location Protocol (SLP) work may offer another approach at the standards level in 1998/1999, but frankly, I question if this will ever find a natural place between DNS and a full directory se rvice.

Middleware might indeed need to continue to play the name game for a while before completely externalizing. However, if vendors are not willing to play more intelligently, they should give up and start writing to externalized directory interfaces like LDAP, Sun's Java Directory Access Protocol (JDAP) and/or Microsoft's Active Directory Services Interface (ADSI).

Bruce Robertson is a program director with the META Group's Global Networking Strategies service. He can be reached at BruceR@metagroup.com.