分布式计算概念一览

一、通信中间件

1、RPC

　　RPC（Remote Procedure Call Protocol）——远程过程调用协议，它将“本地过程调用”的概念运用到分布式应用程序中。它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。对于一个远程过程而言，也可以像普通过程那样被调用，差别仅在于：通过网络将调用路由到另一个应用程序，在过程执行后，在将结果返回给调用者。无论客户机和服务器是否位于同一系统，远程调用的语法和语义都不变。大多数RPC实现都基于同步式请求-应答协议，所谓同步，即在服务器回答一个请求后，客户机才解除阻塞。

有多种 RPC模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本，使得 ONC RPC 协议成为 IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。

2、分布式对象

分布式对象
一般而言，分布式对象由ORB（Object Request Broker，对象请求代理）支持，ORB管理与可能的远程对象的通信和数据交换。
ORB基于“互操作对象引用”概念，允许通过对象工厂和其他辅助对象，方便地远程创建、定位、调用和删除对象。如下图所示：

最常见的ORB实现是CORBA、COM/DCOM和Java，其中，COM/DCOM仅限于Microsoft平台，而CORBA则扩展到多个平台和编程语言。

CORBA:CORBA技术是最早出现的，1991年OMG颁布了COBRA 1.0标准，在当时来说做得非常漂亮；

COM/DCOM:再有就是Microsoft的COM系列，从最初的COM发展成现在的DCOM，形成了Microsoft一套分布式对象的计算平台；

JAVA:而Sun公司的Java平台，在其最早推出的时候，只提供了RMI远程的方法调用，在当时并不能被称为分布式对象计算，只是属于网络计算里的一种，接着推出的JavaBean，也还不足以和上述两大流派抗衡，而其目前的版本叫J2EE，推出了EJB，除了语言外还有组件的标准以及组件之间协同工作通讯的框架。于是，也就形成了目前的分布式对象的三大流派。  

---- 应该说，这三者之中，COBRA标准是做的最漂亮的。COBRA标准主要分为3个层次：对象请求代理、公共对象服务和公共设施。最底层是对象请求代理ORB，规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的“软总线”；在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务；最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。总之，CORBA的特点是大而全，互操作性和开放性非常好。目前CORBA的最新版本是2.3。CORBA 3.0也已基本完成，增加了有关Internet集成和QoS控制等内容。CORBA的缺点是庞大而复杂，并且技术和标准的更新相对较慢，COBRA规范从1.0升级到2.0所花的时间非常短，而再往上的版本的发布就相对十分缓慢了。  

---- 相比之下，Java标准的制订就快得多，Java是Sun公司自己定的，演变的很快。Java的优势是纯语言的，跨平台性非常好。Java分布对象技术通常指远程方法调用（RMI）和企业级JavaBean（EJB）。RMI提供了一个Java对象远程调用另一Java对象的方法的能力，与传统RPC类似，只能支持初级的分布对象互操作。Sun公司于是基于RMI，提出了EJB。基于Java服务器端组件模型，EJB框架提供了像远程访问、安全、交易、持久和生命期管理等多种支持分布对象计算的服务。目前，Java技术和CORBA技术有融合的趋势。  

---- COM技术是Microsoft独家做的，是在Windows 3.1中最初为支持复合文档而使用OLE技术上发展而来，经历了OLE 2/COM、ActiveX、DCOM和COM+等几个阶段，目前COM+把消息通讯模块MSMQ和解决关键业务的交易模块MTS都加进去了，是分布对象计算的一个比较完整的平台。Microsoft的COM平台效率比较高，同时它有一系列相应的开发工具支持，应用开发相对简单。但它有一个致命的弱点就是COM的跨平台性较差，如何实现与第三方厂商的互操作性始终是它的一大问题。从分布对象技术发展的角度来看，大多数人认为COM竞争不过COBRA。

3、MOM

　　消息中间件这里省

同步异步

同步和异步通信时两种不同的交互形式，都需要分布式系统一般技术的支持。
同步通信的特点是：立即响应通信伙伴。通信按照“请求/响应”模式进行，允许会话自由流动，常使用“忙碌”和“等待”。与用户交互的应用程序特别需要这种交互会话模式。同步通信模式要求客户端和服务器总处于可用和运行状态。
异步通信的要求宽松一些。通信伙伴双方基本上互相分离，不执行严格的“请求/响应”模式。一般而言，一方通过一些介体创建要传给接受者的信息，并且不要求立即得到响应。发送者可以存储上下文信息，在接收者回应时在检索上下文信息；不过，不一定非要等到响应。与同步通信的“请求/响应”机制不同，异步通信不要求服务器一直可用，故有利于创建高性能的消息传递系统。

一般而言，同步通信由RPC形式的通信基础结构实现，而异步机制有MOM实现。但完全可以在MOM的基础上实现同步通信，或构建RPC之上的MOM形式的交互。总之，如果需要立即得到响应，则RPC更适合些；如果要得到松耦合的异步通信，则MOM技术室理想之选。
现实世界的要求多种多样，为此，大多数企业都同时包含同步和异步通信。为此，应该使用多种不同的通信基础结构，如简单的FTP（File Transfer Protocol，文件传输协议）和PRC几MOM等高级中间件平台。另外，还有支持两种通信模式的通信基础结构：既支持异步通信也支持标准的同步RPC通信的传输RPC。

下面将介绍用RPC/ORB和MOM技术实现同步和异步通信的最常用方法。例子如下：
1、利用队列模拟同步服务
2、单向异步：激活-忘记RPC（fire-and-forget RPC）
3、回调和轮询服务

例1：使用关联ID将消息放入请求/应答元组，以模拟与大型机的同步交互。实际上，这降级使用了消息队列系统，只表现了低级传输功能，没有充分利用消息传输系统的高级功能。如下图：

、

例2：“激活并忘记RPC”假设RPC或ORB实现单向异步语义：客户端向服务器激活了请求，但不期望得到应答。为此，可以定义一个操作签名，使其不包含任何返回值；或使用中间件的特性，例如，CORBA IDL操作使用关键字oneway。如下图介绍了这种方法：

这种方法有两个重大隐患：
第一，客户端不能保证服务器接收到请求并做了适当处理，这严重影响了该方法的运用。
第二，大多数RPC/ORB使用诸如TCP的可靠通信协议，若通过TCP发送单向请求，那么，在完成服务器在TCP级别的交付前，客户端将一直阻塞。如果服务器正在处理大量请求，则可能不能处理TCP层所有传入的单向请求。也就是说，在服务器至少能从网络读取请求前，客户端一直阻塞。因此，最好不要用这种方法来实现大规模事件通知，而选择一个适当的MOM。

例3：“回调和轮询服务”，这是RPC形式应用程序中，分离客户端和服务器的最常用方式（不要求借用完备的MOM解决方案）。其基本思想与传统的回调一样，在面向对象的语言中，用对象引用实现：客户端将一个请求发送给服务器，服务器存储请求，并将控制返回给客户端（可能发送表示接收到请求的认可）。在处理请求后，服务器（此时的角色是客户端）使用标准RPC/ORB调用机制，将结果返给客户端（此时的角色是服务器），如下图所示：

有时，客户端无法扮演服务器角色，在这种情况下，客户端可周期性地轮询服务器，以了解结果的可用性。

如果有这样的问题：客户端不仅要等待服务器将请求存储在数据库再将认可返回客户端，而且还要等待数据库触发器的执行，从而发送阻塞。这将显著影响回调实现的解耦效果。
服务器端的实现还可使用内部消息队列，以确保有效、可靠地存储传入的请求，从而避免前面的纯数据库方法代理的诸多问题。

接口和载荷语义

一般而言，客户端和服务器（或发送者和接收者）之间的交互导致事务（或其他活动）在接收端的执行。为了确定调用者（或发送者）请求的事务或活动的类型，有必要指定操作。这一般通过两种方式进行：

1. 在服务器组件接口的操作签名中编定事务/活动代码
2. 嵌入消息本身

第一种情况下，请求的事务（或其他活动）使用自我描述的函数名来定义，我们称为接口语义，如下图：

第二种情况下，请求的事务（或其他活动）直接嵌入消息，可将请求嵌入消息头（如在MOM的消息头数据结构中包含这样一个字段），或将其作为应用程序专用的载荷。我们称此为载荷语义。如下图：

 

以文档为中心的消息

随着诸如XML的自我描述性数据结构的出现，一种称为“以文档为中心”的消息类型处理方法开始流行起来。以文档为中心的消息是语义丰富的消息，其中的操作名、参数和返回类型都具有自我描述性。SOAP（Simple Object Access Protocol，简单对象访问协议）技术特别适用于此类解决方案。在底层XML Schema（模式）仅对文档结构施加宽松约束时，可以将参数扩展为任何形式，而且不会破坏与早期软件版本的兼容性。

紧耦合与松耦合

使用UDDI（Universal Description，Discovery and Integration，通用描述、发现和集成）等标准，Web服务可以动态地发现和绑定到其他服务。
在运营情况起伏不定的环境下，必须有一个松耦合架构，以降低整体复杂性和依赖性。松耦合使应用程序环境更敏捷，能更快地适应更改，并且降低了风险。除此之外，系统维护也更方便。
所谓“耦合”，指将两个元素像链子一样连接在一起。在软件领域，“耦合”一般指软件组件之间的依赖程度。那么，什么是依赖？各种依赖对耦合度和松散度有多大影响？软件耦合可以发生在许多级别。必须区分生成时（编译时）依赖和运行时依赖。在分布式环境中，为了确定系统的耦合程度，必须分析各个级别。

大多数情况下，利用松耦合来增加灵活性都会引来相应的代价：增加系统复杂度。为了运用更高级松耦合系统概念，开发工作会更繁重，对开发人员的技术要求也更高，还必须购买价格不菲的队列系统产品。但从长远看，如果经常调整耦合系统，则松耦合投资会引来丰厚回报。