「服务导向架构」（Service-Oriented Architecture；SOA）透过定义明确、自给自足、可在计算机网络上随处呼叫的服务组件，建立企业流程与应用程序。SOA架构可提供前所未有的商业效益，不但软件功能可以重复使用，而且商业流程精确有效，亦容易彼此搭配使用维护。这些潜在效益，使SOA在企业应用上炙手可热。服务组件的组织架构，对于SOA系统的质量有重大影响。因此，如何架构SOA的基础服务组件，协助开发人员设计一套有用的SOA服务，便是相当重要的课题。

在服务导向架构（SOA）中，一个服务乃是指服务提供商所执行的一个工作单元，以达到一个或多个服务消费者所预期的结果。每个服务提供定义明确、自给自足的功能，采取例如与执行环境之间松散耦合的方式。这个功能完全透过接口契约与行为属性来描述，隐藏实际建构方式，在网络上随处可用。

SOA的基本要件包括服务提供商、服务储存库、服务中介者、服务消费者等等，都以服务规格定义（service definition）作为描述、存取、传输、了解各项服务的要素。

转换企业架构型态的现代SOA逐渐崭露头角，关于服务发掘与服务设计的方针也逐渐成型。在这个SOA逐渐成熟的阶段，一些重要SOA建构方式的概念与实务经验相当值得注意。关于服务设计的各个层面，我们将探讨一些通用的软件工程理念与考虑点，以落实SOA的关键层面为重点，例如如何建立商务的归属、如何发掘及设计服务内容、以及如何实现SOA企业架构转型工程。

我们以国际物流服务供货商──德国邮政公司广泛采用SOA的实务经验为例。德国邮政公司的SOA架构以商务为重心，该公司建立了多个SOA流程与方法，将SOA的潜在效益付诸实现。此外，该公司还采用一套相当精细的企业级服务平台，称为SOPware（服务导向平台），这套平台以甲骨文（Oracle）的Fusion Middleware Suite为主，提供商务服务中介所需的支持架构。如此一来，各个业务部门不需要担心服务建构与供应的技术细节，而能轻松快速地组合高阶商务服务与流程。

起跑点：服务发掘（Service Discovery）与套件管理（Portfolio Management）

商务服务与技术服务之异同

SOA架构的主要特色，在于能透过商务推动IT发展，又能透过更具弹性的IT来提升商务运作。虽然SOA的基本概念能用来建立更有效率的IT运作，但SOA更大的优点在于能让业务营运快速建立高竞争力的商务应用软件，并使这些软件能经得起环境变迁的考验。相较之下，技术服务通常内含于商务服务的支持架构中。虽然这些技术服务也相当重要，但一套良好的SOA建构体系应该明确划分商务服务以及技术服务的区别。

为了完全发挥SOA的转型效益，商务人员应该负责找出商务服务的适用范围，并描述这些商务服务的特性。包含德国邮政公司在内的多家企业，都采用商务领域（business domain）的概念来建立商务归属。

建立SOA之商务归属（Business Ownership）

为了建立一套共通的语言，让商务人员与IT人员能藉此讨论相关服务、界定商务服务的归属，我们应该先检视商务营运的基本结构与相互关系 。首先，将一家公司的商务范围划分为多个商务领域，每个商务领域都内含紧密相关的功能与数据，例如可划分为客户、产品、合约等领域。为了设计出最佳的领域划分方式，发挥长期的稳定性效益，并在各层面建立扎实的SOA根基，我们必须先了解这家公司的经营方式，如(图一)所示。

《图一 简化的高阶商务领域基本架构示意图》

德国邮政公司的实务经验显示，判定主要的商业对象以及彼此的相互关系，是建立领域架构的重要第一步，接下来可以更深入分析各个商务流程以及彼此的互动关系，建立更精确的领域规格，以及某些主要领域中的次领域。领域架构应该和实际商务情境以及未来可能的商务情境加以比对，以检查领域架构是否扎实。

设计商务领域必须对业务有深入的了解，同时也需要仰赖某些直觉。就以「客户」与「客户关系」两个领域来说，第一个领域主要管理其他领域所需的主要客户数据，而第二个领域则追踪长期客户关系的各个层面。如果仔细分析基本的业务关系，可发现两者其实有基本的差异。客户领域提供的信息，变动频率不高，但需要提供一个客户各层面的360°视角，而且客户数据的使用方式，在大多数领域都相当近似。相较之下，客户关系领域所提供的功能则有相当多的变异，而且变更频率颇高。只要客户与该公司有新的交易，或是该公司的CRM策略有所演变，都会使客户关系领域产生变化。除此之外，负责客户关系的商务人员，使用这些信息的方式也各不相同，例如有些人将其应用于实时交叉销售（real-time cross-selling）；有些人则使用这些信息来提供更佳的客户服务。

另一重要考虑则是，如果要使用SOA转变整个企业IT架构，商务人员必须对商务架构有所归属，该业务的归属者同时也需负责定义商务领域的范围，并负责提供意见，判断该业务领域该提供哪些业务服务，以及该领域需要哪些服务（所需服务则由其他领域提供）。这样的做法可以建立一套整体的商务及IT规范，包含数据归属的明确定义。在德国邮政公司，来自商务IT机构的企业架构工程师与服务设计师，可协助商务归属者敲定服务的细节，但最终的责任还是要由商务人员来负担，如（图二）所示。

《图二 商务服务架构作为流程与应用间的抽象层示意图》

商务领域以及商务服务，可形成企业流程架构与应用架构之间的一个抽象层，其效益相当明显：透过领域与相关服务的概念，将流程与应用程序拆解开之后，变迁周期就可以各自独立管理。IT系统（包括应用层与基础架构层）可以变更或替换，只要服务合约保持稳定，就不会影响商务流程。反过来说，如果许多建构组件（商务服务）已经就位，可供重复使用时，商务流程就可以相当轻松地变更或扩充。

服务发掘（Service Discovery）

虽然在某些方面，服务与组件相当类似，但服务也类似小型的应用程序，需要以管理应用程序的类似方式加以管理。如（图三）所示：德国邮政公司制定了五个服务设计流程，提供服务套件的建构与改进基础。这些流程也可广泛应用于任何其他产业。

《图三 服务设计流程示意图》

要建立与管理一套商务服务套件，第一步先要进行服务的发掘。为了找出一个商业领域应该提供哪些服务，首先要调查全部的商业对象与其相互关系。商业对象（例如客户、发票、住址等等）并不是IT对象，商业对象是业务营运所需的要件，完全以商业词汇加以叙述，不牵涉任何IT系统的细节。例如「客户」领域的一项重要服务可能是Customer Information（客户信息），而这项商务服务的基本操作方式可能是「建立、读取、更新、删除」等类型，但这个领域也可能有更复杂的功能，需要结合数个基本的服务运作，例如客户领域可能包含一个Customer Address Consistency（客户地址一致性）服务，可以检查客户数据是否存在、检查客户的正确名称，并检验（甚至更正）客户的地址。其它还可能需要的服务，可透过主要商业对象的特定组合而得知（例如合约与相关的发票）。

这种由上而下的服务发掘，可以再搭配两种额外的方式。第一种是追踪商务流程、追查这些流程与商务环境之间的主要互动方式，然后将类似的功能集合起来。这种方式有助于发掘实用性服务，这是单以由上而下方法所容易忽略的。这种商务流程导向的方式，可有效检查服务的完整性，并显示特定服务的重复使用性，但运用这种方式时也需要小心：不同的商务流程（尤其是不同商务人员所制定的流程）常会用不同的语意来表达相同（或近似）的概念。要使服务套件合乎实用，一项重要条件就是要对商务词汇的语意进行透彻而严格的分析（包含商务词汇的翻译与协调）。值得注意的一点是，如果单用这种方式，常可能造成服务的定义过于微细琐碎。

除此之外，也可以透过用途导向的服务发掘方式，来寻找有哪些IT基础架构应用程序（例如大型主机或旧型应用程序）的功能和数据；至今仍有商务应用程序在使用当中，然后将这些程序外加服务接口的包装，在未来的商务应用程序中继续使用这些服务。虽然这种由下而上的方式可以搭配其他两种服务发掘方式，但由于各服务之间的语意缺乏协调，因此这种方式无法带动长远的SOA转型，只能用于诸如在行政环境中证明SOA一般性运作的阶段。

在服务发掘过程一开始，可先投资小量的成本，结合上述的各种方法，建立一些概念性的服务（例如只有规格，没有实际建构内容），然后逐步进行服务的实际建构，严格遵守每个项目的商务优先度与商务案例。因此，商务分析师以及企业商务架构工程师，在整个商务服务发掘的过程中，就扮演相当重要的角色。

实现改革：透过SOA转变企业架构

建构服务套件

德国邮政公司的服务发掘过程，产生了将近100个候选的商务服务（每个服务平均有五到十个操作功能），这些服务根据商务价值、重复运用性、IT复杂度降低能力等因素排定优先级。这些候选服务可做为后续服务套件管理过程的基础，让服务的定义更为妥善，并带动特定服务的细节规格、建构方式、重复使用与生命周期管理。

在建立整个服务套件的过程中，有许多重大问题需要解决，例如服务的归属、建构与维护这些服务的资金来源、生命周期的管理等等。究竟应特别注重SOA服务，或特别注重项目的执行，两者之间应求取平衡，其中有多种不同的服务实践风格可供运用。例如，可以先在企业内部建立大部分可能有用的服务，然后再进行一系列SOA项目来建构或使用这些服务。这种较为服务导向的方式首先建立一套丰富的服务套件，并制定扎实的长期策略，同时需要某种程度的先期投资（尤其是服务设计方法学以及服务中介平台）。另一种较为项目导向的方式，则是以某些项目所需的服务为优先，不强调这些服务将如何共享，这种方式可提供短期的投资报酬，但可能影响长期的SOA效益。

德国邮政从一开始，就强调架构的转型应该根据SOA原则逐步演进，这种演进方式以较小的IT项目着手，具备明显的商务案例以及有限的范围，以提供短期的商务效益（策略性），并符合企业整体的最终应用目标（根据商务领域所制定的SOA蓝图）。这些项目必须有其商务归属者，且无论使不使用SOA，这些项目都必须执行，因此这种演进法可在服务导向与项目导向方式之间取得良好的平衡，如（图四）所示。

《图四 SOA逐步演进示意图》

制定服务规格

每个项目所建构的服务，都需要针对服务的各种特性拟定细节。德国邮政公司采用三步骤的服务规格法。第一步骤得自于服务发掘过程，提供一个「企业服务说明」搭配德国邮政的企业架构模型。这个企业商业对象与服务模型，旨在说明服务架构的逻辑观点，其中包含商务领域、对象与服务。在这个模型中，各种服务以接口加以描述（UML为其正式语言），服务操作的相关说明，则参照模型中的商业对象与其他数据类型。

第二步骤为详细的商务服务规格，其中包括：拟定服务接口的细节、分析IT项目的特定层面（例如服务范围的可能限制），然后进行服务的实践或获取。商务服务的规格在服务设计过程中相当重要，因为这些规格是该服务所牵涉的人员之间基本的沟通方式。在拟定服务规格时，应该考虑下列几大类的信息：

服务规格的最后一步是「技术服务规格」，特别探讨服务中介平台的相关要求，而其他先前所未提及的技术规格（例如特定的数据流量、讯息大小等等）也在此详细说明。将服务加以适当分类，也有助于该服务在设计与建构上应用业界最佳惯例。

一项服务的功能、质量与方针，定义了服务供应者与消费者之间的合约型态，这也就是所谓的服务契约。目前产业界并没有全体通用的服务规格标准，但WSDL与UDDI已经俨然成为基本服务规格的描述与发表标准。此外，现在也有愈来愈多的试验采用WS-I（Web Services Interoperability）规格，让服务能更广泛地重复使用。

规格的重复修订，可以产生更精致、更扎实的细节，具体说明服务的接口与功能性，让服务规格可符合目前的需求以及未来预估的需求，使服务更具弹性及成本效益。服务规格的重复修订，通常需要商务服务归属者、商务分析师、技术分析师三者之间密切的配合。

服务的最佳粗细度？

SOA开发人员常常争论服务的最佳粗细度，虽然服务粗细度目前并没有一致的量化标准，但可以沿用组件设计的理念，例如：呼叫该服务所影响的功能点或数据元素数目。如果一个服务在商务应用程序中呼叫的次数太频繁，或通常只有一小部分的功能被使用，则该服务可能划分太粗。如果一个服务需要太多的参数，则该服务可能太低阶、划分太细。虽然这些观察乃是以实际的服务建构结果为基础，这个问题仍可透过有效的服务套件与生命周期管理过程来解决：服务套件的适用性可随时间大幅成长，首先针对高价值的服务运作来着手，然后逐步加以扩充、演进。一项服务若能达到适当的粗细程度，将可发挥最高的简便性、重复使用性以及可管理性。最适当的服务并不一定要以粗细度来区分，而应以能否发挥最高商务价值来考虑。

德国邮政公司通常将较粗的服务首先加以建构，这些服务都是较稳定的基本服务，从一开始就可以确立。渐渐地，服务消费者愈来愈多，需求也愈来愈精细，因此可以建构较细的服务运作。这些精细的服务运作可提供良好的基础，用以制定一套更丰富、更复杂的服务运作。例如，可将服务彼此结合（复合式服务运作）或搭配成一套流程（搭配式服务运作）。

服务建构与生命周期管理

虽然服务的建构在大多数层面与软件开发相差不多，不过仍有两大差异。

第一点，根据所选定的服务中介平台，其服务接口程序代码不一定要人工撰写，如果有合适的服务设计工具链，可以透过工具自动产生。德国邮政公司根据模型导向架构法，采用一套服务设计工具链，起点为企业商业对象与服务模型，接着将这个模型转变为项目商业对象与服务模型（PBSM）。PBSM的细节在项目规格中进一步敲定之后，工具链可以产生德国邮政公司SOPware服务中介平台的程序代码骨干，以及服务规格说明文件。服务规格采用适当的工具建立模型，而XML与XMI则是广获肯定的标准化交换语言。

第二点，在建立或获取服务中介平台时，必须谨慎考虑该平台是否支持服务测试，因为服务本身需要松散耦合的环境。以德国邮政为例，服务模块的测试采用DevBox，该组件为SOPware的一部分，可提供服务呼叫链接库，并可在开发人员的本机计算机上仿真服务供应者。除此之外，德国邮政也设立了一个服务架构测试实验室，该实验环境提供了所有服务与服务供应者，以供SOA应用程序的整合测试之用。

虽然服务接口将成为企业架构中的稳定要素，服务将会逐步成长，因为愈来愈多的服务运作将加入系统中，不过随着幕后的服务供应者逐渐改变，服务的建构方式也会变迁。尽管SOA架构可以将变迁的影响降到最低，服务的生命周期还是需要管理，其中包括版本控制、商务服务储存库（包括服务模型与规格）、以及可在建构与执行期提供服务实体存取的技术服务储存库（服务登录库）。

技术考虑：服务平台与标准

从以上得知，商务服务可以将商务变迁与IT变迁有效解离，但服务中介所需的IT基础架构（或其中某些要件）也有需要变动的时候，许多企业在EAI或旧型中间件之中纠缠不清，无法切实配合商务所需的脚步而变迁。当某些技术已经过时而无法因应效能成长需求时，仰赖特定工具的EAI配接器与接口，由于需要专属的中间件协议，因此不能轻易地加以转移，在这种情况下，原先预计藉由科技所实现的弹性也不复存在。

采用标准化的服务中介方式或可解决以上课题。例如新发表的Java标准JBI（Java Business Integration）、或是类似德国邮政SOPware的方式（其也是采用JBI）。SOPware之中采用了另一个抽象层，特别将商务服务逻辑与其下的IT基础架构互相解离。这个抽象层完全采用J2EE（也可选用.NET）、XML、WS-I等标准。在2001年完成开发的SOPware，经过技术进展与功能扩充过程，几乎所有的基础架构组件（例如应用服务器、MOM、目录服务器、转型引擎等等）都已经经过有效的更新升级，但开发接口仍然不受影响。关于服务的中介方式，开发人员只需知道简单的XML语法API，即可开发服务或呼叫服务，相关的技术细节与工具则隐藏于幕后。程序设计师可以专心建构商业规则，不需要浪费时间撰写低附加价值的基础架构码。对于德国邮政而言，这种策略提供最佳的弹性与投资保障，这不仅针对商业规则而言，对IT基础架构也有杰出的效益。

P-Si的直线偏亮度异方特性

对于德国邮政而言，这种策略提供最佳的弹性与投资保障，这不仅针对商业规则而言，对IT基础架构也有杰出的效益。虽然有许多科学原则可作为服务发掘与设计的指引，但如同许多架构研究一般，业界老手的直觉经验在整个发展过程中相当有益，尤其对于初期开发过程更为显著。SOA的实践，需要快速而简易的建构方式：商务人员应该以商业规则为重，而不应该操心通讯协议与传输方式，因此采用功能完整的SOA平台可说是相当实用。

此外，采用开放式标准与模块化技术组件，可以让SOA资产的重复使用率更高、TCO更低，并可避免被厂商牵着走，也可降低采用SOA技术的风险。