ch02.htm

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

use IDL to--what else?--define interfaces for the examples used throughout this book.
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Language Independence</FONT></H3>
<P>The IDL language is part of the standard CORBA specification and is independent
of any programming language. It achieves this language independence through the concept
of a <I>language mapping</I>. The OMG has defined a number of standard language mappings
for many popular languages, including C, C++, COBOL, Java, and Smalltalk. Mappings
for other languages exist as well; these mappings are either nonstandard or are in
the process of being standardized by the OMG.</P>
<P><B>New Term: </B>A <I>language mapping</I> is a specification that maps IDL language
constructs to the constructs of a particular programming language. For example, in
the C++ language mapping, the IDL <TT>interface</TT> maps to a C++ <TT>class</TT>.</P>
<P>Language independence is a very important feature of the CORBA architecture. Because
CORBA does not dictate a particular language to use, it gives application developers
the freedom to choose the language that best suits the needs of their applications.
Taking this freedom one step further, developers can also choose multiple languages
for various components of an application. For instance, the client components of
an application might be implemented in Java, which ensures that the clients can run
on virtually any type of machine. The server components of that application might
be implemented in C++ for high performance. CORBA makes possible the communication
between these various components.
<H2><A NAME="Heading8"></A><FONT COLOR="#000077">The CORBA Communications Model</FONT></H2>
<P>In order to understand CORBA, you must first understand its role in a network
of computing systems. Typically, a computer network consists of systems that are
physically connected (although the advent of wireless network technology might force
us to revise our understanding of what &quot;physically connected&quot; means). This
physical layer provides the medium through which communication can take place, whether
that medium is a telephone line, a fiber-optic cable, a satellite uplink, or any
combination of networking technologies.</P>
<P>Somewhere above the physical layer lies the transport layer, which involves protocols
responsible for moving packets of data from one point to another. In this age of
the Internet, perhaps the most common transport protocol in use is TCP/IP (Transmission
Control Protocol/Internet Protocol). Most Internet-based applications use TCP/IP
to communicate with each other, including applications based on FTP (File Transfer
Protocol), Telnet (a host communication protocol), and HTTP (Hypertext Transport
Protocol, the basis for the World Wide Web).
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">Inter-ORB Protocols</FONT></H3>
<P>So how does CORBA fit into this networking model? It turns out that the CORBA
specification is neutral with respect to network protocols; the CORBA standard specifies
what is known as the General<I> </I>Inter-ORB Protocol<I> </I>(GIOP), which specifies,
on a high level, a standard for communication between various CORBA ORBs and components.
GIOP, as its name suggests, is only a general protocol; the CORBA standard also specifies
additional protocols that specialize GIOP to use a particular transport protocol.
For instance, GIOP-based protocols exist for TCP/IP and DCE (the Open Software Foundation's
Distributed Computing Environment protocol). Additionally, vendors can (and do) define
and use proprietary protocols for communication between CORBA components.</P>
<P><B>New Term: </B>The <I>General Inter-ORB Protocol (GIOP)</I> is a high-level
standard protocol for communication between ORBs. Because GIOP is a generalized protocol,
it is not used directly; instead, it is specialized by a particular protocol that
would then be used directly.</P>
<P>For discussion and use of CORBA in this book, your main interest will be the GIOP-based
protocol for TCP/IP networks, known as the Internet Inter-ORB Protocol (IIOP). As
of the 2.0 version of the CORBA specification, vendors are required to implement
the IIOP protocol in order to be considered CORBA-compliant (although they might
offer their proprietary protocols in addition to IIOP). This requirement helps to
ensure interoperability between CORBA products from different vendors because each
CORBA 2.0-compliant product must be able to speak the same language. Some vendors
have gone so far as to adopt IIOP as their products' native protocol (the protocol
used by default) rather than use a proprietary protocol; however, an ORB is allowed
to support any number of protocols, as long as IIOP is supported (when communicating
with each other, ORBs can negotiate which protocol to use). Additionally, a number
of vendors are including IIOP-compliant ORBs with products ranging from database
servers to application development tools to Web browsers. IIOP, as you can see, is
an important key to CORBA interoperability.</P>
<P><B>New Term: </B>The <I>Internet Inter-ORB Protocol (IIOP)</I> is a specialization
of the GIOP. IIOP is the standard protocol for communication between ORBs on TCP/IP
based networks. An ORB must support IIOP (but can support other additional protocols)
in order to be considered CORBA 2.0-compliant.
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">CORBA and the Networking Model</FONT></H3>
<P>With all this discussion of inter-ORB protocols, you have yet to see where CORBA
fits in with the rest of the networking model. Figure 2.3 illustrates the network
architecture of a typical CORBA application. Essentially, CORBA applications are
built on top of GIOP-derived protocols such as IIOP. These protocols, in turn, rest
on top of TCP/IP, DCE, or whatever underlying transport protocol the network uses.
CORBA applications aren't limited to using only one of these protocols; an application
architecture can be designed to use a bridge that would interconnect, for instance,
DCE-based application components with IIOP-based ones. You can see, then, that rather
than supplant network transport protocols, the CORBA architecture creates another
layer--the inter-ORB protocol layer--which uses the underlying transport layer as
its foundation. This, too, is a key to interoperability between CORBA applications,
as CORBA does not dictate the use of a particular network transport protocol. <BR>
<BR>
<A HREF="javascript:popUp('03.jpg')"><B>Figure 2.3.</B></A> <I>Architecture of a
distributed CORBA application.</I>
<H2><A NAME="Heading11"></A><FONT COLOR="#000077">The CORBA Object Model</FONT></H2>
<P>Every object-oriented architecture features an object model, which describes how
objects are represented in the system. Of course, CORBA, being an object-oriented
architecture, has an object model as well. Because CORBA is a distributed architecture,
however, its object model probably differs somewhat from the traditional object models
with which most readers are familiar (such as C++'s or Java's object model). Three
of the major differences between the CORBA object model and traditional models lie
in CORBA's &quot;semi-transparent&quot; support for object distribution, its treatment
of object references, and its use of what are called object<I> </I>adapters--particularly
the Basic Object Adapter (BOA). You will now explore these concepts in greater depth.
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">Object Distribution</FONT></H3>
<P>To a CORBA client, a remote method call looks exactly like a local method call,
thanks to the use of client stubs (a concept you'll explore later in this chapter).
Thus, the distributed nature of CORBA objects is transparent to the users of those
objects; the clients are unaware that they are actually dealing with objects which
are distributed on a network.</P>
<P>Actually, the preceding statement is almost true. Because object distribution
brings with it more potential for failure (due to a network outage, server crash,
and so on), CORBA must offer a contingency to handle such possibilities. It does
so by offering a set of system exceptions, which can be raised by any remote method.
You'll learn about exceptions more in later chapters--on Day 3, you'll see how exceptions
are declared in IDL; on Day 7, you'll add exception handling to a sample application.
For the time being, though, all you need to know is that all operations in all CORBA
objects implicitly can raise a CORBA system exception, which signals a network error,
server unavailability, or other such situation. Thus, with the exception--pun intended--of
this additional exception raised by CORBA object methods, a remote method is otherwise
identical to its local counterpart.
<H3><A NAME="Heading13"></A><FONT COLOR="#000077">Object References</FONT></H3>
<P>In a distributed application, there are two possible methods for one application
component to obtain access to an object in another process. One method is known as
<I>passing by reference, </I>illustrated in Figure 2.4. In this method, the first
process, Process A, passes an object reference to the second process, Process B.
When Process B invokes a method on that object, the method is executed by Process
A because that process owns the object. (The object exists in the memory and process
space of Process A.) Process B only has visibility to the object (through the object
reference), and thus can only request that Process A execute methods on Process B's
behalf. Passing an object by reference means that a process grants visibility of
one of its objects to another process while retaining ownership of that object.</P>
<P><B>New Term: </B>When an object is <I>passed by reference,</I> the object itself
remains &quot;in place&quot; while an object reference for that object is passed.
Operations on the object through the object reference are actually processed by the
object itself. <BR>
<BR>
<A HREF="javascript:popUp('04.jpg')"><B>Figure 2.4.</B></A> <I>Passing an object
by reference.</I> <BR>
<BR>
The second method of passing an object between application components is known as
<I>passing by value </I>and is depicted in Figure 2.5. In this method, the actual
state of the object (such as the values of its member variables) is passed to the
requesting component (typically through a process known as serialization). When methods
of the object are invoked by Process B, they are executed by Process B instead of
Process A, where the original object resides. Furthermore, because the object is
passed by value, the state of the original object is not changed; only the copy (now
owned by Process B) is modified. Generally, it is the responsibility of the developer
to write the code that serializes and deserializes objects (although this capability
is built into some languages, such as Java).</P>
<P><B>New Term: </B>When an object is <I>passed by value,</I> the object's state
is copied and passed to its destination, where a new copy of the object is instantiated.
Operations on that object's copy are processed by the copy, not by the original object.</P>
<P><I>Serialization</I> refers to the encoding of an object's state into a stream,
such as a disk file or network connection. When an object is serialized, it can be
written to such a stream and subsequently read and <I>deserialized,</I> a process
that converts the serialized data containing the object's state back into an instance
of the object. <BR>
<BR>
<A HREF="javascript:popUp('05.jpg')"><B>Figure 2.5.</B></A> <I>Passing an object
by value.</I> <BR>
<BR>
One important aspect of the CORBA object model is that <I>all</I> objects are passed
by reference. (Actually, at the time of this writing, the OMG has issued an RFP (Request
for Proposals) for adding to CORBA the capability to pass objects by value, so it
is likely that this capability will be added to the CORBA standard in the near future.)
In order to facilitate passing objects by value in a distributed application, in
addition to passing the state of the object across the network, it is also necessary
to ensure that the component receiving the object has implementations for the methods
supported by that object. (This is not necessary when objects are passed by reference;
recall that method invocations are executed by the component that owns the actual
object.) When the CORBA pass-by-value capability is specified, it will need to address
these issues; readers should stay tuned to OMG announcements for updates on this
development. (The OMG Web site, which makes available a great deal of CORBA-related
information and specifications, is located at <TT>http://www.omg.org/</TT>.)</P>
<P>There are a few issues associated with passing objects by reference only. Remember
that when passing by reference is the only option, methods invoked on an object are
always executed by the component that owns that object (in other words, the component
that has created that object); an object cannot migrate from one application component
to another. (However, you can devise methods that simulate this behavior; it simply
is not provided by the CORBA architecture itself at this time.) This also means that
all method calls are remote method calls (unless both the calling object and called
object are owned by the same application component). Obviously, if a component invokes
a lengthy series of method calls on a remote object, a great deal of overhead can
be consumed by the communication between the two components. For this reason, it
might be more efficient to pass an object by value so the component using that object
can manipulate it locally. On Day 10 you'll explore this issue in greater detail,
but in the meantime, readers should be aware that CORBA's current lack of pass-by-value
semantics does raise this issue.
<H3><A NAME="Heading14"></A><FONT COLOR="#000077">Basic Object Adapters (BOAs)</FONT></H3>
<P>The CORBA standard describes a number of what are called <I>object adapters, </I>whose
primary purpose is to interface an object's implementation with its ORB. The OMG
recommends that new object adapter types be created only when necessary and provides
three sample object adapters: the Basic Object Adapter (BOA), which you will concentrate
on, and the Library Object Adapter and Object-Oriented Database Adapter, both of
which are useful for accessing objects in persistent storage. (The CORBA specification
describes these object adapters in greater detail.) Again, you will concern yourself
only with the Basic Object Adapter, by far the most commonly used object adapter.</P>
<P>The BOA provides CORBA objects with a common set of methods for accessing ORB
functions. These functions range from user authentication to object activation to
object persistence. The BOA is, in effect, the CORBA object's interface to the ORB.
According to the CORBA specification, the BOA should be available in every ORB implementation,
and this seems to be the case with most (if not all) CORBA products available.
<H4><FONT COLOR="#000077">Server Activation Policies</FONT></H4>
<P>One particularly important (and useful) feature of the BOA is its object activation
and deactivation capability. The BOA supports four types of <I>activation policies,</I>
which indicate how application components are to be initialized. These activation
policies include the following:

<UL>
	<LI>The <I>shared server</I> policy, in which a single server (which in this context
	usually means a process running on a machine) is shared between multiple objects
	<LI>The <I>unshared server</I> policy, in which a server contains only one object
	<LI>The <I>server-per-method</I> policy, which automatically starts a server when
	an object method is invoked and exits the server when the method returns
	<LI>The <I>persistent server</I> policy, in which the server is started manually
	(by a user, batch job, system daemon, or some other external agent)
</UL>

<P><B>New Term: </B>A server <I>activation policy</I> indicates how that particular
server is intended to be accessed; for example, if there is a single server used
by all clients, or a new instance of the server should be started for each client,
and so on.</P>
<P>This variety of activation policies allows an application architect to choose
the type of behavior that makes the most sense for a particular type of server. For
instance, a server requiring a length of time to initialize itself might work best
as a persistent server, because the necessary initialization time would adversely
affect the response time for that server. On the other hand, a server that starts
up quickly upon demand might work well with the server-per-method policy.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>It is worth noting here that the term <I>persistent server</I> has nothing
	to do with the common use of the term <I>persistent,</I> which refers to the capability
	of an object to store its state in some sort of nonvolatile storage facility such