当前位置：文档之家 › SOA技术规范

SOA技术规范

  • 格式：doc
  • 大小：195.00 KB
  • 文档页数：20

欢迎阅读

1. 服务分析规范

1.1. 服务特征与粒度

1.1.1. 服务特征

候选服务的特征是：

 提供一定的功能性，有构成服务的前提条件

 可能转变到服务

 有待经过评审流程的确认

 通过评审的候选服务，成为服务：

 有明确的范围和业务价值

 可能被实现，也可能需要构建

 具备契约、接口及实现

服务是网络中可用的软件资源。服务提供者通过标准机制提供服务，服务使用者通过网络有计划性地使用服务。服务代理发布服务所在位置，并在使用者请求服务时定位服务。服务使用者和提供者的角色不是唯一的；服务提供者也可以是使用者，反之亦然。

下图显示了 SOA 中的三个基本角色（服务提供者、使用者和代理）及其各自的分工和操作。

图：SOA 的角色和交互

提供者在服务约定中以标准语言描述其服务，并向代理发布服务。客户从服务代理处（或登记处）查询所需的服务，并接收有关服务访问的约定和信息。随后，客户或使用者便可绑定到服务，并可与提供者直接通信。

服务包括两部分：接口和实现

图：服务部件

接口定义了使用者和提供者之间可编程的访问约定。服务接口必须包含以下内容：

 服务的识别

 服务输入和输出数据的详细情况

 服务功能和目的的元数据

服务实现包含了服务的功能或业务逻辑。对于服务使用者来说，服务实现应该是一个“黑匣子”；用户没必要知道服务的功能实现细节。 欢迎阅读

1.1.2. 服务粒度判定原则和方法

服务的粒度可以按基于服务的功能及发送和接收的数据数量来定义服务，如细粒度服务、粗粒度服务或组合服务。

在 SOA 中服务粒度有两种相关的意思：服务是如何实现的，服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能，发送和接收少量的数据。粗粒度服务执行了较大的业务功能，并交换了更多的数据。

细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生在每个服务上的数据量较少，因而会对对系统整体性带来影响。所以细粒度服务的用户不能直接调用他所使用的细粒度服务。然而，由于粗粒度服务可能使用多个细粒度服务，因此它们不能提供粒度级的安全和访问控制。

组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量数量不是粗粒度服务和组合服务之间的区别。

粗粒度服务例子，如创建新客户，在这一过程的操作是：需要通过一些外部服务验证对客户进行验证，并在 营销应用系统中创建客户记录。

组合服务例子可以是提供一个新的DSL线，这需要一个服务调用来验证定单、创建或验证客户，确认产品库存及为数据线分配资源。

下图描述了服务粒度的不同级别及其相互关系。

图：服务粒度

作为复用的服务，应注册到服务总线上进行管理和调用，在未来引入服务注册管理软件后进行统一的命名空间管理，路径管理，Qos，SLA等元数据管理。在注册到服务总线时，要根据域模型来定义管理路径。

1.2. 服务识别方法

服务的识别是从业务模型开始的。根据实施SOA的不同初始点，分为自顶向下和自底向上及基于流程的方式。

通常来说，新建以SOA为建设方法论的系统，我们推荐使用自顶向下的方式，统一的定义划分业务域，根据业务域的业务实体模型来定义在其上的服务，进行服务分类，分离出数据服务，业务服务，复合服务，公用服务，定义好其颗粒度。基于SOA来改造现有系统，要对现有系统进行服务化，根据颗粒度的定义原则提炼出服务。然后基于企业级和部门级的流程来服用服务。 欢迎阅读

自顶向下的服务分析，主要是从全局业务流程的角度出发，按照业务流程的详细程度发现流程中需要调用那些业务系统提供的服务，并且需要提供哪些流程服务注册到业务服务总线上被业务系统调用。

自底向上的服务分析，则需要各业务系统开发上在自己业务系统内部的角度把可重用的组件服务话，把需要被全局业务流程调用的服务发布出来，注册在业务服务总线上统一管理。

物资系统采用自顶向下为主的服务建设策略，从Maxim导出的服务以自底向上的方式推到服务模型。

1.2.1. 服务分类和抽象

服务可以分为以下五种类型：

 数据访问允许对不同数据源进行统一访问。

 组件—提供对打包应用服务的访问，如?ERP。

 业务—提供使用一个以上打包应用或定制应用功能的复杂服务。

 组合—使用以上三种类型的服务来创建包括新功能和现有功能的新服务。

 共享的或企业基础架构服务?—?消息日志之类的低级服务，其重用性使快速创建新的高级服务成为可能。

1.2.1.1. 信息访问服务

信息访问服务允许用户对来自于企业内各种有关或无关数据源的数据进行访问、集成和处理。这些服务通常隐藏了对数据源的直接访问、底层格式的复杂性以及数据的直接转换和处理。信息访问服务提供了跨应用的统一API、松散耦合、公共数据模型和一致性信息的重用。

信息访问服务是SOA架构中最为普通、使用最为广泛和最易于实现的服务；将数据层和应用层进行分离通常是非常简单的。由于数据源被广泛地访问和共享，因此它们成为了服务实现的第一目标。

XML 被广泛地应用于应用数据交换。在 SOA 实施中，一个能够提供与数据源无关的、抽象化统一数据访问的基础架构是非常有价值的。XML 数据服务 (XDS) 提供了对多种类型数据源的访问和数据建模能力，并能够将物理数据翻译和转换为逻辑数据，还支持对逻辑数据的基于 XML欢迎阅读

的访问。

1.2.1.2. 组件服务

组件服务是由单个企业资源（无论其是否为ERP、CRM或SCM之类的打包应用）发布的粗粒度服务。“在ERP 中添加客户”就可以作为组件服务的一个范例。这些服务非常有价值，可以直接发布。

组件服务的实现采用了单独的应用API，以提供重用功能。这些服务可以采用分布式计算技术来实现，如 J2EE EJB、COM/DCOM和CORBA。

1.2.1.3. 业务服务

业务服务是功能性的，体现在业务应用中，负责执行一个或多个业务操作。业务服务通常由跨多个应用的多个业务事务组成。其可能是端到端的业务流程，例如：处理新招聘；或者可能作为更大型业务流程的一部分，如以下示例所示：

 业扩

 增加新员工

业扩需要作为更大型业务流程——如“业扩业务受理”的一部分，它需要该流程中的信息来完成业务功能。

1.2.1.4. 组合服务

组合服务是通过将全新逻辑与现有应用（如业务或组件服务）中的事务进行有机组合而创建的。服务总线和业务流程管理工具在组合应用的创建过程中扮演了关键的角色。

特定功能门户（如营销门户和员工门户）是典型的组合应用，其中需要业务、组件和数据服务。

1.2.1.5. 企业基础架构服务

服务注册和目录服务

服务注册和服务目录是SOA平台系统最为基础的服务。 欢迎阅读

服务注册消除服务之间访问的位置关系，使服务调用更为透明。服务注册提供下面的主要功能：

 核心服务，包括复制、UDDI数据存储和安全

 信息服务，包括数据验证、SOA映射、高级分类以及业务信息访问服务

 生命周期服务，包括批准和更改管理、更改通知、业务服务发现和QoS管理

服务目录库是在服务生命周期（从项目初期到完成）中管理元数据的关键组件。其主要目的是存储详细元数据以便在部署前管理和治理资产。服务目录库的主要功能包括：

 服务元数据存储和管理，包括发布和发现元数据，服务依赖管理管理，服务资产版本控制等。

 服务资产使用分析，包括利用率分析，合规分析等，用于在进行更改前预测性地测量更改的影响。

 提供服务发布批准工作流。

安全服务

安全服务是附加在整个SOA平台上的信息安全控制，其目的在于提供安全可靠的解决方案，从而为系统的安全建立基础，提供基本的安全服务，这些服务包括认证、授权、完整性、机密性、可审计性等，确保系统在一定接入水平上的机密性、完整性和可用性。安全服务具备以下几个关键功能：

 身份和策略数据库：用来存储身份和身份属性数据、审核数据、配置信息、策略等。用户包括企业员工、客户和合作伙伴等。通常目录服务可以提供统一的用户身份存储、策略和日志信息，作为集中的用户部署信息库，是认证和访问控制服务的基础。

 用户身份管理：可以提供身份生存周期管理服务，确保用户身份生命周期的各个方面都得到安全、有效的管理，例如密码管理、工作流和同步逻辑。并提供一组客户和管理员附加组件，用于简化身份管理架构的交互和管理。

 访问控制：根据既定的身份和策略数据库实现基于角色和策略的认证和授权。

 支持性安全技术：能够支持多种的认证方式，如PKI技术、认证技术（智能卡、令牌、生物认证）、加密技术等。

 支持系统间的单点登录。

 集中监控用户的访问尝试，提供集中的审计日志服务。 欢迎阅读

2. 服务定义规范

2.1. 服务定义描述

服务是一个软件组件，具有明确的功能，通常封装着业务或者数据。服务由接口、合约和实现组成。

从另外一个角度，我们也可以用下图描述服务定义：

2.1.1. 服务合约和描述

根据SOA的要求，服务消费者功过服务接口调用服务，无需了解服务实现的细节。服务的合约描述为服务消费者提供了该服务相关的服务信息，这些信息使得服务消费者可以决定是否调用该服务。通常，服务合约描述以下关键信息（但并不限定在此范围）：

服务存在：服务名称，服务版本，服务拥有者；

服务类型：包括表示服务、流程服务、业务服务、数据服务等。

服务业务功能定义：即描述该服务完成的业务功能。

服务调用的约束条件和策略：包括安全，服务质量（QoS），事务，服务级别协议（SLA），如何与服务交互，比如交互协议，输入和输出单元及格式；

交互协议包括SOAP、非SOAP的消息、FTP、SMTP/POP以及一些遗留协议等。

2.1.2. 服务接口

服务接口就是一组提供服务消费者调用的交互端口，服务接口将服务的功能向服务消费者（客户通过网络连接到这个服务）公开。接口描述是服务合约的一部分，包括操作协议，接口名，交换信息等，同样需要一组标准的名称进行描述，通常采用XML描述。但接口的物理实现是服务实现的一部分。

2.2. 服务定义输出模板

1物资采购单汇总的服务定义：

服务编码 标识服务的唯一编码，如：00000001

合集下载

ERP与SOA相结合——基于SOA的ERP体系架构的研究

ERP与SOA相结合——基于SOA的ERP体系架构的研究

Ｅ　Ｒ　Ｐ与ＳＯＡ相结合　——基于ＳＯＡ的ＥＲＰ体系架构的研究　文：悠虎　近年来，ＥＲＰ在我国已被越来越多的企业认同和接受。实施ＥＲＰ　已成为企业信息化的重要标志之一。但目前大多数企业在应用ＥＲＰ　系统时均面临着系统重用和集成以及流程敏捷化两方面的问题。　如何使ＥＲＰ系统具有快速可重构性，能动态调整其结构和行为，　以支持企业的管理创新与流程重组优化，并能和企业现有的其他应用　系统实现无缝集成，已成为当前的一个挑战。因此。本文基于软件复　用、软件构件等技术。提出一种基于ＳＯＡ的ＥＲＰ体系架构模型，以满　足企业业务流程重组的需要并具有可靠性、复用性、易扩展性和动态　可变性的特点，实现为企业“量身定制”。　一、面向服务架构（ＳＯＡ）的工作原理　（一ＪＳＯＡ的定义　面向服务架构是一个组件模型，它将应用程序的不同功能单元　（称为服务）通过其间定义良好的接１：３和契约联系起来。服务是指定义　良好的、自包含的、不依赖于上下文和其他服务的一组功能。接口是采　用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统　和编程语言。　（二）ＳＯＡ的体系结构　在面向服务架构中主要有三种角色：　１．服务消费者：利用服务注册中心查找所需的服务，然后使用该　服务。２．服务提供者：是创建服务的实体，并且对使用自身服务的请求　进行响应。３．服务注册中心：注册已经发布的服务，对其进行分类，并　提供搜索服务。它相当于一个服务信息的数据库，为服务提供者与服　务消费者提供一个平台，使两者可以各取所需，同时服务注册中心要　有一个通用的标准，使服务提供商提供的服务符合这个标准。这样，服　务消费者使用的服务才可以跨越不同的服务提供者。　在ＳＯＡ的体系结构中，每个实体的角色不是固定不变的，一个实　体可以同时充当以上三种角色中的一个或多个。　在面向服务的体系结构中主要的操作有：１．发布：使服务提供者　可以向服务注册中心注册自己的功能及访问接口。２．发现：使服务请　求者可以通过服务注册中心查找特定种类的服务。３．绑定和调用：在　获得服务描述信息之后，服务消费者据此去调用服务。　目前，实现ＳＯＡ的技术很多，比如Ｗｅｂ　Ｓｅｒｖｉｃｅｓ、ＣＯＲＢＡ等，这　些技术一个很重要的共同点就是支持在不同的平台上、以不同语言编　写的各种程序以基于标准的方式相互通信。例如，作为ＳＯＡ的一种实　现手段。Ｗｅｂ服务提供了基于可扩展标记语言（ＸＭＬ）的标准接口，具　有完好的封装性、松散的耦合性、协议规范的标准性以及高度的可集　成性等特点，能够良好地满足ＳＯＡ应用模式的需求。目前已经有～系　列基于ＸＭＬ的Ｗｅｂ服务标准被业界广泛接受。形成了Ｗｅｂ服务的　核心技术。服务的提供者可以用Ｗｅｂ服务描述语言（Ｗｅｂ　Ｓｅｒｖｉｃｅｓ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｌａｎｇｕａｇｅ，ＷＳＤＬ）描述Ｗｅｂ服务；用统一描述、发现与　集成（Ｕｎｉｖｅｒｓａｌ　Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ　ａｎｄ　Ｉｎｔｅｇｒａｔｉｏｎ，ＵＤＤＩ）注册　中心发布、注册Ｗｅｂ服务；服务的请求者通过ＵＤＤＩ进行查询，发现　所需的服务后可以利用简单对象访问协议（Ｓｉｍｐｉｅ　Ｏｂｊｅｃｔ　Ａｃｃｅｓｓ　Ｐｒ￣ｏｃｏｌ，ＳＯＡＰ）来绑定、调用这些服务。　（三）ＳＯＡ的特点　与传统开发方法相比，ＳＯＡ架构具有以下几个典型特点：　１．标准化的接口。近年来出现的两个重要标准ＸＭＬ和Ｗｅｂ服务　使得ＳＯＡ得以真正实现。Ｗｅｂ服务使应用功能得以通过标准化接口　提供，并可基于标准化传输方式、采用标准化协议进行调用。采用　ＸＭＬ，开发人员无须了解特定的数据表示格式，便能够在这些应用间　交换数据。　２．松耦合性。通过接口中立。避免了修改一个服务的代码对其他　服务的影响，使开发者能够大量的迁移或取代单个服务而不影响总的　组合应用程序。　３．位置透明性。位置透明性指的是ＳＯＡ系统中的所有服务对于　他们的调用来说都是位置透明的，也就是说每个服务的调用者只需要　知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位　置在哪。　４．服务的可重用性。服务的可重用性设计显著地降低了成本。为　了实现可重用性。服务只工作在特定处理过程的上下文中，

SOA实例

SOA实例

SOA实例

汽车工作订单（Automotive Work Order）描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。

工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行 50,000 英里服务，更换刹车片或轮胎，或者换油。

业务场景如下：

 当顾客打电话预约时创建工作订单。

 为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。

 在安排预约之前确保所有必需的零件都有库存。

 需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。

 计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。

 在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。

 当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。

 记录所用的零件和备件的实际价值以及劳务。

 在完成所有的维修时计算总费用。

 创建发票并且将其交给顾客。

工作订单的流程示意图：

工作订单的类图实例：

上面这些都是OOAD的设计，它包含了所有的业务规则，并且需要很好理解它的业务流程。IBM提出这种设计的缺点：

 许多步骤涉及到遗留系统和数据库的连接，它们不可能遵循OO范式来进行设计。

 如果修改流程或者工作流，那么里面的代码就必须更改。

所以IBM提供了用SOAD的解决方案，提出应该对服务进行分组，而不是对服务还有它的行为跟数据进行封装。

工作订单的服务模型示例：

工作订单的业务流程模型：

工作订单的业务交互模型：

跟OOAD的设计对比一下，就能看出为什么SOA那么受追捧。OOAD各种类和对象之间的关系是错综复杂的，相互之间的调用都牵涉到业务流程，一旦业务做出改动，那么整个设计都得产生很大的变动。SOAD的方法把服务跟流程分离出来，服务模型里面只需定义本地服务的接口和操作，不需理会这个流程是按照什么顺序去走的。因为一个流程可能牵涉好多个服务，多个服务之间的前后顺序可能需要根据业务的需求进行调整，如果服务之间是相互独立，那么流程的改变就不会影响到服务的设计。取上面的例子，制定一个订单过程中，除了订单处理，还有日程安排、检查库存、客户服务等等，如果是OOAD，可能订单处理的类里面就要加入日程、库存和客服的对象或者方法，那么一旦需要增加新的业务流程，那么就需要修改这个类的设计；如果换成SOAD，就可以制定不同的业务流程，调用不同的服务和顺序来达到目的，而不需要去改动任何设计。

SOA详解

SOA详解

SOA代表了面向服务的架构。如果你正在准备采取SOA，以下SOA的面试问题和答案可能对你非常有用。基本上，这些SOA的面试题涵盖了整个SOA。涉及SOA的服务特点和原理，服务，合同，地址和绑定的松耦合，SOA对于业务和IT的主要优点，服务与组件的差别，SOA的业务需求等等。

1. 什么是SOA的服务？

在现实世界中，服务是一种我们花费购买到的一种预期的服务。

例1 （来自真实世界） ：你去餐馆订餐，您的订单首先进入到柜台，然后在厨房进行食物准备，最后服务员提供的食物。因此，为了实现一个餐厅订购服务，您需要三个逻辑部门/服务协同工作（计帐，厨房和服务员）。在软件世界同样的方法称为业务服务。

例2 （软件世界） ：你去亚马逊订购了一本书，有不同的服务，如支付网关，库存系统，货运系统等共同完成一本书的订购。

所有的服务是自包含的，合乎逻辑。他们就像黑盒子。总之，我们并不需要了解业务服务的内部工作细节。对于外部世界，它只是一个能够使用消息交互的黑盒子。例如在“支付网关”业务服务获得消息“检查信贷”后会给出输出：这个客户的信贷有或没有。对于“订单系统”，“支付网关”的服务是一个黑盒子。

2.服务的主要特点是什么？

以下是服务的SOA的主要特点：

A） SOA组件是松耦合的。当我们说松耦合，这意味着每一个服务是自包含单独存在的逻辑。举例来说，我们采取了“支付网关”的服务，并将它附加到不同的系统。

B） SOA服务是黑匣子。在SOA中，服务隐藏有内在的复杂性。他们只使用交互消息，服务接受和发送消息。通过虚拟化一个服务为黑盒子，服务变得更松散的耦合。

C） SOA服务应该是自定义： SOA服务应该能够自己定义。

D） SOA服务维持在一个列表中： SOA服务保持在一个中央存储库。应用程序可以在中央存储库中搜索服务，并调用相应服务。

E） SOA服务可以编排和链接实现一个特定功能： SOA服务可以使用了即插即用的方式。例如，“业务流程”中有两个服务“安全服务”和“订单处理服务” 。从它的业务流程可以实现两种类型：一，您可以先检查用户，然后处理订单，或反之亦然。是的，你猜对了，使用SOA可以松散耦合的方式管理服务之间的工作流。

SOA

SOA

SOA解决方案横向评述

佳讯飞鸿AnyTouch统一CTI应用平台

优点 该方案为CTI中间件，属于基于电子渠道面向客户提供远程服务的行业应用领域，具体来讲，主要用于呼叫中心、电信语音服务等，包括电话远程人工服务、自动语音服务等。方案对人工坐席、语音、录音、运营管理和统计分析等环境进行了集成，形成了统一的中间件环境，这种设计具有独到之处。本方案最大的特点在于把涉及呼叫中心的各种软件和硬件环境集成到一个中间件环境中。

产品集成是呼叫中心建设面临的一个难点问题。呼叫中心包括交换机、CTI、IVR、录音和应用系统等等，技术点很多，因此呼叫中心项目往往具有很大的不确定性，大型呼叫中心的投资会是千万元级的，而微型的呼叫中心可能只有十几万的规模，这中间的差异一方面是需求导致的，另一方面则是集成的产品的差异。因此，基于统一的关于呼叫中心的集成中间件（建议本产品采用这样的名称），呼叫中心各个产品之间互操作的复杂性可以被屏蔽，从而使我们在针对用户的需求规划与呼叫中心的具体解决方案时，能够在一个统一、标准的环境下完成，系统建设可控性也将大大提高。

该方案能够根据企业的实际情况定制各种呼叫中心的业务，同时具备良好的开放性; 能够与企业已有的各种信息化系统融合，实现呼叫中心与各办公信息化系统的结合; 能够同时实现所有的电信增值业务，并为这些各不相同的电信增值业务提供统一的集成开发环境。方案从整体系统性能和可扩展性的角度考虑，采用模块化的分层设计思想，通过对呼叫中心和电信增值业务等应用特性的详细分析，在系统设计时服务层和管理层都提供了强大的图形化集成开发工具和各种管理工具。

另外，方案还详细描述了各主要组成部分的功能和特点、平台的性能数据以及呼叫高峰时期的解决方法，提供了方便使用的服务开发工具、接口开发包以及与其他系统连接的方式，而且还通过支持主流的硬件设备，使系统遵循通信网和计算机网方面的各种主流标准，同时，还紧密结合行业需求。基于这些原因，该方案受到业内用户的欢迎也不足为奇。