Previous | Table of Contents | Next |
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
Scheme |
Description |
Status |
|||
IOR: | Standard stringified IOR format | Required | |||
corbaloc: | Simple object reference. rir: must be supported. | Required | |||
corbaname: | CosName URL | Required | |||
file:// | Specifies a file containing a URL/IOR | Optional | |||
ftp:// | Specifies a file containing a URL/IOR that is accessible via ftp protocol. | Optional | |||
http:// | Specifies an HTTP URL that returns an object URL/IOR. | Optional |