全面的、可伸缩的SOA vs.简单可行的SOA建设模式

申请免费试用、咨询电话：400-8352-114

        每个企业都必须在全面的、可伸缩的SOA与简单可行的SOA建设模式之间找到适合自己的平衡点。
        几年前，由Web服务引发的到今天以SOA（面向服务的架构）形式继续着的狂潮下面出现了一条断层。是的，几乎所有人都认为基于XML的消息技术是实现平台中立的、可以整合到支持企业业务功能的高层服务的正确途径。但是，人们还感到技术规范的标准化过程失去了控制。
        IBM、Microsoft以及其他厂商提出了那么多的Web服务标准，以致不得不发明一个新的集合名词：WS-*。星号是通配符，可以表示“地址”、“事件”、“路由”、“可靠性”、“ReliableMessaging（可靠消息传递通信协议）”、“安全会话”、“安全性”、“交易”、“信任”以及其他多得吓人的术语。经过一番调查，XML的共同发明人Tim Bray断言，“WS-*臃肿、不透明并且非常复杂”。

争议背后的两大阵营
        有人说WS-*是套在马前面的车子—本末倒置了。这种理论认为，重量级厂商与关键客户和合作伙伴密切合作，将一些Web服务规范的复杂性提升到了只有他们才能维持的程度。由于这些规范大大超前于大多数用户目前的需要，因此，它们的发展一直没有得到有效地推动。
        OASIS是目前负责协调众多WS-*规范的标准组织。该组织主席兼CEO Patrick Gannon不情愿地承认说，从一开始就应当让用户参与。他说：“由于没有提出正式的用户需求，我没有参与这些规范的开发工作。不过，我是个实用主义者，规范已经制定了。”
        然而，情况并不总是如此。简单形式的XML消息早在这些标准问世之前很久就取得了成功。Metratech CTO Jim Culbert讲述了其公司的面向服务的计费系统在90年代末是如何运行的。合作伙伴之间交换的消息采用XML格式，并利用具有SSL加密功能的HTTP传输——目前，这种方法仍用于大多数安全的Web服务通信中。
        Seybold分析师Brenda Michelson当年是L.L. Bean首席设计师。他讲述了有关这家公司使用Web服务的早期体验，其经验与Metratech公司类似。当时有两个因素非常突出。首先，Web服务提供一种简单的、无处不在的集成框架，这种框架以后被提升到架构的高度并被打上了REST（表现性状态传输）的标记。其次，XML提供了一种定义服务的通用方式，从它们产生或消费的数据的角度，而非从产生或消费数据的编程的角度来定义服务。这两个因素的结合曾是——现在仍然是强大的推动力。
        对于WS-*的另一种观点认为，那些已经在安全性、事务处理和可靠通信方面付出成本的业界重量级厂商，的确有资格将他们在这些问题上的经验转化为XML语言。RouteOne公司技术总监TN Subramaniam曾经有过痛苦的经历。当时，他准备拟定他自己的单一登录规范，结果在他发现SAML（安全断言标记语言）时放弃自己的规范。他的投资方合作伙伴狂热地采用了SAML，因为所有身份管理厂商（包括Netegrity和Oblix）都支持SAML。
        Subramaniam问道：“让5位每隔一天开一次会的设计师来解决各种分歧，还是建立一个所有厂商都参加的委员会来详尽地考虑所有问题，两种方法谁优谁劣呢？”
        人们不禁会将这两种观点之间的紧张关系解释为WS-Heavy与WS-Lite的不同，在这两个阵营中，WS-Heavy意味着WS-*声称提供的安全性、可靠性和可伸缩性，比较而言，WS-Heavy像一个庄重的大教堂，而WS-Lite意味着吸引着REST、AJAX和RSS等标志的速度、简单性和灵活性，WS-Lite更像是一个集贸市场。但是，本文所采访过的企业设计师中没有一位承诺效忠于某个阵营。下面是五个企业根据自己的需要来实现SOA的例子，他们都是实用主义者，会去做完成工作所需要的任何事情，因此了解他们如何使用（以及不使用）Web服务标准是具有指导意义的。

