|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 5
The INS provides the following features:
Those of you who have used the CORBA Naming Service know that creating the desired tree structure and associated bindings can prove tedious. For example, here is some sample code:
// Create the Departments context
NameComponent nc = new NameComponent("Departments", "");
NameComponent[] name = {nc};
NamingContext ctxDepartments = ctxRoot.bind_new_context(name);
// Create a name binding within the Departments context
nc = new NameComponent("HR", "");
name[0] = nc;
ctxDepartments.rebind(name, objRef);
How many of you have created your own libraries to enable code such as the following:
String binding = "Departments/HR"; namingFacade.rebind(binding,objRef);
The INS now gives you a standard way of achieving the same functionality, as shown below:
ctxRoot.rebind(ctxRoot.to_name("Deptartments/HR"));
The INS defines a new interface called NamingContextExt that features several new methods to assist converting between the tedious names that methods such as rebind() require and the friendlier stringified names. These methods are:
to_string(): converts a NameComponent array into a stringified name
to_name(): converts a stringified name into a NameComponent array
resolve_str(): resolves a stringified name into an object reference
Obtaining a root NamingContextExt is no different from obtaining a root NamingContext, as shown below:
NamingContextExt ctxRoot =
NamingContextExtHelper.narrow(orb.resolve_initial_references("NameService"));
So far, the only standard way to obtain a readable IOR is to use the object_to_string() method on the ORB instance to obtain a long sequence of alphanumeric characters. Although readable, this is no way to remember
an object reference. Think about network addresses: remembering each address as www.DoesNotExist.com proves much easier than
trying to remember each as 204.224.196.10. The INS comes to the rescue with two human-readable URL formats for CORBA object
references:
corbaloc: The corbaloc: format proves useful for CORBA client programs and typically resolves the reference using the GIOP (General Inter-ORB Protocol)
LocateRequest or Request messages. For example, a corbaloc: object reference might look like this: corbaloc:iiop:1.2@XYZ.com:1050/TraderService. This example shows how to get an object reference for TraderService from host XYZ.com on port 1050.
corbaname: The corbaname: format provides a mechanism for a client to bootstrap directly and is typically used to resolve the stringified name from
the root naming context. For example, a corbaname: object reference might look like this: corbaname::ABC.com:1050#Departments/HR, where ABC.com is the host and 1050 is the port. The reference portion up to the hash mark (corbaname::ABC.com:1050) is the URL that returns the root naming context. The URL's remainder (Departments/HR) is the path to the object within the root naming context.
We can modify Part 3's bank program to use these URL formats. Here's what the modified program looks like: