SOA技术规范
- 格式：doc
- 大小：208.00 KB
- 文档页数：22
1. 效劳分析规
1.1. 效劳特征与粒度
1.1.1. 效劳特征
候选效劳的特征是：
➢ 提供一定的功能性，有构成效劳的前提条件
➢ 可能转变到效劳
➢ 有待经过评审流程确实认
➢ 通过评审的候选效劳，成为效劳：
➢ 有明确的围和业务价值
➢ 可能被实现，也可能需要构建
➢ 具备契约、接口及实现
效劳是网络中可用的软件资源。效劳提供者通过标准机制提供效劳，效劳使用者通过网络有方案性地使用效劳。效劳代理发布效劳所在位置，并在使用者请求效劳时定位效劳。效劳使用者和提供者的角色不是唯一的；效劳提供者也可以是使用者，反之亦然。
以下图显示了 SOA 中的三个根本角色〔效劳提供者、使用者和代理〕及其各自的分工和操作。
图：SOA 的角色和交互
提供者在效劳约定中以标准语言描述其效劳，并向代理发布效劳。客户从效劳代理处〔或登记处〕查询所需的效劳，并接收有关效劳访问的约定和信息。随后，客户或使用者便可绑定到效劳，并可与提供者直接通信。
效劳包括两局部：接口和实现
图：效劳部件
接口定义了使用者和提供者之间可编程的访问约定。效劳接口必须包含以下容：
➢ 效劳的识别
➢ 效劳输入和输出数据的详细情况 ➢ 效劳功能和目的的元数据
效劳实现包含了效劳的功能或业务逻辑。对于效劳使用者来说，效劳实现应该是一个“黑匣子〞；用户没必要知道效劳的功能实现细节。
1.1.2. 效劳粒度判定原则和方法
效劳的粒度可以按基于效劳的功能及发送和接收的数据数量来定义效劳，如细粒度效劳、粗粒度效劳或组合效劳。
在 SOA 中效劳粒度有两种相关的意思：效劳是如何实现的，效劳使用和返回了多少数据或多少消息。细粒度效劳执行了最小的功能，发送和接收少量的数据。粗粒度效劳执行了较大的业务功能，并交换了更多的数据。
细粒度效劳是供粗粒度效劳或组合效劳使用的，而不是由终端应用直接使用的。如果应用是使用细粒度效劳建立的，则应用将不得不调用网络上多个效劳，并且发生在每个效劳上的数据量较少，因而会对对系统整体性带来影响。所以细粒度效劳的用户不能直接调用他所使用的细粒度效劳。然而，由于粗粒度效劳可能使用多个细粒度效劳，因此它们不能提供粒度级的平安和访问控制。
组合效劳可以使用粗粒度效劳和细粒度效劳进展组装。数据数量数量不是粗粒度效劳和组合效劳之间的区别。
粗粒度效劳例子，如创立新客户，在这一过程的操作是：需要通过一些外部效劳验证对客户进展验证，并在 营销应用系统中创立客户记录。
组合效劳例子可以是提供一个新的DSL线，这需要一个效劳调用来验证定单、创立或验证客户，确认产品库存及为数据线分配资源。
以下图描述了效劳粒度的不同级别及其相互关系。
图：效劳粒度
作为复用的效劳，应注册到效劳总线上进展管理和调用，在未来引入效劳注册管理软件后进展统一的命名空间管理，路径管理，Qos，SLA等元数据管理。在注册到效劳总线时，要根据域模型来定义管理路径。
1.2. 效劳识别方法
效劳的识别是从业务模型开场的。根据实施SOA的不同初始点，分为自顶向下和自底向上及基于流程的方式。
通常来说，新建以SOA为建立方法论的系统，我们推荐使用自顶向下的方式，统一的定义划分业务域，根据业务域的业务实体模型来定义在其上的效劳，进展效劳分类，别离出数据效劳，业务效劳，复合效劳，公用效劳，定义好其颗粒度。基于SOA来改造现有系统，要对现有系统进展效劳化，根据颗粒度的定义原则提炼出效劳。然后基于企业级和部门级的流程来服用效劳。
自顶向下的效劳分析，主要是从全局业务流程的角度出发，按照业务流程的详细程度发现流程中需要调用那些业务系统提供的效劳，并且需要提供哪些流程效劳注册到业务效劳总线上被业务系统调用。
自底向上的效劳分析，则需要各业务系统开发上在自己业务系统部的角度把可重用的组件效劳话，把需要被全局业务流程调用的效劳发布出来，注册在业务效劳总线上统一管理。
物资系统采用自顶向下为主的效劳建立策略，从Ma*im导出的效劳以自底向上的方式推到效劳模型。
1.2.1. 效劳分类和抽象
效劳可以分为以下五种类型：
➢ 数据访问允许对不同数据源进展统一访问。
➢ 组件—提供对打包应用效劳的访问，如ERP。
➢ 业务—提供使用一个以上打包应用或定制应用功能的复杂效劳。
➢ 组合—使用以上三种类型的效劳来创立包括新功能和现有功能的新效劳。
➢ 共享的或企业根底架构效劳—消息日志之类的低级效劳，其重用性使快速创立新的高级效劳成为可能。
1.2.1.1. 信息访问效劳
信息访问效劳允许用户对来自于企业各种有关或无关数据源的数据进展访问、集成和处理。这些效劳通常隐藏了对数据源的直接访问、底层格式的复杂性以及数据的直接转换和处理。信息访问效劳提供了跨应用的统一API、松散耦合、公共数据模型和一致性信息的重用。
信息访问效劳是SOA架构中最为普通、使用最为广泛和最易于实现的效劳；将数据层和应用层进展别离通常是非常简单的。由于数据源被广泛地访问和共享，因此它们成为了效劳实现的第一目标。
*ML 被广泛地应用于应用数据交换。在 SOA 实施中，一个能够提供与数据源无关的、抽象化统一数据访问的根底架构是非常有价值的。*ML 数据效劳 (*DS)
提供了对多种类型数据源的访问和数据建模能力，并能够将物理数据翻译和转换为逻辑数据，还支持对逻辑数据的基于 *ML的访问。
1.2.1.2. 组件效劳
组件效劳是由单个企业资源〔无论其是否为ERP、CRM或SCM之类的打包应用〕发布的粗粒度效劳。“在ERP 中添加客户〞就可以作为组件效劳的一个例。这些效劳非常有价值，可以直接发布。
组件效劳的实现采用了单独的应用API，以提供重用功能。这些效劳可以采用分布式计算技术来实现，如 J2EE E、/D和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. 效劳接口
效劳接口就是一组提供效劳消费者调用的交互端口，效劳接口将效劳的功能向效劳消费者〔客户通过网络连接到这个效劳〕公开。接口描述是效劳合约的一局部，包括操作协议，接口名，交换信息等，同样需要一组标准的名称进展描述，通常采用*ML描述。但接口的物理实现是效劳实现的一局部。
2.2. 效劳定义输出模板
1物资采购单汇总的效劳定义：
效劳编码 标识效劳的唯一编码，如：00000001
效劳中文名称 物资采购单汇总
效劳英文名称 PurchaseService
方法名称 AggregateOrder
共享围 部门级
效劳目录引用路径 /WebServices/WuziDomain/PurchaseService
效劳版本 v0.1
效劳发布日期 效劳的正式效劳日期
效劳提供者编码 定义该效劳的单位编码，按照"南方电网公司人事信息分类编码"的要求
效劳宿主系统编码 提供该效劳的应用系统
效劳性质编码 描述效劳的特性：
01---关键任务效劳
