什么是SOA?

SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

SOA:Service-Oriented Architecture，面向服务架构，SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理互联网纾的人为依赖性。

SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义适配器进行通讯，不涉及底层编程适配器和通讯模型。

SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。

Service-architecture.com将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”

Looselycoupled.com将SOA定义为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。”

Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”

Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益??“SOA极大的得益于BPM技术和方法论，但是SOA面临的真正问题是确立正确的企业意识，即：强化战略化的SOA计划（针对供应和使用）并鼓励重用。”

虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

需着重注意的是，SOA并不是新生事物??大型IT组织成功构建和部署SOA应用已有多年的历史??这要比现有的XML和Web服务长很多。IBM CICS和BEA TUXEDO就是过去被用于构建SOA应用的两种技术范例。

重点说明的是SOA并不是一种现成的技术，而是一种架构和组织IT基础结构及业务功能的方法。SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。这一定义阐明了SOA的范围。

SOA要求开发人员将应用设计为服务的集合。SOA要求开发人员跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。

但是，SOA并不仅仅是一种开发方法??它还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。通过分析服务间的交互，SOA可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使管理员或分析师能够有针对性的优化业务流程。

SOA的基本特征

SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化重用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：

1 可从企业外部访问

通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。业务伙伴采用先进的B2B协议（ebXML或RosettaNet）相互合作。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或短等）取决于业务目的。

除了B2B协议外，外部用户还可以访问以Web服务方式提供的企业服务。

2 随时可用

当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。

许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。

相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台，用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。

服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。在多数情况下，采用异步模型可以达到同样的效果，但更能够体现SOA的最佳特性。

当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。

3 粗粒度服务接口

粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚??向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。

采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。

除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。

4 分级

一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。

在服务分级方面，须注意服务层的公开服务通常由后台系统（BES's）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。

5 松散耦合

SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。
当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。

消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和Web服务间不存在紧密耦合请求响应，消息类 Web服务在客户和服务器间提供了更为松散的耦合。

6 可重用的服务及服务接口设计管理

如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此，因此SOA实施者应当寻找一种适当的方法进行服务设计过程管理。

服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷??走捷径的项目战术与企业构建可重用通用服务的长期目标。

超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。

在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。

简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用，需要在制定SOA实施计划时加以考虑。

7 标准化的接口

近年来出现的两个重要标准XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。尽管以往的SOA产品都是专有的、并且要求IT部门在其特定环境中开发所有应用，但XML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。这具有巨大的意义！

Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制化J2EE应用中的现有服务，而完全无须了解这些应用的内部工作原理。采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。

你也可以不采用Web服务或XML来创建SOA应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。

8 支持各种消息模式

SOA中可能存在以下消息模式。在一个SOA实现中，常会出现混合采用不同消息模式的服务。

A. 无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。

B. 有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供者的服务难度。

C. 等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改进服务可靠性。

9 精确定义的服务接口

服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。

META将SOA定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。

SOA的优点

了解了SOA的定义和基本特征，最后我们再来看看SOA潜在的优点：

A.编码灵活性

可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务实现方式本身也可以灵活使用。

B.明确开发人员角色

例如，熟悉BES的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了解BES的实现，而将精力放在解决高价值的业务问题上。

C.支持多种客户类型

借助精确定义的服务接口和对XML、Web服务标准的支持，可以支持多种客户类型，包括PDA、手机等新型访问渠道。

D.更易维护

服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。

E.更好的伸缩性

依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整，以满足服务需求。

F.更高的可用性

该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节，这样服务提供者就可以在WebLogic集群环境中灵活部署，使用者可以被转接到可用的例程上。

SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

面向服务架构（SOA）是让IT更加关注于业务流程而非底层IT基础结构，从而获得竞争优势的更高级别的应用程序开发架构。

IT人士如何满足那些日益增长的需求以便快速实现IT价值呢？答案是开发和部署面向服务的架构（SOA）。SOA方法能够更好地让IT与业务目标看齐，使得IT组织可以高效复用资产、为企业更快地创造价值，进而更轻松地应对不断变化的业务需求。

