《Java RMI指南：打造高效分布式应用的宝典》

1星需积分: 4 120 浏览量更新于2024-08-02 收藏 1.99MB PDF 举报

《Java RMI超棒书》是一本由William Grosso所著的专业IT书籍，由O'Reilly出版社于2001年首次发行，拥有572页，书号1-56592-452-5。本书针对Java Remote Method Invocation (RMI)技术进行了深入讲解，为读者提供了丰富的实用技巧和策略，帮助他们更好地理解和应用RMI。该书的核心内容围绕RMI的设计与开发展开，包括基础概念、关键技术模块以及实际应用场景。第1章介绍了RMI的核心类，通过观看文件和层叠流处理来演示其基本操作。接着，作者详细探讨了网络定义、套接字通信和服务器套接字的使用，同时展示了如何定制套接字行为以及特殊用途的套接字。书中还涉及了安全通信，如使用SSL。在第2章中，作者构建了一个基于套接字的打印机服务器实例，展示如何利用网络功能创建分布式服务。这个例子涉及到网络打印机的概念、基本对象设计，以及客户端和服务端之间的交互。此外，书中的“Socket-Based Printer Server”章节涵盖了RMI在远程打印服务中的实践应用。除了基础设计和实现，本书还涉及到了RMI的高级主题，如序列化处理、线程管理、RMI注册表、动态类加载、HTTP隧道、分布式垃圾收集、JNDI（Java Naming and Directory Interface）和CORBA（Common Object Request Broker Architecture）等，这些都是RMI开发者必备的高级知识。作者还强调了代码示例在学习过程中的重要性，每章都包含详尽的示例代码，以便读者能够跟随并理解概念的实际运用。对于那些对RMI有疑问的读者，作者提供了联系方式，鼓励他们通过MSN进行交流和讨论。《Java RMI超棒书》是一部实用且全面的指南，无论你是初次接触RMI的新手还是希望提升技能的资深开发者，都能从中获得宝贵的知识和实践经验。书中详尽的解释和深入的剖析使得它成为RMI学习者不可多得的参考资料。

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

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页未读，继续阅读

kamychuakm

粉丝: 0
资源: 1

《Java RMI指南：打造高效分布式应用的宝典》

Java RMI技术：实现Java远程方法调用

Java RMI 实战指南

Java RMI实现方式总结与实例分享

java rmi java rmi

Rmi.rar_Java RMI_RMI java_java RMI 线程_rmi

JAVA RMI.rar_Java RMI_ME_RMI java_rmi

rmi.zip_Java RMI_java rmi网络_java源代码 RMI

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

rmi.rar_Java RMI_RMI source code_java RMI simple_rmi

JAVA RMI

最新资源