13
`
`const Componentld
`
`TAG_DCE_SEC_MECH = 103; II Security Service
`
`13.6.6.1
`
`TAG_ORB_TYPE Component
`
`it is often useful in the real world to be able to identify the particular kind of ORB an
`object reference is coming from, to work around problems with that particular ORB, or
`exploit shared efficiencies.
`
`The TAG_ORB_TYPE component has an associated value of type unsigned long,
`encoded as a CDR encapsulation, designating an ORB type 1D allocated by the OMG
`for the ORB type of the originating ORB. Anyone may register any ORB types by
`submitting a short (one-paragraph) description of the ORB type to the OMG, and will
`receive a new ORB type 1D in return. A list of ORB type descriptions and values will
`be made available on the OMG web server.
`
`The TAG_ORB_TYPE component can appear at most once in any IOR profile. For
`profiles supporting HOP l.l or greater, it is optionally present.
`
`13.6.6.2
`
`TAG_ALTERNA TE_1I0P_ADDRESS Component
`
`In cases where the same object key is used for more than one intemet location, the
`following standard IOR Component is defined for support in llOP version 1.2.
`
`The TAG_ALTERNATE_||0P__ADDRESS component has an associated value of
`WP?
`
`struct {
`string HostlD,
`unsigned short Port
`
`};
`
`encoded as a CDR encapsulation.
`
`Zero or more instances of the TAG_ALTERNATE_||OP_ADDRESS component type
`may be included in a version 1.2 TAG_|NTERNET_lOP Profile. Each of these
`alternative addresses may be used by the client orb, in addition to the host and port
`address expressed in the body of the Profile. in cases where one or more
`TAG_ALTERNATE__||OP_ADDRESS components are present in a
`TAG_|NTERNET_|OP Profile, no order of use is prescribed by Version 1.2 of llOP.
`
`13.6.6.3
`
`Other Components
`
`The following standard components are specified in various OMG specifications:
`
`' TAG_CODE__SETS - See Section l3.lO.2.4, “CodeSet Component of IOR Multi-
`Component Profile” on page 1342.
`
`° TAG_POLlClES - See CORBA Messaging - chapter 22.
`
`° TAG_SEC_NAME - See the Security Service specification, Mechanism Tags
`section.
`'
`
`l3-20
`
`Common Object Request Broker A rch ileclure (CORB/1), V2. 6
`
`December 200]
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 900 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 900 of 1442
`
`

`
`I3
`
`' TAG_ASSOClAT|ON_OPTlONS - See the Security Service specification, Tag
`Association Options section.
`
`° TAG_SSL_SEC_TRANS - See the Security Service specification, Mechanism
`Tags section.
`
`° TAG_GENER|C_SEC_MECH and all other tags with names in the form
`TAG_*_SEC_MECH - See the Security Service specification, Mechanism Tags
`section.
`
`° TAG_F|REWALL_SEC — See the Firewall specification (orbos/98-O5-04).
`
`' TAG_SCCP_CONTACT_|NFO - See the CORBA/1N lnterworking specification
`(telecom/98-10-03).
`
`° TAG_JAVA_CODEBASE - See the Java to IDL Language Mapping specification
`(formal/99-07-59), Codebase Transmission section.
`
`° TAG_TRANSACT|ON_POL|CY - See the Object Transaction Service specification
`(formal/00-06-28).
`
`° TAG_MESSAGE_ROUTERS - See CORBA Messaging (chapter 22).
`
`' TAG_OTS_POL|CY - See the Object Transaction Service specification
`(formal/00-06-28).
`
`' TAG_|NV_POL|CY - See the Object Transaction Service specification
`(formal/00-06-28).
`
`' TAG_|NET_SEC_TRANS - See the Security Service specification
`(forrnal/O0-O6-25).
`
`' TAG_COMPLETE_OBJECT_KEY (See Section 16.5.4, “Complete Object Key
`Component” on page 16-19).
`' TAG_ENDPO|NT_|D_POS|T|ON (See Section 16.5.5, “Endpoint 1D Position
`Component” on page 16-20).
`
`° TAG_LOCAT|ON_POL|CY (See Section 16.5.6, “Location Policy Component” on
`page 16-20).
`
`' TAG_DCE_STR|NG_B|ND|NG (See Section 16.5.1, “DCE-CIOP String Binding
`Component” on page 16-17).
`
`' TAG_DCE_B|ND|NG__NAME (See Section 16.5.2, “DCE-C101’ Binding Name
`Component” on page 16-18).
`
`' TAG_DCE_NO_P|PES (See Section 16.5.3, “DCE-C101’ No Pipes Component” on
`page 16-19).
`
`13.6.7 Profile and Component Composition in IORs
`
`The following rules augment the preceding discussion:
`
`1. Profiles must be independent, complete, and self-contained. Their use shall not
`depend on information contained in another profile.
`
`2. Any invocation uses information from exactly one profile.
`
`December 2001
`
`CORBA, v2.6: An Information Mndelfor Object References
`
`13-21
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 901 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 901 of 1442
`
`

