Abstract:

We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
在分布式系统中交互的对象与传统单地址空间的对象的处理方式完全不同。这些差异是必需的，因为分布式系统要求程序员了解延迟，具有不同的内存访问模型，并考虑并发和部分故障的问题。

We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
我们考虑了许多试图掩盖本地和远程对象之间区别的分布式系统，结果发现此类系统无法保证健壮性和可靠性的基本要求。过去，这些故障被构建的小型分布式系统掩盖了。然而，在不久的将来可以预见的企业级分布式系统中，这种掩蔽是不可能的。

We conclude by discussing what is required of both systems-level and application-level programmers and designers if one is to take distribution seriously.
最后，我们讨论了那些需要考虑分布式系统的系统级和应用级程序员和设计人员，他们需要些什么。

1 Introduction(引言)

Much of the current work in distributed, object-oriented systems is based on the assumption that objects form a single ontological class. This class consists of all entities that can be fully described by the specification of the set of interfaces supported by the object and the semantics of the operations in those interfaces. The class includes objects that share a single address space, objects that are in separate address spaces on the same machine, and objects that are in separate address spaces on different machines (with, perhaps, different architectures). On the view that all objects are essentially the same kind of entity, these differences in relative location are merely an aspect of the implementation of the object. Indeed, the location of an object may change over time, as an object migrates from one machine to another or the implementation of the object changes.
当前面向对象的分布式系统中的大部分工作都基于对象形成单个本体类的假设。该类由所有实体组成，这些实体可以通过对象支持的接口集的规范以及这些接口中的操作语义来完全描述。该类包括共享单个地址空间的对象，位于同一台机器上的不同地址空间中的对象，以及位于不同机器(或许不同架构)上的不同地址空间中的对象。在所有对象实质上是同一种实体的观点上，相对位置的这些差异仅仅是对象实现的一个方面。实际上，当对象从一台机器迁移到另一台机器或对象的实现发生变化时，对象的位置可能随时间发生变化。

It is the thesis of this note that this unified view of objects is mistaken. There are fundamental differences between the interactions of distributed objects and the interactions of non-distributed objects. Further, work in distributed object-oriented systems that is based on a model that ignores or denies these differences is doomed to failure, and could easily lead to an industry-wide rejection of the notion of distributed object-based systems.
本文认为这种统一的对象观点是错误的。分布式对象的交互与非分布式对象的交互之间存在着本质区别。此外，基于忽略或否认这些差异的模型的面向对象分布式系统的工作注定会失败，并且很容易导致全行业拒绝基于对象的分布式系统的概念。

1.1 Terminology(术语)

In what follows, we will talk about local and distributed computing. By local computing (local object invocation, etc.), we mean programs that are confined to a single address space. In contrast, we will use the term distributed computing (remote object invocation, etc.) to refer to programs that make calls to other address spaces, possibly on another machine. In the case of distributed computing, nothing is known about the recipient of the call (other than that it supports a particular interface). For example, the client of such a distributed object does not know the hardware architecture on which the recipient of the call is running, or the language in which the recipient was implemented.
下面，我们将讨论本地和分布式计算。本地计算（本地对象调用等），我们指的是局限于单个地址空间的程序。相反，我们将使用术语分布式计算（远程对象调用等）来指代调用其他地址空间（可能在另一台机器上）的程序。例如，这种分布式对象的客户端不知道正在运行呼叫的接收者的硬件体系结构，或者实现接收者的语言。

Given the above characterizations of “local” and “distributed” computing, the categories are not exhaustive. There is a middle ground, in which calls are made from one address space to another but in which some characteristics of the called object are known. An important class of this sort consists of calls from one address space to another on the same machine; we will discuss these later in the paper.
鉴于上述“本地”和“分布式”计算的特征，这些类别并非详尽无遗。存在一个中间地带，其中从一个地址空间到另一个地址空间进行调用，但是已知其中被调用对象的一些特征。其中一个重要的类包括在同一台机器上从一个地址空间到另一个地址空间的调用;我们稍后讨论这些内容。

