关于SOA架构的七个关键性问题的解答

 

对于SOA，尤其是像开发人员和CIO等仍有若干关键问题需要回答。

Web 服务以及越来越多的面向服务架构（Service Oriented Architecture，SOA）已经在市场上投放了大量广告。两者都可以给企业带来广泛的短期和长期利益。但对于SOA，尤其是像开发人员和CIO等仍有若干关键问题需要回答。

问：SOA的前提是能够使应用程序像服务那样工作。软件如何像服务一样工作呢？

答：没有SOA，软件包是被编写为独立的（self-contained）软件，即在一个完整的软件包中将许多应用程序功能整合在一起。实现整合应用程序功能的代码通常与功能本身的代码混合在一起。我们将这种方式称作软件设计"单一应用程序"。与此密切相关的是，更改一部分代码将对使用该代码的代码具有重大影响，这会造成系统的复杂性，并增加维护系统的成本。而且还使重新使用应用程序功能变得较困难，因为这些功能不是为了重新使用而打的包。

SOA旨在将单个应用程序功能彼此分开，以便这些功能可以单独用作单个的应用程序功能或"组件"。这些组件可以用于在企业内部创建各种其他的应用程序，或者如有需要，对外向合作伙伴公开，以便用于合作伙伴的应用程序。

"服务"的概念是要使用与实施细节无关的标准化接口来构建这些"组件"。针对一套应用程序服务的Web服务描述语言文档，描述需要作为请求特殊服务（例如，"检查库存"功能可能需要零件数）输入来传输的数据名称和类型，并描述服务响应的细节（它可能返回表示库存中零件数量的一个整数）。

这些详细信息看上去好像与 Java、C++、COBOL 等中实施的功能相同，因此，服务的请求程序无需知道使用的何种语言，而且可以使用任何语言来编写请求程序。这就使一个平台上的服务可以和为另一个平台编写的应用程序集成。互操作性的关键是请求和响应消息，例如，使用SOAP消息发送，其消息使用 XML 编写代码。

问：请举例说明 SOA 如何使企业受益。

答：关键的优势是互操作性，可以使用任何平台之间的功能，而与编程的语言、操作系统和计算机类型等等无关。在上述示例中，"检查库存"功能可能已经编写为一个应用程序要求的服务，例如，监控库存并在需要时自动重新定购的服务，但我们后来发现，同样的服务无需修改即可用于支持由员工使用的基于 Web 的库存监控工具。

就内部而言，应用程序的重复使用是一项关键优势，因为它可以降低开发成本。服务的重复使用，其长期作用在于减少企业中冗余的功能，简化基础架构，从而降低维护代码的成本。通过按服务的使用者来组织应用程序，与传统的编程技术相比，我们获得一个要灵活敏捷得多的集成模型，使我们可以迅速修改业务流程模型。

就外部而言，为服务交互而详细定义的"合同"使业务合作伙伴之间的交互"自由联合"，提供集成所必需的稳定性，并提供更改基层软件（underlying software）问题的一个解决方案。当保留了相同的消息格式时，支持该格式的软件只要仍然支持消息合同，则可以按需进行更改。只要它支持相同的消息格式，甚至可以使用另一种编程语言的实施来完全替换系统，请求程序无需更改。当消息合同不断发展而必须更改时，与相当困难的任务，即支持多个版本的程序 API 和文件格式相比，它使用版本控制（versioning），更容易作为过渡策略支持多个版本的应用程序。

这些是部分关键益处，还有许多其他益处。

问：SOA与Web服务以及SOA和网格计算之间是何关系。

答：SOA是一种面向业务应用程序系统的体系架构设计风格，但可以应用于其他系统，包括中间件技术，例如网格计算。

Web服务是可以用于创建SOA的一套标准。尽管没有Web服务标准也可能创建SOA（例如，在SOAP之前，人们已经在HTTP或JMS上使用XML来实现相似的结果），但运用Web服务标准却是我们目前针对与外部软件交互的最佳方法。