`
`I3
`
`3. Information used to drive multiple inter-ORB protocols may coexist within a single
`profile, possibly with some information (e.g., components) shared between the
`protocols, as specified by the specific protocols.
`
`4. Unless otherwise specified in the definition of a particular profile, multiple profiles
`with the same profile tag may be included in an lOR.
`
`5. Unless otherwise specified in the definition of a particular component, multiple
`components with the same component tag may be part of a given profile within an
`10R.
`
`6. A TAG_MULT|PLE_COMPONENTS profile may hold components shared
`between multiple protocols. Multiple such profiles may exist in an 10R.
`
`7. The definition of each protocol using a TAG_MULTlPLE_COMPONENTS profile
`must specify which components it uses, and how it uses them.
`
`8. Profile and component definitions can be either public or private. Public definitions
`are those whose tag and data format is specified in OMG documents. For private
`definitions, only the tag is registered with OMG.
`
`9. Public component definitions shall state whether or not they are intended for use by
`protocols other than the one(s) for which they were originally defined, and
`dependencies on other components.
`
`The OMG is responsible for allocating and registering protocol and component tags.
`Neither allocation nor registration indicates any “standard” status, only that the tag will
`not be confused with other tags. Requests -to allocate tags should be sent to
`tag_request@omg.org.
`
`_13. 6.8 IOR Creation and Scope
`
`lORs are created from object references when required to cross some kind of
`referencing domain boundary. ORBS will implement object references in whatever
`form they find appropriate, including possibly using the lOR,structure. Bridges will
`normally use lORs to mediate transfers where that standard is appropriate.
`
`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
`0RB::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:
`
`'
`
`ldentifiers 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.
`
`13-22
`
`Common Object Request Broker Arch itecrure (CORBA), v2. 6
`
`December 2001
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 902 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 902 of 1442
`
`

`
`13
`
`
`Nonetheless, there is utility in having a defined way for ORBS to generate and parse
`stringified lORs, 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 10R 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 (extemalized) IOR:
`
`<oref>
`
`<prefix>
`<hex_Octets>
`
`<hex_Octet>
`
`<prefix> <hex_Octets>
`<i><o><r>“:”
`
`<hex_Octet> {<hex_Octet>}*
`<hexDigit> <hexDigit>
`
`<hexDigit>
`
`= <digit>|<a> | <b> | <c>|<d>|<e> | <f>
`
`<digit> . = "D" | "1" | “2" | "3" | "4" | "5" |
`|
`"6" | "7" | "8" | “9"
`= "3"
`"A"
`
`<a>
`
`= "b" 1 "3"
`<b>
`<c> "= “c" I “C”
`
`<d> ..= uvdu I uDn
`= "e" “E"
`
`<f> "= “f" | “F"
`<i> .. ___ uin I III”
`
`<o> :: = "o" | “O”
`
`<r> :: = "r” | "R"
`
`i
`
`(1)
`(2)
`
`(3)
`(4)
`
`(5)
`(5)
`
`(7)
`
`(3)
`
`(9)
`(10)
`
`(11)
`
`(12)
`(13)
`
`(14)
`
`(15)
`
`Note - The case for characters in a stringified lOR is not significant.
`
`The hexadecimal strings are generated by first turning an object reference into an 10R,
`and then encapsulating the lOR 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 lOR 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, 0RB::string_to_object allows URLs in the
`corbaloc and corbaname formats to be converted into object references.
`
`lf 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
`
`December 2001
`
`CORBA, v2. 6: An Information Modelfnr Object References
`
`13-23
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 903 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 903 of 1442
`
`

`
`I3
`
`° 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 HOP or reso|ve_initia|_references. Other transport
`protocols can be explicitly specified when they become available. Examples of 1101’
`and reso|ve_initiaI_references
`(rirz) based corbaloc URLs are:
`
`corbaloc::555xyz.com/ProdI'l'radingservice
`corba|oc:iiop:1.1 @555xyz.comIProdITradingservice
`corbaloc::555xyz.com,:556xyz.com:80lDevlNameService
`corbaloc:rir:/Tradingservice
`corbaloczrirz/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:
`
`<corba|oc>
`<obj_addr_|ist>
`<obj_addr>
`<prot_addr>
`
`= “corba|oc:"<obj_addr_list>["l"<key_string>]
`= [<obj_addr> ",”]* <obj_addr>
`= <prot_addr> | <future_prot_addr>
`= <rir_prot_addr> | <iiop_prot_addr>
`
`<rir_prot_addr>
`<rir_prot_token>
`
`= <rir_prot_token>":"
`= “rir"
`
`<iiop_prot_addr>
`<iiop_id>
`<iiop_prot_token>
`' <iiop_addr>
`<host>
`<version>
`<port>
`<major>
`<minor>
`
`= <iiop_id><iiop_addr>
`= “:" | <iiop_prot_token>":"
`= "iiop"
`= [<version> <host> [“:" <port>]]
`= DNS_style_Host_Name | ip_address
`= <major> ".” <minor> "@" | empty_string
`= number
`= number
`= number
`
`=<future_prot_id><future_prot__addr>
`<future_prot_addr>
`= <future_prot_token>":"
`<future_prot_id>
`<future__prot_token> = possible examples: “atm" | "dce"
`<future_prot_addr>
`= protocol specific address
`
`13-24
`
`Cnmmnn Object Request Broker/lrchitecmre (CORBA), v2.6
`
`December-2001
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 904 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 904 of 1442
`
`

`
`13
`
`<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, versiontag, and a protocol specific address. The
`comma ‘,’ and ‘/’ characters are specifically prohibited in this component of the URL.
`
`rir_prot_addr: reso|ve_initia|_references protocol identifier. This protocol does
`not have a version tag or address. See Section l3.6.10.2, “corbaloc : rir URL”.
`
`iiop_prot_addr: iiop protocol identifier, version tag, and address containing a DN S-
`style host name or IP address. See Section l3.6.lO.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
`
`L6,!)
`.
`
`.
`
`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.
`
`u,” I ££@” 1 u&” I “:1: | 54+”
`
`' “$17
`
`|
`
`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-ASCll alphanumeric
`characters are not escaped. Characters outside this range are escaped, except for the
`following:
`1
`“_15 |
`“/17 l 4:,” | L59”
`,
`_
`.
`u n | 4: n | u n I up: |
`
`“~33 | u*n | uns R “(H ‘ Ar)”
`
`The key_string is not NUL-terminated.
`
`13.6.10.2
`
`c0rbaloc.'rir URL
`
`The corbaloczrir 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>":"
`= llriril
`
`December 200]
`
`CORBA. V2.6: An Information Modelfnr Object References
`
`I3-25
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 905 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 905 of 1442
`
`

`
`I3
`
`Where:
`
`rir_prot_addr: reso|ve__initia|_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 corbaloczrir URL, the <key_string> is used as the argument to
`reso|ve_initia|_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
`
`corbaZoc.'z'iop URL
`
`The corbaloc:iiop URL is defined for use in TCP/lP- and DNS-centric environments
`The full protocol address syntax is:
`
`<iiop_prot_addr>
`<iiop_id>
`<iiop_default>
`<iiop_prot_token>
`<iiop_addr>
`<host>
`<version>
`<port> _
`<major>
`<minor>
`
`= <iiop_id><iiop_addr>
`= <iiop_defau|t> | <iiop_prot_token>":"
`= "1"
`= "iiop”
`= [<version> <host> [":” <port>]]
`= DNS_sty|e_Host_Name | ip_address
`= <major> ".” <minor> “@" | empty_string
`= number
`= number
`= number
`
`Where:
`
`iiop_prot_addr: iiop protocol identifier, version tag, and address containing a DNS-
`style host name or lP address.
`
`iiop_id: tokens recognized to indicate an iiop protocol corbaloc.
`
`iiop_default: default token indicating iiop protocol, “:".
`
`iiop_prot_tokcn: iiop protocol token, “iiop”
`
`iiop_addrcss: a single address
`
`host: DN S-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-26
`
`Common Object Request Broker A rch itecture (CORBA), v2. 6
`
`December 2001
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 906 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 906 of 1442
`
`

`
`13
`
`13.6104
`
`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 LOCATlON_FORWARD status, and respond
`to GIOP LocateRequest messages with LocateRep|y messages.
`
`13.6.10.5
`
`corbaname URL
`
`The corbaname URL scheme is described in the Naming Service specification. lt
`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/stringlpathltolobj
`
`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/tolobj is then used as the argument to a resolve
`operation on that Namingcont ext. The URL denotes the object reference that
`results from that lookup.
`
`corbaname:rir:#aI|ocal/obj
`
`is to be resolved relative to
`This URL specifies that the stringified name a/local/obj
`the naming context returned by resoIve_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 l3.6.l0.l, “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.1 64:358.400.1234567IdevItestIobjectX
`
`13.6.10.7
`
`Future URL Schemes
`
`Several currently defined non-CORBA URL scheme names are reserved.
`lmplementations may choose to provide these or other URL schemes to support
`additional ways of denoting objects with URLs.
`
`December 2001
`
`CORBA, v2. 6: An Information Modelfor Object References
`
`13-27
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 907 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 907 of 1442
`
`

`
`13
`
`Table 13-1 lists the required and some optional formats.
`
`Table 13-1 URL formats
`
`%
`Description
`
`file://
`
`Standard stringified IOR format
`
`Simple object reference. rir: must be supported.
`CosNarne URL
`
`Specifies a file containing a URL/lOR
`
`Specifies a file containing a URL/lOR that is
`accessible via ftp protocol.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Specifies an HTTP URL that returns an object
`URL/IOR.
`
`
`13.7 Service Context
`
`Emerging specifications for Object Services occasionally require service-specific
`context information to be passed implicitly with requests and replies. The
`Interoperability specifications define a mechanism for identifying and passing this
`service-specific context information as “hidden" parameters. The specification makes
`the following assumptions:
`
`° Object Service specifications that need additional context passed will completely
`specify that context as an OMG IDL data type.
`
`' ORB APls will be provided that will allow services to supply and consume context
`information at appropriate points in the process of sending and receiving requests
`and replies.
`
`°
`
`it is an ORB’s responsibility to determine when to send service-specific context
`information, and what to do with such information in incoming messages. It may be
`possible, for example, for a server receiving a request to be unable to de-
`encapsulate and use a certain element of service-specific context, but nevertheless
`still be able to successfully reply to the message.
`
`As shown in the following OMG lDL specification, the IOP module provides the
`mechanism for passing Object Service—specific information. It does not describe any
`service-specific information. it only describes a mechanism for transmitting it in the
`most general way possible. The mechanism is currently used by the DCE ESIOP and
`could also be used by the Internet lnter-ORB protocol (llOP) General lnter_ORB
`Protocol (GIOP).
`
`Each Object Service requiring implicit service-specific context to be passed through
`GIOP will be allocated a unique service context ID value by OMG. Service context ID
`values are of type unsigned long. Object service specifications are responsible for
`describing their context information as single OMG IDL data types, one data type
`associated with each service context 1D.
`
`The marshaling of Object Service data is described by the following OMG IDL:
`
`13-28
`
`Common Object Request Broker Architecture (CORBA), v2. 6
`
`December 2001
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 908 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 908 of 1442
`
`

`
`13
`
`module |OP{
`
`/I IDL
`
`typedef unsigned long
`
`Serviceld;
`
`struct ServiceContext{
`Serviceld
`context_id;
`sequence <octet> context_data;
`
`};
`typedef sequence <ServiceContext>ServiceContextList;
`
`};
`
`The context data for a particular service will be encoded as specified for its service-
`specific OMG IDL definition, and that encoded representation will be encapsulated in
`the context_data member of lOP::ServiceContext. (See Section 15.3.3,
`“Encapsulation” on page 15-14). The context_id member contains the service ID
`value identifying the service and data format. Context data is encapsulated in octet
`sequences to pem1itORBs to handle context data without unmarshaling, and to handle
`unknown context data types.
`
`During request and reply marshaling, ORBs will collect all service context data
`associated with the Request or Reply in a ServiceContextList, and include it in the
`generated messages. No ordering is specified for service context data within the list.
`The list is placed at the beginning of those messages to support security policies that
`may need to apply to the majority of the data in a request (including the message
`headers).
`
`Each Object Service requiring implicit service—specific context to be passed through
`GlOP will be allocated a unique service context ID value by the OMG. Service context
`lD values are of type unsigned long. Object service specifications are responsible for
`describing their context information as single OMG lDL data types, one data type
`associated with each service context ID.
`
`The high-order 20 bits of service-context ID contain a 20-bit vendor service context
`codeset lD (VSCID); the low-order 12 bits contain the rest of the service context ID. A
`vendor (or group of vendors) who wish to define a specific set of service context lDs
`should obtain a unique VSCID from the OMG, and then define a specific set of service
`context lDs using the VSCID for the high—order bits.
`
`The VSCID of zero is reserved for use for OMG-defined standard service context lDs
`
`(i.e., service context lDs in the range O-4095 are reserved as OMG standard service
`contexts).
`
`13. 7.1 Standard Service Contexts
`
`II IDL
`module |OP{
`const Serviceld
`const Serviceld
`const Serviceld
`const Serviceld
`const Serviceld
`const Serviceld
`
`Transactionservice = 0;
`Codesets = 1;
`ChainBypassCheck = 2;
`Chainfiypasslnfo = 3;
`LogicalThreadld = 4;
`B|_D|R_||0P = 5;
`
`December 200]
`
`CORBA, v2.6: Service Context
`
`13-29
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 909 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 909 of 1442
`
`

`
`13
`
`const Serviceld
`const Serviceld
`const Serviceld
`const Serviceld
`const Serviceld
`const Serviceld
`const Serviceld
`
`};
`
`SendingContextRunTime = 6;
`|NVOCATlON_POL|ClES = 7;
`FORWARDED__|DENT|TY = 8;
`UnknownExceptionlnfo = 9;
`RTCorbaPriority = 10;
`RTCorbaPriorityRange = 11;
`ExceptionDetailMessage = 14;
`
`The standard Servicelds currently defined are:
`
`° Transactionservice identifies a CDR encapsulation of the
`CosTransactions::PropogationContext defined in the Object Transaction
`Service specification (formal/00-06-28).
`
`° CodeSets identifies a CDR encapsulation of the
`CONV_FRAME::CodeSetContext defined in Section l3.l0.2.5, “GIOP Code Set
`Service Context” on page 13-43.
`
`° DCOM-CORBA lnterworking uses three service contexts as defined in "DCOM-
`CORBA lnterworking" in the “Interoperability with non-CORBA Systems"chapter.
`They are:
`
`- ChainBypassCheck, which carries a CDR encapsulation of the struct
`CosBridging::ChainBypassCheck. This is carried only in a Request
`message as described in Section 20.9.1, “CORBA Chain Bypass” on page 20-19.
`- ChainBypass|nfo, which carries a CDR encapsulation of the struct
`CosBridging::ChainBypasslnfo. This is carried only in a Reply message as
`described in Section 20.9.1, “CORBA Chain Bypass” on page 20-19.
`
`- Logica|Threadld, which carries a CDR encapsulation of the struct
`CosBridging::LogicalThreadld as described in Section 20.10, “Thread
`ldentification” on page 20-21.
`
`' Bl_D|R_llOP identifies a CDR encapsulation of the
`IIOP::BiDirl|0PServiceContext defined in Section 15.8, “Bi-Directional GIOP”
`on page 15-55.
`
`° SendingContextRunTime identifies a CDR encapsulation of the IOR of the
`SendingContext::RunTime object (see Section 5.6, “Access to the Sending
`Context Run Time” on page 5-18).
`
`° For information on |NVOCATl0N_POLlClES refer to CORBA Messaging
`
`(chapter 22).
`
`' For information on FORWARDED_|DENT|TY refer to the Firewall specification
`(orbos/98-05-O4).
`
`° UnknownExceptionlnfo identifies a CDR encapsulation of a maishaled instance
`of a java.|ang.throwab|e or one of its subclasses as described in Java to lDL
`Language Mapping, “Mapping of Unknownfixceptionlnfo Service Context,"
`section.
`
`' For information on RTCorbaPriority refer to the Real-time CORBA (chapter 24).
`
`13 -3 0
`
`Common Object Request Broker Architecture (CORB/1). v2. 6
`
`December 200]
`
`|PR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 910 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 910 of 1442
`
`

`
`13
`
`' For information on RTCorbaPriorityRange refer to the Real-time CORBA
`(chapter 24).
`
`° ExceptionDetai|Message identifies a CDR encapsulation of a wstring, encoded
`using GIOP l.2 with a TCS-W of UTF-16. This service context may be sent on
`Reply messages with a reply_status of SYSTEM_EXCEPT|ON or
`USER_EXCEPT|ON. The usage of this service context is defined by language
`mappings.
`
`13.7.2 Service Context Processing Rules
`
`Service context lDs are associated with a specific version of GIOP, but will always be
`allocated in the OMG service context range. This allows any ORB to recognize when
`it is receiving a standard service context, even if it has been defined in a version of
`GIOP that it does not support.
`
`The following are the rules for processing a received service context:
`
`' The service context is in the OMG defined range:
`
`0 If it is valid for the supported GIOP version, then it must be processed correctly
`according to the rules associated with it for that GIOP version level.
`- lf it is not valid for the GIOP version, then it may be ignored by the receiving
`ORB, however it must be passed on through a bridge and must be made available
`to interceptors. No exception shall be raised.
`
`‘ The service context is not in the OMG-defined range:
`
`- The receiving ORB may choose to ignore it, or process it if it “understands” it,
`however the service context must be passed on through a bridge and must made
`available to interceptors.
`
`13.8 Coder/Decoder Interfaces
`
`The formats of lOR components and service context data used by ORB services are
`often defined as CDR encapsulations encoding instances of IDL defined data types.
`The Codec provides a mechanism to transfer these components between their IDL
`data types and their CDR encapsulation representations.
`
`A Codec is obtained from the CodecFactory. The CodecFactory_ is obtained
`through a call to ORB::resolve_initiai_references ("CodecFactory").
`
`13.8.1 Codec Interface
`
`module IOP {
`local interface Codec{
`exception Inva|idTypeForEncoding O;
`exception FormatMismatch {};
`exception TypeMismatch {};
`
`CORBA::OctetSeq encode (in any data)
`
`Decembfif 2001
`
`CORBA. V2.6: Coder/Decoder Interfaces
`
`13-3]
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 911 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 911 of 1442
`
`

`
`13
`
`raises (InvalidTypeForEncoding);
`any decode (in CORBA::OctetSeq data)
`raises (FormatMismatch);
`CORBA::OctetSeq encode_va|ue (in any data)
`raises (InvalidTypeForEncoding);
`any decode_value (
`in CORBA::OctetSeq data,
`in CORBA::TypeCode tc)
`raises (FormatMismatch, TypeMismatch);
`
`};
`
`}:
`
`13.8.1.1
`
`Exceptions
`
`InvaIt'dTypeForEncoding
`
`This exception is raised by encode or encode_va|ue when the type is invalid for the
`encoding. For example, this exception is raised if the encoding is
`ENCOD|NG_CDR_ENCAPS version 1.0 and a type that does not exist in that
`version, such as wstring, is passed to the operation.
`
`FormatMismatch
`
`This exception is raised by decode or decode_value when the data in the octet
`sequence cannot be decoded into an any.
`
`TypeMismatch
`
`This exception is raised by decode_value when the given TypeCode does not match
`the given octet sequence.
`
`13.8.1.2
`
`Operations
`
`encode
`
`Convert the given any into an octet sequence based on the encoding format effective
`for this Codes.
`
`This operation may raise |nva|idTypeForEncoding.
`
`Parameter
`
`data
`
`Return Value
`
`The data, in the form of an any, to be encoded into an octet
`sequence.
`
`An octet sequence containing the encoded any. This octet
`sequence contains both the Typecode and the data of the type.
`
`13-32
`
`Common Object Request Broker A rchitecture (CORBA). v2. 6
`
`December 2001
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 912 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 912 of 1442
`
`

