Provides the mapping of the OMG CORBA APIs to the JavaTM programming language, including the class ORB, which is implemented so that a programmer can use it as a fully-functional Object Request Broker (ORB).

An ORB handles (or brokers) method invocations between a client and the method's implementation on a server. Because the client and server may be anywhere on a network, and because the invocation and implementation may be written in different programming languages, an ORB does a great deal of work behind the scenes to accomplish this communication.

What the General User Needs to Know

Most of what an ORB does is completely transparent to the user, and a major portion of the CORBA package consists of classes used by the ORB behind the scenes. The result is that most programmers will use only a small part of this package directly. In fact, most programmers will use only a few methods from the ORB class, some exceptions, and occasionally, a holder class.

ORB Methods

These are the ORB methods that a general user might invoke:

Exceptions

Exceptions in Java IDL are similar to those in any code written in the Java programming language. If a method is defined to throw an exception, then any code using that method must have a try/catch block and handle that exception when it is thrown.

The documentation on Java IDL exceptions has more information and explains the difference between system exceptions and user-defined exceptions.

The following is a list of the system exceptions (which are unchecked exceptions inheriting through org.omg.CORBA.SystemException from java.lang.RuntimeException) that are defined in the package org.omg.CORBA:


        BAD_CONTEXT
        BAD_INV_ORDER
        BAD_OPERATION
        BAD_PARAM
        BAD_TYPECODE
        COMM_FAILURE
        DATA_CONVERSION
        FREE_MEM
        IMP_LIMIT
        INITIALIZE
        INTERNAL
        INTF_REPOS
        INVALID_TRANSACTION
        INV_FLAG
        INV_IDENT
        INV_OBJREF
        INV_POLICY
        MARSHAL
        NO_IMPLEMENT
        NO_MEMORY
        NO_PERMISSION
        NO_RESOURCES
        NO_RESPONSE
        OBJECT_NOT_EXIST
        OBJ_ADAPTER
        PERSIST_STORE
        TRANSACTION_REQUIRED
        TRANSACTION_ROLLEDBACK
        TRANSIENT
        UNKNOWN

The following is a list of user-defined exceptions defined in the package org.omg.CORBA.


        Bounds
        UnknownUserException
        WrongTransaction 
        PolicyError
Note that there are some packages inside the CORBA package with "Package" as part of their names. These packages are generally quite small because all they do is provide exceptions or classes for use by interfaces and classes in the CORBA package.

For example, the package org.omg.CORBA.TypeCodePackage contains two exceptions thrown by methods in the class TypeCode. These exceptions are:

The package org.omg.CORBA.ORBPackage contains two exceptions: The package org.omg.CORBA.DynAnyPackage contains four exceptions:

Holder classes

Holder classes are generated by the idltojava compiler as support for out and inout parameter passing modes. Because the Java programming language does not support out or inout parameters, holder classes are needed as a means of passing a parameter that can be modified. Holder classes implement the org.omg.CORBA.portable.Streamable interface in order to support portable stubs and skeletons.

Holder classes are named by appending "Holder" to the name of the type. Note that the name of the type refers to its name in the Java programming langua ge. For example, a holder class for the interface named Account in the Java programming language would be named AccountHolder.

There are holder classes available for all of the basic IDL data types in the org.omg.CORBA package. So, for instance, there are classes already defined for IntHolder, ShortHolder, LongHolder, FloatHolder, ByteHolder, CharHolder, and so on. New holder classes are generated for all named user-defined IDL types except those defined by a typedef.

Each holder class contains the following:

The default constructor for a holder class sets the value field to the default value for the type as defined by the Java programming language. These default values are:

As an example, if the interface Account, defined in OMG IDL, were mapped to the Java programming language, the following holder class would be generated:



