一、引言

当今，各个企业都在想方设法提高自己的生产效率，并且对IT资产的重组也都在努力的探索当中。借助于面向服务的架构(SOA)技术，IT组织已经在 克服这些问题方面取得了一定的成效；但是，在大多数情况下仍然只是实现了整个IT服务组合的一小部分。目前，有关这方面的大多数的努力也只不过是达到一种 “刚刚满足”的SOA应用状况—在改进构建应用程序的能力以及使之与市场的结合更快更好更为便宜方面。而且正如我们已了解的，要实现这些目标说起来容易做 起来难。

二、传统的基于中间件的复合应用程序

现有的事实是，SOA是一种中间件—而传统情况下，中间件往往要依赖于更多的中间件才能把数据翻译成一种消费者友好的状态。当你最后搞清楚构建一种 融入SOA技术的复合应用程序不仅要求使用一种portal(中间件)而且还有可能要使用一种BPEL引擎(甚至还是中间件)对它进行编排时，这当然使你 非常失望。更糟糕的是，你有可能在一家发布UDDI注册表和注册大量Web服务的组织内工作。但遗憾的是，在大多数情况下，还存在极少的实际消费这些服务 的应用程序。怎么会是这种情况呢？

难道如果无法构建消费这些SOA服务的应用程序我们就该得出结论—什么东西出错了吗？是否是因为业务内容开发者太难构建这种直接消费SOA服务的应 用程序从而导致只好由其它的IT组织为我们创建这样的应用程序呢？是否由于缺乏一种SOA监管架构从而使我们犹豫不决？我想，我对上面所有问题的回答都是 “是的”。而且存在一种非常突出的理由：仅由业务开发者消费和利用这种由IT组织暴露的SOA服务实在是太难了！其实，真正存在的问题是缺乏一种容易的方 法来在SOA上加入一种界面—而这正是把AJAX技术与SOA结合到一起的优点所在。

典型情况下，SOA服务被实现为一种松耦合的封装和暴露业务功能的Web服务。这听起来似乎非常直接，但是实现起来却非常复杂和困难。开发者经常在 SOA服务的开发粒度方面讨论不止；但是现在，大多数开发人员都一致认为“业务级”的开发粒度是最合适的。然而，这仍然需要大量的相关领域专家加入并且要 与业务内容合作才能最终确定这些服务的大小。

三、SOA的复兴

幸运的是，最近人们又对SOA产生了深厚的兴趣。也许企业最终意识到SOA确实能够帮助给它们带来巨大帮助。也许这是由于更好的开发工具和在 Amazon，Yahoo和eBay宣传下的Web服务所致的缘故。也许它就是AJAX？不错—这也正是本人撰写此文之原因。认真地说，我确实认为正是 AJAX成为更新人们对于SOA的重新认识的一种重要的驱动力量，特别是在当今各种新技术混合应用领域。但是，这两种迥然不同的技术应该如何结合并连接到 一起才能迸发出更巨大的力量呢？先让我们来看一下Wikipedia对当前AJAX技术的定义。其中涉及到了Web页面，但是根本没有提及SOA。其中的 描述是：

“AJAX，代表了‘异步JavaScript＋XML’，是一种创建交互式Web应用程序的Web开发技术。其目的是，通过在后台与服务器实现少 量的数据交换从而使前端Web页面感觉起来更具响应性；因此，每当用户作出一个改变时，不必重载整个Web页面。其最终目的是进一步提高Web页面的交互 性、响应速度及可用性。”

此定义中没有提及SOA并不奇怪，因为早期的AJAX应用主要集中在增强页面的功能与可用性方面。这一点已经在众多应用程序，例如Google Maps，Flickr和Yahoo Mail，中得到证实。然而，并不是这些面向消费者的应用程序使我对AJAX的潜力感到激动，而是运行于公司的防火墙背后的业务应用程序真正利用了 AJAX中的优点，因为它向我们展示了两个关键特征：一个是客户端编程模型，另一个是对服务器进行异步调用的易实现。这两种关键能力—在客户端(浏览器) 应用逻辑的能力和在不打断Web页面的情况下存取服务器数据的能力，正是它们拓宽了构建新的更为丰富的Web 2.0企业应用程序的如此众多的可能性应用领域。

前面，我曾提及SOA缺乏一种界面。这也正是AJAX“介于”这其中的原因—它能够给SOA加上一个体面的外观。在此，请让我多作一些解释。我们不 妨考虑一下，如果SOA服务以在线方式出现的话，情况会怎么样？这样的服务通常需要在一个注册表或仓库中进行注册(如果我们幸运的话)，然后就可以用于消 费。例如，我们不妨去看一下StrikeIron网站( [url]www.StrikeIron.com[/url]) 中所提供的内容。StrikeIron已经成功地创建了一种针对普通大众的“Web服务市场”。乍看起来，StrikeIron网站中的目录机制很象一个 小型业务应用程序中所提供的列表。但是稍后，你就会意识到这并不是一些应用程序—它们实际上是一些Web服务。由一家公司针对广大消费者提供 WSDL/REST Web服务的概念本身就蕴含了多种意义。但是，现在先让我们来看一下这家公司所出售的内容。根据StrikeIron提供的信息（他们允许存取这些服 务），它提供的大多数流行的Web服务包括：

·美国地址校验

·全球短信服务

·销售和使用税

·电子邮件校验

·逆向电话查询

毫无疑问，所有这些Web服务都相当有用，而且能被应用于许多不同的领域。但同时，它们又太“商品化”。换句话说，我可能并不在意是谁提供的这些服 务，而仅想得到我所希望的信息。另一方面，我会简单地使用任何Web服务来实现把现金从我的经常帐户转到我的储蓄帐户吗？我不会这么做的。我首先需要建立 对这种服务的信任，因此，我必须与提供该服务的供应商建立一定的关系。存在于我（消费者）和服务提供者之间的这种“信任圈”也正代表了企业内部及其合伙企 业之间的关系。

四、AJAX+SOA技术相结合

上面同样的方式也可以为企业所采用，从而把他们的Web服务提供给更广大的用户群。通过一种Web服务市场，企业可以注册各种Web服务—而这些 Web服务通常情况下仅能为企业内部或合作伙伴所使用。市场供应商显然希望这种情况发生，但是更重要的是，我们看到了一种机会—应用AJAX+SOA技术 来驱动一类新的Web 2.0业务应用程序。

第一次，人们开始感觉到应用程序开发与SOA终于走到了一起。我们拥有通过可重用形式—SOA服务—加以描述的业务功能。我们拥有无所不在的连接— Web。我们拥有正在被证明成为新的应用程序容器的浏览器。我们在这类应用程序容器/浏览器中拥有一种编程模型—JavaScript。并且它们使用的都 是开放式标准！我们还要求什么呢？其实，还有其它一些内容。

我特别希望看到一种更快的基于所有以上技术的开发应用程序的方案—一种不必再依赖于与SOA服务集成到一起的中间件即可构建应用程序的方法。这正是 我所期望的Web应用程序的能力—“直接连接SOA”。这种“直接连接SOA”应该能够穿过传统型门户屏障以及重量级进程引擎进而直接（至少在概念上如 此；稍后，我们将详及）存取SOA服务。在此，我不仅是指Web服务，它也可能是BPEL编制服务，粗粒度POJO服务，RSS回馈或任何其它能够被暴露 为一种“服务”的东西。当然，这其中的接口应该使用开放型标准暴露。

这种新式的开发和运行时刻模型创建了一种构建应用程序驱动的复合应用程序的新方法。它具有客户机/服务器类型的吸引力，而没有传统型重量级客户机/服务器所具有的沉重包袱。它运行于浏览器端并且能够依具体要求而实现。

五、基于用户的复合应用程序

在过去的几年间，我们都听说过“复合应用程序”这一概念。但是，大多数供应商却在一直谈论着“复合服务”—作为一种把他们的宿主服务重构成另一些更好用的服务或门户应用程序的方法。让我作个类比来作进一步的说明。