RouteOne：有效的信用检查
        虽然端到端的SSL常常足以满足需要了，而且这样做足够轻巧，但RouteOne公司的Subramaniam出于两个理由更喜欢WS-Security提供的更细粒度的方法。
        RouteOne是一家通过网络为汽车经销商提供汽车信贷申请服务的公司，RouteOne公司一方面吸引了众多的汽车经销商，另一端则与几家金融公司联网（见图1）。



        在汽车信贷的申请过程中，首先，需要对信用申请书进行数字签名，并且需要根据服务合作伙伴理解的规则去做这件事。WS-Security定义了这类规则，尽管无可否认的是这样做会导致规则太多。一种方法是将签了名的申请放到SOAP消息中，另一种办法是利用带有附件的SOAP。但是，RouteOne的不同合作伙伴之间没有达成一致，因此RouteOne同时使用上述两种方法。这让人感到沮丧，但是Subramamian宁愿有两种规则，也不愿意没有规则。 
        第二个理由涉及一项激励设计WS-*的深层次原则：无处不在的仲裁（intermediation）。RouteOne被要求保存详细的审计日志，但是希望不必加密所有的日志。因此，它使用DataPower的XML加速器，有选择地只加密像工资总额和社会保险号等敏感条目。由于这是基于标准的仲裁系统，DataPower设备可以直接以这种方式修改RouteOne的XML消息传输流。
        当服务直接通信时，没有必要定义实现服务仲裁的约定规则。目前，最引人注目使用WS-Lite的典范——Amazon和eBay——以点对点的方式使用Web服务。在这种模式下，SOAP/WSDL应用程序接口与REST 应用程序接口之间没有太大的差别，因此使用这些平台的绝大多数的开发人员喜欢REST风格也就并不奇怪了。不过，当你的确需要让你的XML传输流经过仲裁系统时，SOAP和WSDL突然成为了更合理的选择。
        不过，Subramaniam是一位实用主义者。普通的XML over HTTP（没有WSDL）也在RouteOne的内部和外部事务中发挥着作用。由于在内部的遗留系统上安装一个小服务程序接口并通过它提取XML数据是一件谁都不会反对的事，因此，这种战略被应用于各种合适的地方。一些RouteOne公司的外部合作伙伴使用同样的方法，并且由于“他们这样做可以毫不费力地赚钱”，所以Subramaniam不可能要求使用其他方法。相反，RouteOne将输入传输流变为SOAP和WSDL格式，以支持未来将BPEL（业务流程执行语言）用于业务创新时的流程编排。目前，没有提供SOAP和WSDL接口的合作伙伴在竞争上并没有处于劣势。不过，竞争的天秤可能不久就会倾斜。
        RouteOne依靠SAML和WS-Security。而Subramaniam希望他也可以使用标准格式的可靠的消息技术。他说：“如果我不发送消息，我们就会损失金钱。”受ebXML（电子商务XML）和JMS（Java消息服务）的启发，他现在与合作伙伴一起使用一种能够保证有序的、可靠地提交消息的方案。不过，他希望OASIS在整合它现在管理的两项规范，WS-Reliability和WS-ReliableMessaging时取得成功。Subramaniam说：“这种重复非常非常糟。我希望有一个通用规范，这样我可以抛弃我自己的东西，使用这个通用规范。”