SOA对需要使用信息技术解决关键业务问题的企业（包括希望减少冗余架构、创建跨客户和员工系统的公共业务接口的企业；需要基于角色和工作流对用户提供个性化信息的业务的企业；希望通过Internet实现跨区销售、升级销售和经由移动设备的访问来提升客户服务的组织）很有价值。

采用服务驱动型方法的企业体验着以下业务和IT好处：

面向服务架构的业务好处

<!--[if !supportLists]-->l    <!--[endif]-->效率：将业务流程从"烟囱"状的、重复的流程向维护成本较低的高度利用、共享服务应用转变。

<!--[if !supportLists]-->l    <!--[endif]-->响应：迅速适应和传送关键业务服务来满足市场需求，为客户、雇员和合作伙伴更高水准的服务。

<!--[if !supportLists]-->l    <!--[endif]-->适应性：更高效地转入转出让整个业务变得复杂性和难度更小，达到节约时间和资金的目的。

面向服务架构的IT好处

<!--[if !supportLists]-->l    <!--[endif]-->复杂性降低：基于标准的兼容性，与点到点的集成相比降低了复杂性。

<!--[if !supportLists]-->l    <!--[endif]-->重用增加：通过重用以前开发和部署的共享服务，实现了更有效的应用程序/项目开发和交付。

<!--[if !supportLists]-->l    <!--[endif]-->遗留集成：用作可重用服务的遗留应用程序降低了维护和集成的成本。

如今的服务驱动型企业都在体验着开发的高效率，服务的高可靠性和服务的高质量，以最大限度获得业务机会所带来的这些好处。

IBM发布31种SOA产品 加速实现面向服务架构

IBM在它的客户中加速实现面向服务架构的努力当中，已经发布了IBM的11项新产品和22项基于WebSphere的软件的更新，IBM还宣布将会对咨询服务增加人力投入，以使得该项目能够在接下来的六个月中完成。

IBM Software 集团的高级副总裁和执行总裁Steve Mills认为SOA软件市场还没有成熟，但是本周发布的软件将会帮助客户开始SOA软件的开发和应用。

图1：共享服务生命周期的设计和运行时阶段

SSLC中的设计时注意事项

现在我们来看看共享服务周期的设计时方面。提到设计时，我主要关注服务投入生产和使用之前的生命周期。本文不涉及设计时建模的许多需求，如开发服务建模方法学，但如有兴趣，我将在未来的文章中阐述这一主题。

确定业务流程

SOA的一个核心原则是业务和IT保持一致以及建立竞技场(playing field)。通过识别企业通过服务定位提供价值的业务流程，服务工程团队(通常是业务、分析师和IT人员的组合)可能在讨论的出发点方面达成一致。

许多企业发觉很难理解从何处开始SOA以及哪些是最合适的业务流程。一种好的方法是首先在白板上定义需求目录。将白板划分为3条泳道，分别代表短期需求(3到6个月——通常本质上更有战术性)，中期需求(6到18个月)和长期需求(超过18个月——通常为战略需求，可能随业务需求的变化而变化)。划分泳道之后，开始为每个区域添加需求。尽量避免按应用系统(如，电子商务网站)思考;看得越远，越有可能达到您要求的高度(例如，我需要完善自己的清单系统)。在生命周期的这一阶段，主要着眼于可能成为业务组成部分的业务流程，如电子商务站点。

完成初步分析之后，服务工程团队可能开始寻找依赖性，试图决定优先级、揭示重用可能性或确定需求之间的依赖性。观察下面的需求目录示例，可以看到对于该企业来说，最初集中在用户注册流程上是再合理不过了，因为许多其他流程依赖于该流程，而且它可以在整个电子商务功能和企业内部网中重用。

<!--[if !vml]--><!--[endif]-->

图2：需求目录示例，它向服务工程团队提供了实现公司未来状态的路线图

根据公司在服务设计和开发方面的成熟度，选择首先开发哪种服务可能很自然地导致构建没有很多依赖性的服务，同时积累经验。尽管这些想法是对的，但是在企业成熟度中，熟悉增强重用的服务建模技术是很重要的，如强大的契约和策略定义。服务工程团队必须意识到重用概念以前曾在业务中提到过多次，但没有多大成效。由于相对于传统应用程序生命周期来说，服务开发周期较短，服务工程团队有能力从短期目录创建一系列可以跨计划快速利用的基础服务，从而实现早期的成功。

无论如何，对初始服务（特别是依赖服务）的选择应与服务工程团队的能力相一致。这是很重要的。新的团队需要时间才能在SSLC的设计阶段具有更多经验。在服务目录中确定的依赖服务可能由于具有较高的重用水平，看似是一个好的侯选服务，但是不适合于尚未成熟的团队。若一个服务已涉及到跨业务线、提供企业级功能或遵守严格的服务质量规章的依赖性，则它可能不是一个理想的初始侯选服务。

另一方面，对于一个具有已定义流程和已知端点的服务，如果这些端点是受控的、成熟的并且范围很小，在必要的情况下，服务本身的离散程度足以构建或重构，那么在很短的时间内，这种服务是初始开发的主要侯选服务。这样的初始服务应该可以很快地验证假设、方法学和流程。正确的设计需要经验和实践。反复进行试验并纠正错误，尤其在SOA计划的成型阶段，这种方法是判断在您的企业内哪些SOA实践可以发挥作用的重要机制。早期选择没有依赖性的孤立服务可能会限制服务工程团队在成型阶段获取更多的学习机会。

服务设计和建模

服务设计和建模阶段的目标是，基于需求目录中确定的业务流程建立一种定义侯选服务的一致方法。真到开始做的时候，服务工程团队通常用白板描绘业务流程、分解步骤以及讨论当前和未来的需求。为此，一致的设计方法学应该使用业务和IT均可理解的常用语言来建立。

服务设计方法学为服务工程团队提供了一系列用于分解业务流程的步骤或活动，基于面向服务的设计原则确定服务中开发哪些方面是合理的。对于这种设计方法学，许多企业最初有一些争执，尤其是服务粒度。过细的粒度可能产生不可重用的服务增殖；过粗的粒度，又很难着手。在团队对建模流程满意之前，它应该将其活动集中在定义良好的业务流程中，这些业务流程可能并没有较大企业需求（如高生产量、长期事务）。

尽管从技术上来说不是建模阶段的一部分（但可能是建模方法学的一部分），但我的经验表明：在定义服务分类原则方面投入时间对企业来说是很重要的。这些指导方针应该定义服务的哪些方面决定了服务是业务线（LOB）或应用程序级服务，还是具有特殊需求的企业服务。这些指导方针可能包括生产量、服务质量（QoS）、正常运行时间、服务关键程度以及多少客户将使用该服务。另外，开始定义与建立和管理服务相关的企业治理控制时，这些指导方针至关重要。开发指导方针可能本身是贯穿始终的工作，但开头很简单，只定义当前需求所要求的部分就可以。而且，服务分类可能有助于将相似功能分组并确认这些功能的业务所有者。记住，后续出现新的需求时可以重新调整指导方针。

<!--[if !vml]--><!--[endif]-->

图3：服务分类及其与SOA治理的关系；此分类可能有助于定义SOA资产的企业治理控制。

根据服务目录示例，企业可能已经建立了企业服务和业务线服务类别。以下进行详细描述。

企业服务

企业服务具有水平影响，可能包括：

1. 无论在是周边或核心部门，安全性都需要符合行业规范。
2. 活动审计。记住审计可能是某一特定功能的一个方面，如外汇交易，而不是进行交易的流程。
3. 一般异常处理。
4. 服务要求24x7可靠性，并且必须据此进行治理。
5. 服务要求大容量和（或）低延迟吞吐量。
6. 根据使用环境，服务可能要求更高级别的客户服务或响应时间。例如，客户个人信息表明他们是贵宾客户，则服务契约会要求不同的SLA。
7. 若服务要求跨业务线进行交互，则可能具有必须满足的企业基础架构需求。
8. 服务与企业数据进行交互。这方面可能意味着企业拥有通用模型，而具体用户数据存储的实现则由业务线控制。经验和实践表明，大量的用户数据存储存在于企业中。SOA目标的一部分就是为了长期巩固这些方面，但在定义未来计划时，不应脱离现实，而是要充分利用现有资源。

业务线服务

这些服务具有垂直影响，可能包括：