`
`13
`
`decode
`
`Decode the given octet sequence into an any based on the encoding format etfective
`for this Codec.
`‘
`
`This operation raises FormatMismatch if the octet sequence carmot be decoded into
`an any.
`
`Parameter
`
`data
`
`Return Value
`
`encode_vaIue
`
`The data, in the form of an octet sequence, to be decoded into an
`any.
`
`An any containing the data from the decoded octet sequence.
`
`Convert the given any into an octet sequence based on the encoding format effective
`for this Codec. Only the data from the any is encoded, not the Typecode.
`
`This operation may raise |nva|idTypeForEncoding.
`
`Parameter
`
`data
`
`Return Value
`
`decode_value
`
`The data, in the form of an any, to be encoded into an octet
`sequence.
`
`An octet sequence containing the data from the encoded any.
`
`Decode the given octet sequence into an any based on the given Typecode and the
`encoding format effective for this Codec.
`
`This operation raises FormatMismatch if the octet sequence‘ cannot be decoded into
`an any.
`
`Parameter
`
`data
`
`tc
`
`Return Value
`
`The data, in the form of an octet sequence, to be decoded into an
`any.
`
`'
`
`The TypeCode to be used to decode the data.
`
`An any containing the data from the decoded octet sequence.
`
`13.8.2 Codec Factory
`
`module IOP (
`typedef short EncodingFormat;
`const EncodingFormat ENCODING_CDR_ENCAPS = 0;
`
`Dficembfif 2001
`
`CORBA. v2. 6: Coder/Decoder Interfaces
`
`13-33
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 913 of 1442
`
`IPR2016-00726 -ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR,
`Ex. 1102, p. 913 of 1442
`
`

