Take naming services, for instance. Some middleware depends on network services like Domain Name Services (DNS) or NetBIOS for naming services like HTTP and some Remote Procedure Call (RPC) solutions. DNS, however, only fits for TC P/IP networks. Some other name services like NetBIOS and Novell's Service Advertising Protocol (SAP) work for other network protocols (IPX/SPX). And still other middleware comes with its own application-layer name service, including Distributed Computing Environment's RPC, most Remote Database Access (RDA), message-oriented middleware (MOM) or object request brokers (ORBs). Yet these may still use network services for the final name to address mapping service at the transport layer.

What is a name service supposed to do for middleware? Should it be a full-directory service or simply a very thin name to network address mapping function? Should it be implemented within the middleware or external to it?

Location Service Scalability In real estate, the prime directive is location, location, location. In network application middleware, some consideration should be given to location. Unfortunately, all too often there's no map provided, and implementers have to draw their maps on the way to deploy ment. What's missing is an electronic (always up-to-date) Thomas' Guide to steer clients to servers or application components. (You'd like it to be a little less quirky and more reliable than the Hitchhiker's Guide To The Galaxy!) Middleware vendors should learn from these historical examples of network naming services: NetBIOS and DNS.

With good old NetBIOS, a fully peer-to-peer naming service, a device broadcasts to register its name (and determine if its name is in use by any other device) and broadcasts its address resolution request. Network managers, however, abhor broadcast traffic: It can engender broadcast storms and require single subnet infrastructures or forwarding of broadcasts across routers.

Microsoft's latest incarnation of NetBIOS, based on the Internet Engineering Task Force's (IETF) RFC covering NetBIOS over TCP/IP, provides a nonbroadcast architecture for NetBIOS name registration and resolution with a centralized name service. Microsoft Windows Internet Name Service (WINS) suppor ts dynamic registration and changes replication among servers, but it does not change the DNS hierarchical naming structure or server-to-server data replication and caching standards. Like DNS, it requires that clients are configured to know the IP addresses of a few available WINS servers to talk to over routed networks via unicast.

Networked applications, however, increasingly depend on TCP/IP and DNS; NetBIOS is not going to survive the Internet revolution. DNS has a hierarchical name space that, because of its unicast and server-based architecture, scales across the enterprise and Internet. Yet, DNS is often hard to maintain and for the most part, provides only the simple name to IP address mapping function without handling any other attributes.

Until recently, the idea that you could update the DNS name space dynamically was fiction. The lack of dynamism was highlighted by the advent of the Dynamic Host Configuration Protocol (DHCP). In the next year or so, we'll see more standards-based options for DNS records to be more dynamically updated with changed IP address information. Not surprisingly, this will be called Dynamic DNS.

Middleware vendors should take this last point to heart in their own naming services designs as they try to go publi c: Who (or which applications) should have the right to update the address mapping (or any other attribute) for a name in the directory or to add entries, and how will the naming service enforce such policy? This problem may force middleware vendors to externalize the naming and directory service functions.