1. 特定业务功能，如采购单（PO）或新的租赁处理。
2. 具有特定UI和外观的表示服务，或者通常用于提供某一特定业务功能的可视化表示的向导。
3. 支持业务线的CRUD（创建、读取、更新、删除）活动的信息和访问服务。
4. 应用服务，如基于特定业务线数据的销售跟踪或预测。

此分类并不完整，但应该可以提供企业如何开始分类工作的概念。

通过检查以上类别，可将以前定义的需求目录中的某些侯选服务放至治理组中，并识别出以前并不明显的许多典型结构：

服务生命周期主要是为了解决业务需求问题，而不是过度陷于具体的分类练习。SSLC评估阶段是为了支持基于实际应用和环境的再评估。我想到电影《梦幻之地》中凯文·科斯特纳听到的声音重复说：“你盖好了，他们就会来”。这与在企业中公开服务没有什么区别。在某一时间点上以某一使用级别定义的内容实际上可能会以完全不同的方式使用，也就是通常在最初设计时并未考虑到的方式。指导方针在重分类阶段应该有所帮助。

在流程的这一阶段，我主要谈论侯选服务与服务实现的概念。Erl（2004）建议侯选服务是潜在的服务，这些服务可能在最后的设计中实现，也可能不实现。设计流程是为了确定设计和开发的未来阶段的输入。理解企业中哪些服务已存在以及哪些需要开发对服务工程团队来说特别重要。支持服务发现的工具（如兼容UDDI的注册库）是促进服务重用和了解现有可用资源的重要组件。

最后，在建模阶段，随着逐渐理解了团队正在定义侯选服务，服务工程团队应通过独立于技术架构和物理环境约束的已确定方法学继续进行设计。服务设计和建模阶段的目的就是定义期望的未来状态。SSLC的构建和组合阶段将使侯选服务遵守组织约束以定义最后的服务实现。

构建和组合

为更加快速经济地开发新的功能，服务生命周期的构建和组合重点集中在开发新服务以及利用企业中现有资源所要求的任务上。这一方法可以缩短上市时间，从而实现SOA的一项关键财务收益。

在本阶段，服务建模和设计阶段确定的侯选服务被具体化成服务操作，并将基础架构和环境实体映射到它们。正如在建模阶段提到的，确定SOA计划的目标是很重要的。由于当前环境的限制，实现这些目标可能比较困难，但是可能会促进某些良性讨论以及某种成本利润分析，从而确定如何实现期望的未来状态。但是，现在的企业需要继续发展，所以您的侯选服务在企业环境中必须具有现实意义。

理解了哪些服务操作和实现比较现实之后，就可以着眼于重用的可能性以及在上一阶段确定的组合。要充分利用SOA，组合的概念对业务敏捷性来说非常重要。开发环境和服务基础架构工具必须推动设计时发现服务，并可组合这些服务，完成整个业务流程。

没有这些工具，SOA计划的成功可能会受到阻碍。随着初始服务对业务线团队和其他工程团队可用，组合的机会可能得以实现。在这种情况下，在分类的同时已确定了初始依赖性。这些依赖性应描述为构建组合服务的直接可能性，并应提供重用的切实收益。本文中只稍微提到了组合，但这些活动的重要性与SSLC的构建和组合阶段直接相关。

考虑需求目录示例：一个称为整合清单系统的计划已在长期目标中确定。在第一次浏览时，该任务可能被描述为物理上废弃旧清单系统，并将存储库整合到一个主数据源中。尽管可能真的会是这样（如果成本利润分析表明废弃旧系统更加经济有效的话），活动也可能表述为一种没这么具体的形式。服务工程团队可能产生一系列逻辑数据服务，对客户隐藏物理端点。构建普适数据访问层的这一方法将通过组合直接利用在中期需求目录中开发的现有检查清单X服务。整合清单系统计划可能要求根据清单文档的典型表示来决定哪些端点需要修改。这种分散式CRUD逻辑应在“服务基础架构工具”中提供，这样的一个示例是BEA AquaLogic Data Services Platform。

通常，服务起源于业务线级别而不是通过企业计划，因为一般情况下这是驱动项目建立和需求的地方。结果，“你盖好了，他们就来了”方案可能导致设计时发现的服务不是良好的重用侯选服务。它们可能不提供足够的性能或一致模式。尽管它们在企业中可用，但仍为应用程序级服务。最后，企业必须开始创建管理流程以控制服务的企业可见性。在通常情况下，服务注册提供确保服务质量的管理机制和流程。这些问题必须在服务生命周期的发布和准备阶段予以解决。

最后，要进行快速的开发，经验表明，工具标准化可使企业充分利用现有知识并在整个SOA计划中重用。这不是说每个人都必须使用相同的IDE或某个特定工具，而是说使用的任何工具必须以类似的模式工作，必须支持标准；若开发人员需要使用不同的工具支持其他项目，则必须降低学习的难度。另外，这些工具必须能够轻松地度量服务的重用性和控制上市时间。通过服务生命周期获得度量可以为企业提供价值巨大的信息，帮助SOA计划获得成功。

BEA域模型

正如许多方法学所述，需要建立一种底层模式来统一所有其他活动。在BEA和SOA环境中，就是BEA的域模型（需要注册）。Dev2Dev中有许多文章描述理解SOA各个方面的重要性（详见David Groves撰写的Successfully Planning for SOA）。共享服务生命周期使用该模型并按此方式提供切实的控制点。在本文定义的设计时阶段中，域模型的影响通过定义项目和应用程序的需求以及架构方法的需求目录来表述。

该方法通常开始于远景，最初通过基础服务或构造块实现。尽管治理在设计阶段没有在SSLC的运行时那么关键，但是治理已开始在流程中产生了一定的影响，特别是在决定初始服务实现时。

本系列文章的第二部分将揭示评估部署服务成本和收益的重要性，并继续关注在运行时如何对服务进行治理。另外，SSLC的设计时和运行时阶段都要求紧密结合业务策略和流程。这就要求确定和设计可能成为侯选服务的业务流程，并将它们组合成可重用服务，以实现业务的灵活性。

结束语

通过进一步理解与共享服务生命周期相关的设计时需求，正在寻求使用SOA促进重用和增加业务灵活性的企业可能认识到及早建立基础架构（如方法学、分类指导方针以及开发工具）是实现早期及后续成功的重要因素。通过突破传统应用程序开发范型以及关注作为发展蓝图的业务流程，服务工程团队可以及时有效地紧密结合业务需求。

本文的第二部分将关注共享服务生命周期的运行时。

SOA 编程模型系列
对于任何独立程序员来说，有效的掌握和应用飞速增长的软件技术、实践、工具和平台，变得越来越困难，当然更不用说非程序员了。然而，如果业务流程转换能够成功进行，很多的非程序员就可以使用现有的 IT 资产来进行他们的工作，而不用去学习繁琐的底层技术细节。本系列文章描述了一个新的面向服务体系结构（SOA）编程模型，该模型实现了业务关系的分离，因此企业中具备不同技术水平和工作角色的人，即使不是专业的 IT 人员，也可以在软件开发生命周期每个阶段创建和使用 IT 资产。这可以显著提高随需应变企业的业务灵活性。

引言
IBM 产品逐渐应用了 SOA 和编程模型。程序员构建服务、使用服务，并且开发聚集服务的解决方案。我们在这里使用"程序员（programmer）"这个泛称，因为 SOA 编程模型的一个关键方面是将"编程"的概念扩展到非传统开发人员的工作角色和技能，比如业务分析员和脚本语言用户。

大多数关于 Web 服务的文章主要集中在服务接口和这些接口的使用方面。为了补充接口标准和最佳实践，IBM 引入了一个编程模型，来实现服务并将它们组合为解决方案。扩展 IBM 软件平台的范围，使之能够被更多的用户团体使用 -- 包括非传统的开发人员 -- 这个模型提供了新的组件类型与用户的角色、目标、技能和概念框架相匹配。这些组件类型使更直观的开发工具可以使用。另一个主要的主题是通过编程模型特性和功能的逐步透明化来增强可使用性。

这是关于 SOA 编程模型系列文章中的第一篇，特别针对软件开发专业人员。在本系列中，我们介绍了实现这些目标的一些新的编程模型元素。我们介绍了如何利用它们来使您选择、开发、建议或管理的软件能够更加容易的开发、重用和消费。将软件构造为服务对于按需的企业来说更加有价值，因为不具备太多技能的开发人员可以将其"接入"到解决方案中，或者编入一个业务流程编排流中来满足快速变更的业务需求。不管你是大型企业或者小型业务的开发人员、独立软件供应商（ISV），还是应用程序提供者或者中间件供应商，你都可以通过这种方式构造你的软件，从而从中受益。那么，让我们立即开始应用 SOA 原理。

SOA 编程模型的亮点
让我们首先重点介绍 SOA 编程模型的几个主要特性。

服务数据对象（SDO）是 IBM SOA 中的一个基础概念。SDO 大大提高了开发人员的生产力，并且将你从如何访问特定后端数据源、应用程序和服务的技术细节中解脱出来。它们提供了简化的抽象，使程序员可以更多的集中在业务逻辑上。SDO 还提供了统一的消息表示来与服务交互，淘汰了用于数据表示的复杂技术迷宫，仅仅访问单个统一模型。

SOA 编程模型同样需要统一的范型来创建和访问业务逻辑。为了易于使用，服务应该隐藏实现技术之间的差别，并应该建立在比现有编程结构（比如 Enterprise Java™Bean（EJB））更高级别的抽象上。服务可以通过组装到模块（这些模块可以组成解决方案）中的组件来实现。通过组件公开的服务可以使用可定位的接口来调用。您可以使用 Web 服务描述语言（WSDL）、Java 或其他语言来描述接口。这个实现类型可以有对所需服务的待定引用，在将组件结合在一起执行之前，这些服务是满足需求的。

这个编程模型还引入了良好定义的组件类型，对程序员开发和部署到解决方案中的常用构件建模。例子包括"无格式旧 Java 对象"、业务流程执行语言（BPEL）流程、结构化查询语言（SQL）服务、Adaptive Business Objects、通过 Java 连接器体系结构（J2C）资源适配器访问的 CICS®程序、使用 SAP 业务应用程序编程接口的应用程序、Java 2 Enterprise Edition（J2EE）无状态会话 bean 和 MQSeries® 应用程序。

企业服务总线是多协议结构的一个关键角色，将服务组件编成无缝的交互，通过在消息路径中加入被称为中介的特别组件，来代理服务间的交互，而不用更改现有的端点，从而允许在核心级别上处理企业关注的内容 -- 比如审核、日志、路由、不匹配接口的适配、等价组件的增量替换、安全等。

新的流程语言缩小了 IT 概念和业务构件之间的间隙。很重要的一个是 BPEL。虽然流程可以通过业务分析员引入图形化工具来定义，但它也是一个可执行程序。流程在按需业务转换中占有重要的地位，例如为扩展价值链描述长时间运行的可执行流程。通过扩展价值链，我们可以跨越多个供应商和 IT 域来进行业务安排，比如一个零售商和他的多个独立的供应商，保险公司及其众多的第三方理赔员，IT 外购状况等。

业务状态机（business state machine）是业务分析师可以通过图形工具创建流程的另一个编程框架，并且在流程设计引擎中执行。状态机可以表示业务构件 -- 比如采购单、保险索赔等 -- 这些转换通过一些良好定义的状态来响应特定的生命周期"事件"。

需要重用的组件可以封装为具有可变点（points of variability）的模板，可以在放入解决方案中时进行设计。这种适配成为我们的编程模型的第一部分，同时结合规则语言和相关的工具，为新型用户提供定制的能力。

另一个创新领域是新的解决方案模型，它让部署者、管理者和其它业务用户可以将组件组装成解决方案。在开发的时候，你可以将服务实现与托管服务的拓扑（系统架构师建模的部署拓扑）关联在一起。模型捕捉的系统需求和环境假设在早期的实现中进行校验，降低了应用程序生命周期的费用，并且极大的提高了可靠性和可计账性（accountability）。该模型的特性还包括现有应用程序的后期绑定、数据转换中介和适配器，可以通过企业服务总线来实现面向服务的交互。

总的来说，SOA 编程模型将开发和部署活动分割为不同的阶段，这些阶段可以发生在不同的时间，并且可以通过不同的个人使用不同的技能来实现。这就产生了关系的分离，使软件组件可以被重用。它也将软件体验划分为单独用户的业务角色、技能和任务。最终，它使软件生命周期可以适应按需企业的需要，因为它们通过针对业务灵活性重新设计 IT 流程来寻求更高的有效性。

编程模型的概念
编程模型通常是 IBM SOA 和 IBM 产品的核心。它定义了程序员可以构建和使用的概念和抽象。运行时产品，例如 WebSphere® Application Server，DB2®和 CICS，可以运行或托管编程模型构件。开发工具支持编程模型构件的建模和实现、组装到应用程序（解决方案），以及部署到运行时环境中。最后，系统管理产品、代理和设备支持对运行时和它们托管的编程模型构件的管理。

编程模型是什么？虽然目前没有公认的一般定义，但我们喜欢将它定义为：

• 程序员构建的一套部件类型。部件类型包括多种编程模型构件：超文本标记语言（HTML）文件、数据库存储过程、Java 类、可扩展标记语言（XML）Schema 定义、定义 MQSeries 消息的 C 结构，等等。
• 一系列角色，将具备相似技能和知识的开发和管理人员分组。用这种方式对开发人员分类有助于生产适应于角色的工具，使非程序员可以实现服务并将服务组装为解决方案。业务分析人员定义业务流程，销售专家定义顾客分类的策略并计算产品折扣。每一种角色包含：
  • 角色所具备的技能。例如，用户界面开发人员开发界面，用来呈现应用程序或者解决方案的功能构件。假设这个角色了解正在开发的应用程序和它的业务目标，充分了解应用程序的用户及他们的任务，精通一些用户界面设计方法，能够通过为每个任务选择恰当的类型来创建易于使用的用户接口。
  • 角色交互（消费或者生产）所用的部件类型和应用程序接口。例如，动态页面设计人员 -- 角色 -- 生产 JavaServer Page（JSP）并消费 EJB -- 部件类型 -- 包装现有的信息资源和应用程序。
  • 角色使用的工具。例如，Web 开发人员所用的适合于角色的工具是所见即所得的页面设计工具，用来构建动态页面，使用与 HTML 和 JSP 标签库相关的控件，并将控件连接到 EJB。

使 Web 服务易于实现和使用的关键是对现有技术和知识进行增量扩展，从而使 SOA 可以被消费。以 CICS COBOL 事务程序形式存在的服务与用 BPEL 编写的服务差别很大。从数据库存储过程中调用服务与从 JSP 中调用也是不同的；技能和期望值是不同的。通过提供工具的分类来使部件类型适应于各种技能，并适应于开发流程的阶段，你可以实现可消费性（consumability）。

本系列的后续文章更加详细的介绍了 SOA 编程模型的部件类型。

产品架构

图 1. 产品架构
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

支持 IBM SOA 方案的产品分成两个主要类别：服务端点和连接它们的消息传送结构。这个通用的架构 -- 包含了许多产品，这些产品都不是 IBM SOA 的专用传输工具 -- 如图 1 所示。

核心是服务间的 ESB 提供的连通性。ESB 是多协议的，支持点到点和发布-订阅两种通信类型，并支持快速处理消息的中介服务。IBM WebSphere MQ，IBM WebSphere MQ Integrator Broker 以及支持 Web 服务和 Java 消息服务（JMS）的 WebSphere 都属于第一个类别。

服务存在于抽象的托管环境（容器）中，并且提供了特定的编程框架。容器加载服务的实现代码，提供到 ESB 的连接性，并管理服务实例。不同类型的服务存在于不同的容器中。（在典型的递规设计的例子中，ESB 本身被认为是用于中介服务的容器。）表 1 列出了一些主要的 IBM SOA 托管环境和托管的组件类型。

表 1. 托管各种组件和服务类型的容器

结束语
IBM SOA 编程模型系列文章的第一篇概述了 IBM 工具和产品如何适用于模型，以及开发人员如何有效的在应用程序开发中使用它。

• 使用 SDO 简化数据访问
• 服务定义以及组件模型发展状况的介绍
• 用组件类型来简化开发
• 基本组件类型
• 服务组合和定制
• 流程组件：BPEL 和业务状态机
• 定制服务：设计模式，模板和可变点
• 面向服务的用户接口
• 用于管理的 SOA 方法
• SOA 软件生命周期开发工具
• SOA 的安全性