ch03.htm

corba比较入门级的介绍详细间接了corba访问发布各种细节。

in the context of IDL) each have attributes or methods that refer to the other class.
<H4><FONT COLOR="#000077">Listing 3.9. Circular reference example.</FONT></H4>
<PRE><FONT COLOR="#0066FF">1: module Circular {
2:     interface A {
3:         void useB(in B aB);
4:     }
5:     interface B {
6:         void useA(in A anA);
7:     }
8: }; </FONT></PRE>
<P>In Listing 3.9, the A interface references the B interface, which in turn references
the A interface. If you were to attempt to compile this code as it is listed, the
IDL compiler would report an error in the useB() method definition because the B
interface is unknown. If you were to reverse the order of definition of the A and
B interfaces, the IDL compiler would signal an error in the useA() method because
the A interface is unknown. As you can see, the circular reference problem is a bit
of a Catch 22.</P>
<P>C and C++ programmers might already know the answer to the circular reference
problem: the <I>forward declaration.</I> A forward declaration allows you to inform
the IDL compiler that you intend to define the declared type later, without defining
the type at that point. (You will have to define the type at some point, however.)
The syntax of a forward declaration, which closely resembles the C/C++ syntax, is
simple:</P>
<PRE><FONT COLOR="#0066FF">interface B;
</FONT></PRE>
<P>This tells the IDL compiler that a definition for the Bar interface will appear
at some point in the future but that for now it should accept references to the as-yet-undefined
Bar. Listing 3.10 illustrates how the forward declaration would fit into the previous
example.
<H4><FONT COLOR="#000077">Listing 3.10. Circular reference example.</FONT></H4>
<PRE><FONT COLOR="#0066FF"> 1: module Circular {
 2:     // Forward declaration of the B interface.
 3:     interface B;
 4:     interface A {
 5:         void useB(in B aB);
 6:     }
 7:     interface B {
 8:         void useA(in A anA);
 9:     }
10: }; </FONT></PRE>
<P>In Listing 3.10, when the IDL compiler reaches the definition for useB(), it sees
that the B interface has already been declared (by the forward declaration) and thus
will not report an error.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>You could just as well have defined the B interface first and made a
	forward declaration to the A interface; the IDL compiler does not impose a particular
	order in which interfaces must be defined. 
<HR>


</BLOCKQUOTE>

