外文翻译4理解远程方法调用

1、大连交通大学2012届本科生毕业设计 （论文） 外文翻译Understanding Java Remote Method Invocation (RMI) Java Remote Method Invocation (RMI) is the Java languages native mechanism for performing simple, powerful networking. RMI allows you to write distributed objects in Java, enabling objects to communicate in memory, across

2、Java Virtual Machines, and across physical devices.RMI is an alternative to using CORBA, the Object Management Groups distributed object architecture. How do the two compare? Its becoming tougher and tougher to draw the line. In fact, neither RMI nor CORBA is clearly a superior technology.Historical

3、ly, RMI has had several distinct advantages over CORBA. For example, RMI provides almost seamless, simple, transparent integration into the Java language itself. The overhead cost of developing an application that uses RMI is very low. RMIs strength lies in ease of use, and it has had great appeal t

4、o software developers who want to focus on the business logic of their code and leave the networking to RMI.By way of comparison, CORBA has historically been well suited for enterprise applications. CORBA provides a cross-platform, cross-language architecture. CORBA also provides a full suite of ent

5、erprise features, such as transactions, security, and persistence. The Internet Inter-Orb Protocol (IIOP), a robust protocol for distributed object communications, is used behind the scenes in CORBA.Note that both these trade-offs are historical. The differences between RMI and CORBA are beginning t

6、o disappear because both RMI and CORBA are learning from each other. Many of the services specific to CORBA are becoming available with RMI coupled with the Java 2 Platform, Enterprise Edition. Similarly,the ease of use of RMI is becoming available in CORBA. In essence, the two camps are converging.

7、 Well look at exactly how later in this appendix and also in Chapter 11.This appendix examines the benefits and drawbacks of RMI and details the architecture and logic behind it. We also compare RMI with CORBA, and we examine how RMI and EJB relate. After reading this, you will be able to write your

8、 own distributed object applications based on the RMI standard.Remote Method InvocationsA remote procedure call (RPC) is a procedural invocation from a process on one machine to a process on another machine. RPCs enable traditional procedures to reside on multiple machines, yet still remain in commu

9、nication. They are a simple way to perform cross-process or cross-machine networking.A remote method invocation in Java takes the RPC concept one step further and allows for distributed object communications. RMI allows you to invoke methods on objects remotely, not merely procedures. You can build

10、your networked code as full objects. This yields the benefits of an object-oriented programming, such as inheritance, encapsulation, and polymorphism.Remote method invocations are by no means simple. Below are just some of the issues that arise:Marshalling and unmarshalling. Remote method invocation

11、s (as well as RPCs) allow you to pass parameters, including Java primitives and Java ob-jects, over the network. But what if the target machine represents data differently than the way you represent data? For example, what happens if one machine uses a different binary standard to represent numbers?

12、 The problem becomes even more apparent when you start talking about objects. What happens if you send an object reference over the wire? That pointer is not usable on the other machine because that machines memory layout is completely different from yours. Marshalling and unmarshalling is the proce

13、ss of massaging parameters so that they are usable on the machine being invoked on remotely. It is the packaging and unpackaging of parameters so that they are usable in two heterogeneous environments. As we shall see, this is taken care of for you by Java and RMI.Parameter passing conventionsThere

14、are two major ways to pass parameters when calling a method: pass-by-value and pass-by-reference, as shown in Figure A.1. When you pass by value, you pass a copy of your data so that the target method is using a copy, rather than the original data. Any changes to the argument are reflected only in t

15、he copy, not the original. Pass-by-reference, on the other hand, does not make a copy. With pass-by-reference, any modifications to parameters made by the remote host affect the original data. The flexibility of both the pass-by-reference and pass-by-value models are advantageous to have, and RMI su

16、pports both. We°ll see how in the pages to come.Distributed garbage collectionThe Java language itself has built-in garbage collection of objects. Garbage collection allows users to create objects at will, and it leaves the destruction of objects to the underlying Java Virtual Machine. But in a

17、 distributed object system, things become more complicated. An object residing on a remote host might have a reference (called a remote reference) to a local object. Thus, the remote host has a reference that actually refers to an object across the network, rather than a local object. But how does g

18、arbage collection work then? After all, a JVMs garbage collector runs within that JVM and does not take into account object references from remote hosts. Because of this, a distributed garbage collector is needed to track remote hosts that reference local objects.Network or machine instabilityWith a

