ch04.htm

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

type:</P>
<PRE><FONT COLOR="#0066FF"><TT>typedef sequence&lt;StockSymbol&gt; StockSymbolList;</TT>
</FONT></PRE>
<P>You're now ready to add the <TT>getStockSymbols()</TT> method to the <TT>StockServer</TT>
interface. This method is described in IDL as follows:</P>
<PRE><FONT COLOR="#0066FF"><TT>StockSymbolList getStockSymbols();</TT>
</FONT></PRE>
<P>That's all the IDL you need for this example. Armed with the <TT>StockMarket.idl</TT>
file, you're now ready for the next step: deciding how you'd like to implement these
IDL definitions.
<H3><A NAME="Heading3"></A><FONT COLOR="#000077">Choosing an Implementation Approach</FONT></H3>
<P>Before actually implementing the server functionality, you'll first need to decide
on an implementation approach to use. CORBA supports two mechanisms for implementation
of IDL interfaces. Developers familiar with object-oriented concepts might recognize
these mechanisms, or at least their names. These include the <I>inheritance</I> mechanism,<I>
</I>in which a class implements an interface by inheriting from that interface class,
and the <I>delegation</I> mechanism, in which the methods of the interface class
call the methods of the implementing class (delegating to those methods). These concepts
are illustrated in Figures 4.1 and 4.2. Figure 4.2 also illustrates that a tie class
can inherit from any class--or from no class--in contrast to the inheritance approach,
in which the implementation class must inherit from the interface class that it implements.</P>
<P><B>New Term: </B>Implementation by <I>inheritance</I> consists of a base class
that defines the interfaces of a particular object and a separate class, inheriting
from this base class, which provides the actual implementations of these interfaces.</P>
<P>Implementation by <I>delegation</I> consists of a class that defines the interfaces
for an object and then delegates their implementations to another class or classes.
The primary difference between the inheritance and delegation approaches is that
in delegation, the implementation classes need not derive from any class in particular.</P>
<P>A <I>tie class,</I> or simply a <I>tie,</I> is the class to which implementations
are delegated in the delegation approach. Thus, the approach is often referred to
as the <I>tie</I> mechanism or <I>tying</I>.</P>
<P>Most IDL compilers accept command-line arguments to determine which implementation
approach to generate code for. Therefore, before you use the IDL compiler to generate
code from your IDL definitions, you'll want to determine the approach you want to
use. Consult your IDL compiler's documentation to determine which command-line arguments,
if any, the IDL compiler expects. <BR>
<BR>
<A HREF="javascript:popUp('01.jpg')"><B>Figure 4.1.</B></A> <I>Implementation by
inheritance.</I></P>
<P><A HREF="javascript:popUp('02.jpg')"><B>Figure 4.2.</B></A> <I>Implementation
by delegation.</I>
<H4><FONT COLOR="#000077"><BR>
How to Choose an Implmentation Approach</FONT></H4>
<P>One question you might be asking by now is how to choose an implementation approach.
In many cases, this is probably a matter of taste. However, there are certain cases
that work well with a particular approach. For example, recall that in the inheritance
approach, the implementation class derives from a class provided by the IDL compiler.
If an application makes use of legacy code to implement an interface, it might not
be practical to change the classes in that legacy code to inherit from a class generated
by the IDL compiler. Therefore, for such an application it would make more sense
to use the delegation approach; existing classes can readily be transformed into
tie classes.


<BLOCKQUOTE>
	<P>
<HR>
<B>Warning: </B>After you've chosen an implementation approach and have written a
	great deal of code, be prepared to stick with that approach for that server. Although
	it's possible to change from one implementation approach to another, this is a very
	tedious process if a lot of code has already been written. This issue doesn't present
	itself very often, but you should be aware of it. 
<HR>


</BLOCKQUOTE>

<P>For the purposes of this example, either implementation approach will do. The
example will use the delegation approach; implementing the server using inheritance
will be left as an exercise.</P>
<P>Note that you can usually mix and match the implementation and delegation approaches
within a single server application. Although you'll use only one approach per interface,
you could choose different approaches for different interfaces in the system. For
example, if you had decided that the inheritance approach was the best match for
your needs, but you had a few legacy classes that mandated the use of the tie approach,
you could use that approach for those classes while using the inheritance approach
for the remainder.
<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Using the IDL Compiler</FONT></H3>
<P>Now that you have defined your system's object interfaces in IDL and have decided
on an implementation approach, you're ready to compile the IDL file (or files, in
a more complex system).


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>The method and command-line arguments for invoking the IDL compiler vary
	across platforms and products. Consult your product documentation for specific instructions
	on using your IDL compiler. 
<HR>


</BLOCKQUOTE>

<P>Recall that this example will use the delegation approach--also called the tie
mechanism--so be sure to consult your IDL compiler documentation for the appropriate
command-line arguments (if any are required) to generate the proper files and source
code. For example, the command to invoke the IDL compiler included with Sun's Java
IDL product is this:</P>
<PRE><FONT COLOR="#0066FF"><TT>idltojava -fno-cpp -fclient -fserver StockMarket.idl</TT>
</FONT></PRE>
<P>In this case, the IDL compiler is named <TT>idltojava</TT>. The <TT>-fno-cpp</TT>
switch instructs the IDL compiler to not invoke the C preprocessor before compiling
the file. The <TT>-fclient</TT> and <TT>-fserver</TT> switches instruct the IDL compiler
to generate client stubs and server skeletons, respectively. For now, you could get
by without the <TT>-fclient</TT> switch because you'll only be implementing the server,
but because you'll want the client stubs later, it will save time to generate them
now.</P>
<P>The command to invoke the IDL compiler included in Visigenic's VisiBroker/C++
for Windows 95 is as follows:</P>
<PRE><FONT COLOR="#0066FF"><TT>orbeline -h h StockMarket.idl</TT>
</FONT></PRE>
<P>Here, the IDL compiler, named <TT>orbeline</TT>, generates client stubs and server
skeletons for the <TT>StockMarket.idl</TT> file. The <TT>-c cpp</TT> switch instructs
the compiler to use the <TT>.cpp</TT> filename extension for C++ source files; similarly,
<TT>-h h</TT> tells the compiler to use the <TT>.h</TT> extension for header files.
You can, of course, substitute your favorite filename extensions in place of these.


<BLOCKQUOTE>
	<P>
<HR>
<B>Tip: </B>As with any utility run from the command line, before you can run the
	IDL compiler, you might have to set the <TT>PATH</TT> variable in your system's environment
	to include the directory where the IDL compiler resides. Generally, your CORBA product's
	documentation will tell you how to set the <TT>PATH</TT> variable to include the
	proper directories. 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077">Client Stubs and Server Skeletons</FONT></H4>
<P>When the IDL compiler is invoked, it generates code that conforms to the language
mapping used by that particular product. The IDL compiler will generate a number
of files--some of them helper classes, some of them client stub classes, and some
of them server skeleton classes.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>Recall from Day 2 that <I>client stubs</I> for an interface are pieces
	of code compiled with client applications that use that interface. These stubs do
	nothing more than tell the client's ORB to marshal and unmarshal outgoing and incoming
	parameters. Similarly, <I>server skeletons</I> are snippets of code that create the
	server framework. These skeletons pass incoming parameters to the implementation
	code--written by you, the developer--and pass outgoing parameters back to the client.
	
<HR>


</BLOCKQUOTE>

<P>The names of the files generated by the IDL compiler are dependent on the language
mapping used and sometimes on command-line arguments passed to the IDL compiler.
(For example, some IDL compilers accept switches that specify prefixes and suffixes
to be added to the class names.) The contents of these files will remain the same,
for the most part, regardless of the IDL compiler used (assuming the products conform
to the standard language mappings). For example, the output of the IDL compiler in
IONA's Orbix/C++ will be roughly the same as the output of Visigenic's VisiBroker/C++
IDL compiler. Similarly, the corresponding Java products will output nearly the same
source code.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>Strictly speaking, the term &quot;IDL compiler&quot; is a misnomer. Whereas
	a compiler generally converts source code to object code, the IDL compiler is more
	of a translator: It converts IDL source code to C++ source code, or Java source code,
	and so on. The generated code, along with the implementations that you provide, are
	then compiled by the C++ compiler, or Java compiler, and so on. 
<HR>


</BLOCKQUOTE>

<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Implementing the Server Interfaces</FONT></H3>
<P>After you have successfully used the IDL compiler to generate server skeletons
and client stubs for your application, you are ready to implement the server interfaces.
The IDL compiler generates a number of files; for each IDL <TT>interface</TT>, the
compiler will generate a source file and header file for the client stub and a source
file and header file for the server skeleton, resulting in four files per <TT>interface</TT>.
(This is for an IDL compiler targeting C++; an IDL compiler targeting Java will,
of course, not generate header files.) Additionally, the IDL compiler can create
separate directories for IDL <TT>module</TT>s; it can also create additional files
for helper classes. Also, most IDL compilers allow you to specify the suffix to use
for client stubs and server skeletons. For example, the client stub files can be
named <TT>StockMarket_c.h</TT> and <TT>StockMarket_c.cpp</TT>, or <TT>StockMarket_st.h</TT>
and <TT>StockMarket_st.cpp</TT>. Refer to your IDL compiler's documentation to determine
what files it produces, what filenames it uses, and how to change the default filename
suffixes.</P>
<P>To keep the example as simple as possible, Java is used as the implementation
language. Java was chosen for this example because of its relative simplicity, particularly
when developing CORBA applications. Of all the languages commonly used for CORBA
application development, Java probably gets in the way of the developer the least,
making it the best suited for an introductory example. Most of the remainder of this
book will use C++ for example code, with the exception of the Java-specific Chapters
13 and 14.
<H4><FONT COLOR="#000077">Using Server Skeletons</FONT></H4>
<P>The server skeleton, as you have learned, provides a framework upon which to build
the server implementation. In the case of C++, a server skeleton is a set of classes
that provides pure virtual methods (methods with no implementations) or methods that
delegate to methods in another class (the tie class discussed previously). You, the
developer, provide the implementation for these methods. In the case of Java, a server
skeleton combines a set of helper classes with an interface, for which you, again,
provide the implementation.</P>
<P>Assuming you use Sun's Java IDL compiler to produce the server skeletons for your
application, you will see that the compiler produced a directory called <TT>StockMarket</TT>
(corresponding to the name of the IDL <TT>module</TT> defined in <TT>StockMarket.idl</TT>).
Within this directory are a number of files containing client stub and server skeleton
definitions:</P>
<PRE><FONT COLOR="#0066FF"><TT>StockSymbolHelper.java</TT>
<TT>StockSymbolListHolder.java</TT>
<TT>StockSymbolListHelper.java</TT>
<TT>StockServer.java</TT>
<TT>StockServerHolder.java</TT>
<TT>StockServerHelper.java</TT>
<TT>_StockServerStub.java</TT>
<TT>_StockServerImplBase.java</TT>
</FONT></PRE>
<P>At this point, your only concern is with the server skeleton portion of these
files. In particular, note that the Java interface describing the <TT>StockServer</TT>
services is contained in the <TT>StockServer.java</TT> file. Its contents appear
in Listing 4.2. The <TT>StockServerImplBase.java</TT> file contains a helper class
from which you'll derive your server implementation class; you need not concern yourself
with its contents because it provides functionality that works under the hood.
<H4><FONT COLOR="#000077">Listing 4.2. StockServer.java.</FONT></H4>
<PRE><FONT COLOR="#0066FF"><TT> 1: /*</TT>
<TT> 2:  * File: ./StockMarket/StockServer.java</TT>
<TT> 3:  * From: StockMarket.idl</TT>
<TT> 4:  * Date: Mon Jul 21 16:12:26 1997</TT>
<TT> 5:  *   By: D:\BIN\DEVEL\JAVA\JAVAIDL\BIN\IDLTOJ~1.EXE JavaIDL</TT>
<TT> 6:  *   Thu Feb 27 11:22:49 1997</TT>
<TT> 7:  */</TT>
<TT> 8: </TT>
<TT> 9: package StockMarket;</TT>
<TT>10: public interface StockServer</TT>
<TT>11:     extends org.omg.CORBA.Object {</TT>
<TT>12:     float getStockValue(String symbol)</TT>
<TT>13: ;</TT>
<TT>14:     String[] getStockSymbols()</TT>
<TT>15: ;
16: }</TT></FONT> </PRE>
<P>Examining Listing 4.2, you see that the <TT>StockServer</TT> interface is placed
in the <TT>StockMarket</TT> package. Furthermore, you can see that this interface
extends the <TT>org.omg.CORBA.Object</TT> interface. All CORBA object interfaces
extend this interface, but you need not concern yourself with this interface's contents