SOA技术规范Word文档格式.docx

上传人:b****3 文档编号:13644188 上传时间:2022-10-12 格式:DOCX 页数:25 大小:302.40KB
下载 相关 举报
SOA技术规范Word文档格式.docx_第1页
第1页 / 共25页
SOA技术规范Word文档格式.docx_第2页
第2页 / 共25页
SOA技术规范Word文档格式.docx_第3页
第3页 / 共25页
SOA技术规范Word文档格式.docx_第4页
第4页 / 共25页
SOA技术规范Word文档格式.docx_第5页
第5页 / 共25页
点击查看更多>>
下载资源
资源描述

SOA技术规范Word文档格式.docx

《SOA技术规范Word文档格式.docx》由会员分享,可在线阅读,更多相关《SOA技术规范Word文档格式.docx(25页珍藏版)》请在冰豆网上搜索。

SOA技术规范Word文档格式.docx

提供者在服务约定中以标准语言描述其服务,并向代理发布服务。

客户从服务代理处(或登记处)查询所需的服务,并接收有关服务访问的约定和信息。

随后,客户或使用者便可绑定到服务,并可与提供者直接通信。

服务包括两部分:

接口和实现

服务部件

接口定义了使用者和提供者之间可编程的访问约定。

服务接口必须包含以下容:

服务的识别

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

服务功能和目的的元数据

服务实现包含了服务的功能或业务逻辑。

对于服务使用者来说,服务实现应该是一个“黑匣子”;

用户没必要知道服务的功能实现细节。

服务粒度判定原则和方法

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

在SOA中服务粒度有两种相关的意思:

服务是如何实现的,服务使用和返回了多少数据或多少消息。

细粒度服务执行了最小的功能,发送和接收少量的数据。

粗粒度服务执行了较大的业务功能,并交换了更多的数据。

细粒度服务是供粗粒度服务或组合服务使用的,而不是由终端应用直接使用的。

如果应用是使用细粒度服务建立的,则应用将不得不调用网络上多个服务,并且发生在每个服务上的数据量较少,因而会对对系统整体性带来影响。

所以细粒度服务的用户不能直接调用他所使用的细粒度服务。

然而,由于粗粒度服务可能使用多个细粒度服务,因此它们不能提供粒度级的安全和访问控制。

组合服务可以使用粗粒度服务和细粒度服务进行组装。

数据数量数量不是粗粒度服务和组合服务之间的区别。

粗粒度服务例子,如创建新客户,在这一过程的操作是:

需要通过一些外部服务验证对客户进行验证,并在营销应用系统中创建客户记录。

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

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

服务粒度

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

在注册到服务总线时,要根据域模型来定义管理路径。

1.2.服务识别方法

服务的识别是从业务模型开始的。

根据实施SOA的不同初始点,分为自顶向下和自底向上及基于流程的方式。

通常来说,新建以SOA为建设方法论的系统,我们推荐使用自顶向下的方式,统一的定义划分业务域,根据业务域的业务实体模型来定义在其上的服务,进行服务分类,分离出数据服务,业务服务,复合服务,公用服务,定义好其颗粒度。

基于SOA来改造现有系统,要对现有系统进行服务化,根据颗粒度的定义原则提炼出服务。

然后基于企业级和部门级的流程来服用服务。

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

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

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

服务分类和抽象

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

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

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

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

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

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

1.2.1.1.信息访问服务

信息访问服务允许用户对来自于企业各种有关或无关数据源的数据进行访问、集成和处理。

这些服务通常隐藏了对数据源的直接访问、底层格式的复杂性以及数据的直接转换和处理。

信息访问服务提供了跨应用的统一API、松散耦合、公共数据模型和一致性信息的重用。

信息访问服务是SOA架构中最为普通、使用最为广泛和最易于实现的服务;

将数据层和应用层进行分离通常是非常简单的。

由于数据源被广泛地访问和共享,因此它们成为了服务实现的第一目标。

XML被广泛地应用于应用数据交换。

在SOA实施中,一个能够提供与数据源无关的、抽象化统一数据访问的基础架构是非常有价值的。

XML数据服务(XDS)提供了对多种类型数据源的访问和数据建模能力,并能够将物理数据翻译和转换为逻辑数据,还支持对逻辑数据的基于XML的访问。

1.2.1.2.组件服务

组件服务是由单个企业资源(无论其是否为ERP、CRM或SCM之类的打包应用)发布的粗粒度服务。

“在ERP中添加客户”就可以作为组件服务的一个例。

这些服务非常有价值,可以直接发布。

组件服务的实现采用了单独的应用API,以提供重用功能。

