Java RMI：构建分布式应用实战指南

需积分: 10 124 浏览量更新于2024-07-27 收藏 2.26MB PDF 举报

"RMI JAVA SERVER STUN 是一本关于Java RMI技术的专业书籍，由William Grosso撰写，由O'Reilly出版社于2001年首次出版。这本书深入介绍了Java远程方法调用（RMI）的各种技巧和策略，旨在帮助读者提升RMI代码的性能。书中涵盖了序列化、线程、RMI注册表、套接字和套接字工厂、激活、动态类下载、HTTP隧道、分布式垃圾收集、JNDI以及CORBA等多个主题。" Java RMI是Java平台中的一个重要特性，它允许Java对象在不同的网络计算机之间进行交互，实现分布式计算。通过RMI，开发者可以创建能够在不同 JVM (Java虚拟机) 上运行的分布式应用程序，这极大地扩展了Java应用程序的能力。本书的章节结构清晰，首先从基础的流(Streams)概念开始，讲解了核心类、查看文件、流的分层以及读写器。然后，深入到套接字(Sockets)的相关知识，包括互联网定义、套接字的创建与使用、服务器套接字、自定义套接字行为，以及特殊用途的套接字，如安全套接字(SSL)。接着，通过一个基于套接字的打印机服务器案例，展示了如何将这些理论知识应用到实际项目中。书中的"定制套接字行为"部分可能包括了如何利用SocketFactory类来创建自定义的通信协议，而"动态类下载"则可能涉及如何在运行时将新类加载到远程系统中，使得分布式系统具有更高的灵活性。HTTP隧道的讨论可能涵盖如何在防火墙或代理服务器环境中使用RMI。分布式垃圾收集部分会讨论如何处理远程对象的生命周期管理，确保资源的有效释放。JNDI（Java命名和目录接口）和CORBA（公共对象请求代理架构）的介绍则可能涉及更广泛的分布式系统集成。 "关于作者"和"读者评价"部分提供了作者的专业背景和读者对书本的反馈，而"索引"和"目录"则方便读者快速定位感兴趣的主题。此外，"错误"和"联系方式"章节为读者提供了报告问题和获取支持的途径，"致谢"部分则表达了作者对参与图书制作人员的感谢。 "RMI JAVA SERVER STUN"是一本全面且深入的Java RMI技术指南，适合希望掌握RMI技术并将其应用于实际项目的开发者阅读。书中丰富的实例和实用策略将帮助读者理解并掌握分布式Java应用程序的设计和开发。

marked at any given time.

1.1.1.3 Resource management

Because streams are often associated with external devices such as files or network connections,

using a stream often requires the operating system to allocate resources beyond memory. For

example, most operating systems limit the number of files or network connections that a program

can have open at the same time. The resource management methods of the InputStream class

involve communication with native code to manage operating system-level resources.

The only resource management method defined for InputStream is close( ). When you're

done with a stream, you should always explicitly call close( ). This will free the associated

system resources (e.g., the associated file descriptor for files).

At first glance, this seems a little strange. After all, one of the big advantages of Java is that it has

garbage collection built into the language specification. Why not just have the object free the

operating-system resources when the object is garbage collected?

The reason is that garbage collection is unreliable. The Java language specification does not

explicitly guarantee that an object that is no longer referenced will be garbage collected (or even

that the garbage collector will ever run). In practice, you can safely assume that, if your program

runs short on memory, some objects will be garbage collected, and some memory will be

reclaimed. But this assumption isn't enough for effective management of scarce operating-system

resources such as file descriptors. In particular, there are three main problems:

• You have no control over how much time will elapse between when an object is eligible to

be garbage collected and when it is actually garbage collected.

• You have very little control over which objects get garbage collected.

[2]

You can use SoftReference (defined in java.lang.ref) to get a minimal level of control over

the order in which objects are garbage collected.

• There isn't necessarily a relationship between the number of file handles still available

and the amount of memory available. You may run out of file handles long before you run

out of memory. In which case, the garbage collector may never become active.

Put succinctly, the garbage collector is an unreliable way to manage anything other than memory

allocation. Whenever your program is using scarce operating-system resources, you should

explicitly release them. This is especially true for streams; a program should always close

streams when it's finished using them.

1.1.2 IOException

All of the methods defined for InputStream can throw an IOException. IOException is a

checked exception. This means that stream manipulation code always occurs inside a

try/catch block, as in the following code fragment:

