ch03.htm

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

In a few moments, you'll explore what each of these modifiers means, how it is used,
and why.
<H4><FONT COLOR="#000077">Methods and Parameters</FONT></H4>
<P>Methods of an interface are, in essence, what define an object's functionality.
Although the object's implementation determines how the object behaves, the interface's
method definitions determine what behavior the object implementing that interface
provides. These method definitions are often called <I>method signatures</I>, or
just <I>signatures</I>. IDL methods can use any IDL data types as input and output
parameters--primitive types, structs, sequences, and even interfaces. The general
syntax for a method declaration is as follows:</P>
<PRE><FONT COLOR="#0066FF">[oneway] return_type methodName(param1_dir param1_type param1_name,
        param2_dir param2_type param2_name, ...);
</FONT></PRE>
<P>The oneway modifier is optional; return_type specifies the type of data returned
by the method, the paramndir modifier specifies the direction of each parameter (one
of in, out, or inout), and paramntype specifies the type of each parameter. Modifiers
such as these are not commonly found in programming languages and thus merit some
attention.</P>
<P><B>New Term: </B>A <I>method signature,</I> often simply called a <I>signature,</I>
describes what a method does (ideally, the method name should specify, at least in
general terms, what the method does), what parameters (and their types) the method
takes as input, and what parameters (and their types) it returns as output. in, out,
and inout Parameters As already mentioned, parameters in a method can be declared
as in, out, or inout. These names are fairly self-explanatory: An in parameter serves
as input to the method; an out parameter is an output from the method; and an inout
parameter serves as an input to and an output from the method.</P>
<P>In remote method terms, this means that before the method is invoked, any in and
inout parameters are marshaled across the network to the remote object. After the
method executes, any out and inout parameters--along with the method's return value,
if any--are marshaled back to the calling object. Note particularly that inout parameters
are marshaled twice--once as an input value and once as an output value. oneway Methods
The typical paradigm for calling a remote method is as follows: When an object calls
a method on a remote object, that calling object waits (this is called <I>blocking</I>)
for the method to execute and return. When the remote object finishes processing
the method invocation (often called a <I>request</I>), it returns to the calling
object, which then continues its processing. Figure 3.2 illustrates this process.</P>
<P><B>New Term: </B>In general, the term <I>blocking</I> refers to any point at which
a process or thread is waiting for a particular resource or another process/thread.
Within the context of CORBA, if a client invokes a remote method and must wait for
the result to be returned, the client is said to <I>block.</I></P>
<P>A <I>request</I> is simply another name for a remote method invocation. The term
is commonly used when referring to the operation of a distributed system. In fact,
when you study CORBA's Dynamic Invocation Interface (DII), you'll see that remote
methods can be invoked through a Request object. <BR>
<BR>
<A HREF="javascript:popUp('02.jpg')"><B>Figure 3.2.</B></A> <I>Blocking on a remote
method call.</I> <BR>
<BR>
When a method is declared oneway, it means that the object calling that method will
not block. Rather, that object will call the remote method and then immediately continue
processing, while the remote object executes the remote method. The advantage to
this approach is that the calling object can continue working rather than wait for
the remote object to complete the request. Figure 3.3 illustrates the operation of
a oneway method. <BR>
<BR>
<A HREF="javascript:popUp('03.jpg')"><B>Figure 3.3.</B></A> <I>The oneway (nonblocking)
remote method call.</I> <BR>
<BR>
The flexibility of the oneway calling paradigm comes at a price, however. Because
the method invocation returns before the method execution is completed, the method
cannot return a value. Therefore, for a oneway method, the return value must be declared
void, and all parameters must be declared as in (out and inout parameters are not
allowed). In addition, a oneway method cannot raise any exceptions. Also, the calling
object has no way of knowing whether the method executed successfully; the CORBA
infrastructure makes a best-effort attempt to execute the method, but success is
not guaranteed. (Readers familiar with the User Datagram Protocol will recognize
the similarity.) Therefore, oneway methods are most useful for situations in which
one object wants to inform another object of a particular status but (1) does not
consider the message to be essential and (2) does not expect (or desire) a response.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>A method that has only in parameters, returns a void, and does not raise
	any exceptions is not automatically a oneway method. The difference between such
	a method and a oneway method is that, whereas the latter is not guaranteed to execute
	successfully (and the client will have no way of determining whether it did), the
	former will result in the client blocking until a result is returned from the remote
	method (even though the result will be null). The important difference here is that
	the success of the non-oneway method can be determined, because a CORBA system exception
	would be raised if this were not the case. 
