5 The Myth of "Quality of Service"

One could take the position that the way an object deals with latency, memory access, partial failure, and concurrency control is really an aspect of the implementation of that object, and is best described as part of the “quality of service” provided by that implementation. Different implementations of an interface may provide different levels of reliability, scalability, or performance. If one wants to build a more reliable system, one merely needs to choose more reliable implementations of the interfaces making up the system.
可以認(rèn)為，對(duì)象處理延遲技掏、內(nèi)存訪問铃将、故障和并發(fā)控制的方式實(shí)際上是該對(duì)象實(shí)現(xiàn)的一個(gè)方面，最好將其描述為該實(shí)現(xiàn)提供的“服務(wù)質(zhì)量”的一部分哑梳。接口的不同實(shí)現(xiàn)可能提供不同級(jí)別的可靠性劲阎、可伸縮性或性能。如果想要構(gòu)建一個(gè)更可靠的系統(tǒng)鸠真，只需要選擇構(gòu)成系統(tǒng)的更可靠實(shí)現(xiàn)的接口悯仙。

On the surface, this seems quite reasonable. If I want a more robust system, I go to my catalog of component vendors. I quiz them about their test methods. I see if they have ISO9000 certification, and I buy my components from the one I trust the most. The components all comply with the defined interfaces, so I can plug them right in; my system is robust and reliable, and I’m happy.
從表面上看，這似乎相當(dāng)合理吠卷。如果我想要一個(gè)更健壯的系統(tǒng)锡垄，我可以訪問我的組件供應(yīng)商目錄。我考察他們的測試方法祭隔』趿耄看他們是否有ISO9000認(rèn)證，然后從最信任的人那里購買組件疾渴。這些組件都有符合定義的接口千贯，所以我可以直接將它們插入系統(tǒng)并且保證系統(tǒng)的健壯可靠。

Let us imagine that I build an application that uses the (mythical) queue interface to enqueue work for some component. My application dutifully enqueues records that represent work to be done. Another application dutifully dequeues them and performs the work. After a while, I notice that my application crashes due to time-outs. I find this extremely annoying, but realize that it’s my fault. My application just isn’t robust enough. It gives up too easily on a time-out. So I change my application to retry the operation until it succeeds. Now I’m happy. I almost never see a time-out. Unfortunately, I now have another problem. Some of the requests seem to get processed two, three, four, or more times. How can this be? The component I bought which implements the queue has allegedly been rigorously tested. It shouldn’t be doing this. I’m angry. I call the vendor and yell at him. After much finger-pointing and research, the culprit is found. The problem turns out to be the way I’m using the queue. Because of my handling of partial failures (which in my naiveté, I had thought to be total), I have been enqueuing work requests multiple times.
讓我們假設(shè)我構(gòu)建了一個(gè)應(yīng)用程序搞坝，該應(yīng)用程序使用(虛構(gòu)的)隊(duì)列接口為某個(gè)組件排隊(duì)工作搔谴。我的應(yīng)用程序盡職盡責(zé)地對(duì)表示要完成的工作的記錄進(jìn)行入隊(duì)操作。另一個(gè)應(yīng)用程序盡職盡責(zé)地將它們出隊(duì)并執(zhí)行工作桩撮。過了一段時(shí)間敦第，我注意到我的應(yīng)用程序由于超時(shí)而崩潰。我覺得這非常煩人店量，但我知道這是我的錯(cuò)申尼。我的應(yīng)用程序不夠健壯。它太容易在超時(shí)時(shí)放棄垫桂。因此师幕，我更改應(yīng)用程序以重試操作，直到操作成功∥芴玻現(xiàn)在我很高興霹粥。我?guī)缀鯊奈匆娺^超時(shí)。不幸的是疼鸟，我現(xiàn)在有另一個(gè)問題后控。有些請(qǐng)求似乎被處理了2次、3次空镜、4次或更多次咪啡。怎么會(huì)這樣呢?據(jù)稱，我購買的實(shí)現(xiàn)隊(duì)列的組件經(jīng)過了嚴(yán)格的測試蛉幸。它不應(yīng)該這樣做。我很生氣砂蔽。我給供貨商打電話，沖他大喊大叫署惯。經(jīng)過多方指責(zé)和研究左驾，終于找到了罪魁禍?zhǔn)住栴}出在我使用隊(duì)列的方式上极谊。由于我對(duì)部分故障的處理（我原本認(rèn)為是全局故障）诡右，我已多次將工作請(qǐng)求排入隊(duì)列。

Well, I yell at the vendor that it is still their fault. Their queue should be detecting the duplicate entry and removing it. I’m not going to continue using this software unless this is fixed. But, since the entities being enqueued are just values, there is no way to do duplicate elimination. The only way to fix this is to change the protocol to add request IDs. But since this is a standardized interface, there is no way to do this.
好吧轻猖，我仍然認(rèn)為還是他們的錯(cuò)帆吻。他們的隊(duì)列應(yīng)該檢測重復(fù)條目并刪除它。除非這個(gè)問題得到解決咙边，否則我不會(huì)繼續(xù)使用這個(gè)軟件桅锄。但是，由于排隊(duì)的實(shí)體只是值样眠，所以沒有辦法進(jìn)行重復(fù)消除。解決這個(gè)問題的唯一方法是更改協(xié)議來添加請(qǐng)求id翠肘。但是檐束，由于這是一個(gè)標(biāo)準(zhǔn)化的接口，所以無法做到這一點(diǎn)束倍。

The moral of this tale is that robustness is not simply a function of the implementations of the interfaces that make up the system. While robustness of the individual components has some effect on the robustness of the overall systems, it is not the sole factor determining system robustness. Many aspects of robustness can be reflected only at the protocol/interface level.
這個(gè)故事的寓意是被丧，健壯性不僅僅是構(gòu)成系統(tǒng)的接口實(shí)現(xiàn)的功能。雖然單個(gè)組件的魯棒性對(duì)整個(gè)系統(tǒng)的魯棒性有一定影響绪妹，但它并不是決定系統(tǒng)魯棒性的唯一因素甥桂。健壯性的許多方面只能在協(xié)議/接口級(jí)別反映出來。

Similar situations can be found throughout the standard set of interfaces. Suppose I want to reliably remove a name from a context. I would be tempted to write code that looks like:
類似的情況可以在標(biāo)準(zhǔn)接口集中找到邮旷。假設(shè)我想從上下文中可靠地刪除一個(gè)名稱黄选。我會(huì)寫這樣的代碼:

while (true) {
  try {
    context -> remove (name);
    break;
  }
  catch (NotFoundInContext) {
    break;
  }
  catch (NetworkServerFaliure) {
    continue;
  }
}

That is, I keep trying the operation until it succeeds (or until I crash). The problem is that my connection to the name server may have gone down, but another client’s may have stayed up. I may have, in fact, successfully removed the name but not discovered it because of a network disconnection. The other client then adds the same name, which I then remove. Unless the naming interface includes an operation to lock a naming context, there is no way that I can make this operation completely robust. Again, we see that robustness/reliability needs to be expressed at the interface level. In the design of any operation, the question has to be asked: what happens if the client chooses to repeat this operation with the exact same parameters as previously? What mechanisms are needed to ensure that they get the desired semantics? These are things that can be expressed only at the interface level. These are issues that can’t be answered by supplying a “more robust implementation” because the lack of robustness is inherent in the interface and not something that can be changed by altering the implementation.
也就是說，我一直嘗試操作婶肩，直到成功(或者崩潰)办陷。問題是，我與name服務(wù)器的連接可能已經(jīng)停止律歼，但是另一個(gè)客戶機(jī)的連接可能保持正常民镜。事實(shí)上，我可能已經(jīng)成功刪除了名稱险毁，但由于網(wǎng)絡(luò)斷開連接而沒有發(fā)現(xiàn)它制圈。然后另一個(gè)客戶機(jī)添加相同的名稱们童，然后我又刪除了該名稱。除非命名接口包含鎖定命名上下文的操作鲸鹦，否則無法使該操作完全健壯慧库。我們?cè)俅慰吹剑枰诮涌诩?jí)別表達(dá)健壯性/可靠性亥鬓。在任何操作的設(shè)計(jì)中完沪，都必須問這樣一個(gè)問題:如果客戶選擇使用與以前完全相同的參數(shù)重復(fù)此操作，將會(huì)發(fā)生什么?需要什么機(jī)制來確保它們獲得所需的語義?這些東西只能在接口級(jí)別上表示嵌戈。這些問題不能通過提供“更健壯的實(shí)現(xiàn)”來解決覆积，因?yàn)槿狈研允墙涌诠逃械模荒芡ㄟ^更改實(shí)現(xiàn)來更改熟呛。

Similar arguments can be made about performance. Suppose an interface describes an object which maintains sets of other objects. A defining property of sets is that there are no duplicates. Thus, the implementation of this object needs to do duplicate elimination. If the interfaces in the system do not provide a way of testing equality of reference, the objects in the set must be queried to determine equality. Thus, duplicate elimination can be done only by interacting with the objects in the set. It doesn’t matter how fast the objects in the set implement the equality operation. The overall performance of eliminating duplicates is going to be governed by the latency in communicating over the slowest communications link involved. There is no change in the set implementations that can overcome this. An interface design issue has put an upper bound on the performance of this operation.
關(guān)于性能也可以提出類似的論點(diǎn)宽档。假設(shè)一個(gè)接口描述一個(gè)對(duì)象，該對(duì)象維護(hù)其他對(duì)象的集合庵朝。集合的一個(gè)性質(zhì)是沒有重復(fù)吗冤。因此，該對(duì)象的實(shí)現(xiàn)需要將重復(fù)消除九府。如果系統(tǒng)中的接口未提供測試引用相等性的方法椎瘟，則必須查詢集合中的對(duì)象以確定相等性。因此侄旬，重復(fù)消除只能通過與集合中的對(duì)象交互來完成肺蔚。集合中的對(duì)象實(shí)現(xiàn)相等操作的速度有多快并不重要。消除重復(fù)對(duì)象的整體性能將由所涉及的最慢通信鏈路上的通信延遲來決定儡羔。集合實(shí)現(xiàn)中沒有能夠克服這一點(diǎn)的更改宣羊。一個(gè)接口設(shè)計(jì)問題為這個(gè)操作的性能設(shè)置了一個(gè)上限。

6 Lessons from NFS

We do not need to look far to see the consequences of ignoring the distinction between local and distributed computing at the interface level. NFS?, Sun’s distributed computing file system [14], [15] is an example of a non-distributed application programer interface (API) (open, read, write, close, etc.) re-implemented in a distributed way.
我們不需要深入研究汰蜘，就可以看到在接口級(jí)別上忽略本地計(jì)算和分布式計(jì)算之間的區(qū)別的后果仇冯。NFS?，Sun的分布式計(jì)算文件系統(tǒng)[14]族操，[15]是以分布式方式重新實(shí)現(xiàn)的非分布式應(yīng)用程序編程接口（API）（打開苛坚，讀取，寫入色难，關(guān)閉等）的示例炕婶。

Before NFS and other network file systems, an error status returned from one of these calls indicated something rare: a full disk, or a catastrophe such as a disk crash. Most failures simply crashed the application along with the file system. Further, these errors generally reflected a situation that was either catastrophic for the program receiving the error or one that the user running the program could do something about.
在NFS和其他網(wǎng)絡(luò)文件系統(tǒng)之前，從這些調(diào)用之一返回的錯(cuò)誤狀態(tài)指示一些罕見的情況：一個(gè)完整磁盤或?yàn)?zāi)難莱预，例如磁盤崩潰柠掂。大多數(shù)故障只是使應(yīng)用程序和文件系統(tǒng)崩潰。此外依沮，這些錯(cuò)誤通常反映了這樣一種情況涯贞，即對(duì)于接收到錯(cuò)誤的程序來說是災(zāi)難性的枪狂，或者運(yùn)行程序的用戶可以對(duì)此做些什么。

NFS opened the door to partial failure within a file system. It has essentially two modes for dealing with an inaccessible file server: soft mounting and hard mounting. But since the designers of NFS were unwilling (for easily understandable reasons) to change the interface to the file system to reflect the new, distributed nature of file access, neither option is particularly robust.
NFS為文件系統(tǒng)中的部分故障打開了大門宋渔。對(duì)于無法訪問的文件服務(wù)器州疾，它基本上有兩種模式:軟掛載和硬掛載。但是皇拣，由于NFS的設(shè)計(jì)者不愿意（出于容易理解的原因）更改文件系統(tǒng)的接口以反映文件訪問的新的分布式特性严蓖，所以這兩個(gè)選項(xiàng)都不是特別健壯的。

Soft mounts expose network or server failure to the client program. Read and write operations return a failure status much more often than in the single-system case, and programs written with no allowance for these failures can easily corrupt the files used by the program. In the early days of NFS, system administrators tried to tune various parameters (time-out length, number of retries) to avoid these problems. These efforts failed. Today, soft mounts are seldom used, and when they are used, their use is generally restricted to read-only file systems or special applications.
軟掛載將網(wǎng)絡(luò)或服務(wù)器故障暴露給客戶機(jī)程序氧急。讀和寫操作返回故障狀態(tài)的情況比在單系統(tǒng)情況下要頻繁得多颗胡，而且在不考慮這些故障的情況下編寫的程序很容易損壞程序使用的文件。在NFS的早期吩坝，系統(tǒng)管理員試圖優(yōu)化各種參數(shù)(超時(shí)長度毒姨、重試次數(shù))以避免這些問題。這些努力都失敗了钉寝。今天弧呐，很少使用軟掛載，當(dāng)使用它們時(shí)嵌纲，通常僅限于只讀文件系統(tǒng)或特殊應(yīng)用程序俘枫。

Hard mounts mean that the application hangs until the server comes back up. This generally prevents a client program from seeing partial failure, but it leads to a malady familiar to users of workstation networks: one server crashes, and many workstations—even those apparently having nothing to do with that server—freeze. Figuring out the chain of causality is very difficult, and even when the cause of the failure can be determined, the individual user can rarely do anything about it but wait. This kind of brittleness can be reduced only with strong policies and network administration aimed at reducing interdependencies. Nonetheless, hard mounts are now almost universal.
硬掛載意味著應(yīng)用程序?qū)炱穑钡椒?wù)器重新啟動(dòng)逮走。這通仇剑可以防止客戶機(jī)程序出現(xiàn)部分故障，但它會(huì)導(dǎo)致工作站網(wǎng)絡(luò)用戶熟悉的一種弊端:一臺(tái)服務(wù)器崩潰言沐，許多工作站——甚至那些顯然與服務(wù)器無關(guān)的工作站——也會(huì)凍結(jié)。找出因果關(guān)系鏈?zhǔn)欠浅＠щy的酣栈，即使可以確定故障的原因险胰，單個(gè)用戶也很少能夠?qū)Υ俗鋈魏问虑椋荒艿却篌荨Ｖ挥型ㄟ^強(qiáng)有力的策略和旨在減少相互依賴的網(wǎng)絡(luò)管理起便，才能減少這種脆弱性。盡管如此窖维，硬掛載現(xiàn)在幾乎是通用的榆综。

Note that because the NFS protocol is stateless, it assumes clients contain no state of interest with respect to the protocol; in other words, the server doesn’t care what happens to the client. NFS is also a “pure” client-server protocol, which means that failure can be limited to three parties: the client, the server, or the network. This combination of features means that failure modes are simpler than in the more general case of peer-to-peer distributed object-oriented applications where no such limitation on shared state can be made and where servers are themselves clients of other servers. Such peer-to-peer distributed applications can and will fail in far more intricate ways than are currently possible with NFS.
注意，因?yàn)镹FS協(xié)議是無狀態(tài)的铸史，所以它假定客戶機(jī)不包含與協(xié)議相關(guān)的任何狀態(tài);換句話說鼻疮，服務(wù)器并不關(guān)心客戶機(jī)發(fā)生了什么。NFS也是一種“純”客戶機(jī)-服務(wù)器協(xié)議琳轿，這意味著故障可以限制在三個(gè)方面:客戶機(jī)判沟、服務(wù)器或網(wǎng)絡(luò)耿芹。這種特性的組合意味著故障模式比對(duì)等分布式面向?qū)ο髴?yīng)用程序更簡單，在這種應(yīng)用程序中挪哄，對(duì)共享狀態(tài)沒有這樣的限制吧秕，而且服務(wù)器本身就是其他服務(wù)器的客戶端。這種對(duì)等分布式應(yīng)用程序可以而且將以比NFS當(dāng)前更復(fù)雜的方式失敗迹炼。

The limitations on the reliability and robustness of NFS have nothing to do with the implementation of the parts of that system. There is no “quality of service” that can be improved to eliminate the need for hard mounting NFS volumes. The problem can be traced to the interface upon which NFS is built, an interface that was designed for non-distributed computing where partial failure was not possible. The reliability of NFS cannot be changed without a change to that interface, a change that will reflect the distributed nature of the application.
NFS對(duì)可靠性和健壯性的限制與該系統(tǒng)各個(gè)部分的實(shí)現(xiàn)無關(guān)砸彬。沒有可以改進(jìn)的“服務(wù)質(zhì)量”來消除對(duì)硬掛載NFS卷的需求。問題可以追溯到構(gòu)建NFS的接口斯入，這個(gè)接口是為不可能出現(xiàn)部分故障的非分布式計(jì)算設(shè)計(jì)的砂碉。NFS的可靠性不能在不更改該接口的情況下更改，這種更改將反映應(yīng)用程序的分布式特性咱扣。

This is not to say that NFS has not been successful. In fact, NFS is arguably the most successful distributed application that has been produced. But the limitations on the robustness have set a limitation on the scalability of NFS. Because of the intrinsic unreliability of the NFS protocol, use of NFS is limited to fairly small numbers of machines, geographically co-located and centrally administered. The way NFS has dealt with partial failure has been to informally require a centralized resource manager (a system administrator) who can detect system failure, initiate resource reclamation and insure system consistency. But by introducing this central resource manager, one could argue that NFS is no longer a genuinely distributed application.
這并不是說NFS沒有成功绽淘。事實(shí)上，NFS可以說是已經(jīng)產(chǎn)生的最成功的分布式應(yīng)用程序闹伪。但是對(duì)健壯性的限制限制了NFS的可伸縮性沪铭。由于NFS協(xié)議本身的不可靠性，NFS的使用僅限于數(shù)量相當(dāng)少的機(jī)器偏瓤，這些機(jī)器位于地理上的同一位置杀怠，并且是集中管理的。NFS處理部分故障的方式非正式地需要一個(gè)集中式資源管理器(系統(tǒng)管理員)厅克，他可以檢測系統(tǒng)故障赔退、啟動(dòng)資源回收并確保系統(tǒng)一致性。但是通過引入這個(gè)中央資源管理器证舟，人們可能會(huì)認(rèn)為NFS不再是一個(gè)真正的分布式應(yīng)用程序硕旗。

7 Taking the Difference Seriously

Differences in latency, memory access, partial failure, and concurrency make merging of the computational models of local and distributed computing both unwise to attempt and unable to succeed. Merging the models by making local computing follow the model of distributed computing would require major changes in implementation languages (or in how those languages are used) and make local computing far more complex than is otherwise necessary. Merging the models by attempting to make distributed computing follow the model of local computing requires ignoring the different failure modes and basic indeterminacy inherent in distributed computing, leading to systems that are unreliable and incapable of scaling beyond small groups of machines that are geographically co-located and centrally administered.
延遲、內(nèi)存訪問女责、部分故障和并發(fā)性方面的差異使得合并本地和分布式計(jì)算的計(jì)算模型既不明智漆枚，也無法成功。通過使本地計(jì)算遵循分布式計(jì)算模型來合并模型抵知，將需要對(duì)實(shí)現(xiàn)語言(或如何使用這些語言)進(jìn)行重大更改墙基，并使本地計(jì)算比其他需要復(fù)雜得多。通過試圖使分布式計(jì)算遵循本地計(jì)算的模型來合并模型刷喜，需要忽略分布式計(jì)算中固有的不同故障模式和基本不確定性残制，從而導(dǎo)致系統(tǒng)不可靠，并且無法擴(kuò)展到地理位置和集中管理的小型機(jī)器組之外掖疮。

A better approach is to accept that there are irreconcilable differences between local and distributed computing, and to be conscious of those differences at all stages of the design and implementation of distributed applications. Rather than trying to merge local and remote objects, engineers need to be constantly reminded of the differences between the two, and know when it is appropriate to use each kind of object.
更好的方法是接受本地計(jì)算和分布式計(jì)算之間存在不可調(diào)和的差異初茶，并在分布式應(yīng)用程序的設(shè)計(jì)和實(shí)現(xiàn)的所有階段意識(shí)到這些差異。與其嘗試合并本地對(duì)象和遠(yuǎn)程對(duì)象浊闪，還不如不斷提醒工程師兩者之間的區(qū)別纺蛆，并知道什么時(shí)候適合使用每種對(duì)象吐葵。

Accepting the fundamental difference between local and remote objects does not mean that either sort of object will require its interface to be defined differently. An interface definition language such as IDL can still be used to specify the set of interfaces that define objects. However, an additional part of the definition of a class of objects will be the specification of whether those objects are meant to be used locally or remotely. This decision will need to consider what the anticipated message frequency is for the object, and whether clients of the object can accept the indeterminacy implied by remote access. The decision will be reflected in the interface to the object indirectly, in that the interface for objects that are meant to be accessed remotely will contain operations that allow reliability in the face of partial failure.
接受本地對(duì)象和遠(yuǎn)程對(duì)象之間的基本區(qū)別并不意味著這兩種對(duì)象都需要以不同的方式定義其接口。接口定義語言(如IDL)仍然可以用來指定定義對(duì)象的接口集桥氏。然而温峭，類對(duì)象定義的另一部分將是規(guī)范這些對(duì)象是用于本地還是遠(yuǎn)程。這個(gè)決定需要考慮對(duì)象預(yù)期的消息頻率是多少字支，以及對(duì)象的客戶端是否能夠接受遠(yuǎn)程訪問所隱含的不確定性凤藏。該決策將間接反映在對(duì)象的接口中，因?yàn)橛糜谶h(yuǎn)程訪問的對(duì)象的接口將包含允許在部分故障時(shí)保持可靠性的操作堕伪。

It is entirely possible that a given object will often need to be accessed by some objects in ways that cannot allow indeterminacy, and by other objects relatively rarely and in a way that does allow indeterminacy. Such cases should be split into two objects (which might share an implementation) with one having an interface that is best for local access and the other having an interface that is best for remote access.
完全有可能揖庄，一個(gè)給定的對(duì)象經(jīng)常需要被某些對(duì)象以不允許不確定性的方式訪問，而被其他對(duì)象很少需要以允許不確定性的方式訪問欠雌。這種情況應(yīng)該分為兩個(gè)對(duì)象(可能共享一個(gè)實(shí)現(xiàn))蹄梢，一個(gè)對(duì)象具有最適合本地訪問的接口，另一個(gè)對(duì)象具有最適合遠(yuǎn)程訪問的接口富俄。

A compiler for the interface definition language used to specify classes of objects will need to alter its output based on whether the class definition being compiled is for a class to be used locally or a class being used remotely. For interfaces meant for distributed objects, the code produced might be very much like that generated by RPC stub compilers today. Code for a local interface, however, could be much simpler, probably requiring little more than a class definition in the target language.
用于指定對(duì)象類的接口定義語言的編譯器需要根據(jù)正在編譯的類定義是用于本地使用的類還是用于遠(yuǎn)程使用的類來更改其輸出禁炒。對(duì)于面向分布式對(duì)象的接口，生成的代碼可能非常類似于今天RPC存根編譯器生成的代碼霍比。然而幕袱，本地接口的代碼可能要簡單得多，可能只需要目標(biāo)語言中的類定義悠瞬。

While writing code, engineers will have to know whether they are sending messages to local or remote objects, and access those objects differently. While this might seem to add to the programming difficulty, it will in fact aid the programmer by providing a framework under which he or she can learn what to expect from the different kinds of calls. To program completely in the local environment, according to this model, will not require any changes from the programmer’s point of view. The discipline of defining classes of objects using an interface definition language will insure the desired separation of interface from implementation, but the actual process of implementing an interface will be no different than what is done today in an object-oriented language.
在編寫代碼時(shí)们豌，工程師必須知道是向本地對(duì)象還是遠(yuǎn)程對(duì)象發(fā)送消息，并以不同的方式訪問這些對(duì)象浅妆。雖然這似乎增加了編程的難度望迎，但它實(shí)際上是通過提供一個(gè)框架來幫助程序員，在這個(gè)框架下凌外，可以知道從不同類型的調(diào)用中可以獲得什么辩尊。要完全在本地環(huán)境下編程，根據(jù)這個(gè)模型趴乡，從程序員的角度來說不需要做任何更改对省。使用接口定義語言定義對(duì)象類的規(guī)程將確保接口與實(shí)現(xiàn)之間所需的分離蝗拿，但是實(shí)現(xiàn)接口的實(shí)際過程與今天在面向?qū)ο笳Z言中所做的沒有什么不同晾捏。

Programming a distributed application will require the use of different techniques than those used for non-distributed applications. Programming a distributed application will require thinking about the problem in a different way than before it was thought about when the solution was a non-distributed application. But that is only to be expected. Distributed objects are different from local objects, and keeping that difference visible will keep the programmer from forgetting the difference and making mistakes. Knowing that an object is outside of the local address space, and perhaps on a different machine, will remind the programmer that he or she needs to program in a way that reflects the kinds of failures, indeterminacy, and concurrency constraints inherent in the use of such objects. Making the difference visible will aid in making the difference part of the design of the system.
編寫分布式應(yīng)用程序需要使用與非分布式應(yīng)用程序不同的技術(shù)。編寫分布式應(yīng)用程序需要一個(gè)與以前編寫非分布式應(yīng)用程序不同的思考方式哀托。但這只是預(yù)期惦辛。分布式對(duì)象不同于本地對(duì)象，保持這種差異是可見的仓手，可以防止程序員忘記差異和犯錯(cuò)誤胖齐。知道一個(gè)對(duì)象在本地地址空間之外玻淑，并且可能在另一臺(tái)機(jī)器上，將提醒程序員需要以一種反映此類對(duì)象使用中固有的故障呀伙、不確定性和并發(fā)性約束的方式進(jìn)行編程补履。使差異可見將有助于使差異成為系統(tǒng)設(shè)計(jì)的一部分。

Accepting that local and distributed computing are different in an irreconcilable way will also allow an organization to allocate its research and engineering resources more wisely. Rather than using those resources in attempts to paper over the differences between the two kinds of computing, resources can be directed at improving the performance and reliability of each.
接受本地和分布式計(jì)算以不可調(diào)和的方式存在差異剿另，還將允許組織更明智地分配其研究和工程資源箫锤。與其使用這些資源試圖掩蓋這兩種計(jì)算之間的差異，不如將這些資源用于提高兩種計(jì)算的性能和可靠性雨女。

One consequence of the view espoused here is that it is a mistake to attempt to construct a system that is “objects all the way down” if one understands the goal as a distributed system constructed of the same kind of objects all the way down. There will be a line where the object model changes; on one side of the line will be distributed objects, and on the other side of the line there will (perhaps) be local objects. On either side of the line, entities on the other side of the line will be opaque; thus one distributed object will not know (or care) if the implementation of another distributed object with which it communicates is made up of objects or is implemented in some other way. Objects on different sides of the line will differ in kind and not just in degree; in particular, the objects will differ in the kinds of failure modes with which they must deal.
這里支持的觀點(diǎn)的一個(gè)結(jié)果是谚攒，如果一個(gè)人把目標(biāo)理解為一個(gè)由相同類型的對(duì)象構(gòu)造的分布式系統(tǒng)，那么試圖構(gòu)造一個(gè)“objects all the way down”是錯(cuò)誤的氛堕。會(huì)有一條線表示對(duì)象模型發(fā)生變化;在這條線的一邊是分布式對(duì)象馏臭，在這條線的另一邊(可能)是本地對(duì)象。在這條線的任意一邊讼稚，另一邊的實(shí)體都是不透明的;因此括儒，一個(gè)分布式對(duì)象不會(huì)知道(或關(guān)心)它與之通信的另一個(gè)分布式對(duì)象的實(shí)現(xiàn)是由對(duì)象組成的，還是以其他方式實(shí)現(xiàn)的乱灵。線兩邊的對(duì)象不僅在程度上不同塑崖，而且在類別上也不同;特別是，這些對(duì)象必須處理的故障模式的類型不同痛倚。

8 A Middle Ground

As noted in Section 2, the distinction between local and distributed objects as we are using the terms is not exhaustive. In particular, there is a third category of objects made up of those that are in different address spaces but are guaranteed to be on the same machine. These are the sorts of objects, for example, that appear to be the basis of systems such as Spring [16] or Clouds [4]. These objects have some of the characteristics of distributed objects, such as increased latency in comparison to local objects and the need for a different model of memory access. However, these objects also share characteristics of local objects, including sharing underlying resource management and failure modes that are more nearly deterministic.
如第2節(jié)所述规婆，我們所使用的術(shù)語本地和分布式對(duì)象之間的區(qū)別并非詳盡無遺。特別是蝉稳，還有第三類對(duì)象抒蚜，它們位于同一臺(tái)機(jī)器上的不同地址空間。例如耘戚，這些類型的對(duì)象似乎是Spring[16]或Clouds[4]等系統(tǒng)的基礎(chǔ)嗡髓。這些對(duì)象具有分布式對(duì)象的一些特征，例如與本地對(duì)象相比延遲增加以及需要不同的內(nèi)存訪問模型收津。但是饿这，這些對(duì)象也與本地對(duì)象有一些共同特征，包括共享底層資源管理和更具確定性的故障模式撞秋。

It is possible to make the programming model for such “l(fā)ocal-remote” objects more similar to the programming model for local objects than can be done for the general case of distributed objects. Even though the objects are in different address spaces, they are managed by a single resource manager. Because of this, partial failure and the indeterminacy that it brings can be avoided. The programming model for such objects will still differ from that used for objects in the same address space with respect to latency, but the added latency can be reduced to generally acceptable levels. The programming models will still necessarily differ on methods of memory access and concurrency, but these do not have as great an effect on the construction of interfaces as additional failure modes.
與分布式對(duì)象的一般情況相比长捧，可以使這種“本地-遠(yuǎn)程”對(duì)象的編程模型更類似于本地對(duì)象的編程模型。即使對(duì)象位于不同的地址空間吻贿，它們也由單個(gè)資源管理器管理串结。因此，局部故障及其帶來的不確定性是可以避免的。關(guān)于延遲肌割，此類對(duì)象的編程模型仍然與相同地址空間中的對(duì)象的編程模型不同卧蜓，但是增加的延遲可以減少到一般可接受的級(jí)別。雖然編程模型在內(nèi)存訪問和并發(fā)性上仍然存在差異把敞，但是這些對(duì)接口構(gòu)建的影響沒有故障模式大弥奸。

The other reason for treating this class of objects separately from either local objects or generally distributed objects is that a compiler for an interface definition language can be significantly optimized for such cases. Parameter and result passing can be done via shared memory if it is known that the objects communicating are on the same machine. At the very least, marshalling of parameters and the unmarshalling of results can be avoided.
將此類對(duì)象與本地對(duì)象或一般分布式對(duì)象分開處理的另一個(gè)原因是，接口定義語言的編譯器可以針對(duì)此類情況進(jìn)行顯著優(yōu)化奋早。如果知道通信的對(duì)象在同一臺(tái)機(jī)器上其爵，則可以通過共享內(nèi)存進(jìn)行參數(shù)和結(jié)果傳遞。至少伸蚯，可以避免對(duì)參數(shù)進(jìn)行編組和對(duì)結(jié)果進(jìn)行解組摩渺。

The class of locally distributed objects also forms a group that can lead to significant gains in software modularity. Applications made up of collections of such objects would have the advantage of forced and guaranteed separation between the interface to an object and the implementation of that object, and would allow the replacement of one implementation with another without affecting other parts of the system. Because of this, it might be advantageous to investigate the uses of such a system. However, this activity should not be confused with the unification of local objects with the kinds of distributed objects we have been discussing.
本地分布式對(duì)象類還形成了一個(gè)組，可以在軟件模塊化方面取得顯著的進(jìn)展剂邮。由這些對(duì)象集合組成的應(yīng)用程序?qū)⒕哂袕?qiáng)制和保證對(duì)象接口與該對(duì)象的實(shí)現(xiàn)之間的分離的優(yōu)點(diǎn)摇幻，并且將允許在不影響系統(tǒng)其他部分的情況下用一個(gè)實(shí)現(xiàn)替換另一個(gè)實(shí)現(xiàn)。因此挥萌，研究這種系統(tǒng)的用途可能是有利的绰姻。但是，這個(gè)活動(dòng)不應(yīng)該與本地對(duì)象與我們所討論的分布式對(duì)象的統(tǒng)一相混淆引瀑。