final public class AccountHolder implements
          org.omg.CORBA.portable.Streamable {
    public Account value;
         // the field that holds an Account object
        public AccountHolder() {}
         // the default constructor
        public AccountHolder(Account initial) {...}
         // creates a new AccountHolder from initial
        public void _read(org.omg.CORBA.portable.InputStream is) {...}
         // reads the contents of is and assigns the contents to value
        public void _write(org.omg.CORBA.portable.OutputStream os) {...}
         // writes value to os
        public org.omg.CORBA.TypeCode _type() {...}
         // returns the type code for Account
}


The Holder classes defined in the package org.omg.CORBA are:


     AnyHolder
     AnySeqHelper
     BooleanHolder
     BooleanSeqHolder
     ByteHolder
     CharHolder
     CharSeqHolder
     DoubleHolder
     DoubleSeqHolder
     FixedHolder
     FloatHolder
     FloatSeqHolder
     IntHolder
     LongHolder
     LongLongSeqHolder
     LongSeqHolder
     ObjectHolder
     OctetSeqHolder
     PrincipalHolder
     ServiceInformationHolder
     ShortHolder
     ShortSeqHolder
     StringHolder
     TypeCodeHolder
     ULongLongSeqHolder
     ULongSeqHolder
     UShortSeqHolder
     ValueBaseHolder
     WCharSeqHolder

Helper Classes

Some of the classes in this package are "helper" classes. These classes fall into two broad categories, helpers for value types and helpers for non value types. Because all of the helper classes in one category provide the same methods, one generic explanation of each category of helper classes is presented here.

Note that, generally, the only helper method an application programmer uses is the narrow method. The other methods are normally used behind the scenes and are transparent to the programmer.

When OMG IDL is mapped to the Java programming language, a "helper" class is generated for each user-defined type. This generated class will have the name of the user-defined type with the suffix Helper appended. For example, if the interface Account is defined in OMG IDL, the idltojava compiler will automatically generate a class named AccountHelper. The AccountHelper class will contain the static methods needed for manipulating instances of the type, in this case, Account objects. These methods provide the means to insert the type into an Any object, extract the type from an Any object, get the type code for the type, get the type's repository id, read the type from an input stream, and write the type to an output stream. Every user-defined type's helper class will include these basic methods. If a user-defined type is a value type IDL type, it's helper class also has to implement the ValueHelper interface, so this category of helper classes will contain additional methods.

In addition, if the IDL type maps to an interface in the Java programming language, the helper class will also contain a method for casting an object (narrowing it) to the type.

The narrow Method

When an object is the return value for a method, it is returned in the form of a generic object, either an org.omg.CORBA.Object object or a java.lang.Object object. This object must be cast to its more specific type before it can be operated on. For example, an Account object will be returned as a generic object and must be narrowed to an Account object so that Account methods may be called on it.

The narrow method has two forms, one that takes an org.omg.CORBA.Object object and one that takes a java.lang.Object object. Whether the interface is abstract or not determines which narrow method its helper class will provide. The helper class for an interface that is not abstract will have a narrow method that takes a CORBA object, whereas the narrow method for an interface that is abstract will take an object in the Java programming language. The helper class for a non-abstract interface that has at least one abstract base interface will provide both versions of the narrow method.

Example of a Basic Helper Class

A basic helper class, for purposes of this explanation, is one with the methods that are provided by every helper class, plus a narrow method if the type defined in OMG IDL maps to an interface in the Java programming language. Types that are not value types will have a basic helper class generated for them.

For example, assuming that the interface Account is not a value type IDL type and is also not an abstract interface and has no abstract base interfaces, its AccountHelper class will include the following methods:

Additional Methods for Value Type Helper Classes

A helper class for a value type includes some additional methods because it must implement the org.omg.CORBA.portable.ValueHelper interface. The main difference is that value types are types that can be passed by value as parameters or return values of a method, which means that they must be serializable.

Assuming that Address is a value type, the AddressHelper class will include the following additional methods:

The Helper classes defined in the package org.omg.CORBA are:


     AnySeqHelper
     AttrDescriptionSeqHelper
     AttributeDescriptionHelper
     AttributeModeHelper
     BooleanSeqHelper
     CharSeqHelper
     CompletionStatusHelper
     ContextIdSeqHelper
     DefinitionKindHelper
     DoubleSeqHelper
     ExcDescriptionSeqHelper
     ExceptionDescriptionHelper
     FieldNameHelper
     FloatSeqHelper
     IDLTypeHelper
     IdentifierHelper
     LongLongSeqHelper
     LongSeqHelper
     NameValuePairHelper
     ObjectHelper
     OctetSeqHelper
     OperationDescriptionHelper
     OperationModeHelper
     ParDescriptionSeqHelper
     ParameterDescriptionHelper
     ParameterModeHelper
     RepositoryIdHelper
     ServiceDetailHelper
     ServiceInformationHelper
     SetOverrideTypeHelper
     ShortSeqHelper
     StringValueHelper
     StructMemberHelper
     ULongLongSeqHelper
     ULongSeqHelper
     UShortSeqHelper
     UnionMemberHelper
     ValueBaseHelper
     ValueMemberHelper
     VersionSpecHelper
     VisibilityHelper
     WCharSeqHelper
     WStringValueHelper

For Advanced Users

The other classes and interfaces in the CORBA package, which are used behind the scenes, can be put into four groups. Three of the groups are used with requests in some capacity, and the fourth group, concerning the Interface Repository, is a category by itself.

Classes Created by an ORB

The first group contains classes that are created by an ORB and contain information used in request operations. They are listed in roughly increasing order of complexity:

Classes That Deal with Requests

The second group of classes deals with requests:

Interfaces That Serve as Constants

The third group contains interfaces that serve as constants. The IDL-to-Java mapping mandates that IDL enums are mapped to a Java class with the enumerated values represented as public static final fields in that class (e.g. DefinitionKind). On the other hand IDL constants defined outside of an IDL interface are mapped to a Java interface for each constant.

This is why several interfaces in the org.omg.CORBA package consist of a single field, value, which is a short. This field is a constant used for such things as an error code or value modifier. For example, the value field of the interface BAD_POLICY is one of the possible reasons for the exception PolicyError to be thrown. To specify this error code, you would use BAD_POLICY.value.

The exception PolicyError uses the value field of the following interfaces as its possible error codes.

The method TypeCode.type_modifier returns the value field of one of the following interfaces. The VM in the names of these interfaces stands for "value modifier." The following constants are returned by a ValueMember object's access method to denote the visibility of the ValueMember object. These flags, used in NamedValue objects or as parameters to methods, are defined in the following interfaces:

Interface Repository Interfaces and Classes

A fourth group contains the Interface Repository interfaces and classes, which are generated by the idltojava compiler from the OMG IDL interface ir.idl. The purpose of the Interface Repository is to identify the interfaces stored in it so that they can be accessed by an ORB. Each module, type, interface, attribute, operation, parameter, exception, constant, and so on is described completely by the Interface Repository API.

An ORB does not require that there be an interface repository, and Java IDL does not include one. Even though this release does not include an implementation of an interface repository, the following IR classes and interfaces have been included for the purpose of creating type codes (see create_value_tc, create_struct_tc, create_union_tc and create_exception_tc methods in interface org.omg.CORBA.ORB)
&nbs

Related Documentation

For overviews, guides, and a tutorial, please see:

CORBA Features Not Implemented in Java IDL


Some of the API included in org.omg.CORBA is provided for conformance with the current OMG CORBA specification but is not implemented in Sun's release of the JDKTM. This enables other JDK licensees to provide implementations of this API in standard extensions and products.

General Summary of Features or API Not Implemented in This Release:


Specific List of Unimplemented Features in Package org.omg.CORBA


Unimplemented Interfaces in package org.omg.CORBA:

Unimplemented Methods in package org.omg.CORBA:

@since JDK1.2