ch10.htm

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

objects to other applications.
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Mixed Server/Client Applications</FONT></H3>
<P>The guidelines for the use of threads in pure servers (applications that behave
as servers only, never as clients) are clear-cut: If the response time requirements
warrant it, multithreading is preferred; otherwise, single threading is adequate.
The guidelines for pure clients are simple as well: Under most circumstances, multithreading
is not required. Therefore, you can conclude that single-threaded architectures are
adequate for most CORBA applications. If your applications were all pure servers
and clients, you'd be right.</P>
<P>When an application demonstrates behaviors of a server and a client--call it a
<I>mixed server/client application</I> for lack of a better term--the design issues
associated with using a single-threaded architecture become insidious. Illustrated
in Figure 10.3 is the basic problem: If a single-threaded, mixed server/client application
passes one of its objects to a second application in a remote method call, and the
second application, in turn, tries to access the object passed to it, both applications
become blocked. <BR>
<BR>
<A HREF="javascript:popUp('03.jpg')"><B>Figure 10.3.</B></A> <I>Single-threaded mixed
server/client application operation.</I> <BR>
<BR>
Of course, this problem is neatly solved by the use of multithreading in the mixed
server/client application, as illustrated in Figure 10.4. If multithreading is not
an option for whatever reason, another solution is required. The remainder of this
section discusses potential solutions to the problems involved in developing single-threaded
applications that need to assume the roles of both client and server.</P>
<P>Presented here are two useful design patterns for designing CORBA applications
using only single-threaded components. Again, the use of multithreading is probably
the cleanest method of implementing CORBA applications, but when multithreading is
not an option, you will want to consider one of these design patterns.
<H4><FONT COLOR="#000077">Object Factory Pattern</FONT></H4>
<P>Recall that single-threaded applications that are pure servers or pure clients
don't suffer from the deadlock problem illustrated in <BR>
<BR>
<A HREF="javascript:popUp('03.jpg')"><B>Figure 10.3.</B></A> The <I>Object Factory
pattern</I> <BR>
<BR>
capitalizes on this property of pure client and pure server applications by moving
functionality to the appropriate component of the application, resulting in application
components that are either pure clients or pure servers.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>In the <I>Object Factory design pattern,</I> a factory object is responsible
	for creating objects of a particular type. For example, the <TT>Bank</TT> object
	can be thought of as an Account factory, since Banks are responsible for creating
	all Account objects in the system. 
<HR>


</BLOCKQUOTE>

<P><A HREF="javascript:popUp('04.jpg')"><B>Figure 10.4.</B></A> <I>Multithreaded
mixed server/client application operation.</I> <BR>
<BR>
To understand how this is feasible, consider the following scenario: A client wishes
to call a remote method on a server. The method takes a particular type of object
as a parameter; call it a Widget. Now assume that the Widget is created by the client.
If the client were to pass a Widget that it created to the server through a remote
method, and that method attempted to call a method on the Widget, the result would
be a deadlock scenario, as described in Figure 10.3. These are the typical application
semantics over which single-threaded applications stumble. It would be most useful
if these types of semantics could be achieved in a way that worked with single-threaded
applications.</P>
<P>This is where the Object Factory pattern steps in (see Figure 10.5). This pattern
takes the place of the object creation step. Rather than create the Widget itself,
the client requests the Factory (which is the same object as the server whose method
the client wishes to invoke) to create the Widget on the client's behalf. The client
can then manipulate the Widget, if desired, and can finally invoke the desired remote
method on the server, passing the Widget as a parameter. Now, because the Widget
exists in the same address space as the rest of the server, the server can manipulate
the Widget as it sees fit. <BR>
<BR>
<A HREF="javascript:popUp('05.jpg')"><B>Figure 10.5.</B></A> <I>Object Factory pattern.</I>
<BR>
<BR>
The Object Factory pattern boasts the advantage of enabling single-threaded clients
to pass objects as parameters to remote methods. This capability comes at a price:
The server must provide methods for creating every type of CORBA object that a client
might want to create. Although providing implementations for these methods is simple,
it can be tedious, particularly in applications containing large numbers of classes.
Also, it can be more inconvenient for clients to call additional methods to create
objects rather than to directly use constructors, although this inconvenience might
be minimal. These drawbacks, however, are often outweighed by the advantages offered
by the Object Factory pattern.
<H4><FONT COLOR="#000077">Exclusive oneway Call Pattern</FONT></H4>
<P>Another approach to creating harmony between single-threaded applications and
CORBA is what you might call the <I>Exclusive </I><TT>oneway</TT><I> Call pattern.</I>
This pattern calls for the exclusive use of <TT>oneway</TT> invocations throughout
the application. Because <TT>oneway</TT> methods don't block, the deadlock issue
associated with single-threaded CORBA applications is eliminated. However, this advantage
comes at a price, as you'll soon find out.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>The <I>Exclusive </I><TT>oneway</TT><I> Call design pattern</I> calls
	for the exclusive use of <TT>oneway</TT> methods for communication between CORBA
	objects. 