19、 single JVM application, a crash of the JVM brings the entire application down. But consider a distributed object application, which has many JVMs working together to solve a business problem. In this scenario, a crash of a single JVM should not cause the distributed object system to grind to a halt

20、. To enforce this, remote method invocations need a standardized way of handling a JVM crash, a machine crash, or network instability. When some code performs a remote invocation, the code should be informed of any problems encountered during the operation. RMI performs this for you, abstracting out

21、 any JVM, machine, or network problems from your code.Downloadable implementationsRemote method invocations allow you to pass whole Java objects as parameters to methods invoked over the network. This means, for example, that you can pass a java.lang.String over the network as a parameter to a metho

22、d. If you pass an entire Java object to a target machine, what youre really passing is that objects data to the target machine. In our String example, this could be the Strings character buffer. But objects also contain code, and that code might not be available on the target machine. For example, S

23、tring objects have a method called length()that returns the length of the String. This logic, as well as the other logic surrounding objects, is stored in .class files in Java. The target machine needs those class files so that it can construct the code portion of the objects you send as parameters

24、to methods over the network. RMI allows for these class files to be automatically downloaded behind the scenes, relieving you of this dogmatic chore. This also means RMI is a very dynamic system, allowing for different object implementations to come in over the wire.SecurityWe mentioned that RMI con

25、tains built-in dynamic class loading. This allows object implementations to arrive from remote, and possibly hostile, sources. Java applets are perfect examples because they are downloaded on the fly and could be malicious. A security mechanism needs be in place to restrict possibly hostile implemen

26、tations and grant system-level access only to authenticated implementations. RMI has such support.ActivationYoud like to be able to invoke methods on remote objects, even if they are not in memory yet. If you invoke a method on a remote object that is not in memory yet, RMI contains measures to auto

27、matically fault the object into memory so that it can service method calls. This is called remote object activation.As you can see, theres a lot involved in performing remote method invocations. RMI contains measures to handle many of these nasty networking issues for you. This reduces the total tim

28、e spent dealing with the distribution of your application, allowing you to focus on the core functionality.RMI is the Java languages native remote method invocation service. It ships with the Java 2 platform, and it is required for any 1.1-compatible Java Runtime Environment. It is built entirely in

29、 Java and is therefore highly cross-platform. This is a big win for RMI-you can write your networking code once and run it in any recent Java Runtime Environment. Contrast this with proprietary, platform dependent RPC libraries, and you can see some real value in RMI.RMI ArchitectureIn RMI, any obje

30、ct whose methods can be invoked from another Java VM is called a remote object. Remote objects are networked objects, which expose methods that can be invoked by remote clients. The physical locations of remote objects and the clients that invoke them are not important. For example, its possible for

31、 a client running in the same address space as a remote object to invoke a method on that object. Its also possible for a client across the Internet to do the same thing. To the remote object, both invocations appear to be the same.RMI and Interface versus ImplementationIn Chapter 1, we discussed on

32、e of object-oriented designs great programming practicesthe separation of the interface of code from its implementation.The interface defines the exposed information about an object, such as the names of its methods and what parameters those methods take. Its what the client works with. The interfac

33、e masks the implementation from the viewpoint of clients of the object, so clients deal only with the end result: the methods the object exposes.The implementation is the core programming logic that an object provides. It has some very specific algorithms, logic, and data. By separating interface fr

34、om implementation, you can vary an objects proprietary logic without changing any client code. For example, you can plug in a different algorithm that performs the same task more efficiently. RMI makes extensive use of this concept. All networking code you write is applied to interfaces, not impleme

35、ntations. In fact, you must use this paradigm in RMIyou do not have a choice. It is impossible to perform a remote invocation directly on an object implementation. You can operate solely on the interface to that objects class.To designate that your object can be invoked on remotely, your class must

36、implement the interface java.rmi.Remote. You must perform this by creating your own custom interface extending java.rmi.Remote. That interface should have within it a copy of each method your remote object exposes.Your remote object implementation (that is, the networked object) implements this inte

37、rface. Client code that wants to call methods on your remote object must operate on IMyRemoteInterface. An additional restriction of RMI is that each method must also throw a java.rmi.RemoteException. A java.rmi.RemoteException is thrown when there is a problem with the network, such as a machine cr

