IT-SC book: Advanced CORBA® Programming with C++

Chapter 14. Implementation Repositories

and Binding

14.1 Chapter Overview

This chapter presents a detailed picture of what happens beneath the covers of an ORB. In particular, this chapter shows how a client establishes connections to the servers it needs to access. Sections 14.2 to 14.4 discuss different modes of binding and explain the role of the implementation repository during binding and automatic server start-up. Section 14.5 discusses the design choices available for implementation repositories and explains how these choices affect object migration as well as reliability, performance, and scalability of an ORB. Sections 14.6 and 14.7 discuss the various activation modes for servers, and Section 14.8 concludes the chapter by discussing some of the security issues surrounding implementation repositories.

14.2 Binding Modes

In Chapter 13, we discuss how clients send requests to servers and receive replies via a connection-oriented protocol such as TCP/IP, but we largely skip over the issues of how a client can establish a connection to the correct server and how a server associates incoming requests with its servant. This process of opening a connection and associating an object reference with its servant is known as binding.

CORBA offers a large amount of flexibility in the way an ORB implements binding. Different ORBs offer different options, and, in general, the design of binding algorithms has profound influence on an ORB's flexibility, performance, and scalability.

ORBs typically support two binding modes: direct binding and indirect binding. Direct binding is supported by all ORBs. Indirect binding relies on an external location broker known as an implementation repository and is an optional component of CORBA (most general-purpose ORBs have an implementation repository). The implementation repository can provide additional features, such as server migration, object migration, automatic server start-up, and load balancing. The precise set of features of the implementation repository depends on the ORB vendor and the anticipated deployment environment of the ORB.

Both direct and indirect binding are protocol-specific. In particular, the addressing information embedded in an IOR depends on the underlying transport. For the remainder of this discussion, we assume that IIOP is used.

14.3 Direct Binding

549

IT-SC book: Advanced CORBA® Programming with C++

Whenever a server application creates an object reference, the server-side run time embeds information to support binding inside the object reference. Specifically, an IOR contains an IP address (or host name), TCP port number, and an object key. If a server inserts its own address and port number into a reference, the reference uses direct binding. An ORB can use direct binding for both transient and persistent references. As you saw in Section 11.4.1, a transient IOR continues to work only for as long as its associated POA exists. After the POA is destroyed or its server shuts down, a transient reference becomes permanently non-functional; it never works again even if its POA is re-created or its server is restarted. Conversely, a persistent IOR continues to denote the same object even if the server shuts down and is restarted.

14.3.1 Direct Binding for Transient References

Transient references always rely on direct binding.[1] When a server creates an IOR using a POA with a TRANSIENT life span policy, the server-side run time embeds binding information in the IOR.

[1] The CORBA specification does not require this, so transient references could also use indirect binding. However, no ORB we are aware of actually does this, because indirect binding for transient references complicates the ORB without providing any benefits.

The address and port number in the profile body are set to the server's own address and port number.

The object key of the IOR is set to contain two elements.

The name of the POA used to create the IOR.

Transient POAs must have names that are unique in space and time among all other POAs in an ORB domain. To enforce this, the ORB can prefix a unique identifier to the POA name when a transient POA is created. For example, the ORB can use a universally unique identifier (UUID) to ensure that no transient POA can ever have a name that was used for another transient POA at some time in the past.

An object ID that is unique within the scope of the associated POA.

Because the object ID need be unique only within the scope of its POA, ORBs, for example, can keep a counter in each POA using the TRANSIENT policy. The counter is incremented for every new reference created by this POA, so all IORs for this POA carry a different object ID. The ORB is not obliged to use a counter and can use some other strategy to generate unique object IDs.

When a client receives a transient reference and invokes the first request, the client-side run time extracts the address and port number from the profile body of the IOR and attempts to open a connection. This connection attempt can encounter one of the following cases.

550

IT-SC book: Advanced CORBA® Programming with C++

The server is running at the host and port indicated by the reference.

In this case, the client sends a request message to the server. The request message contains the object key. The object key consists of (among other things) the POA name and the object ID. The server uses the POA name to locate the appropriate POA, and the POA uses the object ID to locate the appropriate servant. If both POA and servant exist (or can be activated), binding succeeds and the request is dispatched to the servant.

No process is listening at the host and port indicated by the reference.

The client's attempt to open a connection to the server fails, and the client-side run time raises a TRANSIENT exception in the application.

The original server that created the reference was shut down, and a different server has since been started at the same port as the original server.

In this case, the client sends the request to the server that is listening at the port. The server receives the request and attempts to locate a POA with a matching name. However, because all transient POAs have unique names, the POA name in the object key does not match any of the server's POA names. Accordingly, the server returns an OBJECT_NOT_EXIST exception to the client, and binding fails, as it should.

The original server was shut down but later was restarted and happened to get the same port number.

Even though the same server is listening at the same address as originally, binding must fail because a transient reference is valid only for the lifetime of its POA. Again, the client sends the request to the server after opening the connection. However, the POA name in the object key is guaranteed not to match any of the POA names used by the server. Even if the server code creates a transient POA with the same name as that of a previous transient POA, the ORB enforces uniqueness of the transient POA name by prefixing a UUID (or a similar pseudo-random identifier) to the name. The POA name mismatch results in the server sending an OBJECT_NOT_EXIST exception to the client, and binding fails, as it should.

In summary, binding of transient references relies on the actual host address and port number of the server. If the server is still running at that address and port number when the client invokes a request, binding succeeds. If the server is no longer running, the client-side run time raises a TRANSIENT exception. If another server instance is running at that address and port number, the server receiving the request returns an OBJECT_NOT_EXIST exception to the client because the POA name in the object key does not match any of the server's POA names.

14.3.2 Direct Binding of Persistent References

551

IT-SC book: Advanced CORBA® Programming with C++

An ORB has many different options for how to make object references persistent. The simplest mechanism relies on direct binding.

When a server creates a reference using a POA that has a PERSISTENT life span policy, the ORB run time creates a profile body for the IOR that contains the server's address and port number. However, because the reference uses a persistent POA, the ORB does not make its name unique by adding a UUID. Instead, it uses the POA name that was specified by the application when it created the POA.

Binding of the reference now proceeds exactly as with transient references. The client connects to the address and port number found in the reference and sends a request. Provided that the server is running at the correct address, the request is bound to the correct servant. Direct binding for persistent references relies on the following.

The server must always use the same name for the same POA when it creates the POA. The server must always use the same object ID for a particular CORBA object when it creates an IOR for that object.

The server must always start up on the same host and port number.

You can easily take care of the first two points by using the same POA name and object ID when you create a POA or an IOR. However, CORBA does not specify how to enforce the third point, so how you instruct a server to always start on the same host and port varies from ORB to ORB. Typically, the ORB allows you to pass a port number as a command-line argument to the server. The port number is made known to the server-side run time via ORB_init, so the run time can arrange for the server to connect to the specified port. Some ORBs also allow you to use a configuration utility to store the port number that a server should use.

Direct binding of persistent references is simple and efficient. Because an IOR directly contains the host and port number of the server, the client can open a connection directly to the server without incurring any additional overhead. However, direct binding of persistent references also has some drawbacks.

You cannot start the server on a different host without breaking references to persistent objects in the server held by clients. Every reference contains the host domain name or IP address; if the server is moved to a host having a different domain name or a host having a different IP address, clients using a reference created while the server was running on its previous host can no longer bind requests.

The server must listen for requests on a fixed port that must be assigned to the server once and cannot be changed thereafter without breaking references. This requirement in itself is not bad, but it causes administrative problems in large installations because manual administration of port numbers is cumber-some.

552