📄 _chapter 5.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Chapter 5</title>
<link rel="stylesheet" type="text/css" href="docsafari.css">
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<ul></ul>
<table width="100%" border="1" bgcolor="#EBEBFF">
<tr>
<td width="5%" align="left" valign="middle"><a href="_chapter%204.htm"><img src="Larrow.gif" width="17" height="19" border="0"></a></td>
<td align="center" valign="middle"><a class="docLink" href="Front%20matter.htm">CONTENTS</a></td>
<td width="5%" align="right" valign="middle"><a href="_chapter%206.htm"><img src="Rarrow.gif" width="17" height="19" border="0"></a></td>
</tr>
</table>
<h2 class="docChapterTitle">Chapter 5. Remote Objects</h2>
<ul>
<li><p class="docList"><a class="docLink" href="#ch05lev1sec1">Introduction to Remote Objects: The Roles of Client and Server</a></li>
<li>
<p class="docList"><a class="docLink" href="#c5s1">Remote Method Invocations</a></li>
<li>
<p class="docList"><a class="docLink" href="#c5s2">Setting Up Remote Method Invocation</a></li>
<li>
<p class="docList"><a class="docLink" href="#c5s3">Parameter Passing in Remote Methods</a></li>
<li>
<p class="docList"><a class="docLink" href="#c5s4">Using RMI with Applets</a></li>
<li>
<p class="docList"><a class="docLink" href="#c5s5">Server Object Activation</a></li>
<li>
<p class="docList"><a class="docLink" href="#c5s6">Java IDL and CORBA</a></li>
<li><p class="docList"><a class="docLink" href="#ch05lev1sec2">Implementing CORBA Servers</a></li>
</ul>
<p class="docText">Periodically, the programming community starts thinking of
"objects everywhere" as the solution to all its problems. The idea is to have a
happy family of collaborating objects that can be located anywhere. These
objects are, of course, supposed to communicate through standard protocols
across a network. For example, you'll have an object on the client where the
user can fill in a request for data. The client object sends a message to an
object on the server that contains the details of the request. The server object
gathers the requested information, perhaps by accessing a database or by
communicating with additional objects. Once the server object has the answer to
the client request, it sends the answer back to the client. Like most bandwagons
in programming, this plan contains a fair amount of hype that can obscure the
utility of the concept. This chapter:</p>
<ul>
<li>
<p class="docList">Explains the models that make interobject communication
possible;</li>
<li>
<p class="docList">Explains situations where distributed objects can be
useful;</li>
<li>
<p class="docList">Shows you how to use remote objects and the associated
<span class="docEmphasis">remote method invocation</span> (RMI) for
communicating between two Java virtual machines (which may run on different
computers);</li>
<li>
<p class="docList">Introduces you to CORBA, the Common Object Request Broker
Architecture that allows communication between objects that are written in
different programming languages (such as the Java programming language, C++,
and so on).</li>
</ul>
<h3 class="docSection1Title" id="ch05lev1sec1">Introduction to Remote Objects: The Roles of Client
and Server</h3>
<p class="docText">Let's go back to that idea of locally collecting information
on a client computer and sending the information across the Net to a server. We
are supposing that a user on a local machine will fill out an information
request form. The form data gets sent to the vendor's server, and the server
processes the request and will, in turn, want to send back product information
the client can view, as shown in <a class="docLink" href="#ch05fig01">Figure 5-1</a>.</p>
<center>
<h5 id="ch05fig01" class="docFigureTitle">Figure 5-1. Transmitting objects between client and
server</h5>
<p>
<img alt="graphics/05fig01.gif" src="05fig01.gif" border="0" width="300" height="414"></p>
</center>
<p class="docText">In the traditional client/server model, the request is
translated to an intermediary format (such as name/value pairs or XML data). The
server parses the request format, computes the response, and formats the
response for transmission to the client. The client then parses the response and
displays it to the user.</p>
<p class="docText">But if your data is structured, then there is a significant
coding hassle: you have to come up with appropriate ways of translating the data
to and from the transmission format.</p>
<div class="docNote">
<p class="docNoteTitle">NOTE</p>
<table cellSpacing="0" cellPadding="1" width="90%" border="0">
<tr>
<td vAlign="top" width="60">
<img alt="graphics/note.gif" src="note.gif" align="left" border="0" width="54" height="53"><br>
</td>
<td vAlign="top">
<p class="docText">Another method for sending a request for data to a
server is with HTML forms. Then, the client is simply the browser, and the
server needs to gather the requested information and format it as HTML.
Even in that model, it makes sense to separate the form processing from
the data gathering. Typically, the form processing happens on the web
server, and the data gathering happens on a different server, called an
<span class="docEmphasis">application server</span>. You again have two
communicating objects, the client object on the web server and the server
object on the application server. This is a very common model in practice.
In this chapter, we stick to a more traditional client/server example
because it makes the roles of the client and server more intuitive.</td>
</tr>
</table>
</div>
<p class="docText">What would go into a possible solution? Well, keeping in mind
that objects sending requests to one another is the central tenet of OOP, we
could put objects on different machines and have them send messages
<span class="docEmphasis">directly</span> to each other. Let's assume that the
client object was written in the Java programming language so that it can
theoretically run anywhere. For the server objects, there are two obvious
possibilities:</p>
<ul>
<li>
<p class="docList">The server object was <span class="docEmphasis">not</span>
written in the Java programming language (either because it is a legacy object
or because somebody hasn't jumped on the appropriate bandwagon).</li>
<li>
<p class="docList">The server object <span class="docEmphasis">was</span>
written in the Java programming language.</li>
</ul>
<p class="docText">The first situation requires us to have a way for objects to
talk to each other <span class="docEmphasis">regardless</span> of what language
they were originally written in. If you think about it, you will agree with us
that even the theoretical possibility of this is an amazing achievement. How can
what is ultimately a sequence of bytes written in an arbitrary language, that we
may have no knowledge of, tell us what services it offers, what messages it
responds to? Of course, getting this to work in practice isn't easy, but the
idea is elegant. The "common object request broker architecture," or CORBA
standard, by the Object Management Group or OMG (<a class="docLink" href="http://www.omg.org" target="_blank">www.omg.org</a>)
defines a common mechanism for interchanging data and discovering services.</p>
<p class="docText">The fundamental idea is that we delegate the task of finding
out this information and activating any requested services to a so-called
<span class="docEmphasis">Object Request Broker</span> (or ORB). You can think
of an ORB as a kind of universal translator for interobject communication.
Objects don't talk directly to each other. They always use an object broker to
bargain between them. ORBs are located across the network, and it is important
that they can communicate with each other. Most ORBs follow the specification
set up by the OMG for inter-ORB communication. This specification is called the
Internet Inter-ORB Protocol or IIOP.</p>
<div class="docNote">
<p class="docNoteTitle">NOTE</p>
<table cellSpacing="0" cellPadding="1" width="90%" border="0">
<tr>
<td vAlign="top" width="60">
<img alt="graphics/note.gif" src="note.gif" align="left" border="0" width="54" height="53"><br>
</td>
<td vAlign="top">
<p class="docText">Microsoft uses COM, a different, lower-level protocol
for interobject communication. ORB-like services are bundled into the
Windows operating system. As recently as 1999, Microsoft positioned COM as
a competitor to CORBA. However, at the time of this writing, Microsoft is
deemphasizing COM in favor of its NET model for XML-based communication
between software components.</td>
</tr>
</table>
</div>
<p class="docText">CORBA is completely language neutral. Client and server
programs can be written in C++, the Java programming language, or any other
language with a CORBA binding. You use an <span class="docEmphasis">Interface
Definition Language</span> (or IDL) to specify the signatures of the messages
and the types of the data your objects can send and understand. (IDL
specifications look a lot like interfaces in the Java programming language; in
fact, you can think of them as defining interfaces that the communicating
objects must support. One nice feature of this model is that you can supply an
IDL specification for an existing legacy object and then access its services
through the ORB even if it was written long before the first ORB arrived.)</p>
<p class="docText">There are quite a few people who believe that CORBA is the
object model of the future, and that the Java programming language is an
excellent choice for implementing CORBA clients and servers. However, frankly
speaking, CORBA has had a reputation梥ometimes deserved梖or slow performance,
complex implementations, and interoperability problems. After running into quite
a few CORBA problems while writing this chapter, and encountering many of the
same issues when updating it two years later, our sentiments about CORBA are
similar to those expressed by French president Charles De Gaulle's about Brazil:
It has a great future ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -