ch02.htm

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

	as a database of disk files. A persistent server does not necessarily store its state
	in persistent storage (although it could); in this case, the term merely implies
	that the server runs persistently or, in other words, continuously. 
<HR>


</BLOCKQUOTE>

<H2><A NAME="Heading15"></A><FONT COLOR="#000077">CORBA Clients and Servers</FONT></H2>
<P>Traditionally, in a client/server application, the server is the component, or
components, that provides services to other components of the application. A client
is a component that consumes services provided by a server or servers. The architecture
of a CORBA application is no different; generally, certain components of an application
provide services that are used by other components of the application. Not surprisingly,
the general terms <I>client</I> and <I>server</I> refer to these components of a
CORBA application. When considering a single remote method invocation, however, the
roles of client and server can be temporarily reversed because a CORBA object can
participate in multiple interactions simultaneously.</P>
<P>In a CORBA application, any component that provides an implementation for an object
is considered a server, at least where that object is concerned. If a component creates
an object and provides other components with visibility to that object (in other
words, allows other components to obtain references to that object), that component
acts as a server for that object; any requests made on that object by other components
will be processed by the component that created the object. Being a CORBA server
means that the component (the server) executes methods for a particular object on
behalf of other components (the clients).
<H3><A NAME="Heading16"></A><FONT COLOR="#000077">Multiple Personalities? Being Both
a Client and a Server</FONT></H3>
<P>Frequently, an application component can provide services to other application
components while accessing services from other components. In this case, the component
is acting as a client of one component and as a server to the other components (see
Figure 2.6). In fact, two components can simultaneously act as clients and servers
to each other. To understand this situation, consider the following scenario (illustrated
in Figure 2.7): The first component, Component A, receives a reference to an object
created by a second component, Component B, and calls a method on that object. Here,
Component A acts as a client and Component B acts as a server. Now assume that as
a parameter of the method called, Component A passes a reference to an object that
it has created (and thus provides an implementation for the object). Assume further
that Component B now calls some method on that object. For this particular method
invocation, Component A acts as a server, whereas Component B acts as a client. The
two components have not changed their overall roles in the application, but they
have temporarily reversed their roles as client and server. Therefore, from this
example you see that in a CORBA application, the terms <I>client</I> and <I>server</I>
might depend on the context of the method being called and in which component that
method's object resides. <BR>
<BR>
<A HREF="javascript:popUp('06.jpg')"><B>Figure 2.6</B></A>. <I>Acting as a client
and a server.</I> <BR>
<BR>
One last point to consider in the terminology of clients and servers: Although an
application component can function as both a client and a server, it is nevertheless
typical to label such a component as one or the other (not both). In the preceding
example, assume that for the most part, Component A calls methods on objects owned
by Component B. As illustrated in the example, some (or even all) of these method
calls can pass object references to Component B, which can then make calls through
those object references back to Component A. Although Component A is acting as a
server for these method calls, because the overall function of the component is to
use services provided by Component B, and only provides objects as arguments to methods
in Component B, you might very well refer to Component A as the client and to Component
B as the server. Methods called in this way are generally referred to as <I>client
callback methods,</I> or simply <I>callbacks.</I> Callbacks are especially important
given CORBA's current lack of pass-by-value capability; the capability to pass objects
by value, when it becomes available, will eliminate the need for many callbacks.</P>
<P><B><I>New Term: </I></B><I>Client callback method,</I> or simply <I>callback,</I>
is a generic term given to a method that is implemented by a client and called by
a server. Callbacks essentially make a client <BR>
<A HREF="javascript:popUp('07.jpg')"><B><BR>
Figure 2.7.</B></A> <I>A client callback method.</I>
<H2><A NAME="Heading17"></A><FONT COLOR="#000077">Stubs and Skeletons</FONT></H2>
<P>After a developer creates component interface definitions using IDL, he or she
processes the resulting IDL files with an IDL compiler. The IDL compiler generates
what are known as <I>client stubs</I> and <I>server skeletons.</I> Client stubs and
server skeletons serve as a sort of &quot;glue&quot; that connects language-independent
IDL interface specifications to language-specific implementation code. Client stubs
for each interface are provided for inclusion with clients that use those interfaces.
The client stub for a particular interface provides a dummy implementation for each
of the methods in that interface. Rather than execute the server functionality, however,
the client stub methods simply communicate with the ORB to marshal and unmarshal
parameters.</P>
<P><B>New Term: </B>A <I>client stub,</I> which is generated by the IDL compiler,
is a small piece of code that makes a particular CORBA server interface available
to a client.</P>
<P>A <I>server skeleton,</I> also generated by the IDL compiler, is a piece of code
that provides the &quot;framework&quot; on which the server implementation code for
a particular interface is built.</P>
<P>On the other side, you have server skeletons, providing the framework upon which
the server is built. For each method of an interface, the IDL compiler generates
an empty method in the server skeleton. The developer then provides an implementation
for each of these methods. Figure 2.8 illustrates how client stubs and server skeletons
fit into a CORBA application. <BR>
<BR>
<A HREF="javascript:popUp('08.jpg')"><B>Figure 2.8.</B></A> <I>Client stubs and server
skeletons.</I> <BR>
<BR>
You will study the process of building a CORBA client and server in detail on Day
4. There you will find how to use the IDL compiler, how to build a CORBA client using
the client stubs generated by the IDL compiler, and how to build a CORBA server,
starting from the server skeletons also generated by the IDL compiler. Eventually,
you will see that you can build CORBA clients without using client stubs at all,
using what is known as the Dynamic Invocation Interface (DII). Rather than being
statically linked to server interfaces, such clients can discover server interfaces
dynamically and use services not even conceived of at the time the clients were built.
(However, using the DII significantly increases the complexity of a client application
and is probably best left for a certain niche of applications.) Because the Dynamic
Invocation Interface is considered an advanced topic, you won't be seeing any more
of it until Day 11.
<H2><A NAME="Heading18"></A><FONT COLOR="#000077">Beyond the Basics: CORBAservices
and CORBAfacilities</FONT></H2>
<P>Certainly, much can be accomplished using just the basics of CORBA: using IDL
to create component interfaces, then implementing those interfaces and developing
clients to exploit the services provided. However, the Object Management Architecture
(which you'll recall is the Object Management group's overall architecture which
includes CORBA) provides much more than the basic ORB capabilities in the form of
<I>CORBAservices</I> and <I>CORBAfacilities.</I> These capabilities include event
management, licensing, object persistence, naming, security, transactions, user interface
management, data interchange, and much more. The interfaces for using these capabilities
are standardized by the OMG, meaning that their usage is (or will be) consistent
across platforms and products. What's more, the interfaces for CORBAservices and
CORBAfacilities are specified in IDL, meaning that applications can use these services
just as they use any other CORBA objects.</P>
<P>You will examine the CORBAservices and CORBAfacilities, both present and future,
on Day 12. For the time being, you should be aware that there is a difference between
what services and facilities are specified by the OMG and what services and facilities
are available in various CORBA products. Before deciding to use a particular service
or facility in an application design, you should first ensure that a product actually
exists that implements that functionality. Also note that in order to be considered
CORBA 2.0-compliant, a product need not implement any of the CORBAservices or CORBAfacilities;
only the CORBA core functionality is required.
<H2><A NAME="Heading19"></A><FONT COLOR="#000077">Summary</FONT></H2>
<P>In this chapter, you first discovered the two cornerstones of the CORBA architecture:
the Object Request Broker (ORB), which manages the communication of CORBA objects
with each other, and the Interface Definition Language (IDL), which defines application
component interfaces upon which CORBA applications are built. You explored the CORBA
object model, where you learned about inter-ORB protocols (particularly IIOP), CORBA's
use of object references, and the concept of the Basic Object Adapter. You defined
the terms <I>client</I> and <I>server</I> in the context of CORBA and saw that a
single application component can simultaneously act as both a client and a server.
You also saw how IDL definitions create client stubs and server skeletons, which
in turn implement CORBA clients and servers. Finally, you were introduced to CORBAservices
and CORBAfacilities, which provide additional functionality for CORBA applications.</P>
<P>Now that you have developed an understanding of the overall CORBA architecture,
you will move on to the basics of IDL, starting with simple data types and working
up to more complex IDL constructs. You will find this knowledge of IDL necessary
to design and implement CORBA applications.
<H2><A NAME="Heading20"></A><FONT COLOR="#000077">Q&amp;A</FONT></H2>

<DL>
	<DD><B>Q Why would the capability to pass objects by value eliminate the need for
	many callbacks?</B><BR>
	<B><BR>
	A </B>In many cases, a client might only need to pass a simple object to a server
	method. Because objects cannot be passed by value, the server must use callbacks
	to the client to manipulate the object (even if it only wants to read the object's
	state). If the object can be passed by value, the server can operate on a local copy
	of the object, eliminating the need for client callbacks. (Of course, in some cases
	the client will want to retain ownership of the object and will want the server to
	make callbacks; in such cases, the callback paradigm would be retained.)<BR>
	<B><BR>
	Q Client stubs seem too restrictive for my application; do I need to use DII?</B><BR>
	<B><BR>
	A</B> For an overwhelming majority of applications, if you think DII is necessary,
	you might want to reconsider. Due to the complexity and overhead of using DII, it
	is almost always best to avoid it. (See Chapter 11 for more information on when the
	use of DII might be appropriate.)<BR>
	<B><BR>
	Q Why are language mappings a necessary part of CORBA?</B><BR>
	<B><BR>
	A</B> Because CORBA object interfaces are specified in IDL, which is independent
	of any implementation language, it is necessary to specify a methodology for converting
	IDL data types to data types of the implementation language(s) chosen. The language
	mapping for a particular implementation language describes this methodology. Furthermore,
	language mappings for many common languages are standardized, meaning that an application
	written to use one CORBA product can be made to work with a different product with
	little or no modification (as long as the application uses only features of the standard
	language mapping).
</DL>

<H2><A NAME="Heading21"></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="Heading22"></A><FONT COLOR="#000077">Quiz</FONT></H3>

<DL>
	<DD><B>1</B>. Earlier in the chapter, you claimed that the capability to pass objects
	by value, when it becomes available, will eliminate the need for many callbacks.
	Why is this true?<BR>
	<B><BR>
	2</B>. An architect of a CORBA application wants to include two server components
	in the application. The first component has a single method that simply returns the
	time of day. The second component, when initialized, performs a lengthy calculation
	on a large database table; it features a single method that returns the precalculated
	result. Which server activation policies will the architect want to use for these
	two components, and why?<BR>
	<B><BR>
	3</B>. Can you think of a drawback to the use of client stubs in a CORBA client application?
	(Hint: What potentially useful capability does the Dynamic Invocation Interface (DII)
	provide?)<BR>
	<B><BR>
	4</B>. Why are language mappings a necessary part of CORBA?
</DL>

<CENTER>
<P>
<HR>
<A HREF="../ch01/ch01.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch03/ch03.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>