服务导向架构(Service Oriented Architecture SOA)

现在的位置: 首页 > 综合 > 正文

服务导向架构(Service Oriented Architecture SOA)

2013年03月31日 ⁄ 综合 ⁄ 共 3445字 ⁄ 字号小中大 ⁄ 评论关闭

随着企业快速反应(agile)的需求与日俱增，异质型信息系统的整合与重用，确保投资等议题日益重要。信息系统不但要能彼此沟通，还要支持企业再造的重组与分合，进一步结合供应链与消费者等企业外的系统。

服务导向架构(Service Oriented Architecture SOA)应运而生。它代表着分布式松散偶合(loosely coupled)的服务，也就是系统间彼此互为服务，遵循沟通标准呼叫对方，传递 XML 讯息，但不拘平台与开发技术。

何谓服务导向架构

软件架构与方法论一直在演进，有价值的观念与做法依然持续传承着，在正式讨论 SOA 之前，我们先回顾一下历史：1980 年卷起的对象导向风潮让软件有了架构(framework)，可以重用。而 1990 的组件导向，让软件易于重用，且在分散架构下动态结合。而 2000 的服务导向可以跨平台与因特网让整个系统动态整合与重用。

而在服务导向架构下设计软件时，依然本着对象导向分析设计组件，清楚划分层次(layer)来规划与部署组件，再将服务平台架构在组件与模块的合作上。

笔者曾就何谓 SOA 广泛地询问各领域的信息从业人员，结论是众说纷纭。由于它仅是概念的集成，似乎连规范都谈不上，实做这些概念的底层技术才有一堆规范，例如 Web Services/SOAP/HTTP/XML。就笔者个人觉得，它并不是新的技术或想法，而是软件设计的理念经沉淀后，再次举起的架构。

软件架构师长久以来关心的就是如何建立一种系统架构蓝图，该架构允许可重复使用，以更松散耦合的方式工作。例如系统架构建立后要修改功能，但无需打破原有设计。又如何在流程中整合异质的信息系统。SOA 支持可重复使用的组件或服务，搭配商业流程的系统架构，这些组件或服务独立于它们执行的平台。

此波 SOA 的浪潮与以往不同的地方是众信息大厂都遵循标准组织所订立的规范，共通发表朝向 SOA 远景迈进的产品/平台/整合开发环境/软件 Framework。广泛地支持标准能帮助客户降低风险。在这种形势下建置 SOA 变得有前景。

而 SOA 主要的诉求如下：

l 系统整合与分布式架构：一般来说，服务的存取本就多是透过网络在进行，而 SOA 兴起的背景需求是整合，不管是平台、服务流程，还是供应链的整合，大都是分散在不同软硬件上的系统，透过网络串起来。

l 强调界面与松散偶合：继结构化、模块化、对象化、组件重用后，SOA 是再造的传统价值。它要求系统间清楚地的切割，标准化地设计程序接口与存取机制，服务间以讯息沟通。呼叫服务者不需要了解该服务是执行在什么平台，用什么开发技术完成的。而这些特征也就是结构化、封装(对象化)、二进制重用(组件化)等想法的延续，高内聚低偶合仍是基本精神。

l 走开放标准(Open standard)：存取服务方法与沟通协议的标准化是整合的基本，且必须是开放的标准。以往 CORBA/IIOP、COM/DCOM、Java Bean/RMI 等各擅胜场，但都是专属的协议，使得不同平台的组件无法沟通。现今的运作大都能遵循标准组织(如 W3C、OASIS、WS-I 等)的规范，让各软件平台虽底层架构与技术不同，但依然能透过标准接口藉由 Web Service/SOAP 沟通。

l 商业流程整合：在建构系统时，强调厘清商业流程，并对应到特定工作的流程，再将其切割成服务界面，开发者依据服务界面开发，整合者透过微软 BizTalk Server 等流程整合的软件平台设计软件运行流程。

开发的难易度与成熟度

软件开发本身具备着高难度，这与采用何种架构没有很大的关系，无论 SOA 为何，分析设计、切割、开发、测试、组合、项目进行都还是老问题。主要看团队成员对解决问题的经验。若单就以 SOA 架构当作指导原则，是否会增加系统开发的难度？在笔者来看初期因为观念不一致、设计没有固定 pattern、对实做技术不熟悉等情况下，一定比较难。

