ch10.htm

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

enhancements to the CORBA architecture.) Sometimes it is far more efficient for a
server to return an object by value to a client so that the client can act on the
object locally rather than call a series of remote methods--each of which incurs
the overhead of executing a method remotely--on the object. See Figure 10.7 for an
illustration of this scenario.</P>
<P>Clearly, if a client is to invoke a large number of methods on an object, it is
preferable, in terms of efficiency, to act on a local copy of the object rather than
a remote one. This is particularly true if the parameters or return value of the
method(s) are complex values. Such values are even more expensive to transmit across
the network, as is the case with remote methods.</P>
<P>If passing objects by value is sometimes a good idea, but CORBA doesn't offer
the capability, then isn't the entire discussion a moot point anyway? As it turns
out, even though CORBA doesn't offer this capability directly, there are several
approaches that emulate this behavior.
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Rogue Wave ORBstreams.h++</FONT></H3>
<P>Rogue Wave Software offers a product that enables CORBA applications to pass C++
objects by value. The product, which builds on Rogue Wave's <TT>Tools.h++</TT> product,
provides the capability to pass many of the <TT>Tools.h++</TT> classes by value,
as well as user-defined classes that derive from certain <TT>Tools.h++</TT> classes
or conform to the proper Rogue Wave-supplied interfaces. <BR>
<BR>
<A HREF="javascript:popUp('07.jpg')"><B>Figure 10.7.</B></A> <I>Pass-by-reference
versus pass-by-value.</I> <BR>
<BR>
<TT>ORBstreams.h++</TT> does have some disadvantages. For one, it only supports C++.
(If you're implementing a CORBA application entirely in C++--which isn't altogether
unlikely--this probably isn't of concern to you.) Also, the product currently supports
only one ORB--IONA Technologies' Orbix--further limiting your choice of development
tools. Finally, because <TT>ORBstreams.h++</TT> builds on the <TT>Tools.h++</TT>
product, you might be saddled with additional baggage associated with using <TT>Tools.h++</TT>,
if you didn't originally plan on using that product. For all its drawbacks, however,
<TT>ORBstreams.h++</TT> is a good stopgap solution to the current lack of pass-by-value
capability in CORBA.
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">Using CORBA structs</FONT></H3>
<P>Another approach to achieving a pass-by-value-like behavior is the strategic use
of CORBA <TT>struct</TT>s. For each CORBA interface that needs to be passed by value,
the developer creates a <TT>struct</TT> that contains members corresponding to all
the data members of the class implementing the interface. After these <TT>struct</TT>s
are defined, the mechanism works something like this:

<DL>
	<DD><B>1</B>. A method that ordinarily uses interface types for parameters and return
	value instead uses the corresponding <TT>struct</TT> types.<BR>
	<B><BR>
	2</B>. Before calling such a method, the client creates <TT>struct</TT> versions
	of the objects it wants to pass by value. It then invokes the method with these parameters.<BR>
	<B><BR>
	3</B>. The server creates objects corresponding to the <TT>struct</TT>s (if necessary),
	performs its processing, and creates <TT>struct</TT>s for any output parameters or
	return values that are to be passed by value.<BR>
	<B><BR>
	4</B>. The client receives the output parameters and/or return value from the server
	and, if necessary, creates objects that correspond to the <TT>struct</TT> parameters.
</DL>

<P>There are a few disadvantages to this approach. The most significant is that inheritance
is not a feature of <TT>struct</TT>s; therefore, polymorphism is not supported. In
other words, if a particular method takes a certain kind of <TT>struct</TT> as a
parameter, it is not possible to pass another type of <TT>struct</TT> in its place.
Referring to the <TT>Bank</TT> example, this is akin to creating a <TT>CheckingAccount</TT>
object and passing it back in the place of an <TT>Account</TT> parameter. However,
the CORBA <TT>any</TT> type might be of use here, at the expense of increased complexity.
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">Using Conversion Constructors</FONT></H3>
<P>A third approach that emulates pass-by-value capability in CORBA is to pass an
object normally, but then for the client (or server, depending on whether the object
is an input or output parameter) to copy the object's state immediately on receipt.
The process is as follows:

<DL>
	<DD><B>1</B>. A client calls a method on a server, which returns an object reference.
	The server simply returns the object reference as usual.<BR>
	<B><BR>
	2</B>. On receiving the object reference, the client creates a new object of the
	same type, copying the remote object's state into the local one. This is generally
	done through the use of a constructor that takes the remote object as an argument,
	converting that object into a local one (hence the term <I>conversion</I> <I>constructor</I>.)<BR>
	<B><BR>
	3</B>. The client releases the remote object and continues working with the local
	one.
</DL>

<P>Compared to the <TT>struct</TT> approach, the conversion constructor approach
has the advantage of being able to work with objects of inherited class types. Additionally,
this approach does not require the development of separate IDL interfaces and <TT>struct</TT>s--it
is possible to use the exact same implementation classes for local and remote objects.
One potential disadvantage to this mechanism is that the local object must call a
number of methods on the remote object to obtain its initial state (often preferential
to making a number of remote calls over the life of the object). Furthermore, this
approach requires that for an object to be passed by value, its interface must provide
methods that enable its entire state to be read by another object. This requirement
goes against the concept of encapsulation, one of the goals of object-oriented design.
It might also require the developer to write more code.
<H2><A NAME="Heading11"></A><FONT COLOR="#000077">CORBA and X Window System</FONT></H2>
<P>One last issue involves the use of CORBA with applications written for the X Window
System. In both single-threaded and multithreaded applications, using CORBA and X
raises a number of concerns.
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">Single-Threaded Applications Using
CORBA and X</FONT></H3>
<P>The primary issue in writing single-threaded applications that use CORBA and X
is that both these products try to install what is known as an <I>event</I> <I>loop</I>.
An event loop is what the name suggests: a loop in the application code (actually
in the windowing system code which is linked with the application code, in the case
of X) that waits for an event, processes it, and loops back to wait for another event,
and so on, ad<I> </I>nauseum<I>.</I> Such an event loop exists for X as well as for
CORBA. In the case of X, the event loop receives and processes events from the X
server; in the case of CORBA, the event loop processes events from other CORBA applications.
In either case, the event loop is the main loop of the application, designed such
that it expects to be running in its own thread all the time. Therein lies the problem
with single-threaded applications: Both CORBA and X expect to use their own event
loops, each of which expects to be run in its own thread, but there is only one thread
in the application.</P>
<P>Fortunately, ORB products usually have a mechanism for integrating the CORBA event
loop with an X event loop. In these cases, the CORBA events are registered with the
X event loop, so the single-event loop can handle events for both products. You can
refer to your product's documentation for more information on how this is accomplished.
<H3><A NAME="Heading13"></A><FONT COLOR="#000077">Multithreaded Applications Using
CORBA and X</FONT></H3>
<P>In a multithreaded environment, it is perfectly viable to run separate event loops
for X and CORBA, so the issues applying to single-threaded applications don't apply
to multithreaded applications. However, there are a couple of issues to be aware
of: Older revisions of X--versions prior to X11R6.1--are not thread-safe and therefore
must be used with care in a multithreading environment. This means that the developer
must take additional steps to ensure that multiple threads don't access X library
calls at the same time. (As of X11R6.1, however, X is thread-safe and does not suffer
from this restriction.)</P>
<P>A related issue is Motif, a common user interface library for X. As of the time
of this writing, there is not yet a thread-safe version of the Motif library. Thus,
even with the thread-safe X11R6.1 or greater, developers still need to take care
that multiple threads don't execute Motif library calls at the same time. As a result,
integrating CORBA with a Motif application in a multithreaded environment, at least
with the current version of Motif, takes as much effort as integrating CORBA with
a non-thread-safe X library in a multithreaded environment.</P>
<P>Integrating multithreading, CORBA, and non-thread-safe X and/or Motif is certainly
possible, although you can expect it to take some work. All non-thread-safe calls
need to be wrapped in methods that ensure that only one thread can call such a method
at any given time. One way of ensuring this is through a <I>thread queue,</I> a mechanism
enabling multiple threads to be queued (in other words, wait in line) for access
to non-thread-safe code. As thread-safe versions of X and Motif proliferate, this
will become less of an issue, but for now, CORBA developers should be aware.
<H2><A NAME="Heading14"></A><FONT COLOR="#000077">Summary</FONT></H2>
<P>Today you examined several issues associated with developing CORBA applications.
The most significant are those associated with developing CORBA applications in a
single-threaded environment and those raised by CORBA's current lack of pass-by-value
capability. You also learned a few, and by no means an exhaustive list of, workarounds
for these issues.</P>
<P>On Day 11, you'll move on to the next topic in advanced CORBA development: use
of the Dynamic Invocation Interface (DII). The DII enables CORBA applications to
learn about each other dynamically (in other words, at runtime) and access newly
discovered services.
<H2><A NAME="Heading15"></A><FONT COLOR="#000077">Q&amp;A</FONT></H2>

<DL>
	<DD><B>Q If non-trivial single-threaded CORBA applications raise so many design issues,
	why wouldn't someone just use multithreading?</B><BR>
	<B><BR>
	A</B> Although multithreading is often the preferable alternative to wrestling with
	the issues raised by single-threaded applications, there are times when multithreading
	simply isn't available, such as when single-threading is dictated by choices of other
	applications or development tools. It is for cases such as these that the design
	patterns dealing with single-threaded applications are intended.<BR>
	<B><BR>
	Q It was mentioned earlier in the chapter that some CORBA products implement reference
	counting to manage object lifetime. What other way can this be accomplished?<BR>
	<BR>
	A</B> Another mechanism that can be used to manage object lifetime is for each remote
	object to have a heartbeat. Other objects, or the ORBs themselves, can ping each
	remote object to determine whether that object is still alive. If an object doesn't
	respond to the ping within a preset period of time, the other object can assume that
	the application containing that object has crashed. (As it turns out, a mechanism
	similar to this one is used by other ORB-like products such as Microsoft's DCOM and
	ObjectSpace's Voyager.)
</DL>

<H2><A NAME="Heading16"></A><FONT COLOR="#000077">Workshop</FONT></H2>
<P>The following section will help you test your comprehension of the material presented
today and put what you've learned into practice. You'll find the answers to the quiz
in Appendix A. On most days, a few exercises will accompany the quiz; today, because
no real &quot;working knowledge&quot; material was presented, there are no exercises.
<H3><A NAME="Heading17"></A><FONT COLOR="#000077">Quiz</FONT></H3>

<DL>
	<DD><B>1</B>. What is the major issue associated with mixing client and server functionality
	in a single-threaded CORBA application?<BR>
	<B><BR>
	2</B>. How can the use of reference counting in a CORBA application lead to problems?<BR>
	<B><BR>
	3</B>. Which version of X11 (the X Window System) would be required to safely run
	multithreaded X-based applications?<BR>
	<B><BR>
	4</B>. Why is the capability to pass objects by value sometimes useful?<BR>
	<B><BR>
	5</B>. Why is it usually inadvisable to use the Exclusive <TT>oneway</TT> Call design
	pattern introduced earlier in this chapter?<FONT COLOR="#000077"></FONT>
</DL>

<CENTER>
<P>
<HR>
<A HREF="../ch09/ch09.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch11/ch11.htm"><IMG
SRC="../button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <BR>
<BR>
<BR>
<IMG SRC="../button/corp.gif" WIDTH="284" HEIGHT="45" ALIGN="BOTTOM" ALT="Macmillan Computer Publishing USA"
BORDER="0"></P>

<P>&#169; <A HREF="../copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>


</BODY>

</HTML>