`
`13
`
`struct Encoding {
`EncodingFormat format;
`octet major_version;
`octet minor_version;
`
`};
`
`local "interface CodecFactory {
`exception UnknownEncoding {);
`Codec create_codec (in Encoding enc)
`raises (UnknownEncoding);
`
`};
`
`13.8.2.1 Encoding Structure
`
`The Encoding structure defines the encoding format of a Codec. It details the
`encoding format, such as CDR Encapsulation encoding, and the major and minor
`versions of that format.
`
`The encodings which shall be supported are:
`
`' ENCOD|NG_CDR_ENCAPS, version 1.0;
`
`° ENCODlNG_CDR_ENCAPS, version 1.1;
`
`' ENCOD|NG__CDR_ENCAPS, version 1.2;
`
`' ENCOD|NG_CDR_ENCAPS for all future versions of GIOP as they arise.
`
`Vendors are free to support additional encodings.
`
`13.8.2.2 C0decFact0ry Interface
`
`create_codec
`
`Create a Codec of the given encoding.
`
`This operation raises UnknownEncoding if this factory cannot create a Codec of
`the given encoding.
`
`Parameter
`
`enc
`
`The Encoding for which to create a Codec.
`
`Return Value
`
`A Codec obtained with the given encoding.
`
`13-34
`
`Common Object Request Broker/irchitecture (CORBA), V2.6
`
`December