13.6.9 Stringified Object References

   Object references can be “stringified? (turned into an external string form) by the ORB::object_to_string operation, and then “destringified? (turned back into a programming environment’s object reference representation) using the ORB::string_to_object operation.

   There can be a variety of reasons why being able to parse this string form might not help make an invocation on the original object reference:

• Identifiers embedded in the string form can belong to a different domain than the ORB attempting to destringify the object reference.

• The ORBs in question might not share a network protocol, or be connected.

• Security constraints may be placed on object reference destringification.

   Nonetheless, there is utility in having a defined way for ORBs to generate and parse stringified IORs, so that in some cases an object reference stringified by one ORB could be destringified by another.

   To allow a stringified object reference to be internalized by what may be a different ORB, a stringified IOR representation is specified. This representation instead establishes that ORBs could parse stringified object references using that format. This helps address the problem of bootstrapping, allowing programs to obtain and use object references, even from different ORBs.

   The following is the representation of the stringified (externalized) IOR:

(1) <oref> ::= <prefix> <hex_Octets>

(2) <prefix> ::= <i><o><r>“:?

(3) <hex_Octets> ::= <hex_Octet> {<hex_Octet>}*

(4) <hex_Octet> ::= <hexDigit> <hexDigit>

(5) <hexDigit> ::= <digit> | <a> | <b> | <c> | <d> | <e> | <f>

(6) <digit> ::= “0? | “1? | “2? | “3? | “4? | “5? | | “6?| “7? | “8? |“9?

(7) <a> ::= “a? | “A?

(8) <b> ::= “b? | “B?

(9) <c> ::= “c? | “C?

(10) <d> ::= “d? | “D?

(11) <e> ::= “e? | “E?

(12) <f> ::= “f? | “F?

(13) <i> :: = “i? | “I?

(14) <o> :: = “o? | “O?

(15) <r> :: = “r? | “R?

   Note – The case for characters in a stringified IOR is not significant.

   The hexadecimal strings are generated by first turning an object reference into an IOR, and then encapsulating the IOR using the encoding rules of CDR, as specified in GIOP

   1.0. (See Section 15.3, “CDR Transfer Syntax? on page 15-4 for more information.) The content of the encapsulated IOR is then turned into hexadecimal digit pairs, starting with the first octet in the encapsulation and going until the end. The high four bits of each octet are encoded as a hexadecimal digit, then the low four bits.

   13.6.10 Object URLs

   To address the problem of bootstrapping and allow for more convenient exchange of human-readable object references, ORB::string_to_object allows URLs in the corbaloc and corbaname formats to be converted into object references.

   If conversion fails, string_to_object raises a BAD_PARAM exception with one of following standard minor codes, as appropriate:

• 7 - string_to_object conversion failed due to bad scheme name

• 8 - string_to_object conversion failed due to bad address

• 9 - string_to_object conversion failed due to bad bad schema specific part

• 10 - string_to_object conversion failed due to non specific reason

   13.6.10.1 corbaloc URL

   The corbaloc URL scheme provides stringified object references that are more easily manipulated by users than IOR URLs. Currently, corbaloc URLs denote objects that can be contacted by IIOP or resolve_initial_references. Other transport protocols can be explicitly specified when they become available. Examples of IIOP and resolve_initial_references(rir:) based corbaloc URLs are:

   corbaloc::555xyz.com/Prod/TradingService corbaloc:iiop:1.1@555xyz.com/Prod/TradingService corbaloc::555xyz.com,:556xyz.com:80/Dev/NameService corbaloc:rir:/TradingService corbaloc:rir:/NameService

   A corbaloc URL contains one or more:

• protocol identifiers

