第1章引入了中间件，在2.3.2节讨论分层体系结构时又重温了中间件。中间件的任务是为分布式系统的开发提供一个高层的编程抽象，并且通过分层，对底层基础设施中的异构性提供抽象，从而提升互操作性和可移植性。中间件解决方案是基于2.3.1节引入的体系结构模型，也支持更复杂的体系结构模式。58本节我们简要回顾一下现在存在的中间件类别，为在本书的其他部分进一步研究这些解决方案做好准备。中间件的类别 远程过程调用包，（如Sun RPC，第5章）和组通信（如ISIS，第6章和第18章）属于最早的中间件实例。从那以后，出现了大量不同风格的中间件，大部分都基于上面介绍的体系结构模型。我们在图2-12中给出了中间件平台的分类，其中交叉引用了其他章，那些章更详细地讨论了不同种类的中间件。需要强调的是分类并不精确，现代中间件平台试图提供混合的解决方案。例如，许多分布式对象平台提供分布式事件服务，来补充传统的对远程方法调用的支持。类似地，出于互操作性的原因，许多基于组件的平台（和平台的其他分类）也支持Web服务和标准。从中间件标准和今天可用的技术的角度来看，还应该强调这个分类并不完整，其目的在于给出中间件的主要类别。其他（未给出的）解决方案是比较特定的，例如，特定于提供某一通信范型，如消息传递、远程过程调用、分布式共享内存、元组空间或组通信。图2-12中的中间件的顶层分类是根据通信实体和相关通信范型而确定的，遵循五个主要的体系结构模型：分布式对象、分布式组件、发布-订阅系统、消息队列和Web服务。对等系统是这些类别的补充，基于2.3.1节讨论的协作方法，对等系统是中间件一个相当独立的分支。应用服务器，显示为分布式组件的子类，也提供对三层体系结构的直接支持。特别地，应用服务器提供了结构以支持应用逻辑和数据存储的分离，以及对其他特性（如安全性和可靠性）的支持。详细细节将延后到第8章讨论。除了编程抽象之外，中间件也能提供分布式系统的基础设施服务，供应用程序或其他服务使用。这些基础设施服务与中间件提供的分布式编程模式是紧密绑定的。例如，CORBA（第8章）提供给应用一系列的CORBA服务，包括对程序安全和可靠的支持。如上所述和在第8章中的进一步讨论，应用服务器也提供对这些服务的内在支持。中间件的限制 许多分布式应用完全依赖中间件提供的服务来支持应用的通信和数据共享需求。例如，一个适合客户-服务器模型的应用，如一个名字和地址的数据库，可以依赖只提供远程方法调用的中间件。通过依靠中间件支持的开发，能大大简化分布式系统的编程，但系统可依赖性的一些方面要求应用层面的支持。考虑从发送者的邮件主机传递大量的电子邮件消息到接收者的邮件主机。乍一看，这是一个TCP数据传输协议的简单应用（见第3章的相关讨论）。但考虑这样的问题：用户试图在一个可能不可靠的网络上传递非常大的文件。TCP提供一些错误检测和更正，但它不能从严重的网络中断中恢复。因此，邮件传递服务增加了另一层次的容错，维护一个进展记录，如果原来的TCP连接断开了，用一个新的TCP连接继续传递。Saltzer、Reed和Clarke的一篇经典论文［Saltzer et al.1984］对分布式系统的设计给出了类似的、有价值的观点，他们称之为“端到端争论”。可将他们的陈述表述为：一些与通信相关的功能，可以只依靠通信系59 ～60统终点（end point）的应用的知识和帮助，即可完整、可靠地实现。因此，将这些功能作为通信系统的特征不总是明智的（虽然由通信系统提供一个不完全版本的功能有时对性能提高是有用的）。可以看出他们的论点与通过引入适当的中间件层将所有通信活动从应用编程中抽象出来的观点是相反的。争论的关键是分布式程序正确的行为在很多层面上依赖检查、错误校正机制和安全手段，其中有些要求访问应用的地址空间的数据。任何企图在通信系统中单独完成的检查将只能保证部分正确性。因此，可能在应用程序中重复同样的任务，降低了编程效率，更重要的是增加了不必要的复杂性并要执行冗余的计算。这里不进一步介绍他们的争论细节，强烈推荐读者阅读前面提到的那篇论文——那里有许多说明的实例。原文作者之一最近指出：争论给互联网设计带来的实质性好处最近面临着为满足当前应用需求而转向网络服务专门化的危险［www.reed.com］。这个争论给中间件设计者带来一个实际的两难困境，而且给定当代分布式系统中种类繁多的应用（和相关的环境条件）（见第1章），这些困难与日俱增。本质上，底层中间件行为与一个给定应用或应用集的需求和相关环境上下文（如底层网络的状态和风格）有关。这个看法推动了对上下文感知和中间件自适应解决方案的兴趣，见Kon等人的讨论［2002］。
相关资源：七夕情人节表白HTML源码(两款)