<HR>
<BR>
	<BR>
	
<HR>
<B>Note:</B>For a review of CORBA <TT>oneway</TT> methods, refer to Day 3, &quot;Mastering
	the Interface Definition Language (IDL).&quot; 
<HR>


</BLOCKQUOTE>

<P>The exclusive use of <TT>oneway</TT> method calls throughout a CORBA application
exacts a potentially stiff penalty: First, the concept of a clearly laid-out program
flow is lost. Consider a typical client application. There is generally a well-defined
flow of control through the program. That is, there is a main method--it might very
well be C/C++/Java's <TT>main()</TT>--at which the program begins and proceeds to
call other methods. Usually, the flow of the program can be determined by tracing
the sequence of method calls. In other words, the behavior of the application is
at least somewhat predictable because the execution flow can be traced relatively
easily.</P>
<P>Using <TT>oneway</TT> methods exclusively, however, radically alters the landscape
of an application, as illustrated in Figure 10.6. Instead of a well-defined flow
of control traceable throughout the application, the client features a series of
seemingly disjointed <TT>oneway</TT> methods. The exchange between client and server,
rather than following the familiar pattern of &quot;client calls server/server returns
result&quot; is transformed into a volley of <TT>oneway</TT> calls from one application
to the other. The client starts by calling a method on the server. That method, when
completed, calls a method on the client that performs the second step in the application.
That method, in turn, calls another method on the server, which eventually calls
a method on the client, and so on.</P>
<P>Again, because each method called is <TT>oneway</TT>, there is no blocking due
to the client or server being busy. Consequently, each application is free to pass
any CORBA objects--including objects created by itself--without fear of blocking.
The downside of this architecture is that because the flow of control is now shared
between two applications, it is much more difficult to trace.</P>
<P>Another penalty that must be paid by developers wanting to use the Exclusive <TT>oneway</TT>
Call pattern stems from a characteristic of <TT>oneway</TT> methods which you should
recall--namely, that <TT>oneway</TT> messages are not guaranteed to be delivered
to their destination. Building an entire application based on this mechanism is certain
to be a trying experience, primarily because if there are any methods in the application
which require reliable delivery, the developer must implement a mechanism to determine
whether a <TT>oneway</TT> method call actually executed successfully. In other words,
the developer essentially must implement reliable delivery semantics on top of the
unreliable <TT>oneway</TT> mechanism, in addition to implementing all the usual application
functionality. <BR>
<BR>
<A HREF="javascript:popUp('06.jpg')"><B>Figure 10.6.</B></A> <I>Exclusive </I><TT>oneway</TT><I>
Call pattern.</I> <BR>
<BR>
To summarize the Exclusive <TT>oneway</TT> Call design pattern, it should be stressed
that this pattern would be extremely difficult to implement for most real-world production
systems. Consequently, developers are strongly encouraged to pursue a different method
of marrying client and server functionality in a single-threaded application if at
all possible.
<H2><A NAME="Heading6"></A><FONT COLOR="#000077">Object Lifetime</FONT></H2>
<P>In a non-distributed application, management of object lifetime is a non-issue:
When the application is finished using an object, it simply destroys it. With garbage-collected
languages like Java, the developer does not even need to write code to do this--the
application handles it automatically. If the application crashes, the memory used
by its objects is reclaimed by the operating system. Because all objects are self-contained
in the application, there are no issues associated with object lifetime.</P>
<P>In a distributed application, circumstances are different. An application might
use objects that are local to the application--that is, objects that live in the
same address space as the application--or it might use remote objects, which might
reside in a different process on the same machine or on a different machine somewhere
on the network. Many CORBA ORB products use reference counting for managing object
lifetime--a mechanism which works well when applications behave normally. Although
the use of a reference-counting mechanism is not dictated by CORBA, its inclusion
into some major ORB products merits some discussion here. Recall that in such a reference-counting
mechanism, object references are duplicated--that is, their reference count is incremented--when
the reference is passed to an application. Similarly, when an application is finished
using an object, it releases the object reference, that is, decrements the reference
count. When the reference count reaches zero, the object is no longer in use and
can safely be destroyed.</P>
<P>But what happens when an application holding an object reference crashes before
it can release that object reference? This is where the reference-counting mechanism
begins to break down. Under these circumstances, the object's reference count never
reaches zero, and thus the object is never destroyed. This can be thought of as a
sort of memory leak in a distributed application. Consequently, developers might
need to think beyond the reference counting mechanism and consider a contingency
mechanism that picks up where reference counting leaves off.</P>
<P>Because a distributed application cannot truly know when all other applications
are finished using its objects (because it doesn't know whether any of those applications
have crashed), a mechanism over and above the basic reference-counting mechanism
is required. Such a mechanism manages the lifetime of CORBA objects, automatically
determining whether an object is in use and, if not, destroying that object. But
how does this mechanism determine whether an object is still in use? Actually, it
can only <I>guess</I>. To understand how such a mechanism works, consider the following
case study.</P>
<P>One such mechanism, known as the Evictor<I>,</I> manages object lifetime by tracking
the usage of each CORBA object within a server (each CORBA server would contain its
own Evictor). When an object has not been in use for a predetermined period of time
(for example, a day), the Evictor <I>evicts</I> that object. Although it's possible
for the eviction process to simply destroy the unused object, recall that the Evictor
does not know for certain that the object is no longer in use. It is possible that
one of the clients using that object could be dormant for a period of time, and if
the object were destroyed, the client, on waking up, would no longer be able to access
that object. To accommodate this possibility, the Evictor does not actually destroy
a CORBA object after a period of non-use but evicts it into a persistent store, such
as a database. If that object is needed later, it can be resurrected from the persistent
store. All this occurs transparently to clients, which are completely unaware that
objects are being evicted and resurrected as necessary.</P>
<P>Of course, a mechanism such as the Evictor, rather than enabling potentially unused
objects to consume memory in a server process's address space, simply moves the unused
objects to some form of persistent storage. The result is that unused objects still
exist somewhere--in this case, the persistent storage rather than the server application
address space. Using persistent storage for this purpose, in addition to offering
the advantage of freeing up a server machine's memory resources, provides for simpler
maintenance. That is, the objects in persistent storage can be cleaned up periodically,
perhaps as a part of the system's periodic maintenance cycle. Purging the database
of unused objects in this way would not require system administrators to bring down
the server, thus enhancing the server availability.
<H2><A NAME="Heading7"></A><FONT COLOR="#000077">Lack of Pass-by-Value Semantics</FONT></H2>
<P>Perhaps one of the trickiest issues associated with CORBA development is that
CORBA does not currently support the capability to pass objects by value. (This limitation
is expected to be removed in a later version of CORBA; see Appendix C, &quot;What
Lies Ahead? The Future of CORBA,&quot; for more details on this and other future