• protocol specific components such as address and protocol version information

   When the rir protocol is used, no other protocols are allowed.

   After the addressing information, a corbaloc URL ends with a single object key.

   The full syntax is:

   <corbaloc> = “corbaloc:?<obj_addr_list>[“/?<key_string>]<obj_addr_list> = [<obj_addr> “,?]* <obj_addr><obj_addr> = <prot_addr> | <future_prot_addr><prot_addr> = <rir_prot_addr> | <iiop_prot_addr>

   <rir_prot_addr> = <rir_prot_token>?:?<rir_prot_token> = “rir?

   <iiop_prot_addr> = <iiop_id><iiop_addr><iiop_id> = “:? | <iiop_prot_token>?:?<iiop_prot_token> = “iiop?<iiop_addr> = [<version> <host> [“:? <port>]]<host> = DNS_style_Host_Name | ip_address

   <version> = <major> “.? <minor> “@? | empty_string <port> = number <major> = number <minor> = number

   <future_prot_addr> = <future_prot_id><future_prot_addr><future_prot_id> = <future_prot_token>?:?<future_prot_token> = possible examples: “atm? | “dce?<future_prot_addr> = protocol specific address

   <key_string> = <string> | empty_string

   Where:

   obj_addr_list: comma-separated list of protocol id, version, and address information. This list is used in an implementation-defined manner to address the object An object may be contacted by any of the addresses and protocols.

   Note – If the rir protocol is used, no other protocols are allowed.

   obj_addr: A protocol identifier, version tag, and a protocol specific address. The comma ‘,’ and ‘/’ characters are specifically prohibited in this component of the URL.

   rir_prot_addr: resolve_initial_references protocol identifier. This protocol does not have a version tag or address. See Section 13.6.10.2, “corbaloc:rir URL?.

   iiop_prot_addr: iiop protocol identifier, version tag, and address containing a DNS- style host name or IP address. See Section 13.6.10.3, “corbaloc:iiop URL?? for the iiop specific definitions.

   future_prot_addr: a placeholder for future corbaloc protocols.

   future_prot_id: token representing a protocol terminated with a “:?.

   future_prot_token: token representing a protocol. Currently only “iiop? and “rir? are defined.

   future_prot_addr: a protocol specific address and possibly protocol version information. An example of this for iiop is “1.1@555xyz.com?.

   key_string: a stringified object key.

   The key_string corresponds to the octet sequence in the object_key member of a GIOP Request or LocateRequest header as defined in section 15.4 of CORBA 2.3. The key_string uses the escape conventions described in RFC 2396 to map away from octet values that cannot directly be part of a URL. US-ASCII alphanumeric characters are not escaped. Characters outside this range are escaped, except for the following:

   “;? | “/? | “:? | “??| “.? | “@? | “&? | “=? | “+? | “$? |

   “,? | “-? | “_? | “!? | “~? | “*? | “’? | “(“ | “)?

   The key_string is not NUL-terminated.

   13.6.10.2 corbaloc:rir URL

   The corbaloc:rir URL is defined to allow access to the ORB’s configured initial references through a URL.

   The protocol address syntax is:

   <rir_prot_addr> = <rir_prot_token>?:? <rir_prot_token> = “rir?

   Where:

   rir_prot_addr: resolve_initial_references protocol identifier. There is no version or address information when rir is used.

   rir_prot_token: The token “rir? identifies this protocol..

   For a corbaloc:rir URL, the <key_string> is used as the argument to resolve_initial_references. An empty <key_string> is interpreted as the default “NameService?.

   The rir protocol can not be used with any other protocol in a URL.

   13.6.10.3 corbaloc:iiop URL

   The corbaloc:iiop URL is defined for use in TCP/IP- and DNS-centric environments The full protocol address syntax is:

   <iiop_prot_addr> = <iiop_id><iiop_addr><iiop_id> = <iiop_default> | <iiop_prot_token>?:?<iiop_default> = “:?<iiop_prot_token> = “iiop?<iiop_addr> = [<version> <host> [“:? <port>]]<host> = DNS_style_Host_Name | ip_address<version> = <major> “.? <minor> “@? | empty_string<port> = number<major> = number<minor> = number

   Where:

   iiop_prot_addr: iiop protocol identifier, version tag, and address containing a DNS-style host name or IP address.

   iiop_id: tokens recognized to indicate an iiop protocol corbaloc.

   iiop_default: default token indicating iiop protocol, “:?.

   iiop_prot_token: iiop protocol token, “iiop?

   iiop_address: a single address

   host: DNS-style host name or IP address. If not present, the local host is assumed.

   version: a major and minor version number, separated by ‘.’ and followed by ‘@’. If the version is absent, 1.0 is assumed.

   ip_address: numeric IP address (dotted decimal notation)

   port: port number the agent is listening on (see below). Default is 2809.

   13.6.10.4 corbaloc Server Implementation

   The only requirements on an object advertised by a corbaloc URL are that there must be a software agent listening on the host and port specified by the URL. This agent must be capable of handling GIOP Request and LocateRequest messages targeted at the object key specified in the URL.

   A normal CORBA server meets these criteria. It is also possible to implement lightweight object location forwarding agents that respond to GIOP Request messages with Reply messages with a LOCATION_FORWARD status, and respond to GIOP LocateRequest messages with LocateReply messages.

   13.6.10.5 corbaname URL

   The corbaname URL scheme is described in the Naming Service specification. It extends the capabilities of the corbaloc scheme to allow URLs to denote entries in a Naming Service. Resolving corbaname URLs does not require a Naming Service implementation in the ORB core. Some examples are:

   corbaname::555objs.com#a/string/path/to/obj

   This URL specifies that at host 555objs.com, a object of type NamingContext (with an object key of NameService) can be found, or alternatively, that an agent is running at that location which will return a reference to a NamingContext. The (stringified) name a/string/path/to/obj is then used as the argument to a resolve operation on that NamingContext. The URL denotes the object reference that results from that lookup.

   corbaname:rir:#a/local/obj

   This URL specifies that the stringified name a/local/obj is to be resolved relative to the naming context returned by resolve_initial_references(“NameService?).

   13.6.10.6 Future corbaloc URL Protocols

   This specification only defines use of iiop with corbaloc. New protocols can be added to corbaloc as required. Each new protocol must implement the <future_prot_addr> component of the URL and define a described in Section 13.6.10.1, “corbaloc URL? on page 13-24.?

   A possible example of a future corbaloc URL that incorporates an ATM address is:

   corbaloc:iiop:xyz.com,atm:E.164:358.400.1234567/dev/test/objectX

   13.6.10.7 Future URL Schemes

   Several currently defined non-CORBA URL scheme names are reserved. Implementations may choose to provide these or other URL schemes to support additional ways of denoting objects with URLs.

    Table 13-1 lists the required and some optional formats.

   Table 13-1 URL formats