38、ashing or the network dying. Your remote objects can throw their own regular exceptions in addition to the required java.rmi.RemoteException.Stubs and SkeletonsOne of the benefits of RMI is an almost illusionary, transparent networking. You can invoke methods on remote objects just as you would invo

39、ke a method on any other Java object. In fact, RMI completely masks whether the object youre invoking on is local or remote. This is called local/remote transparency. But local/remote transparency is not as easy as it sounds. To mask the fact that Youre invoking on an object residing on a remote hos

40、t, RMI needs to somehow simulate a local object that you can invoke on. This local object is called a stub, and it is responsible for accepting method calls locally and delegating those method calls to their actual object implementations, which are possibly located across the network. This effective

41、ly makes every remote invocation appear to be a local invocation. You can think of a stub as a placeholder for an object that knows how to look over the network for the real object. Because you invoke on local stubs, all the nasty networking issues are hidden behind the scenes.Stubs are only half of

42、 the picture. Wed like the remote objects themselvesthe objects that are being invoked on from remote hoststo not worry about networking issues as well. Just as a client invokes on a stub that is local to that client, your remote object needs to accept calls from a skeleton that is local to that rem

43、ote object. Skeletons are responsible for receiving calls over the network (perhaps from a stub) and delegating that call to the remote object implementation. This is shown in Figure A.2. One of the more interesting responsibilities of stubs and skeletons is the marshalling and unmarshalling of para

44、meters. RMI relies on a technology called object serialization to assist with this, which well learn about a bit later.Bootstrapping and the RMI RegistryFor a client and a server to start talking, they need some way to connect. Acquiring this connection is known as bootstrapping. How does RMI accomp

45、lish bootstrapping?RMI provides an entity known as the RMI Registry for this purpose. When you want to make an object remotely accessible, you register it with the registry. You give the registry a name for the object during this registration. From then on, the Registry will route all incoming reque

46、sts for that name to your object. You can think of the RMI Registry as a giant hashtable that maps names to objects.The RMI Registry accomplishes this task by sitting at a well-known network port and listening for incoming connections. When a remote client wants to access an object registered with a

47、 particular registry, the client issues a request over the network to the registry. The Registry reads the request, looks up the name of the remote object requested, and returns the stub for that remote object to the client. This is shown in Figure A.3.You can have as many RMI registries as you want

48、 on a machine, but only one Registry per VM. And, of course, only one Registry can be bound to a specific port. There are thousands of ports for you to choose from, though, so thats no problem. If you dont specify a port, RMI uses port 1099 by default. Remember that both your client and server must

49、agree on which port the Registry sits at, or they will never find each other.There are two ways to start the RMI Registry. You can launch it as a stand-alone program by typing rmiregistry from a command prompt. You can also start a registry from inside your Java program by accessing the java.rmi.Reg

50、istry class.RMI URLsAn RMI URL is a Java String that is used to locate a remote object on another Java Virtual Machine. It looks very similar to other types of URLs, such as or ftp:/. RMI enforces the following conventions for URLs:1. The URL must begin with the text rmi:/.2. Next, you may specify t

51、he target machine where the Java Virtual Machine is locatedfor example, rmi:/ If you dont specify a target machine, RMI defaults to the local host.3.Finally, append the name of the remote object to which you wish to acquire a remote reference. For example, if your remote object is bound as the name

52、“myObject”, you can reference it from any machine in the world with the RMI URL rmi:/Looking Up a Remote ObjectSo far, our discussion has touched the following concepts:An RMI Registry is a remote object used by clients for bootstrapping, or initially connecting, to your remote objects. Remote objec

53、ts register themselves with the registry, which clients connect to at a well-known port.RMI URLs are used to identify the locations of objects over the network. How do clients use these two abstractions to actually connect to remote objects?理解远程方法调用远程方法调用(RMI)是Java语言用来执行简单、有力网络的与生俱来的机制。RMI允许你使用Java语

