The projection of identity

January 29, 2001 —

Pointers, as noted in earlier installments, are natural implementations of the rule of identity: By their very nature, they exhibit both uniqueness and uniform behavior. But because they're designed to indicate specific memory locations, pointers fail to implement location independence. In many applications -- specifically those designed for use by one individual at one machine -- this is not a problem. In client/server and distributed systems, however, location independence is essential to proper behavior.

An object's identity is independent of its location. An object may take on many forms, including a record in a table, a block in a file, or a structure in memory. It may exist in many physical locations -- different computers, processes, or databases. Regardless of its current form and location, though, the object must always meet the standard of uniqueness and exhibit uniform behavior. Here are a few methods that facilitate this in a distributed environment.

DCOM and CORBA: Location independence at a price

Object broker technologies such as DCOM and CORBA make location independence their business, using the interface definition language (IDL) to convert methods and properties into standard network packets. In this process, called marshalling, a client requests an object from the broker. The broker responds by creating the requested object on the remote machine, creating a proxy on the client machine, and establishing a connection between the two.

This method of ensuring location independence is quite convenient. The proxy and stub hide all the network details behind the veil of interface. Neither client nor server has to change its programming model -- a feature Microsoft calls "Location Transparency." Consequently, unique identity and uniform behavior are implemented automatically under DCOM and CORBA.

This convenience, however, has a price. All of a remote object's methods are, quite naturally, executed remotely. Furthermore, they are executed synchronously -- the client thread blocks while the invocation is marshalled across the network. Marshalling can be a lengthy operation, so the number of calls to remote objects must be minimized. Also, a server machine must maintain an active connection to every client -- the result is that DCOM and CORBA are not scalable.

The DCOM and CORBA mechanisms are also prone to failure. If the network connection is severed, a client thread may block for a significant amount of time before the problem is detected. Moreover, network security measures, including firewalls and NT access permissions, may prohibit the creation of remote objects. Thus, DCOM and CORBA lack the reliability required by mission-critical applications.

Middleware: Location independence, but not for every object

To meet the needs left unfulfilled by DCOM and CORBA, many vendors have created middleware solutions (for example, Inprise's Midas and Microsoft's ADO). Middleware creates a bridge across both storage and machine boundaries.

In a middleware database environment, clients access records on a remote server from within the confines of transactions. Because transactions keep database operations consistent, different client machines can share a data set without compromising its uniform behavior.

When using middleware, the data in the remote database and the data in the local recordset represent the same object. Both instances of the data maintain a joint unique identity and exhibit uniform behavior; location independence is realized. Furthermore, most middleware solutions support disconnected recordsets and asynchronous execution, greatly improving an application's performance and responsiveness.

Middleware can implement location independence of database records because those records are simply data containers and cannot implement business logic on their own. To actively participate in an application, data usually must be loaded from a record into an application-specific business object. True location independence requires unique identity and uniform behavior from those business objects, not just their source records. Since business objects are application-specific, their synchronization must be implemented manually if they are to obey the rule of identity.

True location independence is difficult to achieve in a distributed environment. DCOM, CORBA, and middleware are just a few of the mechanisms that can help. None of them are a universal solution, however. As always, you must choose your tools carefully.

ITworld.com