或许我们可以将 SOA 的推广分为几个阶段：

1. 实做服务：将个别功能需求以 Web Services 架构来实做，或是透过 Web Services 包装旧有系统。
单就这一个阶段而言，熟悉 HTTP/SOAP/XML 等技术，将功能需求化为接口/服务/组件，学习驾驭程序语言与软件开发环境，了解系统平台对 Web Services 的支持等，都是采用 Web Services 需做的额外付出。
另外，要强调的是若预期在第二阶段整合时，将与异质型技术合作，则需要尽量避免传递本身开发架构上特有的对象，如 .NET 的 DataSet 或 Java 的 Vector 等，因为对方平台无法了解这些对象的数据结构，当接到这些 XML 序列化后传递的对象，将无法反序列化成原对象。必须当成 XML 数据本身，用 XPath 语法来解析。但这是一体两面的，若不用专属软件架构，则该软件平台(如 .NET Framework)所提供的效益就大打折扣。在开发系统的功能与整合所需要的弹性间，设计者需做明智的抉择。

2. 流程整合：组合多个 Web Services，强调系统间彼此合作的稳定与正确，强化安全、交易管理、流程的弹性。
只要是跨平台、跨系统的整合，交易/安全/稳定/管理等需求的复杂性就变成两个系统的乘积，长时程的补偿式交易、单一签入…等一堆问题会冒出来。而系统间的除错会让问题雪上加霜，因为互动而直接地跨异质型平台除错几乎不可能，只有靠两个系统完备的纪录、监控与细心地判读来除错。

3. 商用服务：期待动态的服务整合。企业间签订SLA(服务级别协议 service level agreements），透过 Web Services/UDDI/WS-* 等技术进行实时地、动态地商业协同运作。
就这阶段而言，光是商务流程规范就是冗长的进程，企业间的整合有许多非信息技术的问题，而是商业利益的纠葛。若第二阶段的技术扎实，此时信息技术的问题只是扩大了规模。

SOA 本身只是个架构，无所谓成熟，但可从设计者的喜好、能力、开发软件的方便性(.NET/Java)、平台的稳定性(如 Windows 与 IIS、IBM WebShpere)、产品的支持性(BizTalk、SQL Server、DB2...)来评估成熟度。由于众家大厂的共识，并协力鼓吹其架构的优点，在操作系统与软件整合开发环境支持下，要达到上述的第 1 阶段，或第 2 阶段的需求不复杂之前提下，是容易建置与维护的。

成本与效益

单就开发系统时，遵循 SOA 的想法，将功能都用 Web Services 包装起来，初次或许会增加分析、设计的成本，这是缺乏经验所致。但并不必然需要额外购买软硬件，所以相较于传统的开发模式，SOA 在购置成本上不会有多大差异。

虽然 Web Services 所规范的都是标准化技术，你可以用任何熟悉的语言来解析 WSDL、撰写 SOAP、HTTP 协议，但事倍功半，不若用专属的 .NET 或 Java 开发环境来得便捷。若要加上自动化、弹性的流程整合，则还需 BizTalk Server 一类的软件平台。若开发团队已经熟悉 .NET 或 Java，则人力成本也与一般系统开发无异。

由于 SOA 可以提升系统的弹性与重用性，且信息系统整合后，可发挥更深更广的效用，长期而言，这两者都有可观的效益。

结论

这几年来 EAI(Enterprise Application Integration)、A2A(Application to Application)、B2Bi(Business to Business integration)、BPM(Business Process Management)…等等，其行情不断的轮动，都因为是在谈整合，需解决乘积倍增的困难而起起落落。

在 SOA 大旗之下，Microsoft、IBM、Oracle、SAP、BEA…等诸多大厂，提供了标准的执行与开发平台、沟通机制、流程整合、讯息绕送/交易管理/安全等规范。但信息系统的基本：如何满足使用者的需求，整体系统可信赖，并不会因 SOA 而有什么大幅进步，它仅是企业整合比较好的方案。