This chapter is from the book
This chapter is from the book
This chapter is from the book
Names
Two types of name format are specified in the CORBA Interoperable Naming Service:
Stringified name format—Stringified names have an intuitive format that is easy to read and pass from place to place.
Raw name format—Raw names are defined in terms of IDL complex types and can be used only within a CORBA program.
The following sections describe both of these name formats in detail.
Stringified Names
Consider the fully qualified name of the object StockExchange. Its structure is shown in Figure 3.
){kind=link}
Figure 3 The structure of a sample stringified name.
The name is divided into three components by the component separator character / (forward slash). The individual components consist of an id field and a kind field, joined by the kind separator character . (dot). When the kind field is omitted, as in the third component, it is implicitly empty.
Each component of a name maps to an entity in the naming service (either a naming context or an object reference). For example, the components shown imply the existence of three context bindings and one object binding, as given in Table 1.
Table 1 Components of a Stringified Name
|
Stringified Name |
Binds To |
|
empty string |
Initial naming context |
|
London.region |
Naming context |
|
London.region/Main.failover |
Naming context |
|
London.region/Main.failover/StockExchange |
Object reference |
The initial naming context is always present and serves as the entry point to the naming service.
The kind field is intended to describe how a name component is used. For example, we have used the .region suffix to indicate that a naming context refers to a particular geographical location. This resembles the way in which suffixes are used by a file system. For example client.cxx, client.obj, and client.exe would represent three related but distinct files under Windows NT.
The naming service specification does not specify how the kind field should be used, nor does it reserve any specific values for it. The only specific direction given is that the kind field is part of the unique identity of a name. That is, the names London.region and London are distinct and refer to two different entities in the naming service.
Escape Character
An escape character \ (backslash) is reserved for use in stringified names. The escape sequences are defined in Table 2.
Table 2 Escape Sequences in Stringified Names
|
Escape Sequence |
Value | >
|
\/ |
Literal / |
|
\. |
Literal . |
|
\\ |
Literal \ |
Other escape sequences (that is, \ followed by any other character) are reserved by the OMG for future use. The existing escape sequences allow you to embed any of the characters /, ., and \ in an id field or a kind field. For example, the name component
"www\.omg\.org\/index\.html.hierarchy\\of\\kinds"
is interpreted as
id = "http://www.omg.org/index.html", kind = "hierarchy\of\kinds"
when parsed by the naming service. This allows the id and kind fields to be arbitrary strings.
Special Cases
Spaces are legal in both id fields and kind fields.
There are some special constructions for representing empty fields.
An empty kind field is indicated by omitting the kind field and kind separator . (dot), as in London/Main. It is not correct to append a trailing . character to either of the name components. Thus, London./Main. is illegal.
An empty id field is indicated by starting the name component directly with a kind separator . (dot), such as .region/.failover. However, some implementations of the naming service might forbid the use of empty id fields.
An empty id field and an empty kind field are denoted by a single . (dot). For example, a sequence of three empty name components ././. is the only legal representation of a name component with empty id and kind fields. Some implementations of the naming service might forbid the use of empty name components.
Raw Names - CosNaming::Name
Stringified names are a convenient way of representing names in a readable format, but that is not how they are represented internally by the naming service. The raw format of a name is defined by the following IDL extract:
//IDL
#pragma prefix "omg.org"
module CosNaming {
typedef string Istring;
struct NameComponent {
Istring id;
Istring kind;
};
typedef sequence<NameComponent> Name;
...
};
This defines the data type CosNaming::Name, which is the canonical form of a name. It consists of a sequence of NameComponents. Each NameComponent is broken down into an id field and a kind field.
The definition of Istring is a historical artifact and is simply an alias for the type string. Originally, it was defined as a placeholder for an internationalized string (subsequently introduced into IDL as the type wstring). The definition of Istring has not been changed because of backward-compatibility issues.
A raw name is basically a sequence of structs and can be manipulated using the rules for IDL compound types. Consider, for example, how to represent the stringified name London.region/Backup.failover in raw form:
//C++
CosNaming::Name exName(2); //maximum = 2
//length = 0
exName.length(2);
exName[(CORBA::ULong) 0].id = CORBA::string_dup("London");
exName[(CORBA::ULong) 0].kind = CORBA::string_dup("region");
exName[(CORBA::ULong) 1].id = CORBA::string_dup("Backup");
exName[(CORBA::ULong) 1].kind = CORBA::string_dup("failover");
//Java
org.omg.CosNaming.NameComponent exName[]
= new org.omg.CosNaming.NameComponent[2];
exName[0] = new org.omg.CosNaming.NameComponent();
exName[0].id = "London";
exName[0].kind = "region";
exName[1] = new org.omg.CosNaming.NameComponent();
exName[1].id = "Backup";
exName[1].kind = "failover";