Corillian：点对点的简单性
        据Corillian公司首席设计师Scott Hanselman说，很多面向服务的系统不要求可靠的消息技术，而他的公司的银行业中间件就属于这类服务系统。
        Hanselman 说，Corillian的产品，即所谓的Voyager，处理由25％的在线银行用户间接使用的服务。“但是，他们惟一关心的交易是主机上的交易。”因此，他并不操心WS-Reliability与WS-ReliableMessaging的合并。尽管他没有使用WS-Security，但他认为SSL在大多数情况下同样有效。他承认，这种方法将路由器和仲裁系统排除在外，“但是我很少使用它们，因为10次中有9次我们进行点对点消息通信。”
        他也瞧不上UDDI。UDDI是一种倍受指责的标准，用于发布Web服务目录。至于那种认为黄页中找不到的服务就不能被重用的论点，Hanselman并不买账。他说，找到服务实际上并不是开发人员的问题。方便有效地使用它们才是开发人员的问题。
        当然，WSDL也受到了它所应当受到的批评。RouteOne的Subramaniam认为，WSDL 1.1的“愚蠢的”复杂性，使它成为限制SOA的镣铐，他希望“更加干净的”WSDL 2.0能减轻这种负担。Hanselman说，也许是这样，但是“你不可能不使用WSDL 1.1。”数百万Web服务是利用WSDL 1.1进行的，而且这种情况将持续很长一段时间。利用WSDL 1.1，Corillian通过在Voyager的核心说明对象、消息和服务，并将这些说明与不使用XML的内部机制绑在一起。当需要增长时，公司创建了替代的捆绑，使客户可以通过一个Web服务镜头看到引擎。Hanselman认为，如果WSDL 1.1是一种80％的解决方案的话，那么WSDL 2.0可能是90％的解决方案，但是它们谁都不能提供至关重要的方法。

医学中心：数据实时传送
        得到最广泛采用的高级Web服务标准显然是WS-Security。除此之外，很难找到与WS动物园中更奇异的野兽相处过的实践者了，不过，Furrukh Khan讲述了有关他从基本Web服务向高级Web服务迁移过程中引人入胜的故事。Khan在俄亥俄州立大学医学中心工程与医药学院任职，全面负责医学中心的IT工作。
        在这个环境中，来自监测仪器的病人状态数据被记录到数据库中，并且同时传送给智能客户端。客户端程序观察、分析并注释数据流。数据流必须安全可靠近实时地提供给很多的客户端。
        早期部署基于Microsoft的WSE（Web服务扩展），采用了WS-Policy。WS-Policy还没有在标准组织中找到安身之处，但可能不久会找到的。WS-Policy被用于说明登录后端数据库的认证方法（例如，要求规定密钥签署的X.509证书）以及解释所要求的有效载荷签名和加密算法。

 现在，医学中心的系统部署基于Beta版的Microsoft Indigo（一种高级Web服务协议群的Windows实现），使用WS-ReliableMessaging来保证有序、可靠地提供信息。它还使用WS-SecureConversation来优化传送高容量数据流的安全可靠的通道（见图2）。



        Khan解释说，光靠在WS-Policy协助下的WS-Security不能维持近实时的传输流。这个需要频繁与身份管理系统交换证书的协议太爱讲话。实现证书缓存的WS-SecureConversation优化了这项协议。此外，依靠Indigo对WS-ReliableMessaging的支持，能够实现一种特性使路由器可以帮助建立两个终端之间的连接，然后从中抽身不再参与。所有这些带来了巨大的扩展性。
        Khan说：“以前在使用WSE时，每台路由器都将我们限制在300个客户端上。” 他补充说，Indigo可以支持每路由器638个客户端，并且经过优化，运行在路由器后面的每个服务都支持那么多的客户端。他说：“因此如果你不断增加服务，它可以线性的扩展。”该系统目前支持1000多个客户端，所有的客户端每隔30秒就能同时观察病人状态数据。
        在回忆从WSE向Indigo迁移的经历时，Khan符和Scott Hanselman关于将开发人员与XML隔离的观点。
        他说，WSE处理基本的场景，但是除此之外，“我们不得不编写WSE程序。”由于Indigo的更高的抽象水平，这个问题消失了。
        从更大的范围看，Indigo使一个更困难的问题（即在平台原有的服务和传输技术配合下恰当地使用Web服务）迎刃而解。Khan说：“在Microsoft领域中，企业服务与Web服务完全不同，MSMQ生活在自己的世界中，而XML有它自己的工具包。”不同的团队成员必须是不同学科的专家，没人能掌握所有的东西。