2 The Vision of Unified Objects

There is an overall vision of distributed object-oriented computing in which, from the programmer’s point of view, there is no essential distinction between objects that share an address space and objects that are on two machines with different architectures located on different continents. While this view can most recently be seen in such works as the Object Management Group’s Common Object Request Broker Architecture (CORBA) [1], it has a history that includes such research systems as Arjuna [2], Emerald [3], and Clouds [4].
分布式面向对象计算有一个全局的视野，从程序员的角度来看，共享地址空间的对象与位于不同地方的不同体系结构的两台机器上的对象之间没有本质的区别。虽然这种观点最近可以在对象管理组的公共对象请求代理体系结构（CORBA）[1]等作品中看到，但它的历史包括Arjuna [2]，Emerald [3]和Clouds[4]等研究系统。

In such systems, an object, whether local or remote, is defined in terms of a set of interfaces declared in an interface definition language. The implementation of the object is independent of the interface and hidden from other objects. While the underlying mechanisms used to make a method call may differ depending on the location of the object, those mechanisms are hidden from the programmer who writes exactly the same code for either type of call, and the system takes care of delivery.
在这样的系统中，一个对象，无论是本地还是远程，都是用接口定义语言声明的一组接口来定义的。对象的实现独立于接口，并且对于其它对象是隐蔽的。虽然用于进行方法调用的底层机制可能根据对象的位置而有所不同，但这些机制对于程序员是隐藏的，程序员可以为任一类型的调用编写完全相同的代码，并且系统负责传递。

This vision can be seen as an extension of the goal of remote procedure call (RPC) systems to the object-oriented paradigm. RPC systems attempt to make cross-address space function calls look (to the client programmer) like local function calls. Extending this to the object-oriented programming paradigm allows papering over not just the marshalling of parameters and the unmarshalling of results (as is done in RPC systems) but also the locating and connecting to the target objects. Given the isolation of an object’s implementation from clients of the object, the use of objects for distributed computing seems natural. Whether a given object invocation is local or remote is a function of the implementation of the objects being used, and could possibly change from one method invocation to another on any given object.
这个观点可以看作是远程过程调用（RPC）系统的目标扩展到面向对象的范例。RPC系统尝试使交叉地址空间函数调用（对客户端程序员）看起来像本地函数调用。将其扩展到面向对象的编程范例，不仅可以打印参数的编组和结果的解组（如RPC系统中所做的那样），还可以定位和连接目标对象。鉴于对象的实现与对象的客户端隔离，使用对象进行分布式计算似乎很自然。 给定对象调用是本地还是远程是所使用对象的实现的函数，并且可能在任何给定对象上从一个方法调用更改为另一个方法调用。

[图片上传失败...(image-d6dbe5-1543413074363)]

RPC远程过程调用概念及实现
远程过程调用(RPC)详解

Implicit in this vision is that the system will be “objects all the way down”; that is, that all current invocations or calls for system services will be eventually converted into calls that might be to an object residing on some other machine. There is a single paradigm of object use and communication used no matter what the location of the object might be.
这个观点隐含着这个系统将是“对象总是向下传输”;也就是说，系统服务的所有当前调用最终都将转换为可能存在于其他机器上的对象的调用。无论对象的位置如何，都可以使用单一的对象使用和通信机制。

In actual practice, of course, a local member function call and a cross-continent object invocation are not the same thing. The vision is that developers write their applications so that the objects within the application are joined using the same programmatic glue as objects between applications, but it does not require that the two kinds of glue be implemented the same way. What is needed is a variety of implementation techniques, ranging from same-address-space implementations like Microsoft’s Object Linking and Embedding [5] to typical network RPC; different needs for speed, security, reliability, and object co-location can be met by using the right “glue” implementation.
当然，在实际操作中，本地成员函数调用和跨节点对象调用不是一回事。开发人员编写他们的应用程序，以便应用程序中的对象使用与应用程序之间的对象相同的编程粘合剂连接，但是不需要以相同的方式实现这两种粘合剂。需要的是各种实现技术，从微软的对象链接和嵌入[5]等同一地址空间实现到典型的网络 RPC ; 通过使用正确的“粘合”实现，可以满足对速度，安全性，可靠性和对象共址的不同需求。

Writing a distributed application in this model proceeds in three phases. The first phase is to write the application without worrying about where objects are located and how their communication is implemented. The developer will simply strive for the natural and correct interface between objects. The system will choose reasonable defaults for object location, and depending on how performance-critical the application is, it may be possible to alpha test it with no further work. Such an approach will enforce a desirable separation between the abstract architecture of the application and any needed performance tuning.
在此模型中编写分布式应用程序分为三个阶段。第一阶段是编写应用程序而不必担心对象的位置以及如何实现通信。开发人员只需做到对象之间自然和正确的接口。系统将为对象位置选择合理的默认值，并且根据应用程序的性能关键程度，可能不需要进一步的工作就可以对其进行alpha测试。这种方法将在应用程序的抽象体系结构和任何所需的性能调整之间实现理想的分离。

The second phase is to tune performance by “concretizing” object locations and communication methods. At this stage, it may be necessary to use as yet unavailable tools to allow analysis of the communication patterns between objects, but it is certainly conceivable that such tools could be produced. Also during the second phase, the right set of interfaces to export to various clients—such as other applications—can be chosen. There is obviously tremendous flexibility here for the application developer. This seems to be the sort of development scenario that is being advocated in systems like Fresco [6], which claim that the decision to make an object local or remote can be put off until after initial system implementation.
第二阶段是通过“具体化”对象位置和通信方法来优化性能。在这个阶段，可能有必要使用尚不可用的工具来分析对象之间的通信模式，但是当然可以生成这样的工具。同样在第二阶段，可以选择导出到各种客户端（例如其他应用程序）的正确接口集。对于应用程序开发人员来说，这里有很大的灵活性。这似乎是Fresco[6]等系统中提倡的那种开发场景，这些系统声称可以将对象本地或远程的决策推迟到初始系统实现之后。

The final phase is to test with “real bullets” (e.g., networks being partitioned, machines going down). Interfaces between carefully selected objects can be beefed up as necessary to deal with these sorts of partial failures introduced by distribution by adding replication, transactions, or whatever else is needed. The exact set of these services can be determined only by experience that will be gained during the development of the system and the first applications that will work on the system.
最后一个阶段是“真枪实弹”进行测试(例如，正在分区的网络、正在停机的机器)。精心挑选的对象之间的接口可以根据需要加强，以通过添加副本，事务机制或其他任何需要来处理分布式引入的这些部分故障。这些服务的确切集合只能通过在系统开发过程中获得的经验以及将在系统上运行的第一个应用程序来确定。

A central part of the vision is that if an application is built using objects all the way down, in a proper object-oriented fashion, the right “fault points” at which to insert process or machine boundaries will emerge naturally. But if you initially make the wrong choices, they are very easy to change.
该观点的一个核心部分是，如果应用程序一直通过面向对象的方式编程，那么以适当的面向对象的方式，正确的 “故障点” 、或者机器边界会随着开发过程自动显现。但如果你一开始做出错误的选择，他们很容易改变。

One conceptual justification for this vision is that whether a call is local or remote has no impact on the correctness of a program. If an object supports a particular interface, and the support of that interface is semantically correct, it makes no difference to the correctness of the program whether the operation is carried out within the same address space, on some other machine, or off-line by some other piece of equipment. Indeed, seeing location as a part of the implementation of an object and therefore as part of the state that an object hides from the outside world appears to be a natural extension of the object-oriented paradigm.
这一观点的一个概念上的理由是，无论是本地调用还是远程调用都不会影响程序的正确性。如果一个对象支持一个特定的接口，并且该接口的支持在语义上是正确的，那么无论该操作是在同一地址空间内，在某个其他机器上，还是由其他设备脱机执行，对程序的正确性都没有影响。实际上，将位置视为对象实现的一部分，因此将其视为对象对外部世界透明的一部分，这似乎是面向对象范式的自然延伸。

Such a system would enjoy many advantages. It would allow the task of software maintenance to be changed in a fundamental way. The granularity of change, and therefore of upgrade, could be changed from the level of the entire system (the current model) to the level of the individual object. As long as the interfaces between objects remain constant, the implementations of those objects can be altered at will. Remote services can be moved into an address space, and objects that share an address space can be split and moved to different machines, as local requirements and needs dictate. An object can be repaired and the repair installed without worry that the change will impact the other objects that make up the system. Indeed, this model appears to be the best way to get away from the “Big Wad of Software” model that currently is causing so much trouble.
这样的系统将享有许多优点。它将允许以基本方式改变软件维护任务。更改的粒度以及升级的粒度可以从整个系统（当前模型）的级别更改为单个对象的级别。只要对象之间的接口保持不变，就可以随意更改这些对象的实现。可以将远程服务移动到地址空间中，并且可以根据本地需求将共享地址空间的对象拆分并移动到不同的计算机。可以修复对象并安装修复，而无需担心更改将影响组成系统的其他对象。实际上，这种模式似乎是摆脱目前造成如此大麻烦的“大量软件”模型的最佳方式。

This vision is centered around the following principles that may, at first, appear plausible:
这一观点围绕着下列原则展开，这些原则乍一看似乎有理:

• there is a single natural object-oriented design for a given application, regardless of the context in which that application will be deployed;
• 不管部署环境如何，对给定的应用程序来说，都有一个给定的自然的面向对象设计方案；
• failure and performance issues are tied to the implementation of the components of an application, and consideration of these issues should be left out of an initial design; and
• 失败和性能相关的问题与组件的实现有关，这些在设计阶段可以不考虑；
• the interface of an object is independent of the context in which that object is used.
• 对象的接口与使用环境无关。

Unfortunately, all of these principles are false. In what follows, we will show why these principles are mistaken, and why it is important to recognize the fundamental differences between distributed computing and local computing.
不幸的是，所有这些原则都是错误的。在下文中，我们将说明为什么这些原则是错误的，以及为什么认识到分布式计算和本地计算之间的根本区别是很重要的。

3 Déjà Vu All Over Again（似曾相识）

For those of us either old enough to have experienced it or interested enough in the history of computing to have learned about it, the vision of unified objects is quite familiar. The desire to merge the programming and computational models of local and remote computing is not new.
对于我们这些年龄足够大，能够体验它的人，或者对计算历史足够感兴趣，能够了解它的人来说，统一对象的观点是非常熟悉的。将本地和远程计算的编程和计算模型合并的愿望并不新鲜。

Communications protocol development has tended to follow two paths. One path has emphasized integration with the current language model. The other path has emphasized solving the problems inherent in distributed computing. Both are necessary, and successful advances in distributed computing synthesize elements from both camps.
通信协议开发往往遵循两条路径。一条路径强调与当前语言模型的集成。另一条路径强调解决分布式计算中固有的问题。这两者都是必要的，而且分布式计算的成功进展综合了这两条路径的元素。

Historically, the language approach has been the less influential of the two camps. Every ten years (approximately), members of the language camp notice that the number of distributed applications is relatively small. They look at the programming interfaces and decide that the problem is that the programming model is not close enough to whatever programming model is currently in vogue (messages in the 1970s [7], [8], procedure calls in the 1980s [9], [10], [11], and objects in the 1990s [1], [2]). A furious bout of language and protocol design takes place and a new distributed computing paradigm is announced that is compliant with the latest programming model. After several years, the percentage of distributed applications is discovered not to have increased significantly, and the cycle begins anew.
从历史上看，语言方法在两个阵营中的影响力较小。每十年（大约），会有人发现分布式应用程序占的比例较少。他们查看编程接口并确定问题是编程模型与目前流行的任何编程模型不够接近(70年代的消息[7]，[8]，80年代的过程调用[9]，[10]，[11]，90年代的对象[1]，[2])。一场激烈的语言和协议设计的较量开始了，并宣布了一种符合最新编程模型的新的分布式计算范式。几年后，发现分布式应用程序的百分比没有显著增加，于是循环重新开始。

A possible explanation for this cycle is that each round is an evolutionary stage for both the local and the distributed programming paradigm. The repetition of the pattern is a result of neither model being sufficient to encompass both activities at any previous stage. However, (this explanation continues) each iteration has brought us closer to a unification of the local and distributed computing models. The current iteration, based on the object-oriented approach to both local and distributed programming, will be the one that produces a single computational model that will suffice for both.
这个循环的一个可能的解释是每一轮都是本地和分布式编程范式的进化阶段。模式的重复是由于这两种模式都不足以包含前一阶段的两种活动。但是，（这种解释仍在继续）每次迭代都使我们更接近于本地和分布式计算模型的统一。当前的迭代，基于面向对象的本地和分布式编程方法，将产生一个足以满足两者的单一计算模型。

A less optimistic explanation of the failure of each attempt at unification holds that any such attempt will fail for the simple reason that programming distributed applications is not the same as programming non-distributed applications. Just making the communications paradigm the same as the language paradigm is insufficient to make programming distributed programs easier, because communicating between the parts of a distributed application is not the difficult part of that application.
对于每次尝试统一模型失败的不太乐观的解释是，任何这样的尝试都会失败，原因很简单，编写分布式应用程序与编写非分布式应用程序不同。仅仅使通信范式与语言范式相同不足以使编程分布式程序更容易，因为在分布式应用程序的各部分之间进行通信并不是该应用程序的难点部分。

The hard problems in distributed computing are not the problems of how to get things on and off the wire. The hard problems in distributed computing concern dealing with partial failure and the lack of a central resource manager. The hard problems in distributed computing concern insuring adequate performance and dealing with problems of concurrency. The hard problems have to do with differences in memory access paradigms between local and distributed entities. People attempting to write distributed applications quickly discover that they are spending all of their efforts in these areas and not on the communications protocol programming interface.
在分布式计算中，难点不是如何获取东西。分布式计算中的难题涉及处理部分故障和缺乏中央资源管理器。分布式计算中的难题涉及确保足够的性能和处理并发问题。难题与本地实体和分布式实体之间内存访问机制的差异有关。试图编写分布式应用程序的人很快发现他们将所有的努力都投入到这些领域而不是通信协议编程接口上。

This is not to argue against pleasant programming interfaces. However, the law of diminishing returns comes into play rather quickly. Even with a perfect programming model of complete transparency between “fine-grained” language-level objects and “larger-grained” distributed objects, the number of distributed applications would not be noticeably larger if these other problems have not been addressed.
这并不是反对令人愉快的编程接口。然而，收益递减规律很快发挥作用。即使在“细粒度”语言级对象和“大粒度”分布式对象之间具有完全透明的完美编程模型，如果尚未解决这些其他问题，分布式应用程序的数量也不会明显增加。

All of this suggests that there is interesting and profitable work to be done in distributed computing, but it needs to be done at a much higher-level than that of “fine-grained” object integration. Providing developers with tools that help manage the complexity of handling the problems of distributed application development as opposed to the generic application development is an area that has been poorly addressed.
所有这些都表明，在分布式计算中需要完成有趣且有益的工作，但它需要在比“细粒度”对象集成更高的层次上完成。为开发人员提供有助于管理处理分布式应用程序开发问题的复杂性的工具，而不是通用应用程序开发，这是一个没有得到很好解决的领域。