如何导入服务导向架构 SOA

　　根据摩根史旦利在2004年二月对 CIO 的 IT 预算调查 (Morgan Stanley CIO Survey)，有几个重要的讯息值得探讨，在软件预算分类中，Application Integration 是仅次于更新服务器操作系统的最重要项目，可见整合应用系统，深化商业流程自动化，将是最重要的软件开发工作。

　　在同一份调查中同时揭露 Application Outsourcing 高居信息服预算的第一位，显示信息人员必须将重点放在最高阶的信息工作上面，例如实时汇集客户信息以快速响应客户需求，设计自动化的商业流程以降低营运成本，增加信息系统商业智能以协助决策人员做正确的判断。我们需要一个稳定且具有高度整合能力的信息架构做为基础，方能达成这些高价值的工作。

　　服务导向架构 SOA 是系统整合的最佳方案

　　我们很早就了解系统整合的重要性，所以尝试了各种解决方案，并且获得一些成果。最早的解决方案是数据的整合，整合数据带来立即的好处，使用者可以快速取得所需的所有资料。但是因为企业的应用系统通常来自不同的供货商，所以整合所有的数据库非常不容易。后来的方法则是 AP-to-AP 的 EAI 整合方案，由 AP 与其它的系统沟通，取回所有需要的数据，这方法的缺点在于应用系统采用不同的通讯协议与 API，当多个系统互动时，需要的转接程序与数据转换程序大量增加，如果要与其它企业的应用系统互动，则情况变得更为复杂。服务导向架构 SOA 使用 XML 与 Web Services 为底层基础，解决通讯协议与数据沟通的问题，而且包含安全、交易、商业流程整合等等功能，使 SOA 成为最有弹性的系统整合方案。

　　服务导向架构 SOA 的特质

　　有别于传统的系统整合方案，SOA 具有几个重要的特质。第一个特质是每个服务 (Service)有一个明确的界限，其它的程序只能透过服务窗口要求服务。第二个特质是独立自主 (Autonomous)，每个服务不必倚赖其它的系统，我们独立布署服务，并且管理多重版本，别的程序不能存取服务内部的功能与数据，例如传进来的数据既不能修改，也不能退回。第三个特质是共享 Data Schema 与数据规定 (Validation Contract)，因为每个服务使用的内部数据格式不一定相同，所以不可以传递对象，而且数据必须符合规定，Text Format Data 是以前常用的方法，现在 XML 则是最佳选择。第四个特质是运用 Policy，SOA 使用 policy 设计连接端口规定、数据规定、功能规定、安全规定等等，并且协调服务之间的互动流程。

　　导入服务导向架构 SOA 的策略

　　导入服务导向架构 SOA 的最佳策略是与现有的系统共存，而不是替换已经运行中的系统，例如 EDI 系统已经广泛地运行于全球前 10,000 大企业的电子式交易，RosettaNET 是最成功的信息电子 &半导体产业的供应链系统。但是全球仍有数量庞大的中小企业与难以估计的终端系统 (End User Devices)，它们皆希望以便利、低成本的方式与其它系统进行 AP-to-AP 的整合运算，所以为现行系统提供 Web Services 将是最佳的扩展策略。

　　导入服务导向架构 SOA 的最佳实务 (Best Pracrtices)

　　?导入服务导向架构必须有整体的规划，确实执行每个步骤，方能克服障碍，确保成功，下列是为一些宝贵的经验法则，对导入 SOA 有相当大的帮助。

　　?制定统一的 Data Schema(Canonical Schema)：例如原来的 Customer 数据在 ERP 与 CRM 系统有不同的格式，在 SOA 中必须有统一的 Schema。

　　?延伸 Legacy System：使用 Web services 把 Legacy System 包装起来提供开放的服务，是一种不错的选择。

　　?建立管理服务的机制：包括布署、监控、量测、Routing 等等。

　　?汇集服务 (Orchestrate services)：如果汇集一些互动服务可以具有商务意义，则可提供汇集服务给客户使用，通常对应 User Task 且具有 Business Transaction 特性。

　　?使用可靠的讯息传输机制：例如使用 Message Queue 比使用 TCP/IP 的 Socket 较稳定。

　　按 Internet/Intranet 的不同，采用适当的身份识别系统与安全机制。

　　?采用 Services Interface、Services Facade、Services Implementation 三层架构，提高 Services 的弹性。