Providence：复用而非复制
        Providence的医疗系统部署成为典型的两层SOA来支持其临床业务与办公应用，以及医生与患者的门户。一组对应于业务流程的粗粒度的服务是由另一组更基本的服务组织而成的。虽然使用了一些高级标准，如WS-Security，但是Providence没有直接与它们打交道。Providence负责开发的副总裁Reagin说：“我们依靠厂商的安全技术实现。”本案中的厂商是Infravio公司。该公司的Web服务管理系统为Providence部署和管理服务提供了框架。
        Infravio实现了UDDI，但Reagin说，由于使用的服务比较少，目录查找并不那么重要。但是，宣布和执行控制这些服务的使用政策非常重要，监测服务活动也很重要。
        在Infravio的模型中，服务被配置成以每一对生产者和消费为单位，每一对生产者和消费者都由合同来管理。例如，主患者索引是医生和患者门户都使用的通用服务，但使用方法略有不同。出现在患者门户中的患者的健康计划成员号必须从医生门户中删除。通过为不同的消费者创建不同的WSDL接口，Infravio使通用服务可以被重复使用，而不是复制。这种变化是通过一种说明方式实现的，而不是通过编写程序实现的。
        目前，Providence的SOA部署基本上是内部的。服务支持对外的门户，但还没有直接暴露给合作伙伴。不过，这一天将会到来，Reagin对此十分肯定。当这一天到来时，他预期使用的核心标准SOAP和WSDL将实现更多的高级功能：编排、可靠的消息、策略管理的安全性以及审计。WS-*的哪些部分将实现这些功能？Reagin没有为这个问题去伤脑筋。到时候，他将购买—而不是开发所需要的基础设施。

PGP：安全与协作并重
        安全性和可靠的消息技术是Pfizer Global Pharmaceuticals (PGP)集团的关键要求。在Blue Titan的Network Director的帮助下，这家制药巨头的SOA部署满足了这些要求。Network Director管理PGP企业中的Web服务传输流。
        在安全性方面，Blue Titan的“结构”（fabric）执行一项策略。根据这项策略，请求被传送到DataPower仲裁系统进行遵从性审计，然后再传送到Oblix系统进行认证。PGP应用架构主管Martin Brodbeck将WS-Security视为完成这些活动的集成框架。虽然他没有直接接触相关标准（如WS-Policy或WS-Trust），但Blue Titan事实上的确支持它们（见图3）。



        除了安全性外，可靠的消息技术也是PGP关心的关键问题。在市场上有各种各样的面向消息的中间件，并且其中一些还有多种版本（如JMS）的情况下，公司看上了Network Director RM的隐藏差别的能力。虽然该产品对WS-ReliableMessaging的支持不够合适，但PGP正在评估Indigo。Brodbeck说：“Blue Titan在Indigo的配合下，将使RM可靠消息传递的功能非常易于使用。”
        Brodbeck向重要标准（如WS-Security和WS-ReliableMessaging）的小名单添加了RSS。RSS是非常流行的网志联合发布（Weblog syndication）格式。PGP将这种WS-Lite变种视为战略性技术可能让你感到惊讶，可是，如果你想一想协作和知识管理将如何推动一家像PGP这样的企业的总收入的增加，也就不奇怪了。不过，PGP设想的不是那种普通的网志软件。PGP全球应用与架构副总裁Richard Lynn说：“我们必须对RSS重新语境化（recontextualize），使它适用于我们的企业。”
        PGP的要求包括虚拟化RSS输入，使它们独立于硬编码地址，从而聚合它们提供特殊的业务功能，并利用控制已有Web服务的同样类型的说明性策略来保护它们。据Blue Titan创建人、CEO Frank Martinez说，Network Director即将推出的新版本将满足这些要求，扩展该产品的在WS-Lite协议周围包裹上一层WS-Heavy基础设施的能力。

