📄 ch10.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 10 -- Learning About CORBA Design Issues</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="../ch09/ch09.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch11/ch11.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 10<BR>Learning About CORBA Design Issues</FONT><A HREF="#Heading1"></A></H1></CENTER><UL> <LI><A HREF="#Heading1">IDL Creep</A> <LI><A HREF="#Heading2">Single-Threaded Applications</A> <UL> <LI><A HREF="#Heading3">Server Applications</A> <LI><A HREF="#Heading4">Client Applications</A> <LI><A HREF="#Heading5">Mixed Server/Client Applications</A> </UL> <LI><A HREF="#Heading6">Object Lifetime</A> <LI><A HREF="#Heading7">Lack of Pass-by-Value Semantics</A> <UL> <LI><A HREF="#Heading8">Rogue Wave ORBstreams.h++</A> <LI><A HREF="#Heading9">Using CORBA structs</A> <LI><A HREF="#Heading10">Using Conversion Constructors</A> </UL> <LI><A HREF="#Heading11">CORBA and X Window System</A> <UL> <LI><A HREF="#Heading12">Single-Threaded Applications Using CORBA and X</A> <LI><A HREF="#Heading13">Multithreaded Applications Using CORBA and X</A> </UL> <LI><A HREF="#Heading14">Summary</A> <LI><A HREF="#Heading15">Q&A</A> <LI><A HREF="#Heading16">Workshop</A> <UL> <LI><A HREF="#Heading17">Quiz</A> </UL></UL><P><HR SIZE="4"><CENTER><H1><FONT COLOR="#000077"></FONT></H1></CENTER><P>By now you have probably determined for yourself that CORBA is a complex architecture.Like any complex architecture, CORBA comes with its own set of issues that affectthe design and implementation of CORBA systems. For example, the fact that all interfacesin CORBA are specified in IDL has an effect on developers who want to integrate existingsystems with CORBA--usually, IDL interfaces have to be written for a number of existingclasses (not a trivial undertaking). This chapter introduces you to such design issuesand offers suggestions on how to deal with them.<H2><A NAME="Heading1"></A><FONT COLOR="#000077">IDL Creep</FONT></H2><P>The term <I>IDL</I> <I>creep</I> does not refer to that guy in the office downthe hall who thinks he knows everything about the Interface Definition Language.Rather, it is a term coined to refer to the tendency for IDL to permeate a systemdesign--and permeate it does. Think about it: For a class to be understood by CORBA,its interface must be expressed in IDL. Furthermore, if the classes referenced orotherwise used by that class also need to be accessible to CORBA components, thenthose classes must also have their interfaces expressed in IDL. Consequently, itis not uncommon for most, if not all, classes in a system to require IDL specifications.</P><P>If you're designing an application from the ground up, having to define IDL interfacesfor most (or even all) classes isn't terribly demanding. However, if you're convertingan existing application to CORBA, the process can be an arduous one indeed. Becausethe existing classes were probably not written with CORBA--or a distributed architectureof any kind--in mind, the interfaces for those classes might have to be modifiedsomewhat to mesh well with IDL. Although the modifications themselves might not requirea great deal of effort, remember that if the interface of an object changes, anycode that uses that object might have to be modified as well. This cascade effectcan easily turn a few interface changes in a relatively few classes into a frustratingmess of changes throughout an application.</P><P>This scenario doesn't even take into consideration the possibility that the non-CORBAapplication's very architecture might not be amenable to the CORBA architecture.In particular, CORBA's current lack of the capability to pass objects by value canespecially affect the design of an application (discussed later in this chapter).Sometimes, modifying an existing application to use CORBA can be like trying to fita square peg into a round hole.</P><P>The moral is that IDL is pervasive--it has a way of creeping into a system designand slowly taking it over. This is not necessarily a bad thing in itself, but itcan potentially make the "CORBAtization" of legacy applications a difficultprospect. Be prepared to write IDL for any class in an application that might needto be shared between application components.</P><P>It is not always possible to avoid introducing IDL into most classes of an existingapplication without entailing a significant redesign of portions (or all!) of theapplication. However, when designing an application from the ground up, there isone guideline in particular for minimizing the impact of IDL on the rest of the application:Pay close attention to which classes will likely need to be shared between applicationcomponents and which will not. The underlying classes (e.g., classes that aren'tpart of any interfaces between components) generally will not require IDL interfaces.<H2><A NAME="Heading2"></A><FONT COLOR="#000077">Single-Threaded Applications</FONT></H2><P>Although most modern operating systems support multithreaded applications--thatis, applications in which multiple threads of control might be executing in a singleprogram at the same time--the use of multithreading is still limited. There are severalreasons for this: Not all operating systems fully support threading, not all developersuse the later versions of operating systems, which do support threading, and notall developers feel comfortable with it anyway. In addition, using multiple threadsin applications introduces new issues--not the least of which is the need to manageconcurrent access to objects--that complicate application design and development.Consequently, the use of multithreading is not as widespread as it could be.</P><P>CORBA does not force developers into a multithreaded development paradigm; indeed,it is perfectly feasible to create single-threaded CORBA applications. However, dueto the nature of the operation of distributed applications, great care must be takenwhen designing and developing CORBA applications for a single-threaded environment.This chapter tells you why, covering issues on both the server and client ends ofthe application.<H3><A NAME="Heading3"></A><FONT COLOR="#000077">Server Applications</FONT></H3><P>The justification for using multiple threads in server applications is simple:A CORBA server might have multiple clients accessing it at any given time. If theserver is single-threaded, it can only process a request from one client at a time--ifanother client attempts to access the server while the server is busy processinga second client's request, the first client must wait until the server is finished(see Figure 10.1). The obvious disadvantage to this architecture is that if the serverperforms transactions that take time to complete, the apparent responsiveness ofthe system (as far as the end users are concerned) suffers. <BR><BR><A HREF="javascript:popUp('01.jpg')"><B>Figure 10.1.</B></A> <I>Single-threaded serveroperation.</I> <BR><BR>One approach to mitigating this problem is to employ the use of multiple serversin an application. Normally, an enterprise-scale application employs multiple serversanyway, for reasons such as load balancing and redundancy. However, it is simplynot practical to provide a server per concurrent client, given the amount of overheadrequired by each server application. It is much more efficient for a single serverto handle multiple simultaneous clients, and this is precisely the capability affordedby a multithreaded architecture.</P><P>In a multithreaded server architecture (see Figure 10.2), rather than processonly one client request at a time, the server can start a new thread of executionfor each transaction. Because there is always a thread listening for new requests,other clients no longer need to wait for the server to complete a transaction beforeit can accept the next one. The result is that the server appears more responsivebecause it can respond immediately to incoming requests. <BR><BR><A HREF="javascript:popUp('02.jpg')"><B>Figure 10.2.</B></A> <I>Multithreaded serveroperation.</I> <BR><BR>Although the multithreaded architecture can create the illusion of better serverperformance by enhancing server responsiveness, the architecture does not magicallymake servers faster. If the server is processing several transactions simultaneously,the speed at which each transaction is processed is likely to decrease relative toa server processing only one transaction at a time. (Multithreaded applications canbe more efficient than single-threaded applications, however, so a server processingonly one transaction at a time might not be twice as fast as a server processingtwo transactions simultaneously.) So, although the use of multithreading is not intendedto replace the use of multiple servers, it is usually preferable to deploy multiplemultithreaded servers than multiple single-threaded servers. Furthermore, in mostcases, fewer multithreaded servers are required to deliver the same end user responsiveness.</P><P>Because multithreading does not come for free, it is important to understand whenit is appropriate. Managing multiple threads, especially when it is necessary (asit often is) to prevent multiple threads from simultaneously accessing the same data,can result in costly overhead. Consequently, on a machine with a single CPU, addingmultiple threads to an application that is already CPU-bound will only make it slower(although response time to individual clients, as discussed previously, might stillimprove). On the other hand, on a multiprocessing machine, because each thread canpotentially run on its own CPU, performance when using multithreading might increase,even on a CPU-bound application. Where multiprocessing truly shines, however, isin I/O-bound server applications or in applications that act as clients and serverssimultaneously (as you will see in the next section). In an I/O-bound server applicationwith multiple client connections, the likelihood that a given thread will be blockedwhile waiting for I/O increases. Hence, other threads will be given the opportunityto do useful work, thus using the available CPU(s) more efficiently.</P><P>The bottom line regarding the use of threads in CORBA servers is this: If theserver can process transactions quickly enough so that response time is not a concern,a single-threaded server will probably suffice. If the response time of a single-threadedserver is not adequate, the use of multithreading is probably a better alternative.Note that this is true only if the server does not also act as a client. If it performsboth roles, there might be additional issues involved, as you will soon see.<H3><A NAME="Heading4"></A><FONT COLOR="#000077">Client Applications</FONT></H3><P>Unlike a server application, a client application does not need to concern itselfwith providing a reasonable response time to other clients. In most cases, when aclient calls a remote method on a server, it is perfectly reasonable for the clientto wait for the server's response before continuing. This is true as long as oneassumption holds true--that the client application is a <I>pure</I> client; thatis, the application does not create any CORBA objects and pass references to those⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -