SOA

精品文档你我共享AAAAAA1.SOA的定义面向服务的体系结构（service-orientedarchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务，Service），通过这些服务之间定义良好的接口和契约（Contract）联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在各种这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立接口的定义（没有强制绑定到特定的实现上）的特征被称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（Ondemand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。从这个定义中，我们看到下面两点：●它是一种软件系统架构。SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构。它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它其实更像一种架构模式(Pattern)，是一种理念架构，是人们面向应用服务的解决方案框架。●服务（service）是整个SOA实现的核心。SOA架构的基本元素是服务，SOA指定一组实体（服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约），这些实体详细说明了如何提供和消费服务。遵循SOA观点的系统必须要有服务，这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的，并且可以通过网络查找其地址。2．SOA三种角色的关系图1是W3C给出的SOA模型中三种不同角色的关系示意图。其中：服务是一个自包含的、无状态（stateless）的实体，可以由多个组件组成。它通过事先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务（transaction）等离散性任务。服务本身并不依赖于其他函数和过程的状态。用什么技术实现服务，并不在其定义中加以限制。服务提供者（serviceprovider）提供符合契约（contract）的服务，并将它们发布到服务代理。服务请求者（serviceconsumer）也叫服务使用者，它发现并调用其他的软件服务来提供商业解决方案。从概念上来说，SOA本质上是将网络、传输协议和安全细节留给特定的实现来处理。服务请求者通常称为客户端，但是，也可以是终端用户应用程序或别的服务。服务代理者（ServiceBroker）服务请求者（ServiceConsumer）服务提供者（ServiceProvider）服务查找（Find）服务发布（Publish）服务绑定（Bind）ServiceContract服务契约客户（Client）服务（Service）精品文档你我共享AAAAAA服务代理者（servicebroker）作为储存库、电话黄页票据交换所，产生由服务提供者发布的软件接口。这三种SOA参与者：服务提供者、服务代理者以及服务请求者通过3个基本操作：发布（publish）、查找（find）、绑定（bind）相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务，并绑定到这些服务上。服务提供者和服务请求者之间可以交互。所谓服务的无状态，是指服务不依赖于任何事先设定的条件，是状态无关的（state-free）。在SOA架构中，一个服务不会依赖于其他服务的状态。它们从客户端接受服务请求。因为服务是无状态的，它们可以被编排(orchestrated)和序列化（sequenced）成多个序列(有时还采用流水线机制)，以执行商业逻辑。编排指的是序列化服务并提供数据处理逻辑。但不包括数据的展现功能。3．SOA的特征基于上面的讨论，我们给出SOA的下面一些特征：●服务的封装（encapsulation）。将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变，使得用户远离具体实施上的变更。●服务的重用（reuse）。服务的可重用性设计显著地降低了成本。为了实现可重用性，服务只工作在特定处理过程的上下文（context）中，独立于底层实现和客户需求的变更。●服务的互操作(interoperability)。互操作并不是一个新概念。在CORBA、DCOM、webservice中就已经采用互操作技术。在SOA中，通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。SOA提供服务的互操作特性更有利于其在多种场合被重用。●服务是自治的（Autonomous）功能实体。服务是由组件组成的组合模块，是自包含和模块化的。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NETRemoting、EJB、COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时，这些组件的寿命也随之结束。这样当宿主本身或者其他功能部分出现问题的时候，在该宿主上运行的其他应用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)、消息队列(MessageQueue)冗余部署(RedundantDeployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。●服务之间的松耦合度(LooslyCoupled）。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作，请求消息和响应，而不是通过使用API和文件格式。这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码（如COBOL）的实现完全用基于Java语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的通信协议。●服务是位置透明的(locationtransparency）。服务是针对业务需求设计的。需要反映需求的变化，即所谓敏捷（agility）设计。要想真正实现业务与服务的分离，就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。4．三个抽象级别从概念上讲，SOA中有三个主要的抽象级别：精品文档你我共享AAAAAA●操作：代表单个逻辑工作单元（LUW）的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA操作可以直接与面向对象(OO)的方法相比。它们都有特定的结构化接口，并且返回结构化的响应。同方法一样，特定操作的执行可能涉及调用附加的操作。●服务：代表操作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的粒度（granularity）大小也与系统的性能息息相关。粒度太小，会增加服务间互操作通信的开销；粒度太大，又会影响服务面对需求变化的敏捷性。●业务流程：为实现特定业务目标而执行的一组长期运行的动作或活动。业务流程通常包括多个业务调用。在SOA中，业务流程包括依据一组业务规则按照有序序列执行的一系列操作。操作的排序、选择和执行称为服务或流程编排。典型的情况是调用已编排服务来响应业务事件。从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征，以及如何系统地构造它们。这些涉及服务建模、特征抽取的问题已经成为现阶段人们关注的焦点。SOA应用系统总体框架及相关概念看到SOA的一堆名词，读者可能会感到迷惑，有必要结合实际的应用环境进一步阐释SOA的相关概念。总体框架图1所示的就是一个SOA应用系统的大体框架结构。它大体上可以分为五个部分：●展现层（presentation）：图1中5区，通过portal等技术建立展现平台，方便用户在这个界面上提出服务请求。●业务处理建模（businessprocessmodeling）：图1中的4区，SOA元模型从MDA中继承了平台无关模型来对业务处理过程建模。这一部分独立于服务设计和部署层。模型驱动架构MDA（ModelDrivenArchitecture）的主要缺陷是在模型设计阶段就对需求有完整的描述，而且没有需求变更的反馈机制。SOA通过添加敏捷方法AM来应对需求变更的情况。●服务层(Services):图1中的3区，整个SOA的核心层，它承上启下，对上响应业务模型，对下调用相关组件群完成业务需求,形成“业务驱动服务、服务驱动技术”的SOA事务处理格局。服务可以根据粒度分层。虽然细粒度提供了更多的灵活性，但同时也意味着交互的模式可能更为复杂。粗粒度降低了交互复杂性，但敏捷性却下降。●企业组件层（enterprisecomponents）：图1中的2区，这里是相关组件发挥作用的场所。这些组件是平台相关的。因为到了这一层，许多底层软硬件平台的特性已经不再透明了。精品文档你我共享AAAAAA●系统软件层(OperationalSystem):图1中的1区，这一层包括操作系统、数据库管理系统、CRM、ERP、商业智能(BI)等异构系统，是一个集成的平台。除此之外，诸如QoS、安全性等(图1中7区)也是SOA架构的组成部分。在上面的介绍中，自上而下有一条线，如图2所示，由业务建模开始，通过定义业务过程，得到服务模型，它是平台无关的，实现了模型与实现的分离。再通过设计组件群，得到平台相关的组件模型。实施原则JasonBloomberg在其《PrinciplesofSOA》中指出，SOA的实践必须遵循以下原则：●业务驱动服务，服务驱动技术。从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系;另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。●业务敏捷是基本的业务需求。SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统以上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。●一个成功的SOA总在变化之中。SOA工作的场景，更像是一个活的生物体，而不是像传统所说的“盖一栋房子”。IT环境惟一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求有崭新的思维方式。SOA的基础还是一些类似的架构准则。与其他概念的关系1.SOA与WebServices的关系SOA构架是独立于技术实现的。SOA并不必用WebServices来实现，相反，WebServices也并不一定遵循SOA标准。不过，WebServices的特性十分适合用来实现SOA架构。WebServices之间能够交换带结构的文档（比如XML），这些文档可能包含完全异构的数据信息。这些文档可以同时附带关于数据的数据：元数据（metadata）。换句话说，WebServices可以有较粗的粒度，这样较粗的粒度正好可以构成SOA中服务的粒度。说到底，两者是相交的圆，SOA服务和WebServices之间的区别还在于设计。SOA概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，WebServices在需