1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/src/share/classes/org/omg/PortableInterceptor/IOP.idl Wed Apr 27 01:21:28 2016 +0800
1.3 @@ -0,0 +1,617 @@
1.4 +/*
1.5 + * Copyright (c) 2000, 2003, Oracle and/or its affiliates. All rights reserved.
1.6 + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
1.7 + *
1.8 + * This code is free software; you can redistribute it and/or modify it
1.9 + * under the terms of the GNU General Public License version 2 only, as
1.10 + * published by the Free Software Foundation. Oracle designates this
1.11 + * particular file as subject to the "Classpath" exception as provided
1.12 + * by Oracle in the LICENSE file that accompanied this code.
1.13 + *
1.14 + * This code is distributed in the hope that it will be useful, but WITHOUT
1.15 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
1.16 + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
1.17 + * version 2 for more details (a copy is included in the LICENSE file that
1.18 + * accompanied this code).
1.19 + *
1.20 + * You should have received a copy of the GNU General Public License version
1.21 + * 2 along with this work; if not, write to the Free Software Foundation,
1.22 + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
1.23 + *
1.24 + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
1.25 + * or visit www.oracle.com if you need additional information or have any
1.26 + * questions.
1.27 + */
1.28 +
1.29 +#ifndef _IOP_IDL_
1.30 +#define _IOP_IDL_
1.31 +
1.32 +#include "CORBAX.idl"
1.33 +
1.34 +#pragma prefix "omg.org"
1.35 +
1.36 +#ifndef CORBA3
1.37 +#define local
1.38 +#endif
1.39 +
1.40 +module IOP {
1.41 + //
1.42 + // Standard Protocol Profile tag values
1.43 + //
1.44 + /** Profile ID */
1.45 + typedef unsigned long ProfileId;
1.46 +
1.47 + /**
1.48 + * Identifies profiles that
1.49 + * support the Internet Inter-ORB Protocol. The <code>ProfileBody</code>
1.50 + * of this profile contains a CDR encapsulation of a structure
1.51 + * containing addressing and object identification information used by
1.52 + * IIOP. Version 1.1 of the <code>TAG_INTERNET_IOP</code> profile
1.53 + * also includes an array of TaggedComponent objects that can
1.54 + * contain additional information supporting optional IIOP features,
1.55 + * ORB services such as security, and future protocol extensions.
1.56 + * <p>
1.57 + * Protocols other than IIOP (such as ESIOPs and other GIOPs) can share
1.58 + * profile information (such as object identity or security
1.59 + * information) with IIOP by encoding their additional profile information
1.60 + * as components in the <code>TAG_INTERNET_IOP</code> profile. All
1.61 + * <code>TAG_INTERNET_IOP</code> profiles support IIOP, regardless of
1.62 + * whether they also support additional protocols. Interoperable
1.63 + * ORBs are not required to create or understand any other profile,
1.64 + * nor are they required to create or understand any of the components
1.65 + * defined for other protocols that might share the
1.66 + * <code>TAG_INTERNET_IOP</code> profile with IIOP.
1.67 + * <p>
1.68 + * The <code>profile_data</code> for the <code>TAG_INTERNET_IOP</code>
1.69 + * profile is a CDR encapsulation of the <code>IIOP.ProfileBody_1_1</code>
1.70 + * type.
1.71 + */
1.72 + const ProfileId TAG_INTERNET_IOP = 0;
1.73 +
1.74 + /**
1.75 + * Indicates that the value encapsulated is of type
1.76 + * <code>MultipleComponentProfile</code>. In this case, the profile
1.77 + * consists of a list of protocol components, the use of which must
1.78 + * be specified by the protocol using this profile. This profile may
1.79 + * be used to carry IOR components.
1.80 + * <p>
1.81 + * The <code>profile_data</code> for the
1.82 + * <code>TAG_MULTIPLE_COMPONENTS</code> profile is a CDR encapsulation
1.83 + * of the <code>MultipleComponentProfile</code> type shown above.
1.84 + */
1.85 + const ProfileId TAG_MULTIPLE_COMPONENTS = 1;
1.86 +
1.87 + /**
1.88 + * Object references have at least one tagged profile. Each profile
1.89 + * supports one or more protocols and encapsulates all the basic
1.90 + * information the protocols it supports need to identify an object.
1.91 + * Any single profile holds enough information to drive a complete
1.92 + * invocation using any of the protocols it supports; the content
1.93 + * and structure of those profile entries are wholly specified by
1.94 + * these protocols.
1.95 + */
1.96 + struct TaggedProfile {
1.97 + /** The tag, represented as a profile id. */
1.98 + ProfileId tag;
1.99 +
1.100 + /** The associated profile data. */
1.101 + sequence <octet> profile_data;
1.102 + };
1.103 +
1.104 + /**
1.105 + * Captures information about a object references, such as whether the
1.106 + * object is null, what type it is, what protocols are supported, and what
1.107 + * ORB services are available.
1.108 + * <p>
1.109 + * This data structure need not be used internally to any given ORB,
1.110 + * and is not intended to be visible to application-level ORB programmers.
1.111 + * It should be used only when crossing object reference domain
1.112 + * boundaries, within bridges.
1.113 + * <p>
1.114 + * This data structure is designed to be efficient in typical
1.115 + * single-protocol configurations, while not penalizing multiprotocol ones.
1.116 + * <p>
1.117 + * Object references have at least one tagged profile. Each profile
1.118 + * supports one or more protocols and encapsulates all the basic
1.119 + * information the protocols it supports need to identify an object.
1.120 + * Any single profile holds enough information to drive a complete
1.121 + * invocation using any of the protocols it supports; the content
1.122 + * and structure of those profile entries are wholly specified by
1.123 + * these protocols. A bridge between two domains may need to know the
1.124 + * detailed content of the profile for those domains' profiles,
1.125 + * depending on the technique it uses to bridge the domains.
1.126 + * <p>
1.127 + * Each profile has a unique numeric tag, assigned by the OMG.
1.128 + * Profile tags in the range 0x80000000 through 0xffffffff are reserved
1.129 + * for future use, and are not currently available for assignment.
1.130 + * <p>
1.131 + * Null object references are indicated by an empty set of profiles,
1.132 + * and by a "Null" type ID (a string which contains only a single
1.133 + * terminating character). A Null <code>TypeID</code> is the only
1.134 + * mechanism that can be used to represent the type
1.135 + * <code>CORBA.Object</code>. Type IDs may only be "Null" in any message,
1.136 + * requiring the client to use existing knowledge or to consult the
1.137 + * object, to determine interface types supported. The type ID
1.138 + * is a Repository ID identifying the interface type, and is provided
1.139 + * to allow ORBs to preserve strong typing. This identifier is agreed
1.140 + * on within the bridge and, for reasons outside the scope of the
1.141 + * interoperability specification, needs to have a much broader scope to
1.142 + * address various problems in system evolution and maintenance.
1.143 + * Type IDs support detection of type equivalence, and in conjunction
1.144 + * with an Interface Repository, allow processes to reason about the
1.145 + * relationship of the type of the object referred to and any other type.
1.146 + * <p>
1.147 + * The type ID, if provided by the server, indicates the most derived
1.148 + * type that the server wishes to publish, at the time the reference
1.149 + * is generated. The object's actual most derived type may later change
1.150 + * to a more derived type. Therefore, the type ID in the IOR can only
1.151 + * be interpreted by the client as a hint that the object supports at
1.152 + * least the indicated interface. The client can succeed in narrowing
1.153 + * the reference to the indicated interface, or to one of its base
1.154 + * interfaces, based solely on the type ID in the IOR, but must not fail
1.155 + * to narrow the reference without consulting the object via the
1.156 + * "_is_a" or "_get_interface" pseudo-operations.
1.157 + */
1.158 + struct IOR {
1.159 + /** The type id, represented as a String. */
1.160 + string type_id;
1.161 +
1.162 + /**
1.163 + * An array of tagged profiles associated with this
1.164 + * object reference.
1.165 + */
1.166 + sequence <TaggedProfile> profiles;
1.167 + };
1.168 +
1.169 + /**
1.170 + * Standard way of representing multicomponent profiles.
1.171 + * This would be encapsulated in a TaggedProfile.
1.172 + */
1.173 + typedef unsigned long ComponentId;
1.174 +
1.175 + /**
1.176 + * <code>TaggedComponents</code> contained in
1.177 + * <code>TAG_INTERNET_IOP</code> and
1.178 + * <code>TAG_MULTIPLE_COMPONENTS</code> profiles are identified by
1.179 + * unique numeric tags using a namespace distinct form that is used for
1.180 + * profile tags. Component tags are assigned by the OMG.
1.181 + * <p>
1.182 + * Specifications of components must include the following information:
1.183 + * <ul>
1.184 + * <li><i>Component ID</i>: The compound tag that is obtained
1.185 + * from OMG.</li>
1.186 + * <li><i>Structure and encoding</i>: The syntax of the component
1.187 + * data and the encoding rules. If the component value is
1.188 + * encoded as a CDR encapsulation, the IDL type that is
1.189 + * encapsulated and the GIOP version which is used for encoding
1.190 + * the value, if different than GIOP 1.0, must be specified as
1.191 + * part of the component definition.</li>
1.192 + * <li><i>Semantics</i>: How the component data is intended to be
1.193 + * used.</li>
1.194 + * <li><i>Protocols</i>: The protocol for which the component is
1.195 + * defined, and whether it is intended that the component be
1.196 + * usable by other protocols.</li>
1.197 + * <li><i>At most once</i>: whether more than one instance of this
1.198 + * component can be included in a profile.</li>
1.199 + * </ul>
1.200 + * Specification of protocols must describe how the components affect
1.201 + * the protocol. The following should be specified in any protocol
1.202 + * definition for each <code>TaggedComponent</code> that the protocol uses:
1.203 + * <ul>
1.204 + * <li><i>Mandatory presence</i>: Whether inclusion of the component
1.205 + * in profiles supporting the protocol is required (MANDATORY
1.206 + * PRESENCE) or not required (OPTIONAL PRESENCE).</li>
1.207 + * <li><i>Droppable</i>: For optional presence component, whether
1.208 + * component, if present, must be retained or may be dropped.</li>
1.209 + * </ul>
1.210 + */
1.211 + struct TaggedComponent {
1.212 + /** The tag, represented as a component id. */
1.213 + ComponentId tag;
1.214 +
1.215 + /** The component data associated with the component id. */
1.216 + sequence <octet> component_data;
1.217 + };
1.218 +
1.219 + /**
1.220 + * It is often useful in the real world to be able to identify the
1.221 + * particular kind of ORB an object reference is coming from, to work
1.222 + * around problems with that particular ORB, or exploit shared
1.223 + * efficiencies.
1.224 + * <p>
1.225 + * The <code>TAG_ORB_TYPE</code> component has an associated value of
1.226 + * type unsigned long (Java long), encoded as a CDR encapsulation,
1.227 + * designating an ORB type ID allocated by the OMG for the ORB type of the
1.228 + * originating ORB. Anyone may register any ORB types by submitting
1.229 + * a short (one-paragraph) description of the ORB type to the OMG,
1.230 + * and will receive a new ORB type ID in return. A list of ORB type
1.231 + * descriptions and values will be made available on the OMG web server.
1.232 + * <p>
1.233 + * The <code>TAG_ORB_TYPE</code> component can appear at most once in
1.234 + * any IOR profile. For profiles supporting IIOP 1.1 or greater, it
1.235 + * is optionally present.
1.236 + */
1.237 + const ComponentId TAG_ORB_TYPE = 0 ;
1.238 +
1.239 + /**
1.240 + * The code set component of the IOR multi-component profile structure
1.241 + * contains:
1.242 + * <ul>
1.243 + * <li>server's native char code set and conversion code sets, and</li>
1.244 + * <li>server's native wchar code set and conversion code sets.</li>
1.245 + * </ul>
1.246 + * Both char and wchar conversion code sets are listed in order of
1.247 + * preference.
1.248 + */
1.249 + const ComponentId TAG_CODE_SETS = 1 ;
1.250 +
1.251 + /**
1.252 + * A profile component containing the sequence of QoS policies exported
1.253 + * with the object reference by an object adapter.
1.254 + */
1.255 + const ComponentId TAG_POLICIES = 2 ;
1.256 +
1.257 + /**
1.258 + * In cases where the same object key is used for more than one
1.259 + * internet location, the following standard IOR Component is defined
1.260 + * for support in IIOP version 1.2.
1.261 + * <p>
1.262 + * The <code>TAG_ALTERNATE_IIOP_ADDRESS</code> component has an
1.263 + * associated value of type:
1.264 + * <code>
1.265 + * <pre>
1.266 + * struct {
1.267 + * string HostID,
1.268 + * short Port
1.269 + * };
1.270 + * </pre>
1.271 + * </code>
1.272 + * encoded as a CDR encapsulation.
1.273 + * <p>
1.274 + * Zero or more instances of the <code>TAG_ALTERNATE_IIOP_ADDRESS</code>
1.275 + * component type may be included in a version 1.2
1.276 + * <code>TAG_INTERNET_IOP</code> Profile. Each of these alternative
1.277 + * addresses may be used by the client orb, in addition to the host
1.278 + * and port address expressed in the body of the Profile. In cases
1.279 + * where one or more <code>TAG_ALTERNATE_IIOP_ADDRESS</code> components
1.280 + * are present in a <code>TAG_INTERNET_IOP</code> Profile, no order of
1.281 + * use is prescribed by Version 1.2 of IIOP.
1.282 + */
1.283 + const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3 ;
1.284 +
1.285 + /**
1.286 + * Class downloading is supported for stubs, ties, values, and
1.287 + * value helpers. The specification allows transmission of codebase
1.288 + * information on the wire for stubs and ties, and enables usage of
1.289 + * pre-existing ClassLoaders when relevant.
1.290 + * <p>
1.291 + * For values and value helpers, the codebase is transmitted after the
1.292 + * value tag. For stubs and ties, the codebase is transmitted as
1.293 + * the TaggedComponent <code>TAG_JAVA_CODEBASE</code> in the IOR
1.294 + * profile, where the <code>component_data</code> is a CDR encapsulation
1.295 + * of the codebase written as an IDL string. The codebase is a
1.296 + * space-separated list of one or more URLs.
1.297 + */
1.298 + const ComponentId TAG_JAVA_CODEBASE = 25 ;
1.299 +
1.300 + /**
1.301 + * RMI-IIOP has multiple stream format versions. A server
1.302 + * can specify its maximum version by including the
1.303 + * TAG_RMI_CUSTOM_MAX_STREAM_FORMAT tagged component or
1.304 + * rely on the default of version 1 for GIOP 1.2 and less
1.305 + * and version 2 for GIOP 1.3 and higher.
1.306 + *
1.307 + * See Java to IDL ptc/02-01-12 1.4.11.
1.308 + */
1.309 + const ComponentId TAG_RMI_CUSTOM_MAX_STREAM_FORMAT = 38 ;
1.310 +
1.311 + /** An array of tagged components, forming a multiple component profile. */
1.312 + typedef sequence <TaggedComponent> MultipleComponentProfile;
1.313 +
1.314 + /** A service id, represented as an int */
1.315 + typedef unsigned long ServiceId;
1.316 +
1.317 + /**
1.318 + * Service-specific information to be passed implicitly with requests
1.319 + * and replies. Service contexts are composed of service ids and
1.320 + * associated data.
1.321 + */
1.322 + struct ServiceContext {
1.323 + /** The service context id */
1.324 + ServiceId context_id;
1.325 +
1.326 + /** The data associated with this service context */
1.327 + sequence <octet> context_data;
1.328 + };
1.329 +
1.330 + /** An array of service contexts, forming a service context list. */
1.331 + typedef sequence <ServiceContext>ServiceContextList;
1.332 +
1.333 + /**
1.334 + * Identifies a CDR encapsulation of the
1.335 + * <code>CosTSInteroperation.PropogationContext</code> defined in
1.336 + * <i>CORBAservices: Common Object Services Specifications.</i>
1.337 + */
1.338 + const ServiceId TransactionService = 0;
1.339 +
1.340 + /**
1.341 + * Identifies a CDR encapsulation of the
1.342 + * <code>CONV_FRAME.CodeSetContext</code> defined in
1.343 + * Section 13.10.2.5, "GIOP Code Set Service Context," on page 13-43.
1.344 + */
1.345 + const ServiceId CodeSets = 1;
1.346 +
1.347 + /**
1.348 + * Identifies a CDR encapsulation of the RMICustomMaxStreamFormat
1.349 + * service context which contains a single byte specifying
1.350 + * the client's maximum RMI-IIOP stream format version.
1.351 + *
1.352 + * See Java to IDL ptc/02-01-12 1.4.12.
1.353 + */
1.354 + const ServiceId RMICustomMaxStreamFormat = 17 ;
1.355 +
1.356 + /**
1.357 + * DCOM-CORBA Interworking uses three service contexts as defined in
1.358 + * "DCOM-CORBA Interworking" in the "Interoperability with non-CORBA
1.359 + * Systems" chapter.
1.360 + * <p>
1.361 + * <code>ChainBypassCheck</code> carries a CDR encapsulation of the
1.362 + * <code>struct CosBridging.ChainBypassCheck</code>. This is carried
1.363 + * only in a Request message as described in Section 20.9.1, "CORBA
1.364 + * Chain Bypass," on page 20-19.
1.365 + */
1.366 + const ServiceId ChainBypassCheck = 2;
1.367 +
1.368 + /**
1.369 + * DCOM-CORBA Interworking uses three service contexts as defined in
1.370 + * "DCOM-CORBA Interworking" in the "Interoperability with non-CORBA
1.371 + * Systems" chapter.
1.372 + * <p>
1.373 + * <code>ChainBypassInfo</code> carries a CDR encapsulation of the
1.374 + * <code>struct CosBridging.ChainBypassInfo</code>. This is carried
1.375 + * only in a Reply message as described in Section 20.9.1, "CORBA Chain
1.376 + * Bypass," on page 20-19.
1.377 + */
1.378 + const ServiceId ChainBypassInfo = 3;
1.379 +
1.380 + /**
1.381 + * DCOM-CORBA Interworking uses three service contexts as defined in
1.382 + * "DCOM-CORBA Interworking" in the "Interoperability with non-CORBA
1.383 + * Systems" chapter.
1.384 + * <p>
1.385 + * <code>LogicalThreadId</code>, carries a CDR encapsulation of
1.386 + * the <code>struct CosBridging.LogicalThreadId</code> as described
1.387 + * in Section 20.10, "Thread Identification," on page 20-21.
1.388 + */
1.389 + const ServiceId LogicalThreadId = 4;
1.390 +
1.391 + /**
1.392 + * Identifies a CDR encapsulation of the
1.393 + * <code>IIOP.BiDirIIOPServiceContext</code> defined in Section 15.8,
1.394 + * "Bi-Directional GIOP," on page 15-55.
1.395 + */
1.396 + const ServiceId BI_DIR_IIOP = 5;
1.397 +
1.398 + /**
1.399 + * Identifies a CDR encapsulation of the IOR of the
1.400 + * <code>SendingContext.RunTime</code> object (see Section 5.6, "Access
1.401 + * to the Sending Context Run Time," on page 5-15).
1.402 + */
1.403 + const ServiceId SendingContextRunTime = 6;
1.404 +
1.405 + /**
1.406 + * For information on <code>INVOCATION_POLICIES</code> refer to the
1.407 + * Asynchronous Messaging specification - orbos/98-05-05.
1.408 + */
1.409 + const ServiceId INVOCATION_POLICIES = 7;
1.410 +
1.411 + /**
1.412 + * For information on <code>FORWARDED_IDENTITY</code> refer to the
1.413 + * Firewall specification - orbos/98-05-04.
1.414 + */
1.415 + const ServiceId FORWARDED_IDENTITY = 8;
1.416 +
1.417 + /**
1.418 + * Identifies a CDR encapsulation of a marshaled instance of a
1.419 + * java.lang.Throwable or one of its subclasses as described in Java
1.420 + * to IDL Language Mapping, Section 1.4.8.1, "Mapping of
1.421 + * UnknownExceptionInfo Service Context," on page 1-32.
1.422 + */
1.423 + const ServiceId UnknownExceptionInfo = 9;
1.424 +
1.425 + /**
1.426 + * CORBA formal/02-06-01: 13.7.1:
1.427 + * ExceptionDetailMessage identifies a CDR encapsulation of a wstring,
1.428 + * encoded using GIOP 1.2 with a TCS-W of UTF-16. This service context
1.429 + * may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION
1.430 + * or USER_EXCEPTION. The usage of this service context is defined
1.431 + * by language mappings. <br/> <br/>
1.432 + *
1.433 + * IDL/Java: ptc/02-01-22: 1.15.2:
1.434 + * When a System Exception is marshaled, its GIOP Reply message shall
1.435 + * include an associated ExceptionDetailMessage service context. The
1.436 + * callee's stack trace is often very valuable debugging information but
1.437 + * may contain sensitive or unwanted information. The wstring within the
1.438 + * service context will therefore contain additional information relating
1.439 + * to the exception, for example the result of calling either
1.440 + * printStackTrace(PrintWriter) or getMessage() on the exception. When
1.441 + * unmarshaling a System Exception on the client side, the wstring from
1.442 + * any ExceptionDetailMessage service context shall become the Java error
1.443 + * message in the unmarshaled exception object.
1.444 + */
1.445 + const ServiceId ExceptionDetailMessage = 14;
1.446 +
1.447 +
1.448 + // BEGIN part which lived in Interceptors.idl.
1.449 +
1.450 + /**
1.451 + * An array of <code>TaggedComponent</code> objects.
1.452 + */
1.453 + typedef sequence<IOP::TaggedComponent> TaggedComponentSeq;
1.454 +
1.455 + /**
1.456 + * The formats of IOR components and service context data used by ORB
1.457 + * services are often defined as CDR encapsulations encoding instances
1.458 + * of IDL defined data types. The <code>Codec</code> provides a mechanism
1.459 + * to transfer these components between their IDL data types and their CDR
1.460 + * encapsulation representations.
1.461 + * <p>
1.462 + * A <code>Codec</code> is obtained from the <code>CodecFactory</code>.
1.463 + * The <code>CodecFactory</code> is obtained through a call to
1.464 + * <code>ORB.resolve_initial_references( "CodecFactory" )</code>.
1.465 + */
1.466 + local interface Codec {
1.467 +
1.468 + /**
1.469 + * This exception is thrown by <code>Codec.encode</code> or
1.470 + * <code>Codec.encode_value</code> when the type is invalid for the
1.471 + * encoding. For example, this exception is thrown if the encoding is
1.472 + * <code>ENCODING_CDR_ENCAPS</code> version 1.0 and a type
1.473 + * that does not exist in that version, such as <code>wstring</code>,
1.474 + * is passed to the operation.
1.475 + */
1.476 + exception InvalidTypeForEncoding {};
1.477 +
1.478 + /**
1.479 + * This exception is thrown by <code>Codec.decode</code> or
1.480 + * <code>Codec.decode_value</code> when the data in the byte array
1.481 + * cannot be decoded into an Any.
1.482 + */
1.483 + exception FormatMismatch {};
1.484 +
1.485 + /**
1.486 + * This exception is thrown by <code>decode_value</code> when the given
1.487 + * <code>TypeCode</code> does not match the given byte array.
1.488 + */
1.489 + exception TypeMismatch {};
1.490 +
1.491 + /**
1.492 + * Converts the given any into a byte array based on the encoding
1.493 + * format effective for this <code>Codec</code>.
1.494 + *
1.495 + * @param data The data, in the form of an any, to be encoded into
1.496 + * a byte array.
1.497 + * @return A byte array containing the encoded Any. This byte array
1.498 + * contains both the <code>TypeCode</code> and the data of the type.
1.499 + * @exception InvalidTypeForEncoding thrown if the type is not valid for
1.500 + * the encoding format effective for this <code>Codec</code>.
1.501 + */
1.502 + CORBA::OctetSeq encode (in any data)
1.503 + raises (InvalidTypeForEncoding);
1.504 +
1.505 + /**
1.506 + * Decodes the given byte array into an Any based on the encoding
1.507 + * format effective for this <code>Codec</code>.
1.508 + *
1.509 + * @param data The data, in the form of a byte array, to be decoded into
1.510 + * an Any.
1.511 + * @return An Any containing the data from the decoded byte array.
1.512 + * @exception FormatMismatch is thrown if the byte array cannot be
1.513 + * decoded into an Any.
1.514 + */
1.515 + any decode (in CORBA::OctetSeq data) raises (FormatMismatch);
1.516 +
1.517 + /**
1.518 + * Converts the given any into a byte array based on the encoding
1.519 + * format effective for this Codec. Only the data from the Any is
1.520 + * encoded, not the <code>TypeCode</code>.
1.521 + *
1.522 + * @param data The data, in the form of an Any, to be encoded into
1.523 + * a byte array.
1.524 + * @return A byte array containing the data from the encoded any.
1.525 + * @exception InvalidTypeForEncoding thrown if the type is not valid for
1.526 + * the encoding format effective for this <code>Codec</code>.
1.527 + */
1.528 + CORBA::OctetSeq encode_value (in any data)
1.529 + raises (InvalidTypeForEncoding);
1.530 +
1.531 + /**
1.532 + * Decodes the given byte array into an Any based on the given
1.533 + * <code>TypeCode</code> and the encoding format effective for
1.534 + * this <code>Codec</code>.
1.535 + *
1.536 + * @param data The data, in the form of a byte array, to be decoded
1.537 + * into an Any.
1.538 + * @param tc The TypeCode to be used to decode the data.
1.539 + * @return An Any containing the data from the decoded byte array.
1.540 + * @exception FormatMismatch thrown if the byte array cannot be
1.541 + * decoded into an Any.
1.542 + */
1.543 + any decode_value (in CORBA::OctetSeq data, in CORBA::TypeCode tc)
1.544 + raises (FormatMismatch, TypeMismatch);
1.545 + };
1.546 +
1.547 + /**
1.548 + * Defines an encoding format of a <code>Codec</code>, such as
1.549 + * CDR Encapsulation (<code>ENCODING_CDR_ENCAPS</code>).
1.550 + */
1.551 + typedef short EncodingFormat;
1.552 +
1.553 + /**
1.554 + * The CDR Encapsulation encoding.
1.555 + * @see CodecFactory
1.556 + */
1.557 + const EncodingFormat ENCODING_CDR_ENCAPS = 0;
1.558 +
1.559 + /**
1.560 + * Defines the encoding format of a <code>Codec</code>. This class
1.561 + * details the encoding format, such as CDR Encapsulation encoding, and
1.562 + * the major and minor versions of that format.
1.563 + * <p>
1.564 + * The encodings currently supported are:
1.565 + * <ul>
1.566 + * <li><code>ENCODING_CDR_ENCAPS</code>, version 1.0;</li>
1.567 + * <li><code>ENCODING_CDR_ENCAPS</code>, version 1.1;</li>
1.568 + * <li><code>ENCODING_CDR_ENCAPS</code>, version 1.2;</li>
1.569 + * <li><code>ENCODING_CDR_ENCAPS</code> for all future versions of GIOP as
1.570 + * they arise.</li>
1.571 + * </ul>
1.572 + * Vendors are free to support additional encodings.
1.573 + *
1.574 + * @see ENCODING_CDR_ENCAPS
1.575 + */
1.576 + struct Encoding {
1.577 + /**
1.578 + * The encoding format.
1.579 + */
1.580 + EncodingFormat format;
1.581 +
1.582 + /**
1.583 + * The major version of this Encoding format.
1.584 + */
1.585 + octet major_version;
1.586 +
1.587 + /**
1.588 + * The minor version of this Encoding format.
1.589 + */
1.590 + octet minor_version;
1.591 + };
1.592 +
1.593 + /**
1.594 + * <code>Codecs</code> are obtained from the <code>CodecFactory</code>.
1.595 + * The <code>CodecFactory</code> is obtained through a call to
1.596 + * <code>ORB.resolve_initial_references( "CodecFactory" )</code>.
1.597 + */
1.598 + local interface CodecFactory {
1.599 + /**
1.600 + * This exception is thrown by <code>CodecFactory.create_codec</code> when
1.601 + * the factory cannot create a <code>Codec</code> for a given encoding.
1.602 + */
1.603 + exception UnknownEncoding {};
1.604 +
1.605 + /**
1.606 + * Create a <code>Codec</code> of the given encoding.
1.607 + * <p>
1.608 + * @param enc The encoding for which to create a <code>Codec</code>.
1.609 + * @return A <code>Codec</code> obtained with the given encoding.
1.610 + * @exception UnknownEncoding thrown if this factory cannot create a
1.611 + * <code>Codec</code> of the given encoding.
1.612 + */
1.613 + Codec create_codec (in Encoding enc) raises (UnknownEncoding);
1.614 + };
1.615 +
1.616 + // END part which lived in Interceptors.idl.
1.617 +
1.618 +};
1.619 +
1.620 +#endif // _IOP_IDL_