Heavy、Lite还是其他？
        当你把WS-*群当做一个整体时，你必然得出这样的结论——批评者是对的 : 它的确是一只怪物。驯服这只怪物需要一种统一的概念框架。这正是Gannon、Khan和Subramaniam以不同方式表达的观点。Gannon提到由OASIS制定一系列蓝图和参考模型。这些文件旨在帮助设计师了解不同的WS-*规范（这些规范被设计为模块化构件）如何组合在一起，来解决具体的问题。对于医学中心的Khan来说，这不只是蓝图问题。他需要一种能够克服复杂性的工具包，并认为Indigo将成为这种工具包。
        RouteOne的Subramaniam希望最近一个叫做JBI (Java业务集成)的项目能成为Java世界中实现统一的力量。他们Web服务的困难之处“是你必须看到整个图画——WSDL、SOAP以及WS-Security的相关部分和BPEL。”他盼望SeeBeyond（最近被Sun Microsystems收购）和WebMethods等厂商支持JBI。他说：“当你能够看到所有这些东西如何拼在一起构成一幅JBI的大画面时，一个非常美好的基础设施就诞生了。”
        当然，工具包和框架也是双刃剑。甚至在网络协议成为标准并且开放时，你仍会将注意力过多地放在细节上。这正是为什么实用主义的设计者和还不需要高级WS-*特性的开发人员通常关注基本的规范（SOAP和WSDL）的原因。Subramaniam问道：“如果你需要某种外壳的话，为什么不使用SOAP？如果你必须准确地描述你的接口的话，为何不使用WSDL？”
        对于Grossman和其他人来说，重要的是利用SOAP和WSDL在正式的契约与灵活的互操作性之间取得平衡，同时为未来使用更高级的SOA特性打下基础。PGP的Brodbeck认为WSDL是实现可重用事务处理和流程的关键因素。不过，他还把RSS加入到体系中来。其实，惟一真正重要的规范是适合你的规范。

编看编想：SOA的互动
        SOA的实施与一般的项目不同的地方之一，就是SOA所涉及的规范很多，但规范本身又很宽泛，给参与项目的实施者提供了很大的空间。
        当然，现在已经不用从零开始，因为已经有许多厂商在基于SOA的理念和Web服务的基本框架下制定了相关的规范。值得庆幸的是，有规范总比没有好，因为没有规范其实可以理解为有无穷多的规范，让你无所适从。在正文中提到的RouteOne公司的原则非常有效，宁愿有两种规则，也不愿意没有规则。
        厂商在提出自己所倡导的规范时也会提供相应的产品，并影响相关的厂商支持该规范，那么这种规范和产品就是有相当生命力的，应该可以成为用户的备选方案。
        如果把众多的规范划分为WS-Heavy与WS-Lite两大阵营的话，那么用户在选择SOA的方案时就有了一个大致的原则，如果倾向于灵活、简捷的风格，就从WS-Lite中入手，如果强调安全可靠，WS-Heavy则是不可少的着眼点。但WS-Heavy与WS-Lite这种划分法只是一个粗略的框图，可以为企业用户构建SOA提供一个迅速入门的分类，但如果只以规范为核心来实施SOA，那么必然会受制于规范的不完善和产品的限制。
        不管规范如何庞杂，产品如何繁多，但最终目的只有一个——实现业务目标。因此，应用才是SOA的核心，围绕应用来选择相关的规范和确定物理实现的产品才能保证不偏离大方向。正文中PGP集团的作法就是一个不错的例子，既强调安全认证，同时又构建了RSS这种WS-Lite技术，因为PGP集团的业务发展中离不开安全与协作两大因素，是应用的需要融合了规范上的区别。所以说，SOA的实施是一个应用与技术规范、产品三位一体的互动过程。(CCW)