<H2><A NAME="Heading26"></A><FONT COLOR="#000077">Container Types</FONT></H2>
<P>Most programming languages include constructs for dealing with multiple values
of similar types. Arrays are common throughout programming languages: Java includes
java.util.Vector, C++ features its Standard Template Library (STL), and, of course,
various libraries of container classes abound. IDL is no exception, featuring two
such constructs: the sequence, which is a dynamically sizable array, and the array,
which mirrors the array constructs found in many languages.
<H3><A NAME="Heading27"></A><FONT COLOR="#000077">The sequence Type</FONT></H3>
<P>An IDL sequence is simply a dynamically sizable array of values. These values
can be dynamically inserted in or removed from the sequence; the sequence manages
its size accordingly. All values of a sequence must be of the same type or derived
from the same type (with the exception of the any type. For example:</P>
<PRE><FONT COLOR="#0066FF">sequence&lt;float&gt; temperatureSequence;
</FONT></PRE>
<P>defines a sequence of float values and assigns this type to the variable temperatureSequence.
Values of type float can subsequently be added to temperatureSequence, or values
can be removed. Recalling the Appliances example (refer to Listing 3.8), you can
also create a sequence of Television objects:</P>
<PRE><FONT COLOR="#0066FF">sequence&lt;Television&gt; televisionInventory;
</FONT></PRE>
<P>In this case, televisionInventory can be populated with objects of type Television,
or any objects derived from<I> </I>Television, in this case WWWTelevision. If you
had created a third interface derived from Television--for instance, PortableTelevision--the
televisionInventory sequence could contain Televisions, WWWTelevisions, and PortableTelevisions.
<H3><A NAME="Heading28"></A><FONT COLOR="#000077">The Array</FONT></H3>
<P>An IDL array corresponds directly to the array constructs in C, C++, and Java.
An array stores a known-length series of similar data types. For example:</P>
<PRE><FONT COLOR="#0066FF">string DayNames[7];
</FONT></PRE>
<P>defines an array, with the name DayNames, of seven string values. Arrays can hold
elements of any IDL data type; as in the Appliances example (refer to Listing 3.8),
you can define the following array:</P>
<PRE><FONT COLOR="#0066FF">Television TVArray[10];
</FONT></PRE>
<P>to define an array of ten Televisions. Remember that, due to polymorphism, each
array element can hold either a plain Television or the derived WWWTelevision.
<H2><A NAME="Heading29"></A><FONT COLOR="#000077">The exception Type</FONT></H2>
<P>One concept embraced recently by developers is the use of exceptions to perform
error handling. Exceptions, featured in object-oriented languages such as Java and
C++, are constructs which are created to signify some error condition. When a method
raises an exception, the method stops what it is doing and returns immediately. When
the calling method catches the exception, it can either handle the exception or throw
it up to that method's caller. This process might continue all the way up to the
top level (typically, main()); if the top-level method does not handle the exception,
the application usually exits (although allowing this to happen is generally considered
poor programming practice).</P>
<P><B>New Term: </B>When a method passes an exception back to its caller, it is said
that the method <I>throws</I> an exception, or in CORBA-speak, <I>raises</I> an exception.</P>
<P>CORBA and IDL fully support exception handling through predefined standard exceptions
and user-defined exceptions. IDL allows developers to define exceptions and specify
which exceptions are raised by what methods. When an exception is raised, the ORB
passes that exception back to the calling object's ORB, which then passes the exception
back to the calling object. In this way, CORBA extends the familiar exception-passing
mechanism to a distributed architecture.</P>
<P>In addition to their distributed nature, IDL exceptions differ from their counterparts
in C++ and Java in other ways. C++ exceptions can be virtually any type; C++ does
not even require that exception objects be derived from a certain type (for instance,
a method could throw a const char*, if it so desired). Java exceptions can be any
type that implements the java.lang.Throwable interface. IDL, however, is somewhat
more restrictive than these languages; exception objects must be declared explicitly
as such. Furthermore, whereas C++ and Java allow exception types to be derived from
other types, IDL does not support inheritance of exception types.
<H3><A NAME="Heading30"></A><FONT COLOR="#000077">exception</FONT></H3>
<P>The IDL exception type itself is similar to a struct type; it can contain various
data members (but no methods). The definition for an exception type also resembles
the struct definition, as the example in Listing 3.11 shows. The example demonstrates
that an exception need not have any members at all; sometimes the mere act of raising
an exception provides enough error-handling information.
<H4><FONT COLOR="#000077">Listing 3.11. exception definition example.</FONT></H4>
<PRE><FONT COLOR="#0066FF"> 1: // This exception might be used where a file to be opened
 2: // couldn't be located. Since it might be useful for the caller
 3: // to know the invalid filename, the exception provides that
 4: // information.
 5: exception FileNotFoundException {
 6:     string fileName;
 7: };
 8: // This exception might be used where a particuar operation,
 9: // which was supposed to have completed within a given amount
10: // of time, failed to do so. The exception provides the
11: // operation name and the time length given for the operation.
12: exception OperationTimedOutException {
13:     string operationName;
14:     long timeoutLength;
15: };
16: // This exception might be used where an attempt to log into a
17: // system failed. No other information is necessary, so none is
18: // provided.
19: exception InvalidLoginException {
20: };</FONT></PRE>
<H3><A NAME="Heading31"></A><FONT COLOR="#000077">Standard Exceptions</FONT></H3>
<P>In addition to allowing developers to create user-defined exceptions, CORBA also
provides a number of standard exceptions, or system<I> </I>exceptions. Exceptions
in this set might be raised by any remote method invocation. IDL method definitions
don't explicitly declare that they raise a system exception; rather, these exceptions
are raised implicitly. (Actually, when the IDL code is compiled, the generated method
definitions do declare that CORBA system exceptions are raised, as well as any user-defined
exceptions raised by those methods.) In addition to regular methods, even the accessor/mutator
methods--corresponding to the attributes of interfaces--can raise standard exceptions,
even though they cannot raise user-defined exceptions.</P>
<P>The standard exceptions provided by CORBA are listed in Table 3.1.
<H4><FONT COLOR="#000077">Table 3.1. CORBA standard exceptions.</FONT></H4>
<P>
<TABLE BORDER="1">
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT"><B>Exception Name</B></TD>
		<TD ALIGN="LEFT"><B>Description</B></TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">UNKNOWN</TD>
		<TD ALIGN="LEFT">The unknown exception.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">BAD_PARAM</TD>
		<TD ALIGN="LEFT">An invalid parameter was passed.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">NO_MEMORY</TD>
		<TD ALIGN="LEFT">Dynamic memory allocation failure.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">IMP_LIMIT</TD>
		<TD ALIGN="LEFT">Violated implementation limit.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">COMM_FAILURE</TD>
		<TD ALIGN="LEFT">Communication failure.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">INV_OBJREF</TD>
		<TD ALIGN="LEFT">Invalid object reference.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">NO_PERMISSION</TD>
		<TD ALIGN="LEFT">No permission for attempted operation.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">INTERNAL</TD>
		<TD ALIGN="LEFT">ORB internal error.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">MARSHAL</TD>
		<TD ALIGN="LEFT">Error marshaling parameter or result.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">INITIALIZE</TD>
		<TD ALIGN="LEFT">ORB initialization failure.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">NO_IMPLEMENT</TD>
		<TD ALIGN="LEFT">Operation implementation unavailable.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">BAD_TYPECODE</TD>
		<TD ALIGN="LEFT">Bad TypeCode.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">BAD_OPERATION</TD>
		<TD ALIGN="LEFT">Invalid operation.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">NO_RESOURCES</TD>
		<TD ALIGN="LEFT">Insufficient resources for request.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">NO_RESPONSE</TD>
		<TD ALIGN="LEFT">Response to request not yet available.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">PERSIST_STORE</TD>
		<TD ALIGN="LEFT">Persistent storage failure.</TD>
	</TR>
	<TR ALIGN="LEFT" VALIGN="TOP">
		<TD ALIGN="LEFT">BAD_INV_ORDER</TD>
		<TD ALIGN="LEFT">Routine invocations out of order.</TD>