这些服务可以采用分布式计算技术来实现,如J2EEEJB、COM/DCOM和CORBA。

1.2.1.3.业务服务

业务服务是功能性的,体现在业务应用中,负责执行一个或多个业务操作。

业务服务通常由跨多个应用的多个业务事务组成。

其可能是端到端的业务流程,例如:

处理新招聘;

或者可能作为更大型业务流程的一部分,如以下示例所示:

业扩

增加新员工

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

1.2.1.4.组合服务

组合服务是通过将全新逻辑与现有应用(如业务或组件服务)中的事务进行有机组合而创建的。

服务总线和业务流程管理工具在组合应用的创建过程中扮演了关键的角色。

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

1.2.1.5.企业基础架构服务

服务注册和目录服务

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

服务注册消除服务之间访问的位置关系,使服务调用更为透明。

服务注册提供下面的主要功能:

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

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

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

服务目录库是在服务生命周期(从项目初期到完成)中管理元数据的关键组件。

其主要目的是存储详细元数据以便在部署前管理和治理资产。

服务目录库的主要功能包括:

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

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

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

安全服务

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

安全服务具备以下几个关键功能:

身份和策略数据库:

用来存储身份和身份属性数据、审核数据、配置信息、策略等。

用户包括企业员工、客户和合作伙伴等。

通常目录服务可以提供统一的用户身份存储、策略和日志信息,作为集中的用户部署信息库,是认证和访问控制服务的基础。

用户身份管理:

可以提供身份生存周期管理服务,确保用户身份生命周期的各个方面都得到安全、有效的管理,例如密码管理、工作流和同步逻辑。

并提供一组客户和管理员附加组件,用于简化身份管理架构的交互和管理。

访问控制:

根据既定的身份和策略数据库实现基于角色和策略的认证和授权。

支持性安全技术:

能够支持多种的认证方式,如PKI技术、认证技术(智能卡、令牌、生物认证)、加密技术等。

支持系统间的单点登录。

集中监控用户的访问尝试,提供集中的审计日志服务。

2.服务定义规

2.1.服务定义描述

服务是一个软件组件,具有明确的功能,通常封装着业务或者数据。

服务由接口、合约和实现组成。

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

服务合约和描述

根据SOA的要求,服务消费者功过服务接口调用服务,无需了解服务实现的细节。

服务的合约描述为服务消费者提供了该服务相关的服务信息,这些信息使得服务消费者可以决定是否调用该服务。

通常,服务合约描述以下关键信息(但并不限定在此围):

服务存在:

服务名称,服务版本,服务拥有者;

服务类型:

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

服务业务功能定义:

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

服务调用的约束条件和策略:

包括安全,服务质量(QoS),事务,服务级别协议(SLA),如何与服务交互,比如交互协议,输入和输出单元及格式;

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

服务接口

服务接口就是一组提供服务消费者调用的交互端口,服务接口将服务的功能向服务消费者(客户通过网络连接到这个服务)公开。

接口描述是服务合约的一部分,包括操作协议,接口名,交换信息等,同样需要一组标准的名称进行描述,通常采用XML描述。

但接口的物理实现是服务实现的一部分。

2.2.服务定义输出模板

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

服务编码

标识服务的唯一编码,如:

00000001

服务中文名称

物资采购单汇总

服务英文名称

PurchaseService

方法名称

AggregateOrder

共享围

部门级

服务目录引用路径

/WebServices/WuziDomain/PurchaseService

服务版本

v0.1

服务发布日期

服务的正式服务日期

服务提供者编码

定义该服务的单位编码,按照《南方电网公司人事信息分类编码》的要求

服务宿主系统编码

提供该服务的应用系统

服务性质编码

描述服务的特性:

01---关键任务服务

02---任务服务

03---高容量服务

04---高水平服务

05---标准服务

服务拥有者

物资公司招标部

服务类型

业务服务

服务业务功能描述

省物资公司招标部门对物资需求进行汇总处理,然后通过省物资公司的MAXIMO系统生成采购申请审批。

交互属性

是否需要人工交互

确认部门

确认服务功能规格的单位、部门或个人。

服务开发单位

实现服务的开发商单位

服务调用的约束条件和策略

安全

HTTPS协议。

数据加密和摘要,认证方式(WS-Security:

UsernameTokenProfile)

服务质量(QoS)

持久化

服务级别协议SLA

相应时间20ms,重试10次

并发性要求

并发量9

可以使用的时间

可以使用该服务的时间段

消息大小估量

输入10KB,输出消息10KB

2地市公司采购单上报的服务定义:

地市公司采购单上报

DeclareService

DeclareMaterial

部门级

/WebServices/WuziDoma

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工作范文 > 制度规范

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1