src/share/classes/org/omg/PortableInterceptor/IOP.idl

Wed, 26 Feb 2014 14:43:56 -0800

author
katleman
date
Wed, 26 Feb 2014 14:43:56 -0800
changeset 589
abe5b0157c36
parent 158
91006f157c46
child 748
6845b95cba6b
permissions
-rw-r--r--

Added tag jdk8u20-b03 for changeset 9059a1c85704

duke@1 1 /*
ohair@158 2 * Copyright (c) 2000, 2003, Oracle and/or its affiliates. All rights reserved.
duke@1 3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
duke@1 4 *
duke@1 5 * This code is free software; you can redistribute it and/or modify it
duke@1 6 * under the terms of the GNU General Public License version 2 only, as
ohair@158 7 * published by the Free Software Foundation. Oracle designates this
duke@1 8 * particular file as subject to the "Classpath" exception as provided
ohair@158 9 * by Oracle in the LICENSE file that accompanied this code.
duke@1 10 *
duke@1 11 * This code is distributed in the hope that it will be useful, but WITHOUT
duke@1 12 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
duke@1 13 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
duke@1 14 * version 2 for more details (a copy is included in the LICENSE file that
duke@1 15 * accompanied this code).
duke@1 16 *
duke@1 17 * You should have received a copy of the GNU General Public License version
duke@1 18 * 2 along with this work; if not, write to the Free Software Foundation,
duke@1 19 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
duke@1 20 *
ohair@158 21 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
ohair@158 22 * or visit www.oracle.com if you need additional information or have any
ohair@158 23 * questions.
duke@1 24 */
duke@1 25
duke@1 26 #ifndef _IOP_IDL_
duke@1 27 #define _IOP_IDL_
duke@1 28
duke@1 29 #include "CORBAX.idl"
duke@1 30
duke@1 31 #pragma prefix "omg.org"
duke@1 32
duke@1 33 #ifndef CORBA3
duke@1 34 #define local
duke@1 35 #endif
duke@1 36
duke@1 37 module IOP {
duke@1 38 //
duke@1 39 // Standard Protocol Profile tag values
duke@1 40 //
duke@1 41 /** Profile ID */
duke@1 42 typedef unsigned long ProfileId;
duke@1 43
duke@1 44 /**
duke@1 45 * Identifies profiles that
duke@1 46 * support the Internet Inter-ORB Protocol. The <code>ProfileBody</code>
duke@1 47 * of this profile contains a CDR encapsulation of a structure
duke@1 48 * containing addressing and object identification information used by
duke@1 49 * IIOP. Version 1.1 of the <code>TAG_INTERNET_IOP</code> profile
duke@1 50 * also includes an array of TaggedComponent objects that can
duke@1 51 * contain additional information supporting optional IIOP features,
duke@1 52 * ORB services such as security, and future protocol extensions.
duke@1 53 * <p>
duke@1 54 * Protocols other than IIOP (such as ESIOPs and other GIOPs) can share
duke@1 55 * profile information (such as object identity or security
duke@1 56 * information) with IIOP by encoding their additional profile information
duke@1 57 * as components in the <code>TAG_INTERNET_IOP</code> profile. All
duke@1 58 * <code>TAG_INTERNET_IOP</code> profiles support IIOP, regardless of
duke@1 59 * whether they also support additional protocols. Interoperable
duke@1 60 * ORBs are not required to create or understand any other profile,
duke@1 61 * nor are they required to create or understand any of the components
duke@1 62 * defined for other protocols that might share the
duke@1 63 * <code>TAG_INTERNET_IOP</code> profile with IIOP.
duke@1 64 * <p>
duke@1 65 * The <code>profile_data</code> for the <code>TAG_INTERNET_IOP</code>
duke@1 66 * profile is a CDR encapsulation of the <code>IIOP.ProfileBody_1_1</code>
duke@1 67 * type.
duke@1 68 */
duke@1 69 const ProfileId TAG_INTERNET_IOP = 0;
duke@1 70
duke@1 71 /**
duke@1 72 * Indicates that the value encapsulated is of type
duke@1 73 * <code>MultipleComponentProfile</code>. In this case, the profile
duke@1 74 * consists of a list of protocol components, the use of which must
duke@1 75 * be specified by the protocol using this profile. This profile may
duke@1 76 * be used to carry IOR components.
duke@1 77 * <p>
duke@1 78 * The <code>profile_data</code> for the
duke@1 79 * <code>TAG_MULTIPLE_COMPONENTS</code> profile is a CDR encapsulation
duke@1 80 * of the <code>MultipleComponentProfile</code> type shown above.
duke@1 81 */
duke@1 82 const ProfileId TAG_MULTIPLE_COMPONENTS = 1;
duke@1 83
duke@1 84 /**
duke@1 85 * Object references have at least one tagged profile. Each profile
duke@1 86 * supports one or more protocols and encapsulates all the basic
duke@1 87 * information the protocols it supports need to identify an object.
duke@1 88 * Any single profile holds enough information to drive a complete
duke@1 89 * invocation using any of the protocols it supports; the content
duke@1 90 * and structure of those profile entries are wholly specified by
duke@1 91 * these protocols.
duke@1 92 */
duke@1 93 struct TaggedProfile {
duke@1 94 /** The tag, represented as a profile id. */
duke@1 95 ProfileId tag;
duke@1 96
duke@1 97 /** The associated profile data. */
duke@1 98 sequence <octet> profile_data;
duke@1 99 };
duke@1 100
duke@1 101 /**
duke@1 102 * Captures information about a object references, such as whether the
duke@1 103 * object is null, what type it is, what protocols are supported, and what
duke@1 104 * ORB services are available.
duke@1 105 * <p>
duke@1 106 * This data structure need not be used internally to any given ORB,
duke@1 107 * and is not intended to be visible to application-level ORB programmers.
duke@1 108 * It should be used only when crossing object reference domain
duke@1 109 * boundaries, within bridges.
duke@1 110 * <p>
duke@1 111 * This data structure is designed to be efficient in typical
duke@1 112 * single-protocol configurations, while not penalizing multiprotocol ones.
duke@1 113 * <p>
duke@1 114 * Object references have at least one tagged profile. Each profile
duke@1 115 * supports one or more protocols and encapsulates all the basic
duke@1 116 * information the protocols it supports need to identify an object.
duke@1 117 * Any single profile holds enough information to drive a complete
duke@1 118 * invocation using any of the protocols it supports; the content
duke@1 119 * and structure of those profile entries are wholly specified by
duke@1 120 * these protocols. A bridge between two domains may need to know the
duke@1 121 * detailed content of the profile for those domains' profiles,
duke@1 122 * depending on the technique it uses to bridge the domains.
duke@1 123 * <p>
duke@1 124 * Each profile has a unique numeric tag, assigned by the OMG.
duke@1 125 * Profile tags in the range 0x80000000 through 0xffffffff are reserved
duke@1 126 * for future use, and are not currently available for assignment.
duke@1 127 * <p>
duke@1 128 * Null object references are indicated by an empty set of profiles,
duke@1 129 * and by a "Null" type ID (a string which contains only a single
duke@1 130 * terminating character). A Null <code>TypeID</code> is the only
duke@1 131 * mechanism that can be used to represent the type
duke@1 132 * <code>CORBA.Object</code>. Type IDs may only be "Null" in any message,
duke@1 133 * requiring the client to use existing knowledge or to consult the
duke@1 134 * object, to determine interface types supported. The type ID
duke@1 135 * is a Repository ID identifying the interface type, and is provided
duke@1 136 * to allow ORBs to preserve strong typing. This identifier is agreed
duke@1 137 * on within the bridge and, for reasons outside the scope of the
duke@1 138 * interoperability specification, needs to have a much broader scope to
duke@1 139 * address various problems in system evolution and maintenance.
duke@1 140 * Type IDs support detection of type equivalence, and in conjunction
duke@1 141 * with an Interface Repository, allow processes to reason about the
duke@1 142 * relationship of the type of the object referred to and any other type.
duke@1 143 * <p>
duke@1 144 * The type ID, if provided by the server, indicates the most derived
duke@1 145 * type that the server wishes to publish, at the time the reference
duke@1 146 * is generated. The object's actual most derived type may later change
duke@1 147 * to a more derived type. Therefore, the type ID in the IOR can only
duke@1 148 * be interpreted by the client as a hint that the object supports at
duke@1 149 * least the indicated interface. The client can succeed in narrowing
duke@1 150 * the reference to the indicated interface, or to one of its base
duke@1 151 * interfaces, based solely on the type ID in the IOR, but must not fail
duke@1 152 * to narrow the reference without consulting the object via the
duke@1 153 * "_is_a" or "_get_interface" pseudo-operations.
duke@1 154 */
duke@1 155 struct IOR {
duke@1 156 /** The type id, represented as a String. */
duke@1 157 string type_id;
duke@1 158
duke@1 159 /**
duke@1 160 * An array of tagged profiles associated with this
duke@1 161 * object reference.
duke@1 162 */
duke@1 163 sequence <TaggedProfile> profiles;
duke@1 164 };
duke@1 165
duke@1 166 /**
duke@1 167 * Standard way of representing multicomponent profiles.
duke@1 168 * This would be encapsulated in a TaggedProfile.
duke@1 169 */
duke@1 170 typedef unsigned long ComponentId;
duke@1 171
duke@1 172 /**
duke@1 173 * <code>TaggedComponents</code> contained in
duke@1 174 * <code>TAG_INTERNET_IOP</code> and
duke@1 175 * <code>TAG_MULTIPLE_COMPONENTS</code> profiles are identified by
duke@1 176 * unique numeric tags using a namespace distinct form that is used for
duke@1 177 * profile tags. Component tags are assigned by the OMG.
duke@1 178 * <p>
duke@1 179 * Specifications of components must include the following information:
duke@1 180 * <ul>
duke@1 181 * <li><i>Component ID</i>: The compound tag that is obtained
duke@1 182 * from OMG.</li>
duke@1 183 * <li><i>Structure and encoding</i>: The syntax of the component
duke@1 184 * data and the encoding rules. If the component value is
duke@1 185 * encoded as a CDR encapsulation, the IDL type that is
duke@1 186 * encapsulated and the GIOP version which is used for encoding
duke@1 187 * the value, if different than GIOP 1.0, must be specified as
duke@1 188 * part of the component definition.</li>
duke@1 189 * <li><i>Semantics</i>: How the component data is intended to be
duke@1 190 * used.</li>
duke@1 191 * <li><i>Protocols</i>: The protocol for which the component is
duke@1 192 * defined, and whether it is intended that the component be
duke@1 193 * usable by other protocols.</li>
duke@1 194 * <li><i>At most once</i>: whether more than one instance of this
duke@1 195 * component can be included in a profile.</li>
duke@1 196 * </ul>
duke@1 197 * Specification of protocols must describe how the components affect
duke@1 198 * the protocol. The following should be specified in any protocol
duke@1 199 * definition for each <code>TaggedComponent</code> that the protocol uses:
duke@1 200 * <ul>
duke@1 201 * <li><i>Mandatory presence</i>: Whether inclusion of the component
duke@1 202 * in profiles supporting the protocol is required (MANDATORY
duke@1 203 * PRESENCE) or not required (OPTIONAL PRESENCE).</li>
duke@1 204 * <li><i>Droppable</i>: For optional presence component, whether
duke@1 205 * component, if present, must be retained or may be dropped.</li>
duke@1 206 * </ul>
duke@1 207 */
duke@1 208 struct TaggedComponent {
duke@1 209 /** The tag, represented as a component id. */
duke@1 210 ComponentId tag;
duke@1 211
duke@1 212 /** The component data associated with the component id. */
duke@1 213 sequence <octet> component_data;
duke@1 214 };
duke@1 215
duke@1 216 /**
duke@1 217 * It is often useful in the real world to be able to identify the
duke@1 218 * particular kind of ORB an object reference is coming from, to work
duke@1 219 * around problems with that particular ORB, or exploit shared
duke@1 220 * efficiencies.
duke@1 221 * <p>
duke@1 222 * The <code>TAG_ORB_TYPE</code> component has an associated value of
duke@1 223 * type unsigned long (Java long), encoded as a CDR encapsulation,
duke@1 224 * designating an ORB type ID allocated by the OMG for the ORB type of the
duke@1 225 * originating ORB. Anyone may register any ORB types by submitting
duke@1 226 * a short (one-paragraph) description of the ORB type to the OMG,
duke@1 227 * and will receive a new ORB type ID in return. A list of ORB type
duke@1 228 * descriptions and values will be made available on the OMG web server.
duke@1 229 * <p>
duke@1 230 * The <code>TAG_ORB_TYPE</code> component can appear at most once in
duke@1 231 * any IOR profile. For profiles supporting IIOP 1.1 or greater, it
duke@1 232 * is optionally present.
duke@1 233 */
duke@1 234 const ComponentId TAG_ORB_TYPE = 0 ;
duke@1 235
duke@1 236 /**
duke@1 237 * The code set component of the IOR multi-component profile structure
duke@1 238 * contains:
duke@1 239 * <ul>
duke@1 240 * <li>server's native char code set and conversion code sets, and</li>
duke@1 241 * <li>server's native wchar code set and conversion code sets.</li>
duke@1 242 * </ul>
duke@1 243 * Both char and wchar conversion code sets are listed in order of
duke@1 244 * preference.
duke@1 245 */
duke@1 246 const ComponentId TAG_CODE_SETS = 1 ;
duke@1 247
duke@1 248 /**
duke@1 249 * A profile component containing the sequence of QoS policies exported
duke@1 250 * with the object reference by an object adapter.
duke@1 251 */
duke@1 252 const ComponentId TAG_POLICIES = 2 ;
duke@1 253
duke@1 254 /**
duke@1 255 * In cases where the same object key is used for more than one
duke@1 256 * internet location, the following standard IOR Component is defined
duke@1 257 * for support in IIOP version 1.2.
duke@1 258 * <p>
duke@1 259 * The <code>TAG_ALTERNATE_IIOP_ADDRESS</code> component has an
duke@1 260 * associated value of type:
duke@1 261 * <code>
duke@1 262 * <pre>
duke@1 263 * struct {
duke@1 264 * string HostID,
duke@1 265 * short Port
duke@1 266 * };
duke@1 267 * </pre>
duke@1 268 * </code>
duke@1 269 * encoded as a CDR encapsulation.
duke@1 270 * <p>
duke@1 271 * Zero or more instances of the <code>TAG_ALTERNATE_IIOP_ADDRESS</code>
duke@1 272 * component type may be included in a version 1.2
duke@1 273 * <code>TAG_INTERNET_IOP</code> Profile. Each of these alternative
duke@1 274 * addresses may be used by the client orb, in addition to the host
duke@1 275 * and port address expressed in the body of the Profile. In cases
duke@1 276 * where one or more <code>TAG_ALTERNATE_IIOP_ADDRESS</code> components
duke@1 277 * are present in a <code>TAG_INTERNET_IOP</code> Profile, no order of
duke@1 278 * use is prescribed by Version 1.2 of IIOP.
duke@1 279 */
duke@1 280 const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3 ;
duke@1 281
duke@1 282 /**
duke@1 283 * Class downloading is supported for stubs, ties, values, and
duke@1 284 * value helpers. The specification allows transmission of codebase
duke@1 285 * information on the wire for stubs and ties, and enables usage of
duke@1 286 * pre-existing ClassLoaders when relevant.
duke@1 287 * <p>
duke@1 288 * For values and value helpers, the codebase is transmitted after the
duke@1 289 * value tag. For stubs and ties, the codebase is transmitted as
duke@1 290 * the TaggedComponent <code>TAG_JAVA_CODEBASE</code> in the IOR
duke@1 291 * profile, where the <code>component_data</code> is a CDR encapsulation
duke@1 292 * of the codebase written as an IDL string. The codebase is a
duke@1 293 * space-separated list of one or more URLs.
duke@1 294 */
duke@1 295 const ComponentId TAG_JAVA_CODEBASE = 25 ;
duke@1 296
duke@1 297 /**
duke@1 298 * RMI-IIOP has multiple stream format versions. A server
duke@1 299 * can specify its maximum version by including the
duke@1 300 * TAG_RMI_CUSTOM_MAX_STREAM_FORMAT tagged component or
duke@1 301 * rely on the default of version 1 for GIOP 1.2 and less
duke@1 302 * and version 2 for GIOP 1.3 and higher.
duke@1 303 *
duke@1 304 * See Java to IDL ptc/02-01-12 1.4.11.
duke@1 305 */
duke@1 306 const ComponentId TAG_RMI_CUSTOM_MAX_STREAM_FORMAT = 38 ;
duke@1 307
duke@1 308 /** An array of tagged components, forming a multiple component profile. */
duke@1 309 typedef sequence <TaggedComponent> MultipleComponentProfile;
duke@1 310
duke@1 311 /** A service id, represented as an int */
duke@1 312 typedef unsigned long ServiceId;
duke@1 313
duke@1 314 /**
duke@1 315 * Service-specific information to be passed implicitly with requests
duke@1 316 * and replies. Service contexts are composed of service ids and
duke@1 317 * associated data.
duke@1 318 */
duke@1 319 struct ServiceContext {
duke@1 320 /** The service context id */
duke@1 321 ServiceId context_id;
duke@1 322
duke@1 323 /** The data associated with this service context */
duke@1 324 sequence <octet> context_data;
duke@1 325 };
duke@1 326
duke@1 327 /** An array of service contexts, forming a service context list. */
duke@1 328 typedef sequence <ServiceContext>ServiceContextList;
duke@1 329
duke@1 330 /**
duke@1 331 * Identifies a CDR encapsulation of the
duke@1 332 * <code>CosTSInteroperation.PropogationContext</code> defined in
duke@1 333 * <i>CORBAservices: Common Object Services Specifications.</i>
duke@1 334 */
duke@1 335 const ServiceId TransactionService = 0;
duke@1 336
duke@1 337 /**
duke@1 338 * Identifies a CDR encapsulation of the
duke@1 339 * <code>CONV_FRAME.CodeSetContext</code> defined in
duke@1 340 * Section 13.10.2.5, "GIOP Code Set Service Context," on page 13-43.
duke@1 341 */
duke@1 342 const ServiceId CodeSets = 1;
duke@1 343
duke@1 344 /**
duke@1 345 * Identifies a CDR encapsulation of the RMICustomMaxStreamFormat
duke@1 346 * service context which contains a single byte specifying
duke@1 347 * the client's maximum RMI-IIOP stream format version.
duke@1 348 *
duke@1 349 * See Java to IDL ptc/02-01-12 1.4.12.
duke@1 350 */
duke@1 351 const ServiceId RMICustomMaxStreamFormat = 17 ;
duke@1 352
duke@1 353 /**
duke@1 354 * DCOM-CORBA Interworking uses three service contexts as defined in
duke@1 355 * "DCOM-CORBA Interworking" in the "Interoperability with non-CORBA
duke@1 356 * Systems" chapter.
duke@1 357 * <p>
duke@1 358 * <code>ChainBypassCheck</code> carries a CDR encapsulation of the
duke@1 359 * <code>struct CosBridging.ChainBypassCheck</code>. This is carried
duke@1 360 * only in a Request message as described in Section 20.9.1, "CORBA
duke@1 361 * Chain Bypass," on page 20-19.
duke@1 362 */
duke@1 363 const ServiceId ChainBypassCheck = 2;
duke@1 364
duke@1 365 /**
duke@1 366 * DCOM-CORBA Interworking uses three service contexts as defined in
duke@1 367 * "DCOM-CORBA Interworking" in the "Interoperability with non-CORBA
duke@1 368 * Systems" chapter.
duke@1 369 * <p>
duke@1 370 * <code>ChainBypassInfo</code> carries a CDR encapsulation of the
duke@1 371 * <code>struct CosBridging.ChainBypassInfo</code>. This is carried
duke@1 372 * only in a Reply message as described in Section 20.9.1, "CORBA Chain
duke@1 373 * Bypass," on page 20-19.
duke@1 374 */
duke@1 375 const ServiceId ChainBypassInfo = 3;
duke@1 376
duke@1 377 /**
duke@1 378 * DCOM-CORBA Interworking uses three service contexts as defined in
duke@1 379 * "DCOM-CORBA Interworking" in the "Interoperability with non-CORBA
duke@1 380 * Systems" chapter.
duke@1 381 * <p>
duke@1 382 * <code>LogicalThreadId</code>, carries a CDR encapsulation of
duke@1 383 * the <code>struct CosBridging.LogicalThreadId</code> as described
duke@1 384 * in Section 20.10, "Thread Identification," on page 20-21.
duke@1 385 */
duke@1 386 const ServiceId LogicalThreadId = 4;
duke@1 387
duke@1 388 /**
duke@1 389 * Identifies a CDR encapsulation of the
duke@1 390 * <code>IIOP.BiDirIIOPServiceContext</code> defined in Section 15.8,
duke@1 391 * "Bi-Directional GIOP," on page 15-55.
duke@1 392 */
duke@1 393 const ServiceId BI_DIR_IIOP = 5;
duke@1 394
duke@1 395 /**
duke@1 396 * Identifies a CDR encapsulation of the IOR of the
duke@1 397 * <code>SendingContext.RunTime</code> object (see Section 5.6, "Access
duke@1 398 * to the Sending Context Run Time," on page 5-15).
duke@1 399 */
duke@1 400 const ServiceId SendingContextRunTime = 6;
duke@1 401
duke@1 402 /**
duke@1 403 * For information on <code>INVOCATION_POLICIES</code> refer to the
duke@1 404 * Asynchronous Messaging specification - orbos/98-05-05.
duke@1 405 */
duke@1 406 const ServiceId INVOCATION_POLICIES = 7;
duke@1 407
duke@1 408 /**
duke@1 409 * For information on <code>FORWARDED_IDENTITY</code> refer to the
duke@1 410 * Firewall specification - orbos/98-05-04.
duke@1 411 */
duke@1 412 const ServiceId FORWARDED_IDENTITY = 8;
duke@1 413
duke@1 414 /**
duke@1 415 * Identifies a CDR encapsulation of a marshaled instance of a
duke@1 416 * java.lang.Throwable or one of its subclasses as described in Java
duke@1 417 * to IDL Language Mapping, Section 1.4.8.1, "Mapping of
duke@1 418 * UnknownExceptionInfo Service Context," on page 1-32.
duke@1 419 */
duke@1 420 const ServiceId UnknownExceptionInfo = 9;
duke@1 421
duke@1 422 /**
duke@1 423 * CORBA formal/02-06-01: 13.7.1:
duke@1 424 * ExceptionDetailMessage identifies a CDR encapsulation of a wstring,
duke@1 425 * encoded using GIOP 1.2 with a TCS-W of UTF-16. This service context
duke@1 426 * may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION
duke@1 427 * or USER_EXCEPTION. The usage of this service context is defined
duke@1 428 * by language mappings. <br/> <br/>
duke@1 429 *
duke@1 430 * IDL/Java: ptc/02-01-22: 1.15.2:
duke@1 431 * When a System Exception is marshaled, its GIOP Reply message shall
duke@1 432 * include an associated ExceptionDetailMessage service context. The
duke@1 433 * callee's stack trace is often very valuable debugging information but
duke@1 434 * may contain sensitive or unwanted information. The wstring within the
duke@1 435 * service context will therefore contain additional information relating
duke@1 436 * to the exception, for example the result of calling either
duke@1 437 * printStackTrace(PrintWriter) or getMessage() on the exception. When
duke@1 438 * unmarshaling a System Exception on the client side, the wstring from
duke@1 439 * any ExceptionDetailMessage service context shall become the Java error
duke@1 440 * message in the unmarshaled exception object.
duke@1 441 */
duke@1 442 const ServiceId ExceptionDetailMessage = 14;
duke@1 443
duke@1 444
duke@1 445 // BEGIN part which lived in Interceptors.idl.
duke@1 446
duke@1 447 /**
duke@1 448 * An array of <code>TaggedComponent</code> objects.
duke@1 449 */
duke@1 450 typedef sequence<IOP::TaggedComponent> TaggedComponentSeq;
duke@1 451
duke@1 452 /**
duke@1 453 * The formats of IOR components and service context data used by ORB
duke@1 454 * services are often defined as CDR encapsulations encoding instances
duke@1 455 * of IDL defined data types. The <code>Codec</code> provides a mechanism
duke@1 456 * to transfer these components between their IDL data types and their CDR
duke@1 457 * encapsulation representations.
duke@1 458 * <p>
duke@1 459 * A <code>Codec</code> is obtained from the <code>CodecFactory</code>.
duke@1 460 * The <code>CodecFactory</code> is obtained through a call to
duke@1 461 * <code>ORB.resolve_initial_references( "CodecFactory" )</code>.
duke@1 462 */
duke@1 463 local interface Codec {
duke@1 464
duke@1 465 /**
duke@1 466 * This exception is thrown by <code>Codec.encode</code> or
duke@1 467 * <code>Codec.encode_value</code> when the type is invalid for the
duke@1 468 * encoding. For example, this exception is thrown if the encoding is
duke@1 469 * <code>ENCODING_CDR_ENCAPS</code> version 1.0 and a type
duke@1 470 * that does not exist in that version, such as <code>wstring</code>,
duke@1 471 * is passed to the operation.
duke@1 472 */
duke@1 473 exception InvalidTypeForEncoding {};
duke@1 474
duke@1 475 /**
duke@1 476 * This exception is thrown by <code>Codec.decode</code> or
duke@1 477 * <code>Codec.decode_value</code> when the data in the byte array
duke@1 478 * cannot be decoded into an Any.
duke@1 479 */
duke@1 480 exception FormatMismatch {};
duke@1 481
duke@1 482 /**
duke@1 483 * This exception is thrown by <code>decode_value</code> when the given
duke@1 484 * <code>TypeCode</code> does not match the given byte array.
duke@1 485 */
duke@1 486 exception TypeMismatch {};
duke@1 487
duke@1 488 /**
duke@1 489 * Converts the given any into a byte array based on the encoding
duke@1 490 * format effective for this <code>Codec</code>.
duke@1 491 *
duke@1 492 * @param data The data, in the form of an any, to be encoded into
duke@1 493 * a byte array.
duke@1 494 * @return A byte array containing the encoded Any. This byte array
duke@1 495 * contains both the <code>TypeCode</code> and the data of the type.
duke@1 496 * @exception InvalidTypeForEncoding thrown if the type is not valid for
duke@1 497 * the encoding format effective for this <code>Codec</code>.
duke@1 498 */
duke@1 499 CORBA::OctetSeq encode (in any data)
duke@1 500 raises (InvalidTypeForEncoding);
duke@1 501
duke@1 502 /**
duke@1 503 * Decodes the given byte array into an Any based on the encoding
duke@1 504 * format effective for this <code>Codec</code>.
duke@1 505 *
duke@1 506 * @param data The data, in the form of a byte array, to be decoded into
duke@1 507 * an Any.
duke@1 508 * @return An Any containing the data from the decoded byte array.
duke@1 509 * @exception FormatMismatch is thrown if the byte array cannot be
duke@1 510 * decoded into an Any.
duke@1 511 */
duke@1 512 any decode (in CORBA::OctetSeq data) raises (FormatMismatch);
duke@1 513
duke@1 514 /**
duke@1 515 * Converts the given any into a byte array based on the encoding
duke@1 516 * format effective for this Codec. Only the data from the Any is
duke@1 517 * encoded, not the <code>TypeCode</code>.
duke@1 518 *
duke@1 519 * @param data The data, in the form of an Any, to be encoded into
duke@1 520 * a byte array.
duke@1 521 * @return A byte array containing the data from the encoded any.
duke@1 522 * @exception InvalidTypeForEncoding thrown if the type is not valid for
duke@1 523 * the encoding format effective for this <code>Codec</code>.
duke@1 524 */
duke@1 525 CORBA::OctetSeq encode_value (in any data)
duke@1 526 raises (InvalidTypeForEncoding);
duke@1 527
duke@1 528 /**
duke@1 529 * Decodes the given byte array into an Any based on the given
duke@1 530 * <code>TypeCode</code> and the encoding format effective for
duke@1 531 * this <code>Codec</code>.
duke@1 532 *
duke@1 533 * @param data The data, in the form of a byte array, to be decoded
duke@1 534 * into an Any.
duke@1 535 * @param tc The TypeCode to be used to decode the data.
duke@1 536 * @return An Any containing the data from the decoded byte array.
duke@1 537 * @exception FormatMismatch thrown if the byte array cannot be
duke@1 538 * decoded into an Any.
duke@1 539 */
duke@1 540 any decode_value (in CORBA::OctetSeq data, in CORBA::TypeCode tc)
duke@1 541 raises (FormatMismatch, TypeMismatch);
duke@1 542 };
duke@1 543
duke@1 544 /**
duke@1 545 * Defines an encoding format of a <code>Codec</code>, such as
duke@1 546 * CDR Encapsulation (<code>ENCODING_CDR_ENCAPS</code>).
duke@1 547 */
duke@1 548 typedef short EncodingFormat;
duke@1 549
duke@1 550 /**
duke@1 551 * The CDR Encapsulation encoding.
duke@1 552 * @see CodecFactory
duke@1 553 */
duke@1 554 const EncodingFormat ENCODING_CDR_ENCAPS = 0;
duke@1 555
duke@1 556 /**
duke@1 557 * Defines the encoding format of a <code>Codec</code>. This class
duke@1 558 * details the encoding format, such as CDR Encapsulation encoding, and
duke@1 559 * the major and minor versions of that format.
duke@1 560 * <p>
duke@1 561 * The encodings currently supported are:
duke@1 562 * <ul>
duke@1 563 * <li><code>ENCODING_CDR_ENCAPS</code>, version 1.0;</li>
duke@1 564 * <li><code>ENCODING_CDR_ENCAPS</code>, version 1.1;</li>
duke@1 565 * <li><code>ENCODING_CDR_ENCAPS</code>, version 1.2;</li>
duke@1 566 * <li><code>ENCODING_CDR_ENCAPS</code> for all future versions of GIOP as
duke@1 567 * they arise.</li>
duke@1 568 * </ul>
duke@1 569 * Vendors are free to support additional encodings.
duke@1 570 *
duke@1 571 * @see ENCODING_CDR_ENCAPS
duke@1 572 */
duke@1 573 struct Encoding {
duke@1 574 /**
duke@1 575 * The encoding format.
duke@1 576 */
duke@1 577 EncodingFormat format;
duke@1 578
duke@1 579 /**
duke@1 580 * The major version of this Encoding format.
duke@1 581 */
duke@1 582 octet major_version;
duke@1 583
duke@1 584 /**
duke@1 585 * The minor version of this Encoding format.
duke@1 586 */
duke@1 587 octet minor_version;
duke@1 588 };
duke@1 589
duke@1 590 /**
duke@1 591 * <code>Codecs</code> are obtained from the <code>CodecFactory</code>.
duke@1 592 * The <code>CodecFactory</code> is obtained through a call to
duke@1 593 * <code>ORB.resolve_initial_references( "CodecFactory" )</code>.
duke@1 594 */
duke@1 595 local interface CodecFactory {
duke@1 596 /**
duke@1 597 * This exception is thrown by <code>CodecFactory.create_codec</code> when
duke@1 598 * the factory cannot create a <code>Codec</code> for a given encoding.
duke@1 599 */
duke@1 600 exception UnknownEncoding {};
duke@1 601
duke@1 602 /**
duke@1 603 * Create a <code>Codec</code> of the given encoding.
duke@1 604 * <p>
duke@1 605 * @param enc The encoding for which to create a <code>Codec</code>.
duke@1 606 * @return A <code>Codec</code> obtained with the given encoding.
duke@1 607 * @exception UnknownEncoding thrown if this factory cannot create a
duke@1 608 * <code>Codec</code> of the given encoding.
duke@1 609 */
duke@1 610 Codec create_codec (in Encoding enc) raises (UnknownEncoding);
duke@1 611 };
duke@1 612
duke@1 613 // END part which lived in Interceptors.idl.
duke@1 614
duke@1 615 };
duke@1 616
duke@1 617 #endif // _IOP_IDL_

mercurial