Guidelines for Use of the osagent

Resolution 

While the osagent imposes no hard limits on the numbers and types of objects that it can support, there are reasonable best practices that can be followed when incorporating the osagent into a larger overall architecture.

The osagent is designed to be a lightweight directory service with a flat simple namespace which can support a small number of well known objects within a local network.

Applications should use these well known objects to bootstrap to other needed distributed services and not rely on the osagent for all directory needs.

General guidelines

Server registrations should be limited to less than 100 object instances or POAs per ORB domain.

There are two ways in which a server may register an object with the osagent. One way is BY_INSTANCE, where each individual server object is registered. The second way is BY_POA, where only the POA on which the object is activated is registered with the osagent.

The second method, which is the Visibroker default for Visbroker 4.x and later, is more scaleable since the server process makes fewer registrations. In the BY_POA approach the osagent has no knowledge of the actual objects available in the POA which was registered, so the client ORB runtime must locate the object in two steps. First it must determine if there is a suitable POA, then it must contact that POA directly to determine if the object is registered there. A hidden consequence of this architecture is that it is up the application(s) to enforce a consistent global POA namespace. Duplicate POAs (for redundancy and replication) must contain identical object activations. Neither VisiBroker nor the CORBA specification enforce this restriction, it is the responsibility of the application developer/deployer. This form of registration is only available in Visbroker 4.x and later.

Regardless of the registration type (BY_INSTANCE or BY_POA), a well designed application should not register more than 100 objects or POAs.

The osagent keeps track of all clients (not just CORBA servers), so every client places a small load on the osagent. Within any 10 minute period the client population should generally not exceed 100 clients. Note that the gatekeeper counts as one client even though it is acting on behalf of many real clients.

Applications should use the osagent sparsely by binding to small set of well known objects at startup and then using those objects for further discovery.

The osagent communications are based on UDP. Although the message protocol built on top of UDP is reliable, UDP is often not reliable or allowed in wide area networks. Thus use of the osagent is not recommended over wide area networks.

The real default IP of the osagent host must be accessible to clients on a subnet that is not directly connected to the osagent host. The osagent cannot be configured for client access behind a NATed firewall.

The osagent configures itself at startup using the network information available at that time. It will not be able to detect new network interfaces that are added later, such as interfaces associated with a dial up connection. Thus the osagent is meant for use in static network configurations.

The Location Service

The Location Service is built upon the osagent technology. Therefore the location service is subject to the same guidelines described above.

Location Service triggers generate UDP traffic between the osagent and the trigger handlers registered by applications. Use of this feature should be limited to less that 10 objects, monitored by less than 10 processes.

Location Service triggers fire when the osagent determines that an object is available or down. There may be a delay of up to four minutes for a "down" trigger to fire. Thus this is not a realtime feature and should not be used for time critical applications.

ORB domains (osagent domains, osagent networks)

An ORB domain is a cooperating set of osagents which all use the same primary communication port. By default an ORB domain lives within a single subnet. An ORB domain can be configured to include osagents from more than one subnet by using the agentaddr file as explained elsewhere. Here are some guidelines for building ORB domains.

If these rules are violated the symptoms will be (1) startup order dependencies, and (2) inconsistent behavior from tools such as osfind when run from different machines.

Load Balancing/Fault Tolerance

The osagent implements load balancing using a simple round robin algorithm on a per osagent bases, not on an ORB domain basis. So if more than one osagent is in the ORB domain, and load balancing between server replicas is desired, then all such servers need to register with the same osagent.

The client side ORB runtime will cache accesses to the osagent within each client, so multiple binds to the same server object from the same client ORB process will not result in round robin behavior because the second and subsequent attempts use the cache rather than sending a new request to the osagent. This behavior can be changed using ORB properties.

When an osagent is terminated, all servers that were registered with that osagent will attempt to locate another osagent with which to register. This process is automatic, but it may take up to two minutes for the server to perform this function. During that two minute window the server will not be registered in the ORB domain and thus will not be available to new clients. This however does not affect ongoing IIOP communications between the server and clients that were previously bound.

Do not use the osagent for the following situations:

• The ORB domain must span a large number (> 5) of subnets. Maintaining the agentaddr files for a large ORB domain spread over a large number of subnets is difficult and brittle.
• The name space requires a large number (> 100) of well known objects.
• The number of applications (clients) that require the osagent consistently exceeds 100 in a 10 minute period.

In these situations, an alternative directory such as the Naming Service may be more appropriate.