54、言来编写分布式的对象，使对象能够通过记忆体沟通，以及对方的Java虚拟机和物理设备。CORBA和RMI都是对象管理组的分散对象结构可选择的办法。如何比较这两种方法？现在两者变得越来越难划分界限了。事实上，显然RMI和CORBA都不是一种高级技术。从历史角度上讲，RMI要比CORBA多出几个很明显的优点。比如，RMI以无缝、简单以及透明的一体化方式添加进Java语言自身。使用RMI开发一个应用软件的总开支很低。RMI的优点在于不费力，它要求专注于代码商业逻辑的软件开发人员，把网络部分交给RMI.作为比较，CORBA曾经非常适合于企业应用。CORBA提供一种横跨平台的语言结构。CORBA也提供了一

55、套适合企业的特征，例如处理事务，安全和持续性。IIOP是一种用于分散对象联系的协议，在CORBA后使用。CORBA和RMI的不同开始变得消失了因为他们开始互相学习。许多专向于CORBA的服务可以用RMI联系Java 2 平台，企业编译。相同的是，在CORBA中RMI变得同样可行。其实是两个阵营聚合在了一起。我们将在过后的附录以及章中看到。这篇附录检验了RMI的优点和缺点，详述了它之后的结构和逻辑。我也比较了RMI和CORBA，我们还检验了RMI和EJB是如何关联的。读过这篇附录后，你将有能力书写自己的基于RMI标准的分散对象应用。1.1远程方法调用一个远程过程调用是一种两台机器间进程的程序上的

56、调用。RPC可以使处于多媒体机器上的传统的程序仍然可以保持联系。它们是执行跨进程或跨机器间网络的简单方法。在Java中一个RMI进一步使用了RPC的观念，允许其用于分散对象间的通信。RMI还允许你调用远程方法，不仅仅是程序。你可以构造你自己的网络代码作为完整的对象。这些收益得益于一种能够面对对象的设计，例如继承，封装-9-和多态。远程方法调用绝不简单，下面是出现的一些问题：1.1.1列集和解组远程方法调用（以及RPC）允许你通过网络传递参数，包括Java的源文件和Java对象。如果目标机器回馈的数据不同于你所想回馈的呢？举个例子，如果一台机器使用一种不同的二进制标准作为回馈的数字会发生什么？当

57、你开始讨论对象时问题变得更加明显。如果你通过电线发送一个对象的请求会发生什么？指示器在另一台机器上将变得不合用因为那台机器的记忆体完全不同于你的。列集和解组是数据调理参数的处理为了他们可用于被远程调用。参数的封装和未封装是为了他们可用于在两个不同中立的环境中。这将会让你通过Java和RMI来照看。1.1.2参数传递公约当调用一个方法时，有两种基本方法来传递参数：传实参和传形参可参看图。当你传实参时，你传递了一个你的数据的副本为了使目标方法可以使用这个副本胜于源数据。这个协议的任何改变都只在副本上表现出来，而不是在源数据上。传递形参时，在另一方面上，却不是制造一个副本。通过传递形参，任何修改参数

58、所作的远程主机将影响到原始数据。传递实参和形参是很有利的，而且RMI都支持他们。我们将会在下面的几页中看到如何操作。1.1.3分散垃圾的收集Java语言自身有内置的对象垃圾收集。垃圾收集的存在允许用户任意的创建对象，而且它把对象的破坏交给下面的Java虚拟机。但是在一个分散的对象系统中，事情变得更加复杂。一个居于远程主机上的对象可以有一个本机对象的参数。这样，远程主机有一个参数实际上指向一个胜于本地对象的跨网络对象。但是这时如何使垃圾收集系统运作？毕竟，内置的JVM垃圾收集器运行不是很重视远程主机对象参数。因为这个，一个分散式的垃圾收集器需要追踪指向本地对象的远程主机参数。1.1.4网络或机器的不稳定性通过单一的JVM应用，冲击使得整个JVM应用变得不可用。但是考虑到分-10-散对象应用会有很多JVM一起工作来解决问题。在这一关中，单一JVM的冲击并不是导致分散对象系统慢慢停下来的原因。为了加强这点，远程方法调用需要一种标准的方法来处理JVM的冲击，机器的冲击，或是网络的不稳定。当一些代码执行完一个远程调用后，当在操作的期间遇到任何问题，他们将会被告知。RMI将会为你执行这些操作，从代码中摘去出所有的JVM，机器或者网络的问题。1.1.5下载的实施远程方法调用允许你传递整个Java对象作为方法的参数在网络上被调用。举个例子，这意味着你可以通过网络传递java.lang.St