SOA项目设计文档.docx
- 文档编号:24296584
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:38
- 大小:103.78KB
SOA项目设计文档.docx
《SOA项目设计文档.docx》由会员分享,可在线阅读,更多相关《SOA项目设计文档.docx(38页珍藏版)》请在冰豆网上搜索。
SOA项目设计文档
SOA项目设计文档
1SOA概念
随着我国各行业信息化建设的不断深入,企事业单位和政府部门逐步建立起的大批计算机信息系统和各类数据信息因缺乏有效衔接,导致信息资源共享难、“信息孤岛”现象普遍存在。
与此同时,对于企事业单位,随着经济全球化大环境下的市场竞争日益激烈,企业正在通过加快管理转型、技术创新、新产品研发以及业务策略调整等方式来提升自己的核心竞争力、持续占有并扩大市场份额。
对于各级政府部门,在以“大部制”为核心的政府行政管理体制改革的驱动下,以“管理”导向的政府职能正在向“服务”导向转变。
企事业单位和政府部门的这些转型方式及过程的有效实施,一方面更需要信息技术和信息化的手段来支撑,另一方面,这些业务需求也对信息技术和信息化建设本身提出了更高要求:
IT系统(通常也称为“信息系统”、“应用系统”或“软件系统”等)要能快速响应用户业务发展和变化的需求,新系统必须能在充分利用用户原有IT资源基础上快速构建出来,同时要实现跨平台、跨组织的数据共享和业务协同。
SOA(ServiceOrientedArchitecture,面向服务的体系架构)是近年来软件规划和构建的一种新方法,其概念最早由国际咨询机构Gartner公司于1996年首次提出。
由于其本身特性非常符合上述信息化需求和问题的解决思路,因此在2003年以后成为我国软件产业界和各行业用户的关注焦点,并在2006年逐步开始在多个行业信息化建设中被选择和应用。
SOA概念自被提出之后,不少国内外机构、企业均对SOA进行了定义和阐释,但目前还未形成权威、统一的定义。
本书作为国内首部从用户角度对SOA概念和应用进行客观介绍的书籍,在全书中将对SOA做如下定义和说明,以便于用户从应用角度对SOA有直观理解:
SOA不是一种技术,而是一种IT系统和软件的构建方法和过程,贯穿IT系统规划、设计、构建、运维的各个阶段。
SOA与传统的IT系统建设方法和过程有较大区别,简要说明如下:
1.1与传统的建设方法不同
基于SOA的IT系统建设更强调基于统一标准的快速开发和灵活组合。
“服务”是SOA的核心元素,它对应于某个业务流程、业务功能或数据资源,按照统一的规格来组成信息系统。
基于“服务”,SOA能显著缩小用户业务需求与IT支持能力之间的鸿沟,指导IT团队开发出具有良好移植性、扩展性和兼容性的应用系统。
SOA不仅仅站在单个信息系统或集成项目的角度,而是更强调站在用户IT建设全局或行业内信息化建设全局,从而规划并逐步建成统一的IT系统架构模式,并积累可重复使用的信息系统资源库,以实现用户组织内或全行业内的信息资源共享、信息系统协同、新系统的快速构建以及系统对业务变化的快速应变能力。
1.2与传统的建设过程不同
SOA建设过程的重点是基于“服务”的IT系统规划和设计阶段,业务人员将不仅仅是提出需求,而是深入参与各类“服务”的规划和设计。
“服务”间相互独立,所有“服务”的信息可被汇集到统一的服务资源库中,使得用户、其他系统以及其他“服务”可通过服务资源库来访问和使用。
SOA系统的具体开发阶段则是由技术人员依据每个“服务”的功能和范围要求来具体实现或选择已有可用服务,并进行合成与装配。
在SOA系统的运维过程中,业务人员可以自行调整相应的服务,以使IT系统能满足新的业务规则和需求。
此外,与SOA密切相关的还有一个概念——业务流程管理(BPM,BusinessProcessManagement)。
BPM来源于业务流程变革领域,如业务流程再造(BPR)、业务流程建模以及业务流程集成等。
在技术方面,业务流程管理融合了许多相关技术,如流程建模、工作流技术、流程自动化以及业务流程监控等。
借助BPM,通过对业务流程的监控,用户可以及时发现问题,并对业务流程进行不断创新和优化。
而SOA使得这种流程变化更加便捷,从而大大提高了业务的灵活性。
因此,当前SOA系统中大多都包含了BPM的功能和可供用户来开发和管理的技术平台。
近年来,随着SOA技术实现手段、特别是基于标准的互联网技术(如Web服务和XML)不断成熟,SOA发展势头迅猛。
从2006年至今,SOA已经逐渐成为影响中国IT系统构建的主导方法和过程,在我国金融、电信、烟草、电子政务、医疗卫生、企业信息化、B2B、物流以及钢铁制造等行业和领域开始得到应用,关于各行业或领域的SOA应用情况,可参阅本书的第二篇相关内容。
2SOA特点
基于SOA来构建的IT系统具备如下特点:
2.1以业务为中心
SOA更多关注于用户业务,通过业务人员参与SOA系统的规划、设计和管理,使得IT系统能在对业务的深刻理解的基础上进行构建,实现IT系统与用户业务的密切结合。
在具体实施中,通过把完成实际业务流程中的一项任务所需的IT资源组织为服务进行封装,从而达到以业务为核心,通过业务选择技术,避免技术制约业务的问题。
2.2灵活适应变化
IT系统围绕用户业务构建,用户业务在实现层通过表现为一系列松散耦合的“服务”来实现,这些服务可以根据用户需求随需组合,使得IT系统对于业务的适应能力明显提高。
2.3重用IT资源,提升开发效率
SOA强调对“服务”的重用,对原有IT资源的重用度提升是SOA带来的关键效果之一,大量具有高重用的服务资源,为快速构建新的业务功能和业务系统奠定基础,使得IT系统的开发和软件生产效率得到提升。
同时,重用过程有利于保护用户前期的信息化投资和IT资产积累,节省IT系统开发成本,实现用户信息化的可持续性建设与发展。
2.4更强调标准
SOA的实现强调基于统一的标准,SOA系统建立在大量的开放标准和协议之上,以实现系统及信息的互联互通和互操作。
因此,SOA系统从规划到实施,标准都至关重要。
3SOA效益及适用场景
3.1SOA效益
SOA效益主要体现在如下几个方面:
1)提高业务效率和用户满意度
目前,我国企事业单位及政府部门都在强调“服务”能力,各类组织对如何提高服务水平并使IT系统快速响应新业务需求的要求,已经超过了对于IT系统开发效率的要求。
依托“服务”的松耦合性和重用性,通过现有“服务”和IT资产的组装,SOA减少了新业务应用开发的时间,提高了产品和服务的上市速度和开发效率,使得SOA系统中的“服务”和IT资产以更灵活的配置适应新的需求变化,提高了业务效率。
SOA通过创建与具体技术和最终用户设备无关的服务,应用于各种用户服务渠道,以保证一致的用户体验,提高用户的满意度。
2)有利于整合IT资源,提高IT系统的对外协作能力
不少行业的企事业单位实施了很多应用系统,比如金融、电信行业以及一些集团企业,如何在不同省市的子公司、分公司和多元化下属单位整合原有系统和信息资源,都是目前面临的主要系统建设需求。
SOA不仅仅是技术层面,同时提供了系统集成开发的主要方法及策略。
SOA倡导遵循开放标准,并独立于厂商多样性的环境,为基于互联网的组织内和组织间的系统通信协作和资源共享提供了良好的互操作性和可用性。
3)提高投资回报率
采用SOA的企业、机关部门,将基于服务规则和要求,构建下层IT架构,具有技术中立的特性,降低了对厂商的依赖和转换成本;其次,SOA系统以“服务”为中心,梳理和重组业务流程,使各个业务系统能够互联互通和资源共享,这种服务的松耦合及平台中立为机构降低了集成成本,松耦合和模块化简化了维护工作,降低了维护成本;因此,总体而言,SOA可以保护原有IT投资,提高现有IT资产的投资回报率。
单个企业或单位的力量是有限的,只有某个行业内或供应链上的多家企业和单位联合,共享“服务”资源,才能推动SOA的开发模式进程,收到良好效益。
在推进SOA的同时,相应的标准化工作必须先行,用统一标准指导各家的服务开发、接口定义、通用数据格式定义、资源存储、服务注册与查询等SOA实践工作。
3.2SOA适用场景
上述章节提到了SOA的特点以及能带来的效益,但是,SOA并不是在所有的情况和场景下都适用,只有在适宜SOA特性的场景下,并采用合适的实施策略来保障,才有可能逐步得到SOA带来的各项效益。
从SOA特点来看,SOA在一些场景中能发挥其作用和优势,如:
⏹企事业单位或者政府部门内部IT系统的整合
由于业务重组、并购或者内部机制调整,而需要实现组织内的统一管理、协作和信息共享。
需要对多个异构的IT系统进行整合,提高组织的整体决策、监控能力或业务流程效率。
⏹企事业单位和政府部门之间IT资源的共享和协同
为了在业务和市场上合作,需要依赖业务合作伙伴提供其IT系统的非核心业务功能或信息。
某项服务能力,需要多个组织和单位的IT系统需要共享信息,并联合处理,比如电子政务中的“一站式审批”服务、各级政务资源共享交换平台等。
⏹从头开始开发的新应用系统
SOA将是未来IT新系统构建的主导方法,因此考虑到未来的扩展和重用能力,用户在业务允许的条件范围内、可选择基于SOA来构建新应用系统。
⏹基于互联网的一些新的应用模式
基于互联网的软件服务化平台,如SaaS等模式。
在信息化建设中,除自己的IT系统之外,也同时希望集成互联网上的一些软件工具或Web服务的企事业单位,如采用“软件+服务”策略的单位。
但是,也有一些应用场景不适合用SOA来实现,此时采用传统的技术、方法和过程来实施更为妥当,比如下述一些场景:
⏹用户业务涉及效率敏感及实时性要求较高的系统,如工业控制、核心交易系统。
⏹事务及安全性要求较高的业务系统。
⏹用户的业务系统没有集成的需求。
⏹当前的IT系统基于统一的平台和编程方法。
对于大多数企事业单位和政府部门来说,如果采纳了SOA,还需要注意如下事项:
⏹考虑SOA产品选型,重视业务流程的管理,使SOA成为其全面业务转型的实现手段。
⏹企事业单位和政府部门在进行业务规划时,应基于自身实际,不要盲从。
⏹采用SOA要从全局慎重规划,以循序渐进、逐步推进为宜。
具体的规划和实施建议,可参见本书后续章节的相关内容。
4SOA技术概述
4.1SOA技术体系
从技术层面来看,SOA并不是一项技术创新,传统的技术在构建SOA系统时同样能派上用场。
实际上,在采用SOA进行系统整合的项目中很多被整合的系统本身就是基于传统技术开发的,但与传统构建系统的方法比较,SOA更强调标准化应用,更加重视系统的层次架构。
SOA特性之一的互联互通性就体现在系统中任一个服务能被其他服务甚至是其他系统的服务准确无误地发现及理解,而满足这种特性最直接的方式就是每个服务都遵循一系列统一标准。
因此,只要在开发过程中遵循SOA的理念,采用统一的标准,任何现有技术都能用来开发SOA系统。
SOA与传统技术体系的区别在于系统均是基于“服务”构造,“服务”之间的交互和组合采用了一种基于“服务中介平台”的方式实现了松耦合,图1-1是“服务”被提供和使用过程的示意图。
SOA系统中服务交互示意图
在图1-1中,服务提供者是一个可以通过网络寻址到的实体,它提供的“服务”是基于IT系统的某个功能或流程;服务请求者调用和使用服务提供者提供的“服务”;服务中介平台类似代理的角色,以目录方式存储了大量“服务”资源,一方面可以接受服务提供者提供的各类“服务”信息,另一方面可以通过协调机制把“服务”的请求分配给服务提供者。
这样为服务请求者和服务提供者建立了中立的沟通渠道。
上述对服务交互图的描述是为了解释SOA的核心元素“服务”的运行机制。
便于对技术有兴趣的用户IT人员了解。
下述内容将围绕SOA系统的整体技术体系来进行说明。
在具体的项目中,SOA系统构建没有完全统一的模式,系统的体系架构需要根据用户现状进行分析设计。
但在层次和内容上,SOA系统存在一些共性的特征。
通常而言,SOA系统的技术体系包含如下几个层次及内容,如图1-2所示。
SOA系统基本技术体系
1)基础设施层
既包括服务器、网络设备等硬件设施,也包括操作系统、数据库系统等基础软件,作为整个SOA系统运行的基础平台。
2)已有资源层
指用户当前所拥有的IT资源。
“已有应用系统资源”和“已有信息或数据资源”是指用户当前运行的应用系统及数据系统中,若干适合抽取出来作为为上层系统提供服务支持的资源。
被抽取出来的资源可以是某个系统(指应用系统或数据系统)中的某个模块,可以是某个系统,可以是若干系统的合并及组合,也可以是各类格式的数据资源;“已有的组件/构件资源”即包括原先采用组件/构件系统的用户所拥有的组件/构件资源,例如基于COM/COM+、JavaBean/EJB或者是CORBA开发的技术功能组件或业务功能组件,也包括已有的WebServices服务组件。
“基础设施层”与“已有资源层”是服务的具体技术实现层,上层应用使用的服务最终都由这两层提供。
3)服务提供层
本层主要职责是封装下面两层的资源,并以服务的形式展现出来,从而构建整体的应用系统。
这是SOA系统最关键的一层,也是SOA系统设计最难的部分,难点在于服务的规划与设计——该如何划分服务及服务的粒度。
服务的规划与设计不仅直接影响到SOA系统的性能,也间接影响到SOA系统的扩展能力。
但这不仅仅是技术问题,需要从企业战略目标的层次上考虑服务的划分,业务人员的参与也是设计出适合企业使用的服务的关键。
具体方法和原则可参见本书第一篇第3章3.2节的相关内容。
本层主要由三部分组成——服务、企业服务总线(ESB)、服务资源库,各部分内容说明如下:
⏹服务——主要是与业务需求对齐的各类“业务服务”(与用户业务相关的、实现特定业务功能)、“流程服务”(与用户实际业务流程相关、包含人员与IT系统参与的一个处理过程)、“信息服务”(用于共享的各类数据和信息)、“交互服务”(为最终用户、其他IT系统或服务提供多渠道统一访问入口的服务)以及“其他服务”(包括实现安全规则、管理机制、质量策略等各类构建用户IT系统所需的服务)。
⏹企业服务总线(ESB)——为服务之间间接和动态交互提供支持。
ESB具体的功能包括:
消息寻址路由(根据请求对服务的描述以及服务在服务资源库中的注册信息,定位具体的服务)、消息验证(检验服务发送的消息是否满足格式要求)、消息格式转换(把消息从一种格式转成另外一种格式)、消息操作(包括增加或删除字符,或把消息中的特定字符进行转换的操作)等。
ESB包含了传统消息中间件的“消息代理”(MessageBroker)功能,但其增强了服务的动态路由和交换功能。
通过把服务接入ESB,由ESB负责服务消息的流通,用户就可以把注意力全部集中在服务的构建上。
此外,由于消息的发送不再在服务间点对点地进行传送,消息原先的直接交换就变成了现在的间接交换,实现了松耦合。
⏹服务资源库——服务资源库里储存的是已注册的服务的描述信息及相关服务元数据描述信息。
已注册的服务可以分成两大类,一类是可以直接被使用的、实现具体功能的服务,另一类是在运行时才进行组装的服务。
服务的描述信息记录了服务实现的功能、服务该如何调用、服务具体实体所在地以及服务在策略方面作出的规定等。
4)应用接入层
用户在这一层里可以部署各种应用,例如图1-2中所示的在政府、金融、电信等行业的应用。
应用依据业务流程,主要由业务人员设计,IT技术人员辅助。
应用依靠下层提供的服务及服务的组合具体实现。
5)标准体系
标准体系贯穿SOA系统从最底层到最上层全部四层结构,内容上由若干行业内公认的标准组成,是每层系统规划设计时建议采用的规范,为SOA系统的标准化实施确定了边界,同时便于实现SOA系统间的互操作。
6)开发平台及各类工具集
用于对SOA系统进行规划设计、实施测试、运维管理的软件平台及工具集,涵盖系统各个层次。
从系统生命周期角度出发,可划分为如下平台及工具:
⏹规划平台及工具——主要用于做出整个系统的分析与规划,需要进行的工作包括项目管理、需求分析、版本控制以及文档管理等。
⏹设计平台及工具——协助相关人员完成整个系统的设计工作。
具体的平台及工具应该包括“业务建模”(模型化企业的业务)、“流程建模”(把业务整理成流程)、“服务组装”(按照一定规则组装流程形成服务或应用)、“服务建模”(模型化整理出来的服务用于服务生成)。
这个阶段的平台及工具与传统的开发方法所需的平台与工具有较大区别,体现的是SOA的思想。
⏹开发平台及工具——用于实施SOA系统的开发,所采用的开发语言及开发平台没有限制。
⏹测试平台及工具——用于实施SOA系统的测试。
传统的测试平台及测试工具在SOA系统的测试工作中同样可以采用。
⏹注册部署平台及工具——用于实施服务的注册发布以及SOA系统的部署。
⏹监控管理平台及工具——用于SOA系统整个生命周期的监控及管理。
这类平台及工具贯穿系统的规划、设计、开发、测试及部署的各个阶段,监测各个阶段SOA系统的实施进展,便于用户及早对意外情况做出反应。
以上是通用的SOA系统技术体系,可用于指导SOA项目的实施。
各厂商在实际项目实施中可根据用户需求及产品选型情况,在此技术体系基础上提供个性化的解决方案。
4.2SOA标准体系
SOA标准体系是指SOA领域内多种类、多层次的SOA标准所组成的相互联系的有机整体。
这套体系对统一用户与企业对SOA的理解,加快SOA项目实施的规范化,以及增强SOA系统间的互操作能力等方面具有重要意义。
目前国际上尚未有被广泛认可与接受的SOA标准体系。
一些国际标准协会组织(如W3C、OASIS、OMG、WS-I等)及国际主流企业发布了若干用于构建SOA系统的规范及标准(常见的是基于WebServices技术的一系列WS-*规范及标准),但这些规范及标准仅在各个标准化协会或企业内形成初步的体系,而且不同组织发布的规范及标准间存在重复甚至冲突的现象,因此,国际上统一的SOA标准体系短时间内还不能成型。
为让用户了解目前国际上各类规范及标准的研制与使用情况,使用户在做系统开发决策时有一定参考依据,同时抱着建设适合国内用户使用的SOA标准体系的目标,ISOL梳理了各个国际标准协会组织及国际主流企业发布的主流规范及标准,整理出84项关于SOA与WebServices的规范及标准,经过体系化分析,划分出14个标准域(见图1-3),形成当前主流SOA与WebServices规范及标准的全集,最终形成国际SOA标准体系研究报告的白皮书——《SOA标准体系V1.0》(已发布在“中国SOA标准服务网”www.soa-上,详细论述可参阅该文档)。
SOA及WebServices规范及标准域
目前,我国正在基于国内产业和用户需求,建立我国的SOA国家和行业标准体系,此工作已于2007年开始,目前已初步规划出我国SOA国家标准体系,如图1-4所示。
此标准体系会在我国标准化专业机构、软件产业界、学术界以及用户的共同合作下进行细化及具体研制。
中国SOA标准体系全景图
我国SOA标准体系工作将围绕4个层次标准的研制工作展开:
⏹SOA基础标准——是支撑SOA系统实现的通用性基础标准,包括《SOA术语》、《SOA总体技术要求》、《SOA标准化指南》以及《SOA集成开发标准》,这一层次的标准将为SOA系统或产品的基本功能、性能作出限定,并为用户和软件厂商提供使用指导。
⏹SOA支撑技术标准——是SOA系统相关的基础技术标准,在图1-4所示11个标准域的若干标准中,我国将对国外已有的相关成熟技术标准(如部分WS-*标准)进行裁剪和修改,并采纳为我国相应的国家标准,部分国内有特殊需求的标准将采取自主研制的方式来制定。
⏹SOA测评标准——包括两类:
一类对SOA相关的产品对于SOA标准的符合性及互操作性进行评测,第二类为用户提供SOA建设成熟度评估的评测规范,包括相关评测方法和指标。
上述标准规范将作为相应的SOA测评工具和平台的基本依据。
⏹SOA行业/领域标准——将根据行业或领域特征及信息化现状来研究制定适合本行业或本领域的SOA标准体系。
此部分标准的研制工作将由我国各行业相关标准化委员会或行业协会来主导制定。
目前所列出的几个领域为部分有代表性的行业或领域,其他行业或领域也会逐步扩展进来。
目前,中国SOA标准体系正逐步形成之中:
《基于XML的Web服务描述语言》(20030146-T-339)与《基于XML的简单对象访问协议》(20030147-T-339)两项国家标准已完成制定并发布;《Web服务可靠消息传递》(20080478-T-469)与《Web服务互操作框架》(20080477-T-469)已开始研制;《SOA术语》、《SOA总体技术要求》、《SOA标准化指南》与《Web服务管理标准》4个标准处于国家标准公示阶段;《Web服务业务流程规范》等两个标准处于申报阶段;《金融行业SOA标准化指南》等处于计划阶段。
4.3面向服务方法与传统方法的区别
软件开发方法历经数次变革,从结构化分析方法开始,经面向对象方法、面向构件方法,到现在的面向服务方法,这些变革都是为满足客户需求的根本改变,以适应应用领域不断增加的复杂程度而提出的。
1.结构化分析方法
结构化分析方法在20世纪70年代逐步形成,以算法为中心,按照逐层分解、逐步求精的原则,给出一组帮助系统分析人员产生功能规约的原理与技术,方法简单、清晰,符合人们认识世界、改造世界的一般规律,从而大大降低了求解问题的复杂程度。
但其对需求变更的适应能力很差,所需文档数据资料极大,也不适合用于解决复杂的大规模问题。
2.面向对象方法
面向对象方法产生于20世纪80年代,以对象(对象=数据+算法)为中心,为软件工业实现工程化提供了强有力的支持。
面向对象方法具有封装性、多态性和继承性,与人类习惯的思维方法一致,加强了人们对问题域的理解,增强了适应需求变化的能力,且利于用户的参与和各类人员的交流。
但其需要依赖具体的编程语言,与业务存在鸿沟;封装粒度小,耦合度高,难于实现大规模、高层次的重用。
3.面向构件方法
面向构件方法以粗粒度、松耦合的构件封装可重用的功能单元。
企业业务被映射成系统构件,从整个企业的视角出发构思、设计系统,是面向对象方法更高一级的抽象,比面向对象方法更切合企业的实际应用,重用度也进一步提高。
但与开发语言紧密联系,导致接口标准不统一,不同开发语言实现的系统之间很难实现互操作。
4.面向服务方法
面向服务方法是在面向对象方法的基础上扩展的构建系统的思想和方法。
面向服务方法关注的是企业业务,它直接映射到业务,强调IT与业务的对齐,以服务为核心元素来封装企业的业务流程和企业已有应用系统。
服务的粒度更大,更加匹配企业级应用中的业务,可以实现更高级别的重用。
但目前存在相关标准未统一、应用案例较少等一些问题。
上述各类系统构建方法的比较如表1-1所示。
名称
概述
优点
缺点
结构化
方法
以算法为中心,又称为结构化分析
体现了逐层分解、逐步求精的原则,有严格的规则
难于检验分析结果的正确与否;对需求变更的适应能力很差;系统设计人员对分析结果的理解存在障碍
面向
对象
方法
以对象(对象=数据+算法)为中心,实现了对数据和算法的封装和继承
加强了对应用领域的理解,改进了沟通和交流;适应需求变化的能力较强;支持分析和设计结果的复用
纯技术导向,存在与业务的鸿沟;复杂度高,抽象程度低,难以实现大规模和高层次的重用
面向
构件
方法
以组件或构件封装可重用的功能单元
重用度进一步提高,提高了软件企业的开发效率和质量
组件或构件封装方法和接口标准不统一,很难实现与外部应用系统之间的互操作
面向
服务
方法
以服务封装业务流程和应用系统
业务驱动技术,以开放标准实现应用系统之间服务的相互访问,乃至复合应用的组装,实现了更高级别重用
处在概念导入期末尾,相关标准尚未统
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SOA 项目 设计 文档