中间件作为帮助应用软件、数据库系统通过网络实现协作工作的基础软件系统，是现今信息系统构建和运行中不能缺少的一类支撑软件。与某些基础软件不同，中间件对软件与IT技术的进步更加敏感，适应、支持，以至拥抱变化，已是中间件必须面对新技术挑战必有的反应和动作。面对面向服务架构(SOA)、软件作为服务(SaaS)等新的技术浪潮，研究、分析中间件软件可能会如何应对应是很有意义的一件事。

　　消息中间件、交易中间件

　　计算机网络技术的发展、网络应用走向普及，无疑是中间件的第一推动力量。当企业应用从单机及主机终端模式走向客户机/服务器模式、分布式时，今天的中间件就开始形成了。这一轮的软件与IT新技术促成了中间件的形成。

　　计算模式的这一重大变化，使得解决分布式环境中数据的访问、通信、分布式事务管理就成了一个普遍的需求，也就使得在基础层面提供可复用的、通用的的软件组件——中间件成为普遍接受的解决之道。这一阶段，主流的中间件软件是消息中间件和交易中间件。

　　消息中间件主要解决分布式应用中消息的异步、可靠地传输问题;交易中间件则是解决联机事务处理类应用，或多层架构应用中的，对服务的高效访问、并发访问管理、分布式事务的管理等问题的有效工具。
　
　　在此阶段，中间件的基本概念、基本功能构成、应用方式等都已形成。以基本功能构成为例，无论是哪一种中间件，都会包含应用开发、运行时系统，以及监控管理这三个组成部分。

　　对象中间件、J2EE应用服务器

　　随着对象、组件概念与技术的形成和发展，人们很自然地提出了面向对象(OO)和组件化地开发网络应用的需要，也就有了高效率地访问远地对象和组件的要求，由此促使分布式对象技术、分布式组件技术的形成和完善，以及面向对象的中间件和分布式构件中间件的形成。代表性的产品分别是符合CORBA规范的对象中间件，以及J2EE应用服务器软件，它们都和交易中间件有很深的渊源。

　　与交易中间件相比，符合CORBA规范的对象中间件提供了符合标准的对象请求代理程序(ORB)、CORBA服务，帮助应用以标准和可管理地方式实现对远地对象的访问。服务标准的对象访问协议(OMG IIOP)。更标准的应用开发方式和接口、将应用程序接口和实现分离因而更方便地支持C、C++等多种语言的应用开发，这些都是CORBA对象中间件的长处。

　　J2EE应用服务器软件，力图基于可一次编写到处运行的Java语言，给组件化的网络应用的开发以有效地支持。J2EE创造了多类标准化的Java组件，如以表现为主的Web组件、以计算和数据访问为主的企业组件等等，定义了创造和使用这些组件的标准的API。J2EE应用服务器软件，则是提供了这些Java组件的开发环境、部署和运行平台，以及监控和管理工具的中间件软件。

　　无论是CORBA对象中间件，还是J2EE应用服务器，它们都适用于多层结构的分布式应用。与交易中间件相比，这两种中间件在API、数据与功能块(对象或组件)的构造和访问协议、基本系统服务等方面更加“标准”。CORBA对象中间件支持的是面向对象的应用，J2EE应用服务器支持的则是基于Java的分布式、构件化的应用。

　　CORBA足够系统和严谨，在J2EE之后对组件技术也有了支持，也够先进。但也许因为它有些复杂、规范又发展的太过于缓慢，CORBA对象中间件，最终应用面较小，这些年也基本上不发展了。J2EE应用服务器的成功，与Java语言及相关技术对Web及互联网的支持，以及互联网及电子商务快速发展密不可分。与CORBA相比，其简单性也不能不说是一个重要的因素(现在人们又嫌J2EE这几年搞复杂了)。

　　J2EE应用服务器还带来了“平台”的概念和显眼的GUI开发工具。IT厂商之所以喜欢称J2EE应用服务器为“平台”，而不是“中间件”，大概是因为“平台”上有较大的表现空间。就J2EE应用服务器给应用开发、部署和管理提供的支持来看，较之交易中间件，称为“平台”并不为过。

　　J2EE应用服务器软件除了创造了新的市场外，它也确实“蚕食”了绝大多数交易中间件的传统市场，以及消息中间件的一部分市场。J2EE应用服务器在对Web应用的支持、标准化、对构件技术的支持等方面的优势是交易中间件等传统中间件不能比拟的。

　　集成中间件平台

　　先有独立的系统，才会有集成的需要，也才会有对集成中间件的需要。集成中间件力图改变传统的应用集成方式——应用之间点对点的直接连接与交互、与各个应用的适配和交互中的数据转换与处理完全要手工编码来实现、某一方应用接口的变化可能会影响一大片。

　　对于多年前就开始流行的、面向企业应用集成的传统应用集成中间件，各个厂商的产品，功能定位基本相同，大的功能也大体相同，但一些基本的技术概念、具体的功能设计和实现，以及集成开发的具体过程和方法却可能差别不小。这当然会增加使用者的学习成本和用户日后改变的成本。在对新技术的支持上，主要体现在中间件对与应用和系统适配的新的通信协或访问协议的支持方面，对各种新的数据源(XML数据库、XML文档，甚至Web服务等)等的支持和包容方面。

　　SOA及Web服务的流行，使集成中间件面临一个全局性和战略性的技术决断。虽然一些传统的应用集成中间件已能够基于SOAP/HTTP协议实现对标准Web服务的集成、提供遗留应用、系统的服务化封装能力，但人们认为还很不够，希望产品还能在概念、操作等层面体现面向服务的理念——集成的过程是服务封装、组合、编排、发布、部署，以及监控和管理，希望新的SOA应用集成中间件基于开放、标准的技术架构，使用和支持开放、标准的技术，由此带来更长久的生命力和经济性。

　　变化与不变

　　新技术的发展促成了中间件的诞生，促进了中间件的改变和发展，也促使新的中间件产生。在这个过程中，中间件的基本定位没有改变，中间件所面临的最基本的问题也没有改变。数据访问、可靠传输、事务管理、流程管控等仍是传统中间件、新型中间件基本上都要面对和解决的技术问题。中间件厂商都必须拥有跨平台、基于不同的技术解决这些问题的能力。

　　我们看到的变化是：与以往不同的新业务问题与环境，比如基于互联网的应用开发、符合开放技术标准的B2B集成、大量的遗留系统的集成等等。可以用来解决哪些基本技术问题、各类技术问题的新技术。比如面向对象(OO)技术、组件技术、Web服务技术等等。另外，新技术也带来了新的技术问题，需要有办法去解决。比如，Web服务的引入，也引入了Web的查找、管理等新的问题。

　　SOA和SaaS的挑战

　　SOA即面向服务的架构，它是一个伴随互联网、TCP/IP和XML等技术而产生的，以服务为核心概念的软件系统体系架构的建立原则。服务是由某个计算实体提供并有明确接口描述的工作单元，或某种功能;其它的计算实体根据服务的描述信息，与提供方交互使用访问的功能。

　　SOA倡导一种新的软件构造方式，保证软件的功能单元(服务)之间是松偶合的，可以使软件单元(服务)更容易地被重用和组合，软件系统本身更容易、更经济地根据需要改变、修改和构建，最终适应业务迅速变化、业务与IT同步的需要。

　　在服务的消费方与提供方在交互时，需要一些公共的约定和计算基础设施，比如用XML描述服务，通过Web协议访问服务等等。各种中间件软件要支持SOA，就要提供这些相关设施。比如，或独立地或配合以其它相关软件，将现有各类功能模块或组件封装成标准Web服务供外系统访问，或者提供访问外部标准Web服务的能力。

　　SOA使得现有系统、应用以及用户可以以一种能够容纳变化、灵活的架构有效地集成，并实现更大程度的复用。要达到这样的一个目标，改造现有的中间件软件，使之如上所述包容、支持Web服务相关技术是不够的，还需要有一种新的中间件软件——企业服务总线(ESB)，或以ESB为核心的SOA集成套件来帮助达成。

　　ESB被看成是一种新的基础架构软件，它帮助在应用集成中方便地实现与现有各个系统的适配、交换数据的统一表示、转换和加工处理，以及数据/消息在各方之间的传输以及管控。ESB一般包含一个消息传输骨干(消息中间件)，但实施集成者工作在比消息传输层更高的抽象层面。与传统的应用集成中间件一样，ESB需要解决对系统、应用的适配、消息传输的控制、消息的转换和加工，但实施集成者所面对的不再是以来自于各厂家实现的专有的概念实体，而是以标准形式封装了的，更易于复用和组织在一起的服务或提供服务的组件，服务的某种组合，或者提供服务的组件的组合。这种集成模式更易于日后调整和修改。SOA集成套件，以ESB为核心，一般还包含业务流程管理引擎(BPM)和其它相关工具。

　　SOA带来了新的技术问题，需要中间件去应对和解决。比如服务的使用(查找、组合及编排)、服务的管理(治理)、服务质量的控管(在自己的管控范围之外的服务所潜在的不确定性)、交互中的安全(松散模式带来更多的身份鉴别、数据保密问题)等。

　　SOA引起了传统中间件的改变，也促成了新中间件的产生。SOA对中间件的影响是全面的。