<HR>


</BLOCKQUOTE>

<P>There are ways of overcoming the issues associated with blocking. Most commonly,
the use of multithreading can circumvent the blocking &quot;problem&quot; by creating
a separate thread to invoke the remote method. While that thread is blocked waiting
for the result to be returned, other threads can continue working. On Day 10 you'll
study issues such as this in greater detail and learn about some possible resolutions
to these issues.
<H4><FONT COLOR="#000077">Attributes</FONT></H4>
<P>An attribute of an IDL interface is analogous to an attribute of a Java or C++
class, with the exception that IDL attributes always have public visibility. (Indeed,
everything in an IDL interface has public visibility.) The general syntax for defining
an attribute is this:</P>
<PRE><FONT COLOR="#0066FF">[readonly] attribute attribute_type attributeName;
</FONT></PRE>
<P>In Java and C++, it is generally considered good programming practice to provide
accessor and mutator methods for attributes of a class, and to make the attribute
itself protected or private. IDL advances this concept one step further: IDL attributes
map to accessor and mutator methods when the IDL is compiled. For instance, the following
definition:</P>
<PRE><FONT COLOR="#0066FF">attribute short myChannel;
</FONT></PRE>
<P>maps to the following two methods:</P>
<PRE><FONT COLOR="#0066FF">short myChannel();
void myChannel(short value);
readonly Attributes </FONT></PRE>
<P>The preceding example indicates the optional use of the readonly modifier. As
the name suggests, this modifier is used to specify that a particular attribute is
for reading only; its value cannot be modified directly by an external object. (The
object implementing the interface is, of course, free to modify values of its own
attributes as it sees fit.) Although a non-readonly attribute maps to a pair of accessor/mutator
methods, for a readonly attribute the IDL compiler will generate only an accessor
method.
<H4><FONT COLOR="#000077">Inheritance of interfaces</FONT></H4>
<P>IDL interfaces, like the Java and C++ constructs they resemble, support the notion
of inheritance<I>.</I> That is, an interface can inherit the methods and attributes
of another (one can also say that the former interface derives<I> </I>from or is
derived from the latter). In addition to inheriting its superclass' methods and attributes,
a subclass can define additional methods and attributes of its own. The subclass
can also be substituted anywhere that its superclass is expected; for example, if
a method takes a parameter of type Fish and the Halibut interface is a subclass of
the Fish interface, then that method can be called with a parameter of type Halibut
instead of Fish.</P>
<P><B>New Term: </B>A <I>subclass</I>, or <I>derived class</I>, is a class that inherits
methods and attributes from another class. The class from which these methods and
attributes are inherited is known as the <I>superclass</I>, or <I>parent class</I>.
Although IDL uses interfaces and not classes, these general terms can still be applied.</P>
<P><B>New Term: </B>In object speak, <I>polymorphism</I> refers to the ability to
substitute a derived class into a parameter that expects that class's superclass.
Because in a sense the subclass <I>is</I> an instance of the superclass (as a Beagle
<I>is</I> a Dog), any operation that acts on the superclass can also act on the subclass.
Polymorphism is a fundamental property of object-oriented architecture.</P>
<P>The syntax for specifying interface inheritance resembles the syntax used by C++
and Java. The exception in IDL is that no visibility for the superclass is specified
(recall that all methods and attributes are implicitly public). The inheritance syntax
is illustrated in Listing 3.6.
<H4><FONT COLOR="#000077">Listing 3.6. Inheritance syntax example.</FONT></H4>
<PRE><FONT COLOR="#0066FF">1: interface Fish {
2:     ...
3: };
4: interface Halibut : Fish {
5:     ...
6: }; </FONT></PRE>
<P>In Listing 3.6, the Halibut interface inherits from the Fish interface, as indicated
by the colon (:) operator. Attributes and methods have, of course, been omitted.</P>
<P>One last word with respect to inheritance of IDL interfaces: IDL interfaces, like
C++ classes, can inherit from more than one superclass. This capability, known as
<I>multiple inheritance,</I> is not available in Java, although Java allows a single
class to implement multiple interfaces, a feature that often achieves the same result
as multiple inheritance. The syntax for multiple inheritance in IDL is illustrated
in Listing 3.7.
<H4><FONT COLOR="#000077">Listing 3.7. Multiple inheritance syntax example.</FONT></H4>
<PRE><FONT COLOR="#0066FF">1: interface LandVehicle {
2:     ...
3: };
4: interface WaterVehicle {
5:     ...
6: };
7: interface AmphibiousVehicle : LandVehicle, WaterVehicle {
8:     ...
9: }; </FONT></PRE>
<P>In Listing 3.7, the AmphibiousVehicle interface, being both a LandVehicle and
a WaterVehicle, inherits both those interfaces. Note that due to the polymorphic
behavior of derived classes, an AmphibiousVehicle can be substituted for either a
LandVechile or a WaterVehicle.
<H4><FONT COLOR="#000077">interface Definition Syntax</FONT></H4>
<P>The syntax for an interface definition is not unlike the syntax used in C++ or
Java. The body of the interface contains method signatures and attribute declarations,
in no particular order. A few sample interface definitions appear in Listing 3.8.
<H4><FONT COLOR="#000077">Listing 3.8. Sample IDL interfaces.</FONT></H4>
<PRE><FONT COLOR="#0066FF"> 1: // This module defines some useful household appliances.
 2: module Appliances {
 3:     // Television interface definition.
 4:     interface Television {
 5:         // My serial number.
 6:         readonly attribute string mySerialNumber;
 7:         // My current volume level.
 8:         attribute short myVolume;
 9:         // My current channel.
10:         attribute short myChannel;
11:         // Turn this Television on.
12:         void turnOn();
13:         // Turn this Television off.
14:         void turnOff();
15:         // Set this Television's sleep timer.
16:         void setSleepTimer(in short minutes);
17:     };
18:     interface WWWTelevision : Television {
19:         // Surf to the given URL.
20:         void surfTo(in Internet::URL url);
21:     };
22: }; </FONT></PRE>
<P><BR>
Close inspection reveals that IDL interfaces don't specify constructors or destructors.
Java developers should not be surprised at this because Java interfaces don't include
constructors or destructors either (but then again, there are also no destructors
in Java). C++ developers, however, might be wondering what happened to the constructors
and destructors. As it turns out, constructors and destructors are still a part of
CORBA objects; they just aren't included as part of the object's interface. You'll
see the reason for this when you begin building a CORBA application in the next chapter.
<H2><A NAME="Heading23"></A><FONT COLOR="#000077">Other IDL Constructs</FONT></H2>
<P>IDL supports several other useful constructs. Among these are the capability to
refer to any IDL type by a user-specified type name and the capability to declare
a type name without defining it, which is helpful for handling circular references.
<H3><A NAME="Heading24"></A><FONT COLOR="#000077">typedef</FONT></H3>
<P>Like C and C++, IDL supports a typedef statement to create a user-defined type
name. typedef can make any IDL type accessible by a type name of the user's choosing,
a capability that adds convenience to the language. For example, in Listing 3.8,
the Television interface contains the member mySerialNumber, which is of type string.
Because the use of the string type isn't very telling, it might be preferable to
define a SerialNumber type that can then be used by any interfaces and methods requiring
a serial number. Assuming that the string type is adequate for storing serial numbers,
it would be convenient to use a string type but refer to it as a SerialNumber. The
typedef statement allows you to do just this. The statement</P>
<PRE><FONT COLOR="#0066FF">typedef string SerialNumber;
</FONT></PRE>
<P>means that anywhere the SerialNumber type is found, it should be treated as a
string.
<H3><A NAME="Heading25"></A><FONT COLOR="#000077">Forward Declarations</FONT></H3>
<P>Occasionally, you will create interfaces that reference each other--that is, within
the first interface you'll have an attribute of the second interface's type, or a
method that uses the second interface's type as a parameter or return value. The
second interface, similarly, will reference the first interface in the same way.
Listing 3.9 illustrates this concept, known as a <I>circular reference.</I></P>
<P><B>New Term: </B>A <I>circular reference</I> occurs when two classes (or interfaces,