网格计算是一种系统管理策略，其目标是最大限度地减少硬件资源的使用。例如，当突然的需求溢出指定的服务器时，它可能临时将一些请求转向相对没那么繁忙的服务器。网格计算设计为一种面向服务架构（用于调整网格计算的服务叫做网格服务）。

随着我们转向SOA，我们将看到该方法用于支持各种其他新的系统功能。另外一个示例是自主计算伙子管理系统。事实上，SOA是Web服务高级功能的基础，例如WS-Trust和联合身份识别管理规范。

问：因为还没有通用互操作性标准，SOA最大的问题不仍然是供应商中心性（vendor-centricity）吗？

答：有一些基本标准正好适用于Web服务，它们可以用于实施面向服务架构。XML和XML方案分别自1998年和2001年就已成为标准。SOAP 1.2自2003年6月成为标准。UDDI在2003年夏天标准化。WS-Security在2004年4月成为标准。

除了著名标准机构（例如W3C和OASIS）支持的这些正式标准以外，许多"技术建议书规范"也被广泛接受，并作为事实标准得到充分支持。例如，直到 W3C完成WSDL 2.0为止，要求在其产品中支持Web服务的大多数供应商都支持WSDL 1.1规范。

事实上，目前大部分软件供应商对Web服务标准的支持，已导致使用Web服务来广泛实施SOA。

问：SOA如何影响SLA？而您如何让SLA适合您的SOA？

答：当前企业之间的SOA实施通常侧重于改善合作伙伴之间现有业务的效率。同样，性能保证的概念并不是像方便的互操作性和自由联合集成那样的问题，它们可以借助Web服务标准来实现。

当服务成为企业付费的产品时，对特定水平的性能或可用性的保证，以及其它服务质量注意事项具有更为重要的作用。我们可以想象这在将来会成为一个常见要求，正在进行这方面的工作以支持该模型。

 

问：我如何着手构建 SOA？

答：最佳的方法时开始构建较小的SOA，侧重于提高当前缺乏效率的交互性。例如，假设使用一个系统上需要重新键入到另一个系统的打印报告，将两个计算机系统紧密联系在一起，这会消耗时间、浪费成本，导致出错，而且数据无法保持罪行。可以设计一个简单的基于Web服务SOA项目，直接链接信息，将含更新的SOAP消息发送到合作伙伴系统，而不是打印报告。

开始简单的SOA使企业可以在作出大投资之前先衡量ROI，并在出现大的问题之前获得小改善的经验。

CIO在购买软件时应该询问供应商关于对Web服务和SOA的支持，作为一个重要的注意事项。应该检查新应用程序的开发，以便考虑是否某些应用程序功能可能需要用于其他目的，以及可以嵌入对Web服务标准的支持以支持重复使用。

最终要完成大规模的企业转型，可能需要通过建立企业服务总线（形成SOA的骨干网或神经系统）来开始该工作。然后以企业合理的节奏，将服务提供商何服务请求程序逐渐添加到ESB。随着IT的SOA的增长，ESB成为在服务水平上连接应用程序，并调节消息流量以提高效率和可靠性的一种有力方式。

问：管理SOA需要哪些新的服务管理技能？

答：在运用Web服务之前，因缺乏标准和自由联合的策略，合作伙伴整合受到严重限制。随着我们开始使用Web服务和SOA来整合合作伙伴，我们可以发现，使用业务合作伙伴所提供的功能的IT系统已经开始依赖于这些功能的可用性。我们从内部管理我们自己服务的可用性转向要求监视和管理（可能有许多）企业之间的可用性。这明显大大增加了管理IT系统的复杂性，但它也带来了巨大的价值，这就是为什么许多企业要转到这个方向的原因。

Web应用程序系统正在不断发展以支持Web服务标准。"Web服务分布式管理"或WSDM标准正在由OASIS开发，对Web服务管理提供标准化的支持，通过使用Web服务来实现对不同平台的管理，满足涉及独立业务实体的大规模SOA对分布式管理的要求。