　　SaaS

　　SaaS即软件作为服务，它代表了一种新的软件交付模式，不同于以往的产品或系统交付模式。SaaS模式下，企业不再去建立一个完全属于自己的、部署在自己的环境中的信息系统，而是通过公共网络使用由第三方开发并由专业运营商提供的应用系统提供的功能服务，来满足自身信息管理和处理的需要。SaaS是在网络带宽与IT硬件越来越便宜，软件的开发、维护和管理费用(TCO)越来越高的这一大背景下产生的。

　　对于应用服务的使用方和提供方来说，SaaS都意味着不小的变化。使用方按使用量或时间付费租用，不再需要购买一个软件产品或系统，包括中间件软件产品。也就不再需要对后台的计算机系统进行维护和管理，得到的是简便和节省。对于应用服务的开发方和运营商来说，对应用和系统维护、管理工作可以集中在服务中心进行，不再需要大量的现场应用和系统服务人员，因此更加简便和节省。然而，对于应用服务的提供方来说，应用服务系统在功能(通用性与可定制的平衡)、性能(对大规模并发访问，甚至是互联网规模的应用访问)、可靠性(不间断运行)，以及可扩展性(随着应用需求、客户的容量的变化而改变)与安全性(用户信息的私密性、对用户身份的鉴别等)方面提出了更高的要求，涉及开发、部署、运行及管理多个方面。这对中间件提出了更多、更高的要求，同时也是中间件可以展现其功力的地方。

　　性能方面，大型的SaaS应用服务，如互联网规模的应用服务，对中间件软件支持高并发访问、大吞吐量处理的能力和负载均衡能力提出了更高的要求。可靠性方面，要求中间件提供高效、可靠的集群能力保证应用服务的稳定和不间断运行。维护和管理方面，中间件必须提供更全面的动态配置和维护能力，使改变系统配置时可以不停机或少停机。针对不同的应用服务类别或类别组，中间件也完全可以设计提供支持逻辑上相互隔离的功能支持。安全性方面，要求中间件提供更强的用户信息的机密性和使用者身份的鉴别能力等。

　　SaaS是一种趋势，是一种增长很快，但需要较长的时间才能成为企业信息化的主流形式。不能简单地以为，所有的应用服务都必须以SaaS形式来实现和提供

　　从复杂再到均衡

　　中间件所面临的挑战，远不止来自SOA和SaaS。来自以客户为中心、实时企业、业务流程再造等新的业务需求，互联网环境、公共的无线网络等新应用环境，Eclipse、OSGi、Ajax、开源软件框架新的开发技术，都要求中间件予以积极地响应。中间件由此也经历了从技术单一、功能单一、单一系统，到支持多样技术、包含众多功能和平台化、套件化的过程，从简单逐步走向复杂。

　　先前的复杂有其道理，当前的均衡则是复杂后的要求。从Java企业应用开发中程序人员有取舍地使用J2EE、偏爱简单、功能单一的开源开发框架，以及软件人员普遍地对J2EE日趋复杂的担忧，Java EE(J2EE)新规范对简单化要求的响应和谋划，以及SOA/Web服务技术的简单与明了的趋向，都可以印证上述判断。为什么会如此?因为商业化的中间件软件确实越做越大，定位越来越宽泛，功能越来越“完整”，超出了每一个用户的实际功能需要，以及每一个使用者对复杂度的容忍度。“简约”也就成了新风格中间件的一个重要特征。

　　新风格的中间件

　　新风格的中间件的“新”体现在以下的几个方面。一，新的定位观。新中间件必须有明确和清晰的市场或问题域定位。定位不应太宽泛，以至于什么问题都能解决，解决什么问题都不是最好。二，新的概念观。新风格的中间件的开发及运行时概念是面向服务的。这是新风格的中间件的一个重要特征。三，新的“量级”观。运行时环境是非重量级的，或轻量级或“适量级”的。应用开发简便、快速。四，新的标准观。不追求处处皆标准，看重的是中间件与外部环境的互操作的标准性。五，新的产品观。不追求产品功能一步到位，强调系统是可扩展的，可以滚动式的逐步升级和完善。

　　中间件的新风格体现了当前中间件软件对功能与大小尺度的“适度”与“平衡”的追求。产品功能上不求完整和复杂，体积上不求大，讲究适量、轻量，支持高效、简单的新的开发方法学。新风格的形成，其影响因素不只是单一的技术因素。新技术带给中小中间件厂商越来越大的挑战，新风格的中间件也给它们带来难得的发展机遇。新风格的中间件给中小中间件厂商提供的机遇，也是中国中间件厂商面临的机遇。