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.
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:
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:
value
, which contains an instance of the typed
value
value
field
value
field to an output
stream
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:
false
for boolean
types
0
for numeric and char types
null
for strings
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
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.
narrow
Methodorg.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.
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:
public static void insert(org.omg.CORBA.Any a, Account ac)
Account
object into an Any
object.
Parameters: a theAny
object into which theAccount
object will be inserted ac theAccount
object to be inserted
public static Account extract(org.omg.CORBA.Any a)
Account
object from an Any
object.
Parameters: a theAny
object from which theAccount
object will be extracted Returns: theAccount
object that is the value for the givenAny
object
public static org.omg.CORBA.TypeCode type()
Returns:
the typecode for an Account
object
public static String id()
Returns:
the repository id of an Account
object
public static Account
read(org.omg.CORBA.portable.InputStream istream)
Account
object from an input stream.
Parameters: istream the input stream from which theAccount
object will be read Returns: theAccount
object that was contained in the input stream
public static void
write(org.omg.CORBA.portable.OutputStream ostream)
Account
object to an output stream.
Parameters:
ostream the output stream to which the Account
object will be written
public static Account narrow(org.omg.CORBA.Object obj)
Object
object to an Account
object.
Parameters: obj the CORBAObject
that will be narrowed to this type Returns: the CORBAObject
as anAccount
object
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:
public static ValueHelper get_instance()
AddressHelper
, creating it if necessary.
Returns: anAddressHelper
object, which implements the interfaceValueHelper
public java.io.Serializable
read_Value(org.omg.CORBA.portable.InputStream istream)
Address
from the given input stream.
Parameters: istream the input stream from which theAddress
object will be read Returns: the serializedAddress
object
public void write_Value(org.omg.CORBA.portable.OutputStream os,
java.io.Serializable obj)
Address
to the given output stream.
Parameters: ostream the output stream to which theAddress
object will be written obj the serializedAddress
object that will be written
public Class get_class()
Address
.
Returns:
the Class
object for this type
public String get_id()
Address
.
Returns: the repository id for this type
public String [] get_truncatable_base_ids()
Address
.
Returns:
an array of String
objects containing the truncatable base
repository ids for this type
public org.omg.CORBA.TypeCode get_type()
Address
.
Returns: theTypeCode
object indicating the type of anAddress
object
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
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.
ValueMember
object's
access method to denote the visibility of the ValueMember
object.
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