从分布式系统的角度看REST

你知你每天在打的電話的計費系統是用什麼的嗎?
請問EJB 的底層是什麼? 它用什麼protocol?

另外, CORBA 和EJB 是不對level 的東西, 不要拿來比較.
corba 是架構的名字, 和J2EE 一樣.
EJB 要比的是CCM.
所以我認為你的<还算略微有些了解> 是真的太<略微>了.

請你回去好好的看一下Corba 不用在這跟我爭論, 你連EJB, CCM
CORBA, J2EE 這些名詞都未搞清楚, 更別說它們的底層是什麼一回事了.
什麼樣的系統做什麼事, 本來就不會都需要的.
我從沒說過每個enterprise 都需要它, 別亂給我給加話.
事實上就是, 你沒有碰過需要distributed 的系統, 如此而已.
舉個簡單的, 人們每天在用的銀行服務, 後端CORE BANKING大多數都是主機, 而主機又主要是CICS.
海關每天進出的貨物, 很多還在用TUXEDO.
真的有在用J2EE 來做Distrbuted 的還真的不是哪麼critical.

soap 是RPC 的一種,REST 也是.

另外"目前REST本身的功能还很少" 这个是什么含义 不太明了。

3.6.3 分布式对象（Distributed Objects，DO）
分布式对象风格将系统组织为结对进行交互的组件的集合。一个对象是一个实体，这个实体封装了一些私有的状态信息或数据、操作数据的一组相关的操作或过程、以及一个可能存在的控制线程，这种封装使得它们能够被整体地看作单个的单元[31]。通常，一个对象的状态对于所有其他对象而言，是完全隐藏和受到保护的。检查或修改对象状态的唯一方法是对该对象的一个公共的、可访问的操作发起请求或调用。这样就为每个对象创建了一个良好定义的接口，在对象的操作实现和它的状态信息保持私有的同时，公开操作对象的规格，这样做改善了可进化性。
一个操作可以调用可能位于其他对象之上的操作。这些操作也同样可以调用其他对象之上的操作，以此类推。一个相关联的调用链被称作一个动作（action）[31]。状态分布于对象之间，这对使状态尽可能保持最新而言是有利的，但是不利之处是难以获得系统活动的总的视图（缺乏可见性）。
一个对象为了与另一个对象交互，它必须知道另一个对象的标识。当一个对象的标识改变时，它必须对所有显式调用它的其他对象做修改[53]。这就必需要有一些控制器对象来负责维护系统的状态，以完成应用的需求。分布式对象系统的核心问题包括：对象管理、对象交互管理和资源管理[31]。
分布式对象系统被设计用来隔离正在被处理的数据，因此该风格通常不支持数据流。然而，当它和移动代理风格相结合时，可以为对象提供更好的移动性。

3.6.4 被代理的分布式对象（Brokered Distributed Objects，BDO）
为了降低对象标识的影响，现代分布式对象系统通常使用一种或更多种中间风格（intermediary styles）来辅助通信。这包括基于事件的集成风格和被代理的客户/服务器（brokered client/server）风格[28]。被代理的分布式对象风格引入了名称解析组件——其目的是将该组件接收到的客户端请求中一个通用的服务名称解析为一个能够满足该请求的对象的特定名称，并使用这个特定名称来答复客户端。尽管它改善了可重用性和可进化性，但额外的间接层要求额外的网络交互，这降低了效率和用户可觉察的性能。
被代理的分布式对象系统目前受到两个标准的控制：OMG[97]所开发的CORBA行业标准和ISO/IEC [66]所开发的开放分布式处理（ODP）的国际标准。
尽管分布式对象引起了非常多的兴趣，然而与大多数其他的基于网络的架构风格相比，这样一类架构风格能够提供的优点很少，它们最适合被使用在包括了对已封装服务（例如硬件设备）的远程调用的应用中，在这些应用中，效率和网络交互的频率并不是很值得关注。

这与类似CORBA[97]那样的中间件形成了对比。因为CORBA仅仅允许通过一个ORB来进行通信，它的转移协议IIOP对于通信的参与方使用什么内容来进行通信做了太多的假设。HTTP请求消息包括了标准化的应用语义（application semantics），而IIOP消息却没有包括。“Request”符号在IIOP中仅仅提供了方向性，这样ORB能够根据自身是否应该作出回应（即“LocateRequest”）或者是否应该通过一个对象来解释该请求，来对请求进行路由。具体的语义通过一个对象的key和操作的组合来表达，它是特定于对象的，而不是跨所有对象标准化的。
一个独立开发者能够生成与一个IIOP请求相同的比特，而不使用相同的ORB，但是比特本身是由CORBA的API和它的接口定义语言（IDL）定义的。生成这些比特需要一个由IDL编译器生成的UUID、一段对IDL操作签名做镜象的结构化二进制内容、遵循IDL规范的回应数据类型（definition of the reply data type(s)）的定义。其语义因此由网络接口（IIOP）来定义，而不是由对象的IDL规范（IDL spec）来定义。这是否是一件好事，取决于应用的性质——对于分布式对象这是必需的，对于Web这并不是什么好事。
为何这些差别是很重要的？因为它将一个网络中间组件能够成为有效的代理（effective agent）的系统，和一个网络中间组件最多只能成为路由器的系统区分了开来。
这种形式的区分也可以在将消息解释为一个单元（a unit）或者解释为一个流（a stream）中看到。HTTP允许接收者或发送者来自行决定。CORBA的IDL甚至（仍然）不允许使用流，即使当它确实得到了扩展以支持流之后，通信的双方仍然被绑定在相同的API上（译者注：即CORBA的基于库的API），而不是能够自由地使用最适合于它们的应用类型的东西。

6.5.2 HTTP并不是RPC
人们常常错误地将HTTP称作一种远程过程调用（RPC）[23]机制，仅仅是因为它包括了请求和响应。调用远程机器上的一个过程（procedure）的观念，是RPC与其他形式的基于网络的应用通信的区别所在。RPC的协议识别出过程并且传递给它固定的一组参数，然后等待在使用相同接口返回的一个消息中提供的回答。远程方法调用（RMI）也是类似的，除了过程被标识为一个｛对象，方法｝的组合，而不是一个简单的服务过程（service procedure）。被代理的RMI添加了名称服务的间接层和少量其他的技巧（trick），但是接口基本上是相同的。
将HTTP和RPC区分开的并不是语法，甚至也不是使用一个流作为参数所获得的不同的特性，尽管它帮助解释了为何现有的RPC机制对于Web来说是不可用的。使得HTTP与RPC存在重大不同的是：请求是使用具有标准语义的通用的接口定向到资源的，这些语义能够被中间组件和提供服务的来源机器进行解释。结果是使得一个应用支持分层的转换（layers of transformation）和间接层（indirection），并且独立于消息的来源，这对于一个Internet规模、多个组织、无法控制的可伸缩性的信息系统来说，是非常有用的。与之相比较，RPC的机制是根据语言的API（language API）来定义的，而不是根据基于网络的应用来定义的。

to Lordaeron：
对于服务器端来说，REST与RPC的建模方式还是有很大区别的。REST不是RPC，Fielding说的很清楚。你根本就没有读懂Fielding的含义，也完全不理解HTTP是用来做什么的。

to Lordaeron：
少跟我来你这一套下三烂的流氓手段，不要再以势压人了，尽管这种手段在你们公司内部也许屡试不爽。到底是我一直在跟你客气，还是你一直在跟我客气，拜托先搞搞清楚。我一直在试图心平气和地讨论我们真正关心的问题，你从来就不屑于以一种心平气和的态度说出你真正的观点，也不肯正面抨击我提出的观点，唯有以势压人而已。瞧不起人的似乎更应该是我，你也配来鄙视别人？在我看来你真的是很滑稽，一大早就碰到了一件乐事。