📄 ch11.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 11 -- Using the Dynamic Invocation Interface (DII)</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="../ch10/ch10.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch12/ch12.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 11<BR>Using the Dynamic Invocation Interface (DII)</FONT><A HREF="#Heading1"></A></H1></CENTER><UL> <LI><A HREF="#Heading1">Introducing the Dynamic Invocation Interface</A> <UL> <LI><A HREF="#Heading2">The Purpose of DII</A> <LI><A HREF="#Heading3">Comparison with Static Interfaces/IDL</A> </UL> <LI><A HREF="#Heading4">Using DII: An Overview</A> <UL> <LI><A HREF="#Heading5">Introducing the Request</A> <LI><A HREF="#Heading6">Anys and TypeCodes: A Review</A> <LI><A HREF="#Heading7">Request and Reply Options</A> <LI><A HREF="#Heading8">DII Example</A> </UL> <LI><A HREF="#Heading9">Summary</A> <LI><A HREF="#Heading10">Q&A</A> <LI><A HREF="#Heading11">Workshop</A> <UL> <LI><A HREF="#Heading12">Quiz</A> </UL></UL><P><HR SIZE="4"><CENTER><H1><FONT COLOR="#000077"></FONT></H1></CENTER><P>On Day 10, "Learning About CORBA Design Issues," you took a short breakfrom developing the sample <TT>Bank</TT> application to study some design issuesraised by the CORBA architecture. As you saw, using CORBA sometimes requires youto rethink parts (or all!) of the design of some applications because CORBA introducessome restrictions of its own.</P><P>Today you'll continue your hiatus from the sample <TT>Bank</TT> application--thistime to study a simple client that accesses a server object through the Dynamic InvocationInterface (DII). DII enables a client to access services without having been compiledwith a client stub for those services. (Recall in the past that with your applicationsyou had to compile and link client stubs that used CORBA object services.) How doesthis work? The DII enables CORBA clients to discover interfaces dynamically (in otherwords, at runtime rather than compile time) and invoke methods on objects that implementthose interfaces. Today you'll learn about DII and why it is useful, and then you'llsee how a client application is implemented to use DII services.<H2><A NAME="Heading1"></A><FONT COLOR="#000077">Introducing the Dynamic InvocationInterface</FONT></H2><P>Until now, the CORBA clients you've implemented have been static in some respect,aware of only the interfaces whose client stubs had been included with the rest ofthe client application at compile time. Thus, the <TT>BankClient</TT> and <TT>ATMClient</TT>applications only knew about the <TT>Bank</TT> interface, the <TT>ATM</TT> interface,the <TT>Account</TT> interface, and so on. For the purposes of the <TT>Bank</TT>application, static knowledge of interfaces works well; there is no reason for aclient to access other types of objects unknown to it at compile time. However, thereare times when more dynamic client applications are called for, and this is whereDII comes in. (You'll see very soon the situations which call for the capabilityprovided by DII.)</P><P>It should be stressed that the Dynamic Invocation Interface could quite possiblybe the least useful feature of CORBA. You'll see later in this chapter that thereare only a handful of types of applications which really benefit from using DII;in almost all other cases, chances are that you'll never have to use DII. However,for the sake of completeness--and just in case, by some freak chance, you might everfind yourself needing to use it--a discussion of DII is included here.<H3><A NAME="Heading2"></A><FONT COLOR="#000077">The Purpose of DII</FONT></H3><P>As stated earlier, DII enables a CORBA client application to discover interfacesat runtime. This means that such a client application can be compiled with no clientstubs at all, thus having no prior knowledge of any type of CORBA server object.(The client need not discover all server interfaces dynamically, though; it can becompiled with client stubs for some interfaces and find other interfaces dynamically.)In any case, DII is the enabling feature of CORBA that lets clients use servicesof objects that were unknown to the client at compile time. (Note that the use ofDII only applies to a client; when a server method is invoked, that server has noknowledge of whether a method was invoked via the conventional static mechanism orthrough DII.)</P><P>So why is the Dynamic Invocation Interface useful? After all, shouldn't the designerof an application know what kind of objects the application will need to access?In most cases, this is true, but some types of applications, although uncommon, dobenefit from the capability to discover new object types and use them. There areat least two practical examples: a CORBA design tool and a generic object browserapplication.<H4><FONT COLOR="#000077">A Hypothetical CORBA Design Tool Using DII</FONT></H4><P>One potential use for DII is in a design tool for creating CORBA applications.Such a tool would have access to the IDL interfaces used to create the CORBA objects,because developers don't generally deal with CORBA objects for which they have nosource code or IDL. However, because you can never be sure what developers are goingto do, it would be a nice touch for the tool to have the capability to discover existingCORBA interfaces and generate client code to use those objects. The tool could alsoenable the developer to plug in CORBA server objects based on either their IDL interfacesor the interfaces as determined through DII (much as controls can be plugged in todevelopment tools such as Visual Basic and JavaBeans-aware Java development tools).<H4><FONT COLOR="#000077">A Generic Object Browser Using DII</FONT></H4><P>Another possible use for the Dynamic Invocation Interface is in an esoteric, butsometimes practical, application: one that browses objects on the network. Thereare many reasons why you might want to do this in some types of applications. Forexample, envision an automated test application that discovers objects, learns theirinterfaces, and invokes each method in the interface with a set of dummy parameters.The results could then be recorded and later analyzed to determine objects' compliancewith a test plan. Because the test application would discover object interfaces dynamicallyusing DII, it would not need to be recompiled to handle new types of objects, makingit useful as a generic testing tool.</P><P>Yet another type of object browsing tool could look for objects that implementparticular methods and then enable a user to access those objects. This would behelpful if a particular design called for a set of standard methods that should beimplemented by all objects in the system, but for some reason it did not define abase class from which all interfaces would derive (this is not always possible whenmixing together interfaces from various sources, such as different products or differentprojects). For example, if each object were to define a <TT>killObject()</TT> method,an object browser could use DII to look for objects that defined such a method, whichwould in turn enable users to kill objects at will. Although this is a trivial example,it sets the stage for a more complex set of methods that could, for example, provideremote system administration features.</P><P>Taking this idea one step further, it would be possible to design a Web objectbrowser that could browse objects, instead of Web pages consisting of static HTML,Dynamic HTML, Java applications, and so on. Objects could support a basic interfaceand also, optionally, offer additional capabilities in the form of methods that thebrowser could discover through DII. Because such an application would most likelybe interactive, the user could determine which methods were interesting through inspection.In fact, a clever browser application could determine which methods are interesting,based on their names and parameter lists.</P><P>As a final example, consider an interpreted scripting language such as Perl orTcl (or some other fictitious scripting language). DII could be used to interfacesuch a language with CORBA objects. When a script accessed an operation on a CORBAobject, the interpreter could use DII to "assemble" a remote method invocationfrom the IDL interface definition, pass the proper arguments to the method, and returnthe result to the script. Here the language interpreter would essentially replacethe IDL compiler, which as you should recall is usually responsible for interfacingCORBA objects with various languages. However, the language interpreter would alsohave to become an IDL compiler of sorts, since it would have to translate IDL definitionsinto DII method calls.<H3><A NAME="Heading3"></A><FONT COLOR="#000077">Comparison with Static Interfaces/IDL</FONT></H3><P>By now it has been established that DII offers at least one advantage over theconventional static process of invoking methods on objects. You have also seen somepotential applications in which DII would prove useful. Although this range of applicationsis admittedly limited, DII is instrumental in making them possible--without DII,such applications could not exist at all. To review the advantages of DII:<UL> <LI>A client need not be aware of server interfaces at compile time; in fact, the interface definition for the server object does not need to even exist at the time that the client is compiled. This makes possible enormous flexibility in applications using DII (if you can find an application that requires such flexibility).<BR> <BR> <LI>The DII offers several options for obtaining return parameters from a method. The client application can obtain the result normally, invoke the method using <TT>oneway</TT> semantics (even if the interface's IDL did not declare the method as <TT>oneway</TT>, although this may not be advisable), or poll for a result. These options enable even greater flexibility in DII applications than in their static invocation-making counterparts.</UL><P>There are, however, some disadvantages associated with using the Dynamic InvocationInterface:<UL> <LI>Applications using DII are more complex than their client stub-using counterparts. This is because a method call through DII must push each of the input arguments one at a time, invoke the method, and then pull each of the return arguments back. If this is done by hand, it can be a tedious and error-prone process.<BR> <BR> <LI>While static type-checking capability is built into the static method invocation mechanism, there essentially is none for DII method calls. Consequently, subtle differences in interface definitions may cause an application to inadvertently invoke incorrect methods--even if the application code compiles correctly! Such errors can be difficult to track down, making them especially insidious.<BR> <BR> <LI>Because each argument to a method must be pushed one at a time, additional overhead is incurred in each DII method call.<BR> <BR> <LI>Of course, there is also the overhead associated with the actual discovery of interfaces. A DII client will typically need to "negotiate" with a server (or a number of servers) to locate the interface (or interfaces) in which that client is interested.</UL><H2><A NAME="Heading4"></A><FONT COLOR="#000077">Using DII: An Overview</FONT></H2><P>Now that you know what the DII is designed for, you need to see how it is used.The process of issuing a DII method invocation differs from issuing a static methodinvocation, as you might expect. There are three major concepts associated with usingthe DII: the <TT>Request</TT> object, the use of <TT>Any</TT>s and <TT>TypeCode</TT>s(which you will recall from Day 3), and available options for sending requests andreceiving replies.<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Introducing the Request</FONT></H3><P>The <TT>Request</TT> is a "pseudo-object" (that is, it does not representa CORBA object, but is implemented as an object as far as the implementation languageis concerned) that invokes a method on a CORBA object. To invoke a method using DII,you first obtain a reference to the object on which the method is to be invoked.Then, using the object's <TT>request()</TT> or <TT>create_request()</TT> method,you create a <TT>Request</TT> object. Depending on which method you choose, you populatethe <TT>Request</TT> with arguments, return types, and exceptions, using the <TT>add_value()</TT>and <TT>result()</TT> methods of the <TT>Request</TT> object. Then you invoke themethod (using one of the methods discussed later in this section) and finally retrievethe result of the method invocation (again using one of the methods discussed later).</P><P>The purpose of the <TT>Request</TT> is to encapsulate input parameters to methodinvocations and return result values from them. A <TT>Request</TT> can be createdin one of two ways, depending on how you intend to use the <TT>Request</TT>. (Notethat a <TT>Request</TT> object can be used for only one method invocation on oneobject; to call a method twice, call two separate methods on the same object, orto call methods on two different objects, you need to create two <TT>Request</TT>objects.) The two methods for creating a <TT>Request</TT> object are as follows:<UL> <LI>Invoke the <TT>request()</TT> method on the CORBA object. The <TT>request()</TT> method takes the name of the method to be invoked as a parameter, for instance, <TT>request("getBanks")</TT>. You then call <TT>add_value()</TT> on the returned <TT>Request</TT> object to add input parameters. Finally, you call <TT>result()</TT> on the <TT>Request</TT> object to specify the type of the return parameter.<BR> <BR>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -