Web2.0: 基于XML和Java标准的集成技术---下注在技术更替的关键时刻

标准能够推动技术革命：比如SQL语言标准对数据库市场产生的巨大影响，再比如HTML、HTTP、URL以及SSL这几个标准的融合促使了万维网的产生。我们完全可以相信：协议级的标准（XML，Web服务）以及编程语言级的标准（Java 和.NET 中的一个, XML Query, 等等）同样将会对集成技术产生深远的影响。
系统集成需要用到广泛的信息技术（请看图1）：

企业应用集成（Enterprise application integration， EAI）：直接通过Intranet连接两个或者多个商务应用（更确切地说，是跨越企业防火墙的连接）
B2B集成（Business-to-business integration ，B2BI）：直接通过Internet或是虚拟专用网（virtual private network，VPN）连接企业及其商务伙伴的应用。
用户界面集成（User interface (UI) integration）：整合并且个性化多个应用系统的用户界面，使用户可以使用一个统一的“Web流”（比如一个门户中的Java页面流），从而把这些全异的后端系统整合到一块。
数据集成（Data integration）：把全异的应用以及数据存储中的数据整合到一起，从而定义一个统一的业务对象视图——比如，通过合并客户关系管理（CRM）系统以及企业资源规划（ERP）系统等多个系统中的数据从而创建一个统一的“客户”模式。
目前，各种专有解决方案各自分散地占据着系统集成市场，没有一个方案达到足够的规模，能够满足我们这个面向Web的世界的需求。
（注意：因为专有的系统集成技术通常需要用户在所有参与节点运行特定供应商提供的软件，说服一个跨国企业以及它所有的商业伙伴运行同一个专有的系统集成软件是不可能的事情。）同时，系统集成费用仍然是高昂的——通过各种方式它消耗了70%以上的IT建设自由支配资金，但是仍然保持着十分混乱的状态，从而使企业倾向于仅仅把各种各样的应用连接到一起，好象这变成了一种商业义务。
很显然，这个行业必须做得更好才行。我们坚信它会更好，因为我们可以从用户界面平台中扩展出Web应用（也就是现在的浏览器到数据或应用的体系结构），从而造就一个统一的集成平台。目前，大多数新的应用已经从一开始就具备了“支持web”的能力——即支持浏览器前端。我们主张将来的系统从一开始就要具备“支持web集成”的能力，也就是说，能够被插入到新兴的“基础体系”中，这个“基础体系”是由可扩展标记语言（XML）和Web 服务组成的，这两项技术能够使应用程序和基于Web的其他应用程序无缝地整合到一起。
但是XML和Web服务仅仅定义了协议，也就是说，仅仅定义了标准的wire格式来保证互操作性。企业如何去做，才能在业务运行逻辑的规划过程中，保护自己的投资呢？业务运行逻辑的任务是将web应用粘合到一起。如同Servlet，JSP，以及ASP这样的应用编程标准对于Web的成功十分重要一样，集成规划标准对于基于Web的系统集成也是至关重要的。
事实上，很多在这种“巨大改变”中必不可少的基础结构标准都已经存在了。
如同先前曾经出现的情况——大家都来支持Web应用的开发——一样，系统集成市场在横扫一切的标准化进程中也达到了平衡和统一。BEA已经和我们的平台竞争对手（主要是IBM和Microsoft）以及同盟进行了合作，目标就是把Web加入到系统集成的开发以及系统集成平台——Web2.0中去。如果你愿意，你同样可以加入这个联盟！假设我们成功了（如同行业分析家们预测的那样），Web应用服务器（目的是为了支持web应用程序的开发和托管）将会被Web应用平台所取代，后者包括了紧密集成的门户、EAI、B2BI、以及数据集成技术。那时候，Web2.0对企业信息技术产生的影响将会远远超过Web1.0！
集成技术的层次关系
系统集成所需的各种技术的层次关系比较容易理解。我们推荐的分层方式如图2所示。让我们从下至上逐层分析。

中间件基础结构
所有系统集成产品（包括传统的专有技术以及新出现的Web平台技术）的基础都是中间件总线，它提供了互连互通的机制并且保证了服务质量。过去，系统集成行业厂商们选择了工业标准的中间件（Java企业第二版：J2EE，或是基于.NET的技术）来开发和托管Web应用，可是，当整合多个应用的时候它们却采用了专有的中间件技术。
但是，web2.0将会构建在一个既是开发平台也是托管平台的统一平台之上。因此，标准的Web应用服务器（Weblogic、WebSphere、.NET、等等）正在取代专有的集成中间件：目前已经证明，对标准的Web应用服务器进行扩充以进行集成比重新把专有集成方案的代理组件嵌入到符合Web标准的应用服务器中要容易得多。（注意：大多数以往的专有集成方案提供商正在把应用服务器技术纳入到他们的下一代集成方案中去，这一事件成为这种融合趋势的最好证明。当然，这些供应商也面临着巨大的挑战，因为，Web应用平台的领头羊[BEA, IBM, Microsoft]多年前就已经将该领域圈定为自家的“后花园”。）
应用对外连接层
Web服务和适配器把Web集成平台和其他应用以及数据源连接到一起。在图2中，尽管中间件层是绿色的（表示J2EE和.NET现在是成熟可靠的），但本层却是红绿结合的，这是因为必需的Web服务标准仍在不断扩充。
XML/Web服务
Web服务只是简单地在不同应用之间传递XML信息。图3显示了Web服务所处的时间和位置，Web服务应该成为应用之间互操作的最佳方式。定义理想的粗粒度且持续稳定的、能够完美封装应用的业务接口是一种高超的技术，或者说是艺术。


商业应用系统的架构师们应该仔细审视Web服务的这种候选方案。让我们来看一下图4中描述的一整套新兴的XML/Web服务标准（也被称为acronym soup，意为一锅缩写字头组成的汤，这是因为这些标准又是建立在一大堆有缩写字母表示的标准之上，其中包括SOAP、RPC、XML-RPC、以及HTTP等）。和前面的Web层次一样，我们推荐采用一组基本的核心标准，通过这些标准“集成Web”将达到临界状态。
我们把一些特定的技术纳入到了这组核心技术中，这些技术的基本规范中包括了对Web服务的互操作性（WS-I）进行验证。（注意：目前，容器间的Web服务互操作应该遵守XML Schema、SOAP1.1、以及WSDL 1.1这几个标准中针对Web服务互操作的基本规范。如果你甘冒供应商已经作过测试的范围之外的风险，你很可能会在不同的容器之间遇到互操作问题——例如，WebLogic 和.NET之间的容器内部互操作问题。然而，新的Web服务标准将不再有这样的问题出现。）
针对Web服务的负载能力，一种以XML Schema为代表的，基于XML的模式语言，是最为适合它的。如果说XML Schema正在变成一种支持可互操作商务对象的混合语言，那么简单对象访问协议（SOAP）就是“可组合的”消息头的框架，它可以提高在不同应用之间传递那些商务对象的服务质量（比如，安全性和传递可靠性。）
在利用Web服务时，程序员们不应该为了得到松耦合特性而“生硬改写”模式去适应业务逻辑，尽管松散耦合曾经造就了Web的巨大成功。
但是，松耦合并不是Web服务的固有特性——你必须通过编写程序来实现它。（注意：Web的松耦合是指Web站点可以进行根本性的改变[比如从.NET移植到Java]，但是不会影响到最终用户[用户甚至不会感觉到ASP网页已经变成了JSP网页]）。Web服务的松耦合是十分难以达到的。因为，尽管我们期望Web服务的“连接通道”的两端可以各自接受修改，但Web客户端[浏览器]以及浏览模式[HTML]是确定不变的。
如果你使用Java编程环境作为你的Web服务“设计中心”（就是说，从Java类自动生成Web服务定义语言[WSDL]），我们建议您使用“包装器”类，而不是直接导出应用对象。我们还建议您利用XML Schema的可扩展性模型，并且尽量使用上层的绑定方式，比如采用XML Query以及诸如XML Beans, JAX-B,和JAX-RPC这类的“模式编译器”。这样，开发者就能够保证应用程序或者Web服务接口的改变对另一方产生的影响最小。
我们建议在最终将会成为Web服务核心的那些标准上应用以上这些由WS-I定义的基本规范。WS-Security提供了可选择的加密方式（私有的）、认证方式，并且支持委托授权机制（安全上下文的传播）。这些正在形成的OASIS（Organization for the Advancement of Structured Information Standards，
结构化信息标准促进组织）标准和Web服务的“SSL”（安全套接层协议）是相互兼容的。
WS-RM （WS-Reliable Messaging，Web 服务中的可靠通信协议）和WS-寻址（来自BEA, IBM, Microsoft, 以及其他厂商）确保了消息能够通过不可靠网络和系统，在“事务特性得到保证”的情况下，进行传递。
WS-RM和WS寻址使用存储和转发机制进入Web服务层，这一领域以往一直被像MQSeries这样的面向消息的中间件产品所占据。尽管对于查询操作来说，同步的Web服务更为适合，BEA仍然肯定地认为这种异步的Web服务是针对事务/更新的“最佳处理位置”。这也就是我们投入大量的精力，希望能够使异步的Web服务可以像同步的Web服务一样被容易编程使用的原因。
适配器
适配器解决了集成最后阶段的难题：它们提供了Web技术到非Web技术或者“遗留技术”（比如COBOL/CICS）的连接方式。（注意：使用“遗留技术”这个词我没有任何不敬的意思：成为一种长久被人们使用的遗留技术是软件的最高目标[当然，很多软件没有达到这个目标]，而且，从真正意义上说，所有的生产应用都是遗留的。）即使在XML和Web服务出现之后，适配器仍保持着重要的地位，因为目前只有十分少的遗留系统直接扩展了对Web服务的支持。（相反，遗留系统将会被Web服务和新的业务逻辑 “包装”起来，然后部署到WebLogic, WebSphere, 和.NET这样的容器中去）。
如果没有一个标准的适配器模型，集成平台几乎不可能到达临界状态。这一点可以参照通用的数据库适配器，即Java数据库连接 (JDBC)，对Java的成功所产生的巨大影响。
J2EE连接器架构（Connector Architecture，CA）对JDBC进行了泛化处理，从而为Java适配器定义了一个通用的模型。J2EE连接器架构（或者.NET）消除了m x n 式的费用支出方式，m x n是指每一个集成供应商（m）都必须为每一个遗留系统（n）提供一个不同的专有的适配器。除此之外，J2EE连接器架构还保护了您在集成方案中的程序设计投资，就好比JDBC保护了数据库应用系统的投资一样。
转换、整合以及映射层
一个期望深深根植于我们关于Web2.0的观念中，那就是使XML成为跨越不同系统的数据表示方式。不管市场营销如何地夸大了XML的这一功能，XML自身并不能避免不同数据表示之间的不匹配，而且我们也正在目睹多的数不清的XML Schemas在企业之间泛滥。（在一些大型公司中，仅仅是用来表示“客户”这一结构的模式的数量可能就已经超过了100个。）XML只是定义了一种通用的构造文件的字母元素（就好比是“结构化的ASCII”）；仍然需要各个公司和行业去定义词汇表（从XML到业务对象的语义映射），从而使快捷的转换成为可能。一些这样的词汇表将会采取“从上至下”的方式定义，它们由行业标准制定机构或是行业工会来定义。另外一些则采取“从下至上”（就像自然语言的产生）的方式逐渐成型，个别的公司或是一小群公司制定了与其进行交易的Web服务的必要组成部分，然后逐渐形成了词汇表。
尽管基于XML的EAI总是在一个单独的公司之内实施，但是也面临着同样的问题。能够把一个词汇表映射为另一个词汇表的工具能够在很大程度上减轻这种负担——这个工具就是XML Query，它正在成为XML处理领域的“SQL”。尽管XML转换正在变得容易和快速，你还是应该通过在企业应用架构中引入审查/批准的流程，从而尽量限制XML Schema数量的过分膨胀。
程序开发层
开发连接集成业务流程（业务流和web流）和底层的商业应用的粘合程序的花销仍然主宰着集成解决方案的开支。不幸的是，目前的处理技巧与理想的境界仍然相差很远——如果达到理想境界，业务分析员只需要定义高层的业务流程，基础结构就能够“神奇地”自动生成必要的粘合程序。历史上，集成项目最大的一个风险在于：粘合程序的编写过分地依赖于专有应用的编程接口（API）。在没有标准API的情况下，根本无法保护在集成代码以及程序员身上所作出的投入。而且，根本就没有足够丰富的符合API标准的工具（如同为了开发SQL和J2EE而产生的开发工具）。独立软件供应商们（Independent software vendors ，ISVs）竭尽全力地构建能够部署于多个容器中的集成解决方案。（比如，可以移植到WebLogic 和WebSphere上的方案）。
当然，Java和XML组织已经在扩展Web应用平台标准方面做出了巨大的努力，以便保护集成工作中所作出的投资。
·
一下是一些值得密切关注的热点：
XML Query (W3C)
·  Java Web 服务 (JWS) (JSR-181)
·  Process Definition for Java (JSR-208)
·  BPEL4WS (由BEA, IBM, 和Microsoft发布)
·  Java Meta Data (JSR-175)
·  XML Beans (来自BEA的开放源码)
·  Portlets (JSR-168)
·  Content Management Interface (JSR-170) （JSR-170)
·  Apache Struts and Java Server Faces (JSR-127)
·  Web Services for Remote Portlets (WSRP; OASIS)
业务流程编制层/ Orchestration层
在业务流程控制级，我们向集成项目加入了必需的说明性粘合指令：包括工作流，“Web流”，“工作列表”（贯穿整个组织的一系列相互协作的文档），以及流程的编排——抽象的消息序列，它定义了工作流如何在企业内部以及企业之间组合。
在业务流程控制级最容易理解的技术就是业务流程管理（Business Process Management ，BPM），BPM利用图形语言和工具来定义工作流——即一个由各种任务和异常处理构成的计算序列。可以肯定企业将会需要各种各样的工作流表示语言：
关注业务分析的工作流表示语言语言（例如Aris）
与Java无缝集成的工作流表示语言（Process Definition for Java/JPD）
与编程语言无关的工作流表示语言（BPEL4WS）
对于基于Java的工作流，PDJ仍然是最好的选择。
BPEL4WS在Java和.NET之间提供了一定的独立性，不过需要付出的代价是必须引入一种新的XML编程语言。可以预见PDJ 和 BPEL将会合并——PDJ将会变成BPEL工作流的Java实现。
集成代理及管理层
尽管集成方案仍然需要编码，但是它的目标仍是使编码量达到最少。在这点上安全性也具有相似特征：过去，授权过程完全是在应用中通过手工编写代码实现的。现在，处于领先地位的Web平台通过面向业务的规则，从管理的角度定义了安全策略。（这种策略可应用于特定的端点或是整个应用）。
指令和控制方面也出现了相同的变化——如何路由一个特定的请求（比如一个交易）可能取决于用户（服务的质量），内容（钱数），接收方（转换和适配器应用于其上），或者基础结构的状态（可用性，负载）。如果这样的逻辑处理用程序编制于应用之中，那么不改变业务逻辑并且重新部署它就很难对应用做出改变。通过采用管理的方式获取这样的元数据，就能够非常容易和经济地适应这些变化。
集成平台的管理环境必须为集成代理之间的互通和平台与其他应用的连接提供一个功能广泛的操作视图。
可以预见，集成应用的配置环境将会越来越支持自我优化特性，以及自愈特性——只有在可用系统资源不足，以至于难以达到服务质量要求的时候才会对系统管理员作出提醒。
结论
解决集成的花销和复杂度可能是人们对IT业提出的最大的要求。不幸的是，世上没有万能药：集成现在是，并且将来还会是一个固有的难题。尽管这样，有了Web2.0，这个行业仍然可以得到巨大的改进——方式就是通过提高投资保护的程度和降低非内在的复杂度。利用标准的集成平台和相关工具，该行业应该能够使非内在的复杂度减少10倍——使集成项目更加容易预测，更加容易成功，而且还可能更加充满乐趣。
当然，Web 2.0仍然需要时间去完善。Web 服务标准仍然在不断发展：可互操作的端到端的安全性，以及可靠的传递机制将会在今年的年底出现。
如果说Web2.0标准仍然没有到位，这是否意味着各个企业和单位需要等待它的正式出台呢？我看很难这么做。代表Web以及Java标准集成中最前沿技术的产品可以为保护长期投资争取到一个非常有利的位置。这些集成方案——比如WebLogic集成、门户、Liquid Data、以及它们的直接竞争对手——在功能和特性上具有排它的相互竞争性。
那么，各个企业和单位如何为基于Web2.0的集成做好准备呢？答案是可以同时从战术和战略两方面对待集成的挑战：战术上，利用最合适的标准和专有技术的混合来完成工作；战略上，把注压在新兴的Web 2.0集成平台之上。
对于那些仍然对融合了这些标准的集成方案持怀疑态度的人，我有一个故事要送给他们：在1997年，我曾做了一个不太被人们注意的预言：服务器端Java标准的融合趋势（后来发展成为J2EE）将会对Web应用的开发产生巨大的影响。
那时候，大约存在着30个独立的Web应用服务器供应商，每个都在发展它们自己的专有编程模型和开发工具。可是现在，由BEA的WebLogic和IBM的WebSphere领导的基于J2EE标准的Web应用服务器市场拥有数十亿美元的潜力。而且，至少是因为J2EE的流行，Microsoft发布了它的.NET系列。
历史将会再次证明，花在基于We的集成项目中的钱是很值得的。对可扩展的集成方法的迫切需求、希望通过标准来保护投资的渴望、以及对符合标准的容易使用的开发工具的需求都将会促进这个大融合。就像所有的技术转型期一样，目前存在着获得竞争优势的巨大机会，尤其是对于那些独立软件供应商和专注于集成的系统集成商。当然，同时也存在风险。是的，在向一个还没成熟的技术下注的时候风险就会存在，但是，如果没能把握这个即将来临的浪潮，而错失了赚钱良机，不同样也是一种风险吗？

_xyz