try{

while( -1 != (nextByte = bufferedStream.read( ))) {

char nextChar = (char) nextByte;

...

}

catch (IOException e) {

...

}

The idea behind IOException is this: streams are mostly used to exchanging data with devices

that are outside the JVM. If something goes wrong with the device, the device needs a universal

way to indicate an error to the client code.

Consider, for example, a printer that refuses to print a document because it is out of paper. The

printer needs to signal an exception, and the exception should be relayed to the user; the

program making the print request has no way of refilling the paper tray without human

intervention. Moreover, this exception should be relayed to the user immediately.

Most stream exceptions are similar to this example. That is, they often require some sort of user

action (or at least user notification), and are often best handled immediately. Therefore, the

designers of the streams library decided to make IOException a checked exception, thereby

forcing programs to explicitly handle the possibility of failure.

Some foreshadowing: RMI follows a similar design

philosophy. Remote methods must be declared to throw

RemoteException (and client code must catch

RemoteException). RemoteException means "something

has gone wrong, somewhere outside the JVM."

1.1.3 OutputStream

OutputStream is an abstract class that represents a data sink. Once it is created, client code

can write information to it. OutputStream consists of the following methods:

public void close( ) throws IOException

public void flush( ) throws IOException

public void write(byte[] buffer) throws IOException

public void write(byte[] buffer, int startingOffset, int numberOfBytes)

throws

IOException

public void write(int value) throws IOException

The OutputStream class is a little simpler than InputStream; it doesn't support navigation.

After all, you probably don't want to go back and write information a second time. OutputStream

methods serve two purposes: writing data and resource management.

1.1.3.1 Writing data

OutputStream defines three basic methods for writing data:

public void write(byte[] buffer) throws IOException

public void write(byte[] buffer, int startingOffset, int numberOfBytes)

throws

IOException

public void write(int value) throws IOException

These methods are analogous to the read( ) methods defined for InputStream. Just as there

was one basic method for reading a single byte of data, there is one basic method, write(int

value), for writing a single byte of data. The argument to this write( ) method should be an

integer between 0 and 255. If not, it is reduced to module 256 before being written.

Just as there were two array-based variants of read( ), there are two methods for writing arrays

of bytes. write(byte[] buffer) causes all the bytes in the array to be written out to the

stream. write(byte[] buffer, int startingOffset, int numberOfBytes) causes

numberOfBytes bytes to be written, starting with the value at buffer[startingOffset].

The fact that the argument to the basic write( ) method is

an integer is somewhat peculiar. Recall that read( )

returned an integer, rather than a byte, in order to allow

instances of InputStream to signal exceptional conditions.

write( ) takes an integer, rather than a byte, so that the

read and write method declarations are parallel. In other

words, if you've read a value in from a stream, and it's not -1,

you should be able to write it out to another stream without

casting it.

1.1.3.2 Resource management

OutputStream defines two resource management methods:

public void close( )

public void flush( )

close( ) serves exactly the same role for OutputStream as it did for InputStream™ itshould

be called when the client code is done using the stream and wishes to free up all the associated

operating-system resources.

The flush( ) method is necessary because output streams frequently use a buffer to store

data that is being written. This is especially true when data is being written to either a file or a

socket. Passing data to the operating system a single byte at a time can be expensive. A much

more practical strategy is to buffer the data at the JVM level and occasionally call flush( ) to

send the data en masse.

1.2 Viewing a File

To make this discussion more concrete, we will now discuss a simple application that allows the

user to display the contents of a file in a JTextArea. The application is called ViewFile and is

shown in Example 1-1. Note that the application's main( ) method is defined in the

com.ora.rmibook.chapter1.ViewFile class.

[3]

The resulting screenshot is shown in Figure

1-1.

[3]

This example uses classes from the Java Swing libraries. If you would like more information on Swing,

see Java Swing (O'Reilly) or Java Foundation Classes in a Nutshell (O'Reilly).

Figure 1-1. The ViewFile application

catch (java.io.IOException ioException)

{

_fileViewingArea.setText("\n

Error occured while reading file");

}

The important part of the code is the View button's action listener and the

copyStreamToViewingArea( ) method. copyStreamToViewingArea( ) takes an

instance of InputStream and copies the contents of the stream to the central JTextArea.

What happens when a user clicks on the View button? Assuming all goes well, and that no

exceptions are thrown, the following three lines of code from the buttons's action listener are

executed:

FileInputStream fileInputStream = _fileTextField.getFileInputStream( );

copyStreamToViewingArea(fileInputStream);

fileInputStream.close( );

The first line is a call to the getFileInputStream( ) method on _fileTextField. That is,

the program reads the name of the file from a text field and tries to open a FileInputStream.

FileInputStream is defined in the java.io* package. It is a subclass of InputStream used

to read the contents of a file.

Once this stream is opened, copyStreamToViewingArea( ) is called. copyStream-

ToViewingArea( ) takes the input stream, wraps it in a buffer, and then reads it one byte at a

time. There are two things to note here:

• We explicitly check that nextByte is not equal to -1 (e.g., that we're not at the end of the

file). If we don't do this, the loop will never terminate, and we will we will continue to

append (char) -1 to the end of our text until the program crashes or throws an

exception.

• We use BufferedInputStream instead of using FileInputStream directly.

Internally, a BufferedInputStream maintains a buffer so it can read and store many

values at one time. Maintaining this buffer allows instances of Buffered-InputStream

to optimize expensive read operations. In particular, rather than reading each byte

individually, bufferedStream converts individual calls to its read( ) method into a

single call to FileInputStream's read(byte[] buffer) method. Note that buffering

also provides another benefit. BufferedInputStream supports stream navigation

through the use of marking.

Of course, the operating system is probably already buffering

file reads and writes. But, as we noted above, even the act of

passing data to the operating system (which uses native

methods) is expensive and ought to be buffered.

1.3 Layering Streams

The use of BufferedInputStream illustrates a central idea in the design of the streams library:

streams can be wrapped in other streams to provide incremental functionality. That is, there are

really two types of streams:

Primitive streams

剩余466页未读，继续阅读

haojaky

粉丝: 0
资源: 2

Java RMI：构建分布式应用实战指南

java_rmi.rar_RMI java_java.rmi

java rmi java rmi

java-rmi-server.rar_Java RMI_rmi _服务器

Rmi.rar_Java RMI_RMI java_java RMI 线程_rmi

RMI.zip_Java RMI_RMI java_rmi

JAVA RMI.rar_Java RMI_ME_RMI java_rmi

java_in_rmi.rar_Java RMI_RMI java_rmi _精通rmi

Java RMI的Server和Client工程实例

Java RMI的应用.rar_Java RMI_Performance RMI_RMI java_rmi _成绩

RMI规范说明.rar_Java RMI_RMI java_rmi

最新资源