AcmeGrid，我们在本文中虚构的一家网格计算供应商，它提供一种服务—网格计算—能够使你的应用程序运行为一种服务。这家公司的顾客告诉它他 们想通过一个方法实现把许多服务组合成一种粗粒度的服务。因此，很自然地，AcmeGrid发布了一种基于Eclipse的AcmeGrid复合应用程序 构造器(CAB)。有趣的是，CAB看上去很象一个BPEL设计器，但是与AcmeGrid发布的服务更为紧密地集成到一起。尽管相当漂亮，但是，它并不 是一种真实的应用程序，充其量也只是一种服务。实质上，CAB更象一个服务构造器。但是，当我们在努力构建应用程序时有谁会需要一种服务构造器呢？不久， 另一家虚构的供应商，我们暂且称其为AcmePortal，宣布了它的Portal复合应用程序构造器(PCAB)。它也发行了一种基于Eclipse的 设计器；尽管它的外观感觉也象一个BPEL设计器，但是，这个程序却“知道”如何构建portal。在许多情况下，一个portal和一个应用程序有一样 好的效果。但是，如果你硬性要求把一个portal转换为一个应用程序的话，也只是徒然。

实际上，我非常想实现一种基于用户的复合应用程序，而不是一种基于中间件的复合应用程序。为此，我需要一种开发和运行时刻平台—这种平台不仅能够使 用AJAX和SOA，而且还能够对这二者进行管理。一些经销商又进一步推进了AJAX应用程序的概念—直接从浏览器中调用基于WSDL的Web服务，其实 质上是作一种SOAP调用。这种方法甚至还有一个名字—“客户端/SOA”。这对于简单的非企业或消费者应用程序而言可能是不错的，但是对于真正的企业程 序却不是这样。为什么呢？因为当你直接从浏览器端调用Web服务时，监管功能等于交给了浏览器—这简直就是说，根本不存在监管问题。图1展示了非监管的 Web服务消费框图。我还从来未遇到过一家不去监管自己的服务的企业，并且也不相信企业仅仅因为我们在技术上实现非常有效就会允许这样的事情发生。如果你 不相信我的看法，那么你只须记住企业是从来不会对除HTTP和SSL以外的应用程序开放其防火墙的。不管我们如何劝告系统主管，他们是不会开放其它端口 的。

 

图1.展示了非监管的Web服务消费框图

六、我们需要一种新型的平台

由上面可知，我们所讨论的不仅是停留在AJAX和SOA技术方面。其实，我们真正需要的是一种平台，它能够为AJAX和SOA共存于企业之中提供必 要的监管能力。这个平台还提供站在客户端角度消费SOA服务的能力，而且还能监管服务消费情况。图2展示了如何通过一个服务网关来监管Web服务。一个服 务网关实际上是一个服务端抽象，它能够代表客户端监管并调节服务存取，这在刚才我们所讨论的情况下是指基于浏览器的AJAX应用程序。使用服务网关的漂亮 之处在于，你并不被限制仅访问在企业内运行的服务。这种服务网关能够监管注册到企业内的任何服务。在基于WSDL的Web服务中，企业会注册WSDL，而 WSDL又提供在运行时刻到服务的绑定。这可能是运行在企业的数据中心的一种服务，但是它有可能与一个运行于一家合伙企业的数据中心的服务一样容易。如果 企业允许（通过监管）应用程序存取服务的话，那么，这些服务运行于何处是无关紧要的。

 

图2.监控下的Web服务消费

七、结论

读完本文，我希望你已开始欣赏起把AJAX和SOA结合到一起的强大威力来了—特别是这二者之间的共存方式以及实现新式的具有企业要求的监管能力的 基于Web服务的应用程序。我坚信，我们正在进入到一种充满令人惊异的机会的新时代的前夕。Web 2.0时代社会性网络，图片共享以及各种标注技术都是伟大的，但是真正有影响力的还在于Web 2.0对企业的响应。