📄 ch02.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><SCRIPT LANGUAGE="JavaScript"><!--function popUp(pPage) { var fullURL = document.location; var textURL = fullURL.toString(); var URLlen = textURL.length; var lenMinusPage = textURL.lastIndexOf("/"); lenMinusPage += 1; var fullPath = textURL.substring(0,lenMinusPage); popUpWin = window.open('','popWin','resizable=yes,scrollbars=no,width=525,height=394'); figDoc= popUpWin.document; zhtm= '<HTML><HEAD><TITLE>' + pPage + '</TITLE>'; zhtm += '</HEAD>'; zhtm += '<BODY bgcolor="#FFFFFF">'; zhtm += '<IMG SRC="' + fullPath + pPage + '">'; zhtm += '<P><B>' + pPage + '</B>'; zhtm += '</BODY></HTML>'; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 }//--> </SCRIPT> <META NAME="Author" Content="Bryan Flores"> <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1"> <TITLE>Teach Yourself CORBA In 14 Days -- Ch 2 -- Understanding the CORBA Architecture</TITLE></HEAD><BODY TEXT="#000000" BGCOLOR="#FFFFFF"><CENTER><H1><IMG SRC="../button/sams.gif" WIDTH="171" HEIGHT="66" ALIGN="BOTTOM" BORDER="0"><BR><FONT COLOR="#000077">Teach Yourself CORBA In 14 Days</FONT></H1></CENTER><CENTER><P><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"><IMGSRC="../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> <HR></CENTER><CENTER><H1><FONT COLOR="#000077">Day 2<BR>Understanding the CORBA Architecture</FONT><A HREF="#Heading1"></A></H1></CENTER><UL> <LI><A HREF="#Heading1">Overview</A> <LI><A HREF="#Heading2">The Object Request Broker (ORB)</A> <UL> <LI><A HREF="#Heading3">Marshaling</A> <LI><A HREF="#Heading4">Platform Independence</A> <LI><A HREF="#Heading5">ORB Summary</A> </UL> <LI><A HREF="#Heading6">Interface Definition Language (IDL)</A> <UL> <LI><A HREF="#Heading7">Language Independence</A> </UL> <LI><A HREF="#Heading8">The CORBA Communications Model</A> <UL> <LI><A HREF="#Heading9">Inter-ORB Protocols</A> <LI><A HREF="#Heading10">CORBA and the Networking Model</A> </UL> <LI><A HREF="#Heading11">The CORBA Object Model</A> <UL> <LI><A HREF="#Heading12">Object Distribution</A> <LI><A HREF="#Heading13">Object References</A> <LI><A HREF="#Heading14">Basic Object Adapters (BOAs)</A> </UL> <LI><A HREF="#Heading15">CORBA Clients and Servers</A> <UL> <LI><A HREF="#Heading16">Multiple Personalities? Being Both a Client and a Server</A> </UL> <LI><A HREF="#Heading17">Stubs and Skeletons</A> <LI><A HREF="#Heading18">Beyond the Basics: CORBAservices and CORBAfacilities</A> <LI><A HREF="#Heading19">Summary</A> <LI><A HREF="#Heading20">Q&A</A> <LI><A HREF="#Heading21">Workshop</A> <UL> <LI><A HREF="#Heading22">Quiz</A> </UL></UL><P><HR SIZE="4"><CENTER><H1><FONT COLOR="#000077"></FONT></H1></CENTER><H2><A NAME="Heading1"></A><FONT COLOR="#000077">Overview</FONT></H2><P>On the first day, you learned about CORBA's history and saw how the CORBA architecturefits into the world of client/server application development. You were also presentedwith a brief overview of the CORBA architecture. By the end of this Day, you willhave a deeper understanding of the CORBA architecture and its components. These arethe major aspects covered in this chapter:<UL> <LI>The Object Request Broker (ORB), one of the cornerstones of the CORBA architecture <LI>The Interface Definition Language (IDL), the other CORBA architectural cornerstone <LI>The CORBA communications model, how CORBA objects fit within the network architecture <LI>The CORBA object model, including object references and Basic Object Adapters (BOAs) <LI>The definition and roles of clients and servers in the CORBA architecture <LI>The use of client stubs and server skeletons to build CORBA applications</UL><UL> <LI>An overview of CORBAservices and CORBAfacilities, which provide additional functionality to CORBA applications</UL><H2><A NAME="Heading2"></A><FONT COLOR="#000077">The Object Request Broker (ORB)</FONT></H2><P>As one might guess, a fundamental part of the Common Object Request Broker architectureis the <I>Object Request Broker</I> <I>(ORB).</I> The concept of an ORB is this:When an application component wants to use a service provided by another component,it first must obtain an object reference for the object providing that service. (Howthis object reference is obtained is an issue in its own right--and will be discussedlater--but for the purposes of studying the ORB mechanism, assume for the time beingthat the object reference is already available.) After an object reference is obtained,the component can call methods on that object, thus accessing the desired servicesprovided by that object. (The developer of the client component knows at compiletime which methods are available from a particular server object.) The primary responsibilityof the ORB is to resolve requests for object references, enabling application componentsto establish connectivity with each other. (See Figure 2.1 for an illustration ofthese ORB concepts.) As you will see, the ORB has other responsibilities as well.<BR><BR><A HREF="javascript:popUp('01.jpg')"><B>Figure 2.1.</B></A> <I>ORB resolution ofobject requests.</I><H3><A NAME="Heading3"></A><FONT COLOR="#000077">Marshaling</FONT></H3><P>After an application component has obtained a reference to an object whose servicesthe component wants to use, that component can invoke methods of that object. Generally,these methods take parameters as input and return other parameters as output. Anotherresponsibility of the ORB is to receive the input parameters from the component thatis calling the method and to <I>marshal</I> these parameters. What this means isthat the ORB translates the parameters into a format that can be transmitted acrossthe network to the remote object. (This is sometimes referred to as an <I>on-the-wire</I>format.) The ORB also <I>unmarshals</I> the returned parameters, converting themfrom the on-the-wire format into a format that the calling component understands.The marshaling process can be seen in Figure 2.2. <BR><BR><A HREF="javascript:popUp('02.jpg')"><B>Figure 2.2.</B></A> <I>Marshaling parametersand return values.</I> <B><I><BR><BR>New Term: </I></B><I>Marhsaling</I> refers to the process of translating input parametersto a format that can be transmitted across a network.</P><P><I>Unmarshaling</I> is the reverse of marshaling; this process converts data fromthe network to output parameters.</P><P>An <I>On-the-wire format</I> specifies the format in which data is transmittedacross the network for the marshaling and unmarshaling processes.</P><P>The entire marshaling process takes place without any programmer interventionwhatsoever. A client application simply invokes the desired remote method--whichhas the appearance of being a local method, as far as the client is concerned--anda result is returned (or an exception is raised), again, just as would happen witha local method. The entire process of marshaling input parameters, initiating themethod invocation on the server, and unmarshaling the return parameters is performedautomatically and transparently by the ORB.<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Platform Independence</FONT></H3><P>A product of the marshaling/unmarshaling process is that, because parameters areconverted upon transmission into a platform-independent format (the on-the-wire formatis provided as part of the CORBA specification) and converted into a platform-specificformat upon reception, the communication between components is platform-independent.This means that a client running on, for instance, a Macintosh system can invokemethods on a server running on a UNIX system. In addition to independence of operatingsystem used, differences in hardware (such as processor byte ordering, or endianness)are also rendered irrelevant because the ORB automatically makes these conversionsas necessary. In essence, any differences in platforms--be it operating system, endianness,word size, and so on--are accounted for by the ORB.</P><P>Note again that the process of marshaling and unmarshaling parameters is handledcompletely by the ORB, entirely transparent to both the client and server. Becausethe entire process is handled by the ORB, the developer need not concern himselfwith the details of the mechanism by which the parameters are marshaled and unmarshaled.<H3><A NAME="Heading5"></A><FONT COLOR="#000077">ORB Summary</FONT></H3><P>Because the concept of the ORB is central to an understanding of the CORBA architecture,it is important to make sure that you grasp the ORB concepts. To summarize the purposeof the ORB, its responsibilities are as follows:<UL> <LI>Given an object reference from a client, the ORB locates the corresponding object implementation (the server) on behalf of the client. (Note that it is the responsibility of the client to obtain an object reference in the first place, through a process you'll learn later.) <LI>When the server is located, the ORB ensures that the server is ready to receive the request. <LI>The ORB on the client side accepts the parameters of the method being invoked and marshals (see the next section) the parameters to the network. <LI>The ORB on the server side unmarshals (again, see the next section) the parameters from the network and delivers them to the server. <LI>Return parameters, if any, are marshaled/unmarshaled in the same way.</UL><P>The major benefit offered by the ORB is its platform-independent treatment ofdata; parameters can be converted on-the-fly between varying machine formats as theyare marshaled and unmarshaled.<H2><A NAME="Heading6"></A><FONT COLOR="#000077">Interface Definition Language (IDL)</FONT></H2><P>If the concept of the Object Request Broker is one cornerstone of the CORBA architecture,the <I>Interface Definition Language</I> (IDL) is the other. IDL, as its name suggests,is the language used to define interfaces between application components. Note thatIDL is not a procedural language; it can define only interfaces, not implementations.C++ programmers can think of IDL definitions as analogous to header files for classes;a header file typically does not contain any implementation of a class but ratherdescribes that class's interface. Java programmers might liken IDL definitions todefinitions of Java interfaces; again, only the interface is described--no implementationis provided.</P><P><B>New Term: </B>The <I>Interface Definition Language (IDL)</I> is a standardlanguage used to define the interfaces used by CORBA objects. It is covered in greatdetail on Day 3.</P><P>The IDL specification is responsible for ensuring that data is properly exchangedbetween dissimilar languages. For example, the IDL <TT>long</TT> type is a 32-bitsigned integer quantity, which can map to a C++ <TT>long</TT> (depending on the platform)or to a Java <TT>int</TT>. It is the responsibility of the IDL specification--andthe IDL compilers that implement it--to define such data types in a language-independentway.</P><P>IDL will be covered in great detail in the next chapter. After that, you will⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -