SOA真正面目：优势与不足

《SOA真正面目：优势与不足》由会员分享，可在线阅读，更多相关《SOA真正面目：优势与不足（13页珍藏版）》请在装配图网上搜索。

1、SOA （service-orien ted arch it ec ture），面向服务的架构，恐怕是近一段时间以来最 热门的话题之一。在2004年中国软件业评出的10大热点名词中，SOA名列榜首。ZapThink 调研公司在最近发表的一份报告中也预测，到2006年，基于SOA架构的中间件产品将成为 网络化商业系统的主要设计思路。Gartner集团的分析师也指出，今年，SOA架构下的中间 件产品将进入主流应用之中。Gartner还预言：“到了 2008年，至少60%的企业将使用SOA作为创建任务苛刻的应用程序和过程的指导原则”。认清SOA的本来面目SOA架构是一场革命，其实质就是将系统模型与系

2、统实现分离。软件业从最初的面向过程、面向对象，到后来的面向组件、面向集成，直到现在的面向 服务，走过了一条螺旋上升的曲线。其实，自从上世纪70年代提出“软件危机”，诞生软 件工程学科以来，软件业为了彻底摆脱软件系统开发泥潭，一直也没有放弃努力。在经典软件工程理论中，不管是瀑布方法还是原型方法，都是从需求分析做起，一步一 步构建起形形色色的软件系统。但是，需求变更像一个挥之不去的阴影，时刻伴随着系统左 右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段，甚至上线阶段 遭遇应接不暇的需求变更的极端痛苦。客户将变更的需求视为bug（错误），也是测试上现 阶段的主要问题。如何解决这一问

3、题？能否来一场软件开发和架构的革命？SOA架构的提出，就是被人看 成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。1. 定义SOA并不是一个新概念，有人就将CORBA和DCOM等组件模型看成SOA架构的前身。早在 1996年，Gar tn er Group就已经提出了 SOA的预言。不过那个时候仅仅是一个“预言”，当 时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两 年，SOA的技术实现手段渐渐成熟了。在BEA、HP等软件巨头的极力推动下，才得以慢慢风 行起来。Gartner为SOA描述的愿景目标是实现实时企业（Real-Time Enterpris

4、e）。关于SOA，目前尚未有一个统一的、业界广泛接受的定义。一般认为:SOA，面向服务的 架构是一个组件模型，它将应用程序的不同功能单元 服务（service），通过服务间定 义良好的接口和契约（contract）联系起来。接口采用中立的方式定义，独立于具体实现服 务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准 的方式进行通信。这种具有中立接口的定义（没有强制绑定到特定的实现上）的特征被称为 服务之间的松耦合。从这个定义中，我们看到下面两点：它是一种软件系统架构。SOA不是一种语言，也不是一种具体的技术，更不是一种 产品，而是一种软件系统架构。它尝试给出在特定

5、环境下推荐采用的一种架构，从这个角度 上来说，它其实更像一种架构模式（Pattern），是一种理念架构，是人们面向应用服务的解 决方案框架。服务(service)是整个SOA实现的核心。SOA架构的基本兀素是服务，SOA指定一一 组实体(服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约)，这些 实体详细说明了如何提供和消费服务。遵循SOA观点的系统必须要有服务，这些服务是可 互操作的、独立的、模块化的、位置明确的、松耦合的，并且可以通过网络查找其地址。2. SOA三种角色的关系图1是W3C给出的SOA模型中三种不同角色的关系示意图。其中：服务是一个自包含的、无状态(stat e

6、less)的实体，可以由多个组件组成。它通过事 先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务(transaction)等离散性 任务。服务本身并不依赖于其他函数和过程的状态。用什么技术实现服务，并不在其定义中 加以限制。服务提供者(service provider)提供符合契约(contract)的服务，并将它们发布到 服务代理。服务请求者(service consumer)也叫服务使用者，它发现并调用其他的软件服务来提 供商业解决方案。从概念上来说，SOA本质上是将网络、传输协议和安全细节留给特定的实 现来处理。服务请求者通常称为客户端，但是，也可以是终端用户应用程序或别的服务。

7、服务代理者(service broker)作为储存库、电话黄页或票据交换所，产生由服务提供 者发布的软件接口。这三种SOA参与者：服务提供者、服务代理者以及服务请求者通过3个基本操作：发 布(publish)、查找(find)、绑定(bind)相互作用。服务提供者向服务代理者发布服 务。服务请求者通过服务代理者查找所需的服务，并绑定到这些服务上。服务提供者和服务 请求者之间可以交互。所谓服务的无状态，是指服务不依赖于任何事先设定的条件，是状态无关的(state-free)。在SOA架构中，一个服务不会依赖于其他服务的状态。它们从客户端接 受服务请求。因为服务是无状态的，它们可以被编排(orch

8、estrated)和序列化(sequenced) 成多个序列(有时还采用流水线机制)，以执行商业逻辑。编排指的是序列化服务并提供数 据处理逻辑。但不包括数据的展现功能。3. SOA的特征基于上面的讨论，我们给出SOA的下面一些特征：服务的封装(encapsulation)。将服务封装成用于业务流程的可重用组件的应用程 序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装 隐藏了复杂性。服务的API保持不变，使得用户远离具体实施上的变更。服务的重用(reuse)。服务的可重用性设计显著地降低了成本。为了实现可重用性， 服务只工作在特定处理过程的上下文(con text

9、)中，独立于底层实现和客户需求的变更。服务的互操作(interoperability)。互操作并不是一个新概念。在CORBA、DCOM、web service中就已经采用互操作技术。在SOA中，通过服务之间既定的通信协议进行互操作。 主要有同步和异步两种通信机制。SOA提供服务的互操作特性更有利于其在多种场合被重 用。服务是自治的(Auto nomous )功能实体。服务是由组件组成的组合模块，是自包含 和模块化的。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术， 如.NET Rem ot ing、EJB、COM或者CORBA，都需要有一个宿主(Hos t或者Ser

10、ver)来存放和管 理这些功能实体；当这些宿主运行结束时，这些组件的寿命也随之结束。这样当宿主本身或 者其他功能部分出现问题的时候，在该宿主上运行的其他应用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如 事务处理(Transaction)、消息队列(Message Queue)冗余部署(Redundant Deployment)和集 群系统(Cluster)在SOA中都起到至关重要的作用。服务之间的松耦合度(LooslyCoupled)。服务请求者到服务提供者的绑定与服务之 间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比

11、如程序设计 语言、部署平台，等等。服务请求者往往通过消息调用操作，请求消息和响应，而不是通过 使用API和文件格式。这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式 保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码(如COBOL)的实现 完全用基于Java语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真 实的，只要新代码支持相同的通信协议。服务是位置透明的(location transparency)。服务是针对业务需求设计的。需要 反映需求的变化，即所谓敏捷(agility)设计。要想真正实现业务与服务的分离，就必须 使得服务的设计和

12、部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需 求的服务的位置，甚至不必知道具体是哪个服务参与了响应。4. 三个抽象级别从概念上讲，SOA中有三个主要的抽象级别:操作：代表单个逻辑工作单元(LUW)的事务。执行操作通常会导致读、写或修改一 个或多个持久性数据oSOA操作可以直接与面向对象(00)的方法相比。它们都有特定的结 构化接口，并且返回结构化的响应。同方法一样，特定操作的执行可能涉及调用附加的操作。服务：代表操作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的 粒度(granularity)大小也与系统的性能息息相关。粒度太小，会增加服务间互操作通信 的开销；

13、粒度太大，又会影响服务面对需求变化的敏捷性。业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通 常包括多个业务调用。在SOA中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排 序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。从建 模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征，以及 如何系统地构造它们。这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。SOA应用系统总体框架及相关概念看到SOA的一堆名词,读者可能会感到迷惑，有必要结合实际的应用环境进一步阐释SOA 的相关概念。总体框架

14、图1所示的就是一个SOA应用系统的大体框架结构。它大体上可以分为五个部分：POJBflSWSRP 国 回JCciProcessnent&P时 E WC如pEPFlfilPresentabfln=一rn自乩. ERP.zs1酊24卜 T展现层(presen tat ion):图1中5区，通过por tal等技术建立展现平台，方便用 户在这个界面上提出服务请求。业务处理建模(business process modeling):图1中的4区，SOA元模型从MDA 中继承了平台无关模型来对业务处理过程建模。这一部分独立于服务设计和部署层。模型驱 动架构MDA (Model Driven Archit

15、ecture)的主要缺陷是在模型设计阶段就对需求有完整 的描述，而且没有需求变更的反馈机制。SOA通过添加敏捷方法AM来应对需求变更的情况。服务层(Services):图1中的3区，整个SOA的核心层，它承上启下，对上响应业 务模型，对下调用相关组件群完成业务需求,形成“业务驱动服务、服务驱动技术”的SOA 事务处理格局。服务可以根据粒度分层。虽然细粒度提供了更多的灵活性，但同时也意味着 交互的模式可能更为复杂。粗粒度降低了交互复杂性，但敏捷性却下降。企业组件层(enterprise components):图1中的2区，这里是相关组件发挥作用 的场所。这些组件是平台相关的。因为到了这一层，许

16、多底层软硬件平台的特性已经不再透 明了。系统软件层(Operational System):图1中的1区，这一层包括操作系统、数据库管 理系统、CRM、ERP、商业智能(BI)等异构系统，是一个集成的平台。除此之外，诸如QoS、安全性等(图1中7区)也是SOA架构的组成部分。在上面的介绍中，自上而下有一条线，如图2所示，由业务建模开始，通过定义业务过 程，得到服务模型，它是平台无关的，实现了模型与实现的分离。再通过设计组件群，得到 平台相关的组件模型。业痔过現宦買实施原则Jason Bloomberg在其Principles of SOA中指出，SOA的实践必须遵循以下原则：业务驱动服务，服务

17、驱动技术。从本质上说，在抽象层次上，服务位于业务和技术 中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系; 另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。业务敏捷是基本的业务需求o SOA考虑的是下一个抽象层次：提供响应变化需求的能 力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统以上的整个架 构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活 性。 一个成功的SOA总在变化之中。SOA工作的场景，更像是一个活的生物体，而不是像 传统所说的“盖一栋房子”。IT环境惟一不变的就是变化，因此面向服务架

18、构设计师的工 作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求有崭新 的思维方式。SOA的基础还是一些类似的架构准则。与其他概念的关系1. SOA 与 Web Services 的关系SOA构架是独立于技术实现的。SOA并不必用Web Services来实现，相反，Web Services 也并不一定遵循SOA标准。不过，Web Services的特性十分适合用来实现SOA架构。Web Services之间能够交换 带结构的文档(比如XML)，这些文档可能包含完全异构的数据信息。这些文档可以同时附 带关于数据的数据：元数据(metadata)。换句话说，Web Ser

19、vices可以有较粗的粒度， 这样较粗的粒度正好可以构成SOA中服务的粒度。说到底，两者是相交的圆，SOA服务和Web Services之间的区别还在于设计。SOA概念 并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解。其中的区别也就是 定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web Services 在需要交互的服务之间如何传递消息有具体的指导原则；从战术上实现SOA模型是通过 HTTP传递的SOAP消息中最常见的SOA模型。因而，从本质上讲,Web Services是实现SOA 的具体方式之一。2. SOA中的服务与组件对象(Components O

20、bjects)的关系相似之处在于：都有一个或多个接口，并且，服务发布者和使用者都遵守这些接口。分陌武担轩禦构简向功能康向流程垃计目前是酋丁实现需貳说计目的是为丁适廳变化开投周期民交互式和車用性开发成本为中心业务为中心应用阴舉服务协遍敏龍的稲松鋼咅的同构技术畀构技术面i論療需憔入了解玄塗细爷独直咿实施鈿話不同之处在于：SOA是关于模式(schemas)的，组件对象是关于对象类型(object types) 的；SOA通过像SOAP这样的标准消息机制(messages)来实现通信，而组件对象通过方法 调用(method calls)来交互。与 CORBA 中的接口定义语言 IDL (Interfa

21、ce Definition Language)相比，SOA 在 WSDL (Web Services Definition Language)中采用 XML，会显得 更加普遍和通用。联系之处在于：服务最终还是通过类和组件对象来实现的。SOA被认为是传统紧耦合的、面向对象的模型的替代者。像通用对象代理架构CORBA (Common Object Reques t Broker Arch it ec ture)和分布式组件对象模型 DCOM (Dis tribu ted Component Object Model)。在SOA中，单个服务可以用面向对象方法来设计，但是，整个 SOA的设计却是面向服

22、务的。下面的表格中给出了 SOA与分布式组件架构的不同点。3. SOA与网格计算(Grid Computing)的关系网格计算(GridCompu ting)是利用互联网技术，把分散在不同地理位置的计算机组成 一台虚拟超级计算机。每一台参与的计算机就是其中的一个“节点”，所有的计算机就组成 了一张节点网网格。从实质上来说“网格计算”是一种分布式应用，网格中的每一台计 算机只是完成工作的一个小部分，虽然单台计算机的运算能力有限，但成千上万台计算机组 合起来的计算能力就可以和超级计算机相比了。网格计算基于因特网，提供了资源整合和共享的平台。十分适合作为SOA架构的实施平 台。我们来具体地看一下：S

23、OA的构建策略：创建一个面向服务的计算SOC (service-based computing)环境；可 以用类似于web services的技术来设计服务：使用SOAP通信机制；采用XML数据格式；强 调服务的重用和互操作；最大化的应用现有资源；希望有一个类似于网格计算环境的基础平 台。网格作为平台的基本特点：网格被视为一个由各种计算资源组成的统一环境，其管理软 件将网格整合成一个完整而协调的透明计算整体；网格是一个虚拟的应用服务器;是一个应 用实现和数据处理的理想平台；服务在网格中部署和调用执行；商业逻辑和服务调用被当成 网格程序一样在平台上运行；网格为SOC计算的有效性、快速性、灵活性、

24、伸缩性和计算环 境的管理提供便利。SOA带给企业什么？作为需要构建SOA应用的企业来说，究竟有些什么好处呢？我们来看一下： 集成现有系统，不必另起炉灶。面向服务的体系结构可以基于现有的系统投资来发 展，而不需要彻底重新创建系统。通过使用适当的 SOA 框架并使其用于整个企业，可以将 业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口和名称。服务的内 部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种组件的匿名性 使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系 统中、用不同的编程语言开发的组件来创建服务。遗留系统可以通过Web服务

25、接口来封装 和访问。 服务设计松耦合，带来多方面优点。服务是位置透明的，服务不必与特定的系统和 特定的网络相连接。服务是协议独立的，服务间的通信框架使得服务重用成为可能。对于业 务需求变化，SOA能够方便组合松耦合的服务，以提供更为优质和快速的响应，允许服务使 用者自动发现和连接可用的服务。松耦合系统架构使得服务更容易被应用所集成，或组成其 他服务，同时提供了良好的应用开发、运行时服务部属和服务管理能力。提供对服务使用者 的验证(authentication)授权(authorization)，来加强安全性保障，这一点也优于其 他紧耦合架构。 统一了业务架构，可扩展性增强。在所有不同的企业应用

26、程序之间，基础架构的开 发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个 定义良好的SOA框架内。这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑，增强了可扩展性。又由于面向服 务的敏捷设计，在应对业务变更时，有了更强的“容变性”。加快了开发速度，减少了开发成本。组织的Web服务库将成为采用SOA框架的组 织的核心资产。使用这些Web服务库来构建和部署服务将显著地加快产品的上市速度，因 为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。SOA减 少了开发成本，提高了开发人员的工作效

27、率。研究表明，一般系统的接口的开发费用占到整个开发费用的33%,最高的竟达到了70%。 在SOA中，接口的重用会节省费用60%。而且节省的费用不是一次性的，而是每年。随着业 务需求的发展和新的需求的引入，通过采用SOA框架和服务库，为现有的和新的应用程序 增强和创建新的服务的成本大大地减少了。同样，开发团队的学习难度也降低了，因为他们 可能已经熟悉了现有的组件。持续改进业务过程，降低激变风险。SOA允许清晰地表示流程流，这些流程流通过在 特定业务服务中使用的组件的顺序来标识。这给商业用户提供了监视业务操作的理想环境。 业务建模反映在业务服务中。流程操纵是以一定的模式重组部件(构成业务服务的组件

28、)来 实现的。这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。重用 现有的组件降低了在增强或创建新的业务服务过程中带来的风险，也减少了维护和管理支持 服务基础架构的风险。实现SOA的相关技术图1是一张SOA技术实施的示意图，其中涉及的主要技术包括以下几个：Roa煽血角 层抽篡成亠个 逻辐脂铮网绪面向服务 架枸工具 (teals)iOA抽象出业奔 处理中的救件功能面向服务的 处理SOP面向服务和管理S 0 MS 0 M保证SOI的质量SOA的先决条件：廉务 的安全初场剔管理国：SOAK术实犍示意1. XMLXML 1.0 (可扩展标记语言，Extensible Markup

29、Language)标准是一个基于文本的 World Wide Web组织(W3C)规范的标记语言。与HTML使用标签来描述外观和数据不同， XML 严格地定义了可移植的结构化数据。它可以作为定义数据描述语言的语言，如标记语法 或词汇、交换格式和通信协议。2SOAP简单对象访问协议(Simple Objec t Access Pro to col)是一个基于XML的，用于在分 布式环境下交换信息的轻量级协议oSOAP在请求者和提供者对象之间定义了一个通信协议, 这样，在面向对象编程流行的环境中，该请求对象可以在提供的对象上执行远程方法调用 因为SOAP是平台无关和厂商无关的标准，因此尽管SOA并

30、不必须使用SOAP，但在带有单独 IT基础架构的合作伙伴之间的松耦合互操作中，SOAP仍然是支持服务调用的最好方法。W3C SOAP 1.2规范在服务请求者和服务提供者之间定义使用XML格式的消息进行通信。 将应用程序请求(在XML中)放入SOAP信封中(也是XML )，并从请求者到提供者发送 应用程序请求，提供者发回的响应也采用相同的形式。最近SOAP被称为面向服务的架构协 议 (Services-Oriented Architecture Protocol)oSOAP的优点在于它完全和厂商无关，相对于平台、操作系统、目标模型和编程语言可以 独立实现。另外，传输和语言绑定以及数据编码的参数选

31、择都是由实现决定的。3WSDLWeb服务描述语言WSDL (Web Services Description Language)是一个提供描述服务 IDL标准方法的XML词汇Web服务描述语言(WSDL)规范定义了一个XML词汇表，该词汇 表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。我们能够将Web 服务定义为软件，这个软件通过描述SOAP消息接口的WSDL文档来提供可重用的应用程序 功能，并使用标准的传输协议来进行传递。WSDL描述包含必要的细节,以便服务请求者能够使用特定服务： 请求消息格式 响应消息格式向何处发送消息。WSDL是基于XML的，因此WSDL文档是计算机

32、可读的(machine-readable)。这样开 发环境使用WSDL将集成服务的流程自动处理到请求者应用程序。例如WebSphere Studio 产生一个Java的代理对象，它能够像本地对象一样实现服务，但是实际上代理对象仅仅处 理请求的创建和响应消息的解析。不管服务是否用Java、C#或者其他的语言实现，生成的 Java代理对象都能够从WSDL描述中调用任何的Web服务。实际上,WSDL不能像编程语言那 样描述实现细节。4UDDI统一描述、发现和集成(Universal Description, Discovery and Integration)规范 提供了一组公用的SOAP API，

33、使得服务代理得以实现。UDDI为发布服务的可用性和发现所 需服务定义了一个标准接口(基于SOAP消息)。UDDI实现将发布和发现服务的SOAP请 求解释为用于基本数据存储的数据管理功能调用。为了发布和发现其他SOA服务，UDDI通过定义标准的SOAP消息来实现服务注册(Service Regis try)。注册是一种服务代理，它是在UDDI上需要发现服务的请求者和发 布服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开发工具(如M icrosoft Visual St udio .NET)并通过创建以发送请求并处理响应的方式访问服务 的代码来绑定服务。SOA不需要使用UD

34、DI，但由于UDDI是建立在SOA 上来完成自身工作的，所以UDDI是 服务发现的一个好的解决方案。5. ESB如图2所示，企业服务总线ESB (Enterprise Service Bus)是SOA架构的一个支柱技 术。作为一种消息代理架构它提供消息队列系统，使用诸如SOAP或JMS (Java Message Service)等标准技术来实现。# ESP,NETSeivices转换连接层SOAP/HTTP可靠的异步安全通信霞制通信层SOAP/HTTPC/C+ Legacy星賊ligticns谨接层有人把ESB描述成一种开放的、基于标准的消息机制，通过简单的标准适配器和接口, 来完成粗粒度应

35、用(比如服务)和其他组件之间的互操作。ESB的主要功能有：通信和消息处理、服务交互和安全性控制、服务质量和服务级别管 理、建模、管理和自治、基础架构智能等。SOA 的不足作为一个具有发展前景的应用系统架构，SOA尚处在不断发展中，肯定存在许多有待改 进的地方。随着标准和实施技术的不断完善，这些问题将迎刃而解，SOA应用将更加广泛。缺憾之一：可靠性(Reliability)SOA还没有完全为事务的最高可靠性 不可否认性(nonrepudiation)、消息一定会被 传送且仅传送一次(once-and-only-once delivery)以及事务撤回(rollback)做好准备，不过等标准和实施

36、技术成熟到可以满足这一需求的程度并不遥远。缺憾之二：安全性(Security)在过去，访问控制只需要登录和验证；而在SOA环境中，由于一个应用软件的组件很容 易去与属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性 就复杂得多了。缺憾之三：编排 (Orchestration)统一协调分布式软件组件以便构建有意义的业务流程是最复杂的，但它同时也最适合面 向服务类型的集成，原因很显然，建立在SOA 上面的应用软件被设计成可以按需要拆散、重 新组装的服务。作为目前业务流程管理(BPM)解决方案的核心，编排功能使IT管理人员能 够通过已经部署的套装或自己开发的应用软件的功能，把

37、新的元应用软件(meta-application)连接起来。事实上，最大的难题不是建立模块化的应用软件，而是 改变这些系统表示所处理数据的方法。缺憾之四：遗留系统处理(Legacy support)SOA中提供集成遗留系统的适配器，遗留应用适配器屏蔽了许多专用性API的复杂性和 晦涩性。一个设计良好的适配器的作用好比是一个设计良好的SOA服务：它提供了一个抽象 层，把应用基础设施的其余部分与各种棘手问题隔离开来。一些厂商就专门把遗留应用软件 “语义集成”到基于XML的集成构架中。但是集成遗留系统的工作始终是一种挑战。缺憾之五 ：语义 Semantics定义事务和数据的业务含义，一直是IT管理人

38、员面临的最棘手的问题。语义关系是设 计良好SOA架构的核心要素。就目前而言，没有哪一项技术或软件产品能够真正解决语义 问题。为针对特定行业和功能的流程定义并实施功能和数据模型是一项繁重的任务，它最终 必须由业务和IT管理人员共同承担。不过，预制组件和经过实践证明的咨询技能可以简化 许多难题。采用XML技术也许是一个不错的主意。许多公司越来越认识到制定本行业XML标准的重 要性。譬如，会计行业已提议用可扩展业务报告语言(XBRL)来描述及审查总账类型的记录。重要的是学会如何以服务来表示基本的业务流程。改变开发方式需要文化变迁，相比之 下，解决技术难题只是一种智力操练。性能(performance

39、)： SOA的第六个缺憾？批评SOA的人士经常会提到性能是阻碍其采用的一个障碍，但技术的标准化总需要在速 度方面有一些牺牲。这种怀疑观点通常针对两个方面：SOA的分布性质和Web服务协议的开 销。不可否认，任何分布式系统的执行速度都不如独立式系统，这完全是因为网络的制约作 用造成的。当然，有些应用软件无法容忍网络引起的延迟，例如那些对实时性要求很高的应 用软件。所以在应用SOA架构之前，搞清楚它的适用范围就显得很重要了。除了上述几点之外，笔者认为还有两点也颇值得关注：松耦合和敏捷性要求之间的权衡难题:服务松耦合设计其实是一把双刃剑，在带来应变敏捷性的同时，也给业务建模和服务划 分带来难题。这就是为什么在SOA讨论中，业务建模的争论总是最多的原因。跨系统集成难题：面向服务的体系结构设计将跨越计算机系统，并且还可能跨越企业边界。我们不得不考 虑在使用Internet时安全性功能和需求，以及如何链接伙伴的安全域。Internet协议并 不是为可靠性(有保证的提交和提交的顺序)而设计的，但是我们需要确保消息被提交并被 处理一次。当这不可能时，请求者必须知道请求并没有被处理。