SOA架构模式（共7篇）
SOA架构模式 篇1
0引言
从软件技术角度理解SOA,即一切以 服务为核 心 , 其对外部提供一个统一契约 ,而服务由 组件构成 ,组件是若干操 作的集合 ,操作对应 具体实现 程序模块[1]。 服务是在识别业务过程的基 础上 ,分析 、实现业务 过程前后逻辑性 。 该应用来 自需求用 例 ,展示逻辑 也即为业务的一 部分 。 在某些具 体实践上 ,只要能提 供服务手段都可实现SOA。
SaaS本身是一种软件服务提供模式,但与以往 软件服务不同,其完全基于互联网资源和技术,类似于国外按需软件ODS或应用服务提供商ASP,对软件和应用进行服务托管。SaaS供应商不再为企业搭建网络基础设施和软硬件平台,也不再向企业提供除咨询以外的实施服务。 企业可根据实际业务需求,通过Internet网络向SaaS供应商采购或租用基于Web的软件,企业软件监管可全权委托SaaS供应商,并且SaaS供应商还提供软件代码离线控制及数据便捷存储,以便用户根据自身实际业务需求开展系统实施和应用。就企业而言,SaaS既可节约 自身采购成本、降低管理风险,还可利用互联网共享行业最先进技术和应用。
SOA作为一种软件架构,将软件模 块化、分区化后, 可简化软件模块单元,定制其接口方式、接口协议及接口数据服务;SaaS模式中的“服务”本质是服务提供商向使用方提供的某种 意义上的 增值,是一种产 品外延。换言之,SOA和SaaS两者的“服务”实际上是两 个范畴,但若从更高层角度理解两者间的联系,发现两者在不同层面上相互影响。本文从企业应用角度,探讨如何将两者有机结合,利用SaaS模式所带来的服务在数据层、存储层和访问控制层上进行SOA架构优化和部署。
1SaaS软件服务下SOA数据层架构
SaaS模式中,数据被分成不同构件,公共资源用来配置、管理和存储共性资源,可释放用户本地空间,以便执行个性化程序。而个性构 件会根据 企业业务 变化而变 化。 当业务发生变化时,企业会产生许多独特数据需求,要求SaaS软件服务既可满足特定客户数据需求,又可保证客户业务数据隔离,以实现SaaS模式的安全性、高效性[2]。 SOA架构下数据层管理,需既保证实用性,又具有良好的扩展性,可有效结合SaaS服务供应商所提供的网络空间进行大规模存储。如果将数据划分成共性和个性两个部分,那么数据库分类处理所形成的架构更能满足SOA要求。本文比较和分析不同类型数据架构,分析数据架构针对特定需求的可扩展性及安全性。实现动态数据扩展,既满足用户对数据模 型的特定 扩展,又不影响 其他用户 使用,从而节约资源,降低存储成本[3]。
1.1SaaS软件服务下数据层架构设计
如图1所示 ,SaaS软件服务 下的数据 层分为3层: 1类型数据 库 。 包括公共 数据库和 客户数据 库 。 其中,公共数据库保存公共资源 ,企业可向SaaS服务商申请使用该资源 ,但无权修 改 。 然后利用SOA服务将共 有数据进行切分 ,不断划分为 更小粒度 ,实现数据 存储解耦。剖开数据与应 用界面 ,使程序只 能通过接 口访问数据,以满足企业客户对数 据服务度 量的需求 ,且可根据实际定制服务 进行付费 。 客户数据 库保存企 业自定义配置数据和应 用及相应 程序 。 基于细粒 度划分构 件则可划分不同 数据级 。 用户在该 架构的基 础上 ,不断拓展其应用面 ,深入开发自 定义需求 ,满足企业 个性化业务 ;2业务逻辑层 ;3数据访问 层 。 数据访问 层只对数据库的数 据进行访 问 ,基于逻辑 层所提供 的接口代码,尤其是公共 数据库中 共享信息 。 但数据访 问层无法对公共数 据进行更 新或删除 ,只能创建 用户个性 化业务数据 ,对客户数据库进行读写操作 。
1.2SaaS软件服务下数据存储架构设计
SaaS模式的目的是共享与个性化。共享可使企业节省资源,访问同一个应用实例。而个性化则可使企业具有私密信息与定制,使数据直接产生隔离,个性化不仅能提高企业效率,而且也为企业减少成本。基于上文分析的数据层架构,若要设计存储数据方式,主要考虑实现既有共享又有隔离耦合。通常,存储架构被划分为以下类型:
(1)单独隔离数据库。该类型最安全,使每个用户都拥有独立且隔离的数据库。利用核心数据定义、建立与实际应用关系。该设计使用户定义需求可在最优前提下得到保障。用户可在该类型数据模型下,方便实现业务和流程扩展,以满足个性化需求。从系统运维角度,单独隔离数据库发生故障时,系统可以非常便捷地恢复备份数据, 已达到高级别安全程度,但缺点是在该数据架构下,由于数据库有限,能支持的用户数也有限,相对其它数据架构, 只有当用户自身数据 具备很强 独立性时,才会采用 该类型。
(2)将用户数据库共享,采用独立的可扩展标记语言。 该模式是半共享模式,开放数据库,每个用户都具备不同数据表架构。一个数据库存储多个用户信息,每个用户均有所属的表,在同一个可扩展标记语言描述表组中包含所有的表。在该数据架构下,用户采用半开放式方法,既能共享数据,又能保留核心部分,也使得在硬件上可容纳更多应用。SaaS服务商可节约一部分资源,降低运营成本。 但维护性不如单独隔离数据库,即使表里数据并未完全损坏,但仍需大量时间恢复用户表。该架构并不适用于多种用户数据表,但安全性较高。
(3)用户数据库与可扩展标记语言均共享。该模式具有互联网模式架构特点,将用户数据在一个用户数据库上进行存储和记录。全部共享架构下,用户通过名称和属性划分不同数据记录,数据隔离程度相对较低,相应的安全级别低,但该模式具有较好的共享性、经济性等特点。
就用户数据安全性而言,全部共享则意味着若系统异常将导致用户数据 泄露,这对系统 安全性提 出了更高 要求。数据运维和备份也需要相应的额外支出。如果不对共享数据进行处理,一旦出错,数据将难以恢复。该架构比较适合用户数据存储量小、安全性要求低的企业,如图2所示。
2SaaS软件服务下SOA访问控制层架构
云计算使SaaS软件模式受到广泛关注,但其安全性不容忽视。本文从SOA角度研究SaaS信息系统体系架构中的访问控制层,提高SaaS信息系统体系架构安全性, 增强其系统架构可行性。
2.1原有RBAC访问控制模型
授权策略作为访问控制重点,其主要目的是为确保信息系统中某些敏感 数据和信 息只限定 于特定用 户访问。 在基于SOA的信息系统体系架构中,多数访问控制模型采用RBAC(基于角色的访问控制)模型。RBAC将角色作为用户与权限的中间层,通过将权限赋予角色,再将角色授予用户的模式实现用户权限分配。RBAC模型图如3所示。
RBAC访问控制模型 在实际应 用中不断 成熟,但在SaaS信息系统架构下,SaaS模式多用户特性决定了传统RBAC管理模型仍然存在许多局限性,主要体现在以下4个方面:
(1)传统软件架构中访问控制权限是以管理员和其他应用用户为基础,通常用户数量和岗位数量较少,用户角色划分和管理较为简单。在结合SOA架构下,访问不能仅存在于部分用户上,由于SaaS具有多用户特性,决定其具有庞大的用户数量,继续使用传 统RBAC访问控制 模型,只会增加用户维护难度,难以到达控制要求,RBCA已不再适应于面向多用户的SaaS信息系统。
(2)SaaS模式内,不仅用户数量庞大,而且每一 个用户内职位划分也各不相同,角色定义呈现出多样化特点, 角色具体权限 在不同情 况下有不 同定义。 因此,传统RBAC访问控制模型不能为用户提供角色权限灵活管理。
(3)传统软件架构中访问控制是单一。对于SaaS体系机构而言,传统软件架构面向单用户,但在SaaS信息系统中,如果直接使用传统访问控制模型,将导致角色名冲突。在多用户环境 下,角色定义 存在交叉 等特点,传统RBAC模型无法解决此问题。
(4)SaaS模式是资源分布式的云计算模式之一,值得注意的是,如何解决异构用户跨级管理访问控制,由于传统设计架构中不存在多用户这一新特性,所以传统RBAC模型需进行改进以适应SaaS应用新需求。
2.2SaaS模式下新型访问控制架构设计
传统SaaS访问控制模型对权限管理不完善,通常将所有对象权限归为一个权限集合。然而,数据是SaaS信息系统核 心,SaaS实现依赖 于元数据。 因此,在传统RBAC模型基础上,针对上述 数据存储 模型和用 户业务流,提出MRBAC(基于角色多用户访问控制模型)权限管理方案。MRBAC用户层次访问控制模型,如图4所示。
用户首先进行身份认证,采用“用户名+ 密码”方式, 考虑到SaaS网络服务性质,用户名和密码传输时需采用加密算法保 证信息安 全。 用户成功 认证后,方可进入MRBAC访问控制流程。
根据获得用户选择登录角色,如果用户角色为固定角色,判断用户角色是否符合动态和静态互斥原则。如果符合,判断用户登录时选择的角色中是否有活动角色,若有, 则获取活动角色,判断活动 角色是否 符合委托 机制和动 态、静态互斥原则;如果不符合,则失败退出,否则获取用户元数据角色对应对象权限集合T1和用户需要访问元数据对象权限T2,比较T1和T2。如果T1≥T2,则成功获得访问权限,然后可获取值数据信息,否则用户将因权限缺失而无法访问。用户结束本次访问后,判断用户是否继续访问,如果继续,则获取其需要访问对象的权限与用户权限相比较,否则结束访问。
当然,在MRBAC模式下,也可继续利用缓存以使存储用户登录后具有所有权限。待用户再次访问数据时,无需重新获取用户角色信息和权限信息,该方法在很大程度上节省了访问时间。
3结语
将SOA模式与SaaS服务进行整合,为用户提供个性化服务,既能利用SOA所提供的接口和契约,将软件模块交互,通过松耦合进行升级或替代,以降低定制成本,又可发挥SaaS规模化优势,利用互联网资源进行快速便捷服务,两者有机结合,互补互利。利用该整合,不仅可满足企业现场设计、生产、服务的需求,也可基于不同供应商提供不同服务,对企业展示和运行提供全方位支撑,推动企业应用创新突破。SOA的意义在 于其自身 具有模块 化服务,可使企业信息化工作变得更具灵活性,企业根据自身实际业务需求拼接软件服务,使IT与业务保持同步。而SaaS模式结合SOA模式则更进一步使企业能快 速适应各类系统,既满足企业自身业务特殊性要求,也结合SaaS共享服务和运维保障,对企业各方面运营管理效率都具有重要意义。
摘要：SOA是一种面向特定服务体系结构的组件模型,其主要功能是将应用程序中开发的不同功能模块(服务),通过已定义接口联系应用程序平台,而应用程序平台及底层实现对于用户是可见的,用户可通过这些中立接口和契约开发协议,获取相应服务。SaaS是目前流行的一种软件服务模式,该模式基于互联网,为终端用户提供软件服务。探讨如何在SaaS模式下定制企业SOA应用架构,如何使两者在不同层面互相发挥作用,企业如何更好推动该架构建立。
关键词：SOA,SaaS,云计算,架构,应用模式
SOA架构模式 篇2
为有效地解决这些问题, 使企业IT系统具备扩展性强和随时支持业务流程变化的基础功能, 成功实施企业应用集成、整合将是必要的措施。本文提出了事件驱动的业务过程和服务驱动的松耦合动态集成相结合的EDSOA企业应用集成参考模型。
1 企业应用集成及应用架构介绍
1.1 企业应用集成简介
企业应用集成 (Enterprise Application Integration, EAI) 的概念最初仅指企业内部不同应用系统之间的互连, 以期通过应用整合实现数据在多个系统间的同步和共享[1]。伴随着企业应用集成EAI技术的不断发展, 它所被赋予的内涵变得越来越丰富。现在EAI的概念已经扩展到业务整合 (Business Integration) 的范畴, 不仅要提供底层应用支撑系统间的互连, 同时还要实现存在于企业内部应用与应用之间、本企业和其他合作伙伴间[2]端到端的业务流程的管理, 包括用户互动、应用整合、B2B整合、自动化业务流程管理、企业门户以及对所有应用系统和流程的管理监控等方方面面。
1.2 面向服务体系结构
面向服务的体系结构 (Service Oriented Architecture, SOA) 建立在分布式计算技术的基础上, 可以基于现有的系统投资来发展, 而不需要彻底重新创建系统。这种体系结构本质上是动态的, 它提供对服务的登记、发现和调用的支持。SOA的软件开发人员可以将企业应用系统以服务的形式通过网络发布, 即任何服务应用程序都可以同其他位置的基于服务的应用系统交互, 并充分考虑服务的重用。
1.3 事件驱动体系架构
事件驱动体系架构 (Event-Driven Architecture, EDA) 是一种设计和构建应用的方法, 其中事件触发消息在独立的非耦合模块之间传递。事件源通常发送消息到中间件或消息代理, 需要者可订阅这个消息。由于事件消息用发布订阅方式通过消息代理传输, 一个事件便可传送给多个需要者。EDA和SOA之间主要的区别是:在SOA中, 发布者和需要者只有一对一的关系;而在EDA中, 事件发布者最终可以传送消息给基于订阅规则的任何数量的消费者。也就是说信息在两个系统间交互时, 根本不需要知道对方的详细信息。上述特点能很好地满足企业的应用需求, 如跨部门的应急联动系统或联合监管协同服务等应用[3]。
2 基于事件驱动的SOA (EDSOA) 企业应用集成模式架构
2.1 事件驱动型SOA
所有业务都是事件驱动的, 事件驱动型SOA为组织提供了响应这些实时业务动态所需的能力。它结合了面向服务的架构 (SOA) 的请求-响应模式和事件驱动架构的事件发布-提交模式。前者对服务事件的支持允许设计人员将应用程序设计映射到业务问题, 后者通常由事件和请求/响应组成。服务和事件处理的结合产生了更好的敏捷性和快速的信息性响应。
EDSOA的目标是对SOA进行扩展, 从而使解决方案能够以极快的速度从海量数据流中迅速标识出有价值的事件。它把专门化实时系统的数据流管理和复杂事件处理的功能变为应用程序的一部分。用户和系统能够获得最高到微秒级的状态图, 并且能够及时获知需要特别关注的一些改变。之所以有这样的优势, 一方面, 是因为SOA提供了一种集成框架, 可将来自多个系统的数据集合在一起, 并且当企业对请求进行响应时, SOA可以提供与某种系统的集成, 从而为企业提供帮助;另一方面, 不像SOA的请求/响应系统, 要求请求者必须明确发送请求信息, 而一个事件驱动架构提供一个机制去动态响应事件。在一个EDA系统里, 事件产生者发布事件, 事件消费者接受事件, 所以EDA极大地改善了企业对各种看似无关的事件的响应能力, 而这些事件往往会对企业造成影响。通过提供即时过滤、聚集和关联事件的功能, EDA能够以极快的速度检测有可能对企业造成威胁或为企业提供商业机遇的事件和模式, 并且为企业提供对此做出即时反应的能力。企业通过使用全面的数据提要和确切的事件定义, 能够快速做出反应并应对出现的挑战。
2.2 EDSOA应用集成参考模式
在企业应用集成领域, 企业一直面临削减成本和最大限度地利用现有技术的难题, 但与此同时, 他们还必须不断地努力, 以期更好地服务客户, 更快地响应企业战略重点, 从而赢得更大的竞争力。从信息的整合再到功能与流程的整合, 从企业内部的应用整合到跨企业边界的整合, 企业整合的需求不断变化和丰富。在当前激烈竞争的环境下, 一个成功的企业在IT构建上需要解决下列问题:
(1) 如何实现应用系统的快速构建、迁移和伸缩, 以满足不断变化的市场需求。
(2) 如何能够让已有的多种应用系统无缝集成起来。
(3) 如何设计现代IT架构, 使系统不仅功能强大和可靠, 而且还有强大的灵活性和可扩展性, 以满足不断增长的新需求。
通过对事件驱动SOA架构的分析可知, 事件驱动SOA架构可以解决以上这些问题, 基于此, 本文提出了完整的基于事件驱动SOA架构的企业应用集成参考模式, 如图1所示。
图1中的各个功能实体都以服务的形式出现, 是在特定层次上为特定应用提供服务的基础设施。实体服务可以是具有内部完整功能闭环的应用系统且对外提供特定功能的服务单元。
整个体系结构中的服务由以下几层构成: (1) 企业服务总线 (Enterprise Service Bus, ESB) , 这是SOA体系中的基础架构, 各个服务通过总线来互相访问; (2) 应用服务层, 这一层主要是指需要集成的企业各个应用系统和数据存储库; (3) 总线接入层, 这一层提供了适配器[4,5]服务, 支持多种主流应用的接入协议, 这样使用户可以访问各个应用服务, 并通过消息机制使各种应用接入ESB, 使用ESB的各种服务; (4) 核心服务层, 提供多种企业服务总线所需的必要服务支持, 在这一层提供总线基本服务, 如消息分发/订阅、队列、目录服务以及数据转换/映射服务等; (5) 业务支持层, 这一层侧重在业务支持上, 通过通用、标准的对象和服务模型, 可以在这一层上定义可重用的和基于企业界标准的业务流程, 同时, 还提供统一的用户交互服务, 包括手机银行、网上银行和传统银行网点。建立在企业服务总线之上的用户交互服务可以很小巧, 并关注于各自交互的特点。
该集成框架基于面向服务技术, 通过各类适配器服务接口将企业应用封装成统一的应用服务, 然后发布到目录服务中心, 并通过企业服务总线中的基础核心服务, 如统一数据格式和消息传递等, 来实现各个应用系统间的通信交互。在该集成框架中, 应用服务既可以是已有的旧应用, 也可以是新开发的应用。该集成平台是连接各类应用的桥梁, 采用的是松耦合方式, 即任何应用都以独立服务的形式连接到系统中来, 方式灵活, 简单快速, 真正实现了“即插即用”。
当在该框架下需要进行过程集成和业务集成时, 首先通过业务流程定义服务, 并根据事件驱动的模型将已经注册的应用服务在一定的规则下组成相应的业务流程链。业务集成模型的实现是由集成引擎调用应用服务的接口实现数据的存取, 并通过消息引擎在各个应用服务间传递路由数据, 实现定义的业务流程。
业务系统可以从SOA和EDA中受益匪浅, 因为当事件发生时EDA能触发事件消费者, SOA服务可以快速地从相同的消费者中访问、查询。系统需要快速的响应性, 当事件触发时这个系统必须能快速决定必须的动作。到事件结束, 事件应该被发布和消费, 而且事件要穿越SOA所有的边界, 包括整个体系结构和物理层。图2演示了事件被激发并穿越体系结构的所有层。
在图2的环境中, 一个事件能被定义为任何系统的平台的、组件的、业务的或应用进程的变化。事件可能是高层的业务事件或底层的系统事件。因为事件能被传送和接收, 订阅事件的应用程序和服务能对这些变化作出响应[6]。
可以看出SOA完全可以提供一个灵活松耦合的可扩展的基础集成服务平台, 比较完善地实现数据集成和应用集成。而且随着事件驱动架构的介入, 可以顺利地实现企业业务流程的建模和集成, 最终实现企业应用集成的最高层次, 即过程集成。
2.3 EDSOA模式在企业应用集成中的结合应用
信息系统应用集成在近两年成为企业信息化建设的热点。应该说EAI建设是企业对其信息系统建设的一个总结。从EAI建设的驱动力来说, EAI是为了解决企业内的“蜘蛛网”、“信息孤岛”等问题而产生的。企业通过建设EA系统, 有效地降低了接口数量, 并且在各个信息系统之间架起了沟通的桥梁。EAI为许多企业疏通了脉络, 提高了信息系统的整合能力。
由于企业行业化、协同工作与动态电子商务以及实时企业与业务流程自动化的需要等这些商业发展因素的驱动, 企业应用集成越来越成为人们关注的焦点。事件驱动的SOA的好处是很明显的。通过实现具有实时反应能力的企业, 事件驱动的SOA能够通过提高客户满意度、有效地管理意外事件和提高竞争的灵活性等措施增加企业的收入。通过提高价值链的可见性和减少获取客户的成本, 事件驱动的SOA还能够降低运营成本。因此, 通过更快的产品投放市场时间和更优越的技术支持和服务, 企业的市场领先地位将得以提高等。
事件驱动的SOA创建了把流程、方式和商业逻辑应用到原始数据中的基础。它把SOA请求/响应的范例与事件驱动的结构的发布/订阅模式结合在了一起。事件驱动的SOA还允许设计者描绘旨在解决商业问题的应用程序。这一般包括事件和请求/响应的互动。通过把面向服务和事件处理与商务流程管理、商务活动监视和企业服务总线等技术结合在一起, 事件驱动的SOA创造了极大的灵活性。
3 结束语
基于事件驱动SOA架构的企业应用集成体系结构将减少集成那些完全不同系统所需的时间, 并通过快速开发和组件重用来快速部署服务。从高度集成环境中的多个事件源捕获、关联和汇集事件的能力可确保企业对变化的业务情况进行预测并快速作出响应。相信新技术与新业务流程的相互融合, 将为我国企业在管理与业务模式上的创新提供机遇, 也会为“实时企业”的理念、管理模式、相关技术以及相应的支撑管理软件在我国企业的应用实践提供良好的基础。
摘要：针对在当前企业应用整合中存在的集成平台缺乏灵活性和适应性、扩展性较差、互操作性不高等问题, 本文提出了事件驱动的业务过程和服务驱动的松耦合动态集成相结合的EDSOA企业应用集成模式。该体系架构具有松耦合、行业支持和高度可集成能力等优势, 可满足企业行业化、协同工作与动态电子商务以及实时企业与业务流程自动化的需要, 也可以方便地实施EAI。
关键词：企业应用集成,面向服务的软件架构,事件驱动架构,业务整合
参考文献
[1]柴晓路.EAI和Web服务轻松进行企业应用集成[EB/OL].http://www.ccw.com.cn/htm/center/app/02-2-28-2.asp, 2002-02-28.
[2][美]Fred A Cummins.企业集成[M].杨旭, 等, 译.北京:机械工业出版社, 中信出版社, 2003.
[3]Global Research Partners.Event-driven Architecture:The Next Big Thing[C].Gartner Application Integration and Web Services Sum-mit, 2004.
[4]Jeff Sutherland, W J Van den Heuvel.Enterprise Application Inte-gration Encounters Complex Adaptive Systems:A Business Object Perspective[C].Proceedings of the35th Hawaii International Con-ference on System Sciences (HICSS′02) , 2002.
[5]David S Linthicum.The Evolution of Adapters[J].EAI Journal, 2002 (12) :36-40.
SOA架构模式 篇3
随着社会的快速发展, 一个企业、单位、部门需要不断组建新业务, 企业间的合并、企业内部部门的重组, 国家政策的变化也可引发企业原有业务的变化。通过手持移动设备、ATM机、计算机网络、客户呼叫中心、公司员工等多个渠道为客户提供同质服务对现代业务提出了新的要求。另一方面企业现有业务运作的传统IT系统, 积累了大量数据财富, 但由于开发技术不同, 开发团队相异, 采用的数据格不统一, 已成为企业进一步开发新业务的障碍。
一个企业的IT战略是其发展的信息基础, 其IT架构的构建, 需要企业决策者、各级业务管理部门、IT设计人员共同参与;在此过程中企业业务人员与IT设计人员之间的快速有效沟通成为关键要素。传统的沟通方法是双方在市场调研、需求分析、功能设计阶段进行反复磋商, 根据业务和IT技术的要求, 由IT人员落实。这一过程比较长, 甚至出现了IT系统还没有完成, 原先的需求就发生了变化。因此只有在更高层次的业务建模、业务流程、流程管理的概念框架下进行沟通才能尽快地将业务变化落实到IT架构中, 适应敏捷业务的要求。
基于以上所述, 传统的软件设计方法已无法适应现代企业业务敏捷化的要求, 已无法考虑到复杂多变的业务需求, 社会迫切需要一种新的软件设计方法。另一方面, 面向对象的程序设计技术, CORBA、DCOM、JAVA Bean等分布式组件技术的发展, 为新的软件设计方法积累了一批经验, 提供了技术保证。在这一背景下, 促成了面向服务的架构SOA的诞生和发展。
1、SOA的发展过程
具备SOA形式的系统出现得比较早, 但概念最初由世界著名的咨询公司Gartner于1996年提出7。其基本思想是将企业应用程序构建为一系列可执行业务功能的服务, IT资源通过服务的形式重用;业务模式在动态业务环境中重新组合, 以此满足企业业务敏捷性的要求。另外, 从社会的角度看, 企业愿意将自己的服务通过无偿或有偿的方式提供出来供别人使用。
SOA的发展, 其实质就是SOA标准规范的发展, 根据Steve.Jones的观点1, 经历了中间件和Web服务两个阶段。上世纪80年代初TCP/IP技术的发展, 催生了中间件技术, 如CORBA的I-IOP, 后为解决中间件的紧耦合问题产生了SOAP、WSDL、UDDI等Web服务技术。
Gartner预言, 至少有60%的企业将采用SOA做为其IT架构2。在国内, 许多高校、科研机构和企业举办各种关于SOA的研讨会。如普元信息技术有限公司2007年在成都、广州、上海、北京举办了四次关于SOA在中国如何发展的研讨;共有1600人次以上的CIO、IT信息主管和技术精英参加3。可以肯定的说, SOA已成为计算机领域内近年来最热门的研究领域之一, 是企业IT战略架构的必然模式。
2、SOA概述
2.1 SOA的概念及相关错误观点
SOA是Service-oriented Architecture的缩写, 称为面向服务的体系架构, 是一种软件架构方法、原则。有译为"以服务为中心的体系结构"2。它是Internet环境下信息系统集成的一种体系架构。在这种体系结构中, 以高度抽象的具有独立功能的服务为基本单位构造各种松耦合的应用系统, 以最大的灵活性和重用性提高应用系统的开发效率。
目前, 对SOA的认识存在三种误区, 表现为以下三个方面:
(1) SOA就是Web服务
Web服务是SOA最重要的实现手段, 但不是唯一形式。服务组件架构SCA (Service Component Architecture) 和面向服务的数据对象SDO (Service Data Object) 构建的系统是SOA的一种形式;eb XML规范构建的电子商务系统又是SOA的另一种形式;CORBA、DCOM、JAVA Beans等中间件技术也可构建SOA形式的系统。
(2) SOA是一种新的技术
把SOA与面向过程、面向对象的程序设计等同起来, 认为是一种全新的技术。其实, SOA的服务仍然靠传统软件技术去实现, 只是在具体的程序实现基础上抽象出了一层描述层, 将具体的实现与描述隔离开来, 使业务人员和部分设计人员能够在该层进行高度抽象的设计。
(3) SOA是各种规范、标准的集合
SOA是实现异构系统互操作的最佳体系架构, 各种标准、规范是其理论基础。但实现SOA还需要各种具体的软件技术和开发平台, 各种平台在支持基本标准的基础上, 对各种扩展标准有不同支持。
2.2 实现SOA的主要技术
基于开放标准, 具有粗粒度、松耦合服务的技术均可构建SOA。实现SOA的技术有许多种, 主要有Web服务技术, SCA、SDO技术, 分布式对象技术, Web Sphere MQ技术, B2B Platform技术等。
2.2.1 Web服务技术
Web服务是实现SOA的最有效手段, 其SOAP、WSDL、UD-DI、WS-Security、WS-Transaction、WS-Policy、WS-Reliability、WS-addressing标准和规范丰富了SOA的思想, 其描述的服务在业务层抽象, 独立实现, 构造的系统具有松耦合性, 服务能够重用, 有明确的接口定义, 较粗的粒度, 无状态等特点, 这些是SOA的典型特征。目前已有大量的Web服务平台供开发者选择, 如IBM的Web Sphere application server6, 微软的.NET Framework等。
2.2.2 SCA、SDO技术
服务组件架构直接采用Web服务和XML开发服务, 程序员在底层技术上考虑各种异构环境的具体实现细节, 通过组件的实现提供服务, 用接口公开其功能, 并使用其它服务。SDO定义和规范了服务的数据, 使SCA独立于数据源和具体数据访问技术, 实现服务间的数据交换, 通过对组件的组装构建应用系统。
2.2.3 分布式对象技术
分布对象技术包括CORBA、J2EE、DCOM等, CORBA是一个开放标准, 支持RPC (Remote Procedure Call) 调用, 多种编程语言, 可把CORBA对象作为Web服务发布, CORBA IDL可作为服务定义语言, 实现高层次抽象, 用其构建的SOA系统效率较Web服务的高, 但CORBA要求服务请求者和服务提供者都用CORBA实现。J2EE除具有开放标准, 支持远程调用外, 本身支持XML和SOAP进行通信, J2EE EJB也可将其对象直接发布为Web服务。
2.2.4 B2B Platform
Eb XML、Rosetta Net也是理想的构建SOA的Web服务平台, 它们都有开放标准, 基于XML和业务文档异步交换, 为服务注册、服务安全、服务监控与管理、业务流程管理、补偿事务及可靠消息传递提供了集成机制。
2.3 SOA的标准规范体系
SOA是基于许多开放标准的, 这些标准实现了异构系统之间的互操作。主要有eb XML系列标准 (eb XML Registry、eb XML BP、eb XML msg、UBL) , Web服务系列标准 (SOAP、WSDL、UDDI、BPEL、WSDM、WS-Security、WS-Reliability、WS-Transaction、WS-CDL) , SOA本身标准 (SOA IM、SOA CS) 等。
2.3.1 SOA运行时的架构1 (如图1)
2.3.2 主要标准
SOAP (Simple Object Access Protocol) 称为简单对象访问协议, Web服务的基本标准。Web服务用作其所有信文的规范, 基于XML, 在分布式环境下交换结构化、有类型的数据。
WSDL (Web Service Description Language) 称为服务描述的语言。用于在抽象层描述服务传递消息的类型、服务的操作、服务的地址、服务的接口、服务名称、服务与SOAP的绑定等;完成服务的描述与服务实现的隔离。现为Web服务的基本规范。
UDDI (Universal Description and Discovery Integration) 称为通用描述、发现与集成标准, 虽然发布早, 由于支持的厂商少, 仍不能算作Web的基本规范。它主要实现服务的注册、服务的分类、服务的查找。一般有发布和修改、发现和获取两类操作。
Web服务事务模型与规范, WSCoordination和WSTransaction (简称WS-C、WS-T) 。其中WS-T包括WSAtomic Transaction和WS-Business Activity。是Web服务的补充规范。
Web服务的安全协议, Web Service Security (WSS) , 主要是解决用户令牌的传递、SOAP消息的完整性和保密性。是Web服务的补充规范。
只有基本标准和规范还无法提供满足企事业要求的服务质量, 有了补充规范后才能建立企业级的SOA, 即对安全、可靠、事务提供支持。
3、SOA的实现
3.1 SOA的设计模式
SOA的设计模式有服务注册表 (Service Registry) 模式, 企业服务总线 (Enterprise Service Bus, ESB) 模式, 服务编排 (choreography) 模式三种。
3.1.1 服务注册表 (Service Registry) 模式
服务注册表模式是基于SOAP、WSDL、UDDI标准的模式, 在这种模式下由服务请求者、服务提供者、服务注册表三种角色组成, 其架构如图2。实现过程4如图3。根据注册表服务的对象又分为有公有注册表、私有注册表、专有注册表三种。
3.1.2 企业服务总线 (Enterprise Service Bus, ESB) 模式
ESB是一个提供通信、整合、安全、事务支持和服务质量控制等SOA要求性能的基础架构。ESB通过提供一个服务的地址和命名控制点来提供这些性能。服务请求者通过以特定的地址和协议调用服务来访问ESB。ESB有许多端口, 一个端口包含一个协议, 一个或多个地址, 一个特定的方式处理服务交互的特性, 如事务、安全等。具体架构如图4
3.1.3 服务编排 (choreography) 模式
服务编排模式采用基于应用的逻辑封装服务, 从而将组合服务中的服务排序与具体服务分离开来, 以小粒度的服务组合成大粒度的服务, 模式化的实现商业流程并自动执行, 监视商业流程的执行效果, 实现工作流解决方案。具体实现技术有两种:基于BPEL4WS标准的服务编排实现;基于特定工作流或消息流的实现。
3.2 Web服务平台
Web服务是实现SOA的最重要手段, 现在有许多软件工具帮助实现服务的发布、管理、整合、服务请求者与服务提供者之间的数据转换。这些软件统称为Web服务平台。
3.2.1 Web服务平台的关键要素
Web服务平台为服务请求者和服务提供者进行交互提供了与下层实现技术无关的基础设施, 关键要素有服务契约、服务契约库、服务注册与查找、服务层安全、服务层数据管理、服务层通信、多协议和多传输支持、服务层服务质量、服务层管理、对多种编程语言的支持、服务的编程接口。这些要素能够完成服务的定义 (WSDL文档自动生成) 、保证企业级服务质量, 将复杂的服务调用、数据转换自动完成。
3.2.2 Web服务平台的选用原则5
(1) 平台必须是基于标准或规范的, 至少支持SOAP、WSDL。
(2) 根据企业或单位的各种需求, 解决方案考察现有及新兴标准, 并评估这些标准的成熟成度, 有无竞争的标准。这些标准在不同厂商的产品及技术间的互操作性。
(3) 考察企业的独特需求与资产, 充分利用这些已有的投入。
(4) 标准本身由于竞争问题产生互操作障碍, 要考虑WS-I是否有这些标准的Profile。
3.2.3 Web服务的实现过程
Web服务的开发过程可以分为服务的发现、服务的描述或发布、服务的逻辑实现、服务的调用。
3.2.3. 1 服务的发现
在SOA的实现过程中, 服务的发现是指在一定范围内 (通常是企业范围、或若干关键业务流程范围内) 确定可能成为服务的服务候选者。一般采用下述三种方法确定服务候选者。第一种方法是自顶向下分解业务进行分析, 该方法将业务活动从上层分解直至每个业务活动都可以清楚的进行描述为至, 然后再逐级向下分解每个子业务活动, 将最终的子活动做为服务候选者。第二种方法是通过业务目标来分析, 该方法通过对业务目标进行分析, 进一步找到新的服务。第三种是自下而上的对现有系统分析, 找出前两种分析过程遗失的服务。这三种方法共同筛选才能找出所有服务。服务的发现必须在业务、流程、业务流程、业务建模等抽象层进行, 贯彻业务对齐、松耦合、重用的原则。这主要由业务分析师和系统架构师完成。
3.2.3. 2 服务的描述或发布
服务的描述主要是完成服务的WSDL文档的生成, 用来说明服务采用的数据类型、提供的操作、传递的消息、服务与SOAP的绑定、服务的地址和名称、服务的质量等。服务的WSDL可以由服务开发人员书写, 也可以程序包装发布成服务时自动生成。服务的发布就是将具有独立功能, 完成特定业务的程序打包成Web服务, 在服务平台中注册。
3.2.3. 3 服务的逻辑实现
服务的逻辑实现由IT设计人员或程序人员完成, 同样的服务描述可以在不同的操作系统环境下, 用不同的语言完成。由服务平台完成服务描述到服务实现间的映射, 服务请求者不需了解技术细节。
3.2.3. 4 服务的调用
服务请求者必须输入实际参数、根据服务的WSDL编写和解读SOAP, 才能调用相关服务。这些可以由用户编写程序来实现, 也可以由Web服务平台自动生成, 即根据WSDL生成服务代理 (Service Proxy) 与服务框架 (Service Skeleton) 。服务调用者根据服务代理生成的调用代码调用服务, 服务开发者根据服务框架生成实现服务的代码框架。
4、SOA的发展趋势
4.1 We服务标准日臻完善
众多主流IT公司和组织的参与, 使各种基于互操作、安全、系统重构的标准不断完善。每一个标准大致从最初提出要经过Proposal Draft、Working Draft、Nomination Draft、Specification、Standards几个阶段。现在规范标准有:SOAP、WSDL、UDDI, WS-Security、WS-RP、WS-Reliability、SOAP-MTOM。推荐标准有:ASAP、BPEL、WS-Coordination、WS-Policy, WS-Addressing、WS-CAP、WS-Choreography、WSDM、WS-Eventing、WS-Federation、WS-IL、WS-Provisioning、WS-Reliable Messaging、WS-Resource Framework等。总共有30多个, 这些推荐、规范、标准为SOA的发展开辟了广阔的空间和奠定了坚实的基础。
4.2 SOA的开发平台
目前的主要开发平台有Apache SOAP2.3、AXIS1.2 (Apache Extensible Interaction System) 、IBM的Web Sphere application server6、Microsoft Visual Studio.NET、Sun ONE Web等。
在市场上, Web Sphere具有主导地位, Web服务应用平台市场的竞争主要就集中在IBM Web Sphere和Microsoft.NET两家之间6。随着开源运动的发展, 基于JAVA Bean的Sun ONE Web也成为SOA开发人员的重要平台。
4.3 基于SOA的应用开发发展迅速
到目前为止, IBM已经帮助全球4500多家企业成功地实施了基于SOA的整合, 这其中包括很多中国的企业, 如中远集运、北京朝阳区政府、南京玄武区政府、山西移动等。8在国内电力行业开始将原有系统改造成SOA架构, 许多企业开始将原有系统重新整合成SOA架构, 以满足新形势下业务敏捷性要求。许多高校和科研机构积极进行SOA相关的各种研究, 成如火如荼之势。
4.4 目前的研究热点
在SOA的开发中, 将多个独立的服务组合成复合服务, 形成服务流程, 通过服务流程满足企业业务的要求。服务流程的编排成为SOA系统的关键, 一个服务可以被多个流程使用, 一个服务流程也可发布为一个服务供其它服务流程调用。服务的评价是服务编排中必须考虑的问题, 服务的可靠性、响应速度、安全性等成为服务编排时的重要因素。
5、SOA发展中存在的问题
5.1 标准有待进一步完善
标准化不足是制约SOA发展的重要因素。Web服务是实现SOA最好的方式, 但Web服务本身还有很多不成熟的方面。除了SOAP和WSDL相对成熟外, 在可靠消息、安全Web服务、Web事务处理等方面的标准还有待完善。存在着不同组织机构竞争的局面, 如eb XML系列的标准和Web服务标准有重叠, W3C的WS-CDL与OASIS的BPEL同是服务编制领域的规范;Web服务规范中用于表达策略的有三种, 由BEA、IBM、Microsoft及SAP开发的WS-Policy Framework, OASIS的Web Service Policy Language (WSPL) , W3C的WSDL 2.0 feature and properties。这三种规范不统一, 给开发者造成选择的困难。
5.2 服务质量有待提高, 可公开的服务少
服务需要不断的维护, 并使用服务提供者的资源, 现在还没有建立一种有偿使用机制, 各大公司并没有向SOA理想中的那样, 将自己的服务公布出来, 影响了SOA的发展。
5.3 概念体系不够清晰
现在SOA被各种媒体热炒, 出现了各种错误的概念。如把Web服务的软件架构就认为是SOA, 又有人认为SOA是一种新的技术, 把SOA的实现技术ESB当成是SOA。将SOA与前面的软件设计割裂开来, 认为解耦、松耦合、代码重用是SOA的主要特征。
6、SOA实现过程中的问题解决办法
(1) 根据企业级服务质量构建SOA, 选择合适的服务质量规范, 合理的服务平台。
(2) 基于业务对齐的角度分析SOA的服务, 从低耦合、粗粒度、可重用的角度描述服务。
(3) 从局部到全局性逐步实现SOA, 甚至只实现传统部分系统的集成。
(4) 根据服务规约对服务质量进一步完善, 在有偿使用、服务响应时间、服务数据的可靠性、安全性等方面扩大服务的使用率, 推进SOA的发展。
结束语
SOA的发展必将对企业的业务拓展、服务质量的提升、技术成本的降低产生重大影响。对软件设计方法从思想、方法产生革命性的变化。我们现在谈论SOA多在理想的环境下进行, 总是认为所定义的服务恰好适合企业的业务, 不需要任何后续的返工或修改即可重用于多种业务运营;定义的服务已在粒度、耦合度、重用性和技术中立间作了平衡, 而且保持高效的、可伸缩的、安全的和可靠的优势。事实SOA的实现对一个企业来说应是一个长期规划, 经济效益是其根本。
摘要：本文通过对SOA产生的社会原因、发展过程的分析指出了其出现的必然性;从SOA的概念内函、标准、实现技术说明了SOA的基本组成;从SOA的设计模式、Web服务平台、服务的实现过程介绍了SOA的实现过程。同时分析了SOA的发展趋势、目前存在的问题以及应对办法。
关键词：SOA,Web服务,平台,系统集成,中间件
参考文献
[1].李春旺.SOA标准规范体系研究[J].现代图书情报技术.2007 (5) 。
[2].毛新生.SOA原理.方法.实践[M].北京:电子工业出版社, 2007.7。
[3].新浪科技.2007-11-01.SOA让世界变得更平.[EB/OL].http://tech.sina.com.cn/it/2007-11-01/16331827668.shtmlg
[4].王能斌, 王洌, 王泓.Web数据的管理和交换.北京:科学技术出版社, 2006.5。
[5].Eric Newcomer, Greg Lomow著, 徐涵译.Understanding SOA with WebServices中文版.北京:电子工业出版社, 2006.6。
[6].王瑄, 李燕.应用Web Services存在某些方面构建多层架构的高效.NET应用-XML China论坛开发纪实.北京:科学技术出版社, 2005.6。
基于SOA架构的教务管理系统 篇4
1.1 SOA介绍
SOA(Service—Oriented Architecture)是一种面向服务的架构,它将应用程序的不同功能单元称为服务,通过这些服务之间定义良好的接口和契约联系起来。
SOA着眼于日常的业务应用,并将它们划分为单独的业务功能和流程,即所谓的服务[1]。SOA的发展打破了传统应用软件开发的模式,实现了将软件依据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。应用程序不同功能单元的接口采用中立的方式进行定义,独立于实现服务的硬件平台、操作系统和编程语言,这使得构建在各种各样的系统中的服务可以一种统一和通用的方式进行交互[2]。
1.2 Web service
Web service涵盖了HTTP、SOAP、WSDL、UDDI等技术规范,在内网和外网上通过标准的协议和信息格式发布和访问应用服务。利用Web service的松散捆绑集合形式,能够快速开发、发现、发布和动态的绑定应用服务。
由此,基于Web service的SOA有助于企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。服务的提供者是创建服务的实体,它通过服务注册器发布服务合约,服务请求者通过查询服务注册器找到感兴趣的服务后向服务注册器发出的请求,如图1所示。
2 基于SOA架构的教务管理系统模型构建
2.1 需求概述
高校规模迅速扩大,校区分散所带来的一系列管理问题正严重制约着高校的发展,不同校区由于历史原因所使用的管理软件各不相同,而不同系统之间的交互问题则是迫切需要解决的问题。基于SOA架构的教务管理系统可以很好的解决系统间交互冲突问题,从而提升院校教学管理效率,提升不同校区间的发展潜力。
2.2 基于SOA架构的系统架构方案
在基于SOA架构的系统中,具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件组合构建起来的。因此,基于SOA的架构也一定是从企业的具体需求开始构建的。高校教务管理主要涉及到教务管理部门、学生和教师等,其主要功能为实现学生管理、教学计划管理、成绩管理等应用,其系统架构如图2所示。
2.3 基于Web service的系统逻辑架构
教务管理系统web service架构采用J2EE三层结构:数据表现层、业务逻辑层和数据层。
数据表现层是为教师、学生和管理人员提供应用服务的图形界面,有助于用户理解和高效的定位应用服务,如窗体服务、报表服务、页面服务和文件服务等。
业务逻辑层位于数据表现层和数据层之间,为实现教务管理系统的业务逻辑专门提供了一个明确的层次,在这个层次封装了与系统关联的应用模型,并把用户表示层和数据库代码分开。业务逻辑层提供客户应用程序和数据服务之间的联系,主要功能是执行应用策略和封装应用模式,并将封装的模式呈现给客户应用程序,如登录与身份认证、数据查询、数据导入/导出、数据统计分析和数据加解密等。
数据层位于三层模式中最底层,它用来定义、维护、访问和更新数据并管理和满足应用服务对数据的请求。
三层结构系统通过层与层之间分离的功能提供了更好的性能。这种应用结构使得业务逻辑层能从数据表示层分离出,变成一个明确的专业层,从而提高了系统的可维护性[3]。
3 基于SOA架构的教务管理系统实现
教务管理系统包括以下子部分:管理控制与数据处理、数据采集与信息发布和系统管理。管理控制和数据处理子系统涵盖了教学计划、课表安排、教材管理、学籍管理、成绩管理等子系统;数据采集与信息发布子系统以公共服务为主;系统管理子系统包含数据库加密、数据导入/导出、门户更新等子系统。
每一个子系统可利用Web Services提供统一的接口标准,在SOA下实现信息的构建、解析和传输,从而实现系统间的数据交换[4]。
JAVA具有跨平台的优越性,而J2EE的WEB服务可方便构建能够访问现有业务流程的SOA系统,因此可使用J2EE技术开发基于SOA的教务管理系统。
4 结束语
SOA架构中可通过拆分与组合各种核心模块,做到有针对性的构建满足不同需求的SOA应用系统。基于SOA构架的教务管理系统可实现学校自上而下整体的紧密结合,既杜绝了重复开发的高成本,又提高了教学管理效率。
参考文献
[1]叶宇风.基于SOA的企业应用集成研究[J].微电子学与计算机,2006,23(5):211-213.
[2]叶钰,应时,李伟斋,等.面向服务体系结构及其系统构建设计[J].计算机应用研究,2005,22(2):32-34.
[3]Krishna J,Narendra M.Thumbhekodige.Oracle J2EE Companion[M].北京:清华大学出版社,2005:85-90.
SOA架构模式 篇5
一、我国电子政务的现状与存在的问题
传统的电子政务系统主要针对各部门自身的业务需求来实现, 造成应用系统独立建设, 缺乏统一的标准, 各个部门自成体系, 信息资源分割严重, 信息孤岛大量存在, 资源获取和可用性差, 信息交换共享十分困难。
政务部门在各自的信息系统建设中, 多从自身业务出发来构建信息系统, 业务数据固化于软件实现中, 且信息资源单独管理, 造成了业务与数据的相对自我封闭。对需要跨部门共享的业务信息, 因其描述格式、描述方式均不统一, 标准化程度低, 导致大量事实性信息孤岛出现, 且不同孤岛间的数据获得与使用较为困难。如何建立起电子政务应用的标准化数据体系, 保证数据表达、处理、展现的规范化已经成为电子政务建设中亟待解决的重要问题。SOA的应用为突破信息孤岛、整合信息资源、协同政务应用、缩短开发周期、降低开发成本提供了很好的解决方案。
二、SOA的基本结构
SOA是软件工程方法的重要发展, 也是软件产业形态由产品转向服务的里程碑性技术基础。SOA是一种新的应用架构模型, 它以服务驱动为核心理念, 按需连接系统资源, 通过将原有应用中的零散功能整理包装为具有互操作性的标准服务, 实现服务的快速组合和重用, 保证应用敏捷性与扩展性, 满足政务业务发展需要。SOA结构中共有3种角色:①服务提供者。发布自己的服务, 并且对使用自身服务的请求进行响应。②服务注册中心。注册已经发布的服务提供者, 对其进行分类并提供搜索服务。③服务请求者。利用服务注册中心查找所需的服务, 然后使用该服务。SOA的基础是服务描述和服务发现。服务描述主要提供服务的接口描述信息和服务部署信息等。服务发现是指服务请求者通过查询服务注册中心去定位符合其需求标准的服务。
三、SOA在电子政务中的5种应用模式
SOA技术架构强调统一规划、统一标准、统一平台、统一管理, 以需求为导向, 以业务服务为焦点。所有服务以松散耦合的状态存在于系统之中, 可以随业务需求的变化, 快速组合成跨单位的具有高协作能力、高应急能力的应用系统。采用SOA的技术架构和技术理念, 一方面深度满足用户的业务需求, 另一方面解决了政务系统项目的重复建设问题。SOA在电子政务中的5种应用模式如图1所示。
1.软基础设施应用模式
从软基础设施的角度, SOA的应用可以分为利用信息资源目录梳理业务活动和业务对象的应用模式, 以及建立业务主题库的应用模式两类。利用信息资源目录梳理业务活动和业务对象的应用模式用于梳理业务以支撑基于SOA的应用;建立业务主题库框架的应用模式则主要是阐述如何建立业务领域的主题库, 基于这种应用模式可以建立多层次、分布式应用系统的基础库。
2.资源共享应用模式
资源可以通过服务的模式对外共享, 任何需要这些资源的机构和个人都能拿到所需要的资源。资源的有效共享依赖于3个方面:一是资源本身的描述, 二是资源本身的实际存储方式, 三是资源的提供方式。资源本身的描述和逻辑集中有赖于基于元数据的资源描述, 逻辑集中就是将资源的描述以目录的形式进行统一存储;资源的物理存储方式依赖于应用构建前期对数据的规划, 此层的变动只会影响资源的物理层面特性, 并不影响其服务的特性, 因此原有的对应用层限制最大的数据层, 通过目录的统一服务变得非常灵活而有弹性;最后, 资源的提供方式则是基于前两个方面的服务方案, 资源共享以服务的形式体现。
3.业务协同应用模式
如何实现这些业务的协同是SOA在这种应用模式下的重点。在这种应用模式下, 完成业务协同包括3个步骤:
(1) 业务处理服务。业务处理服务源于对组织内或组织间业务活动的分析, 组织内的业务处理服务可以直接基于业务活动抽象的用例来构造;组织间的业务活动一部分来自于对业务活动的分析, 另一部分来自于资源共享的需求, 进而依据这部分需求建立起共享的服务。
(2) 业务流程服务。业务流程服务源于对组织内各部门间或组织间的业务关系的分析, 通过建立业务的前置关系、后置关系从而形成业务流程, 依据业务活动间的关系建立起对外提供的业务服务。
(3) 服务查询检索。服务查询检索主要是供外部用户明确了解组织提供了哪些服务、具体的服务内容是什么以及如何获取和使用这些服务。
最后通过服务检索查询的功能开发定义明确的交互界面, 用户可以通过交互界面查询定位所需的服务。
4.不同服务渠道的应用模式
原有的系统建设通常不会建立服务层完成系统间的调用, 而是直接调用下层其他应用或者采用数据共享的方式, SOA在应用与业务之间加入一个服务层, 从而避免直接访问下层其他应用。另外, 在大多数机构中, 存在不同的应用和技术共存, 由于这些应用提供的功能都是特定的, 要在应用间共享信息最好的解决方案是转向一种面向服务的架构和Web服务, 即在业务层之上加入一个服务层。
5.基于虚拟数据中心的应用模式
即忽略数据在不同节点的部署而集中提供服务。如果要在单节点上提供虚拟数据中心, 可以建立非分布式目录中心用于提供虚拟中心服务;如果在多节点上建立虚拟数据中心, 即跨节点的虚拟中心, 需要建立分布式目录中心用于提供虚拟中心服务。
总之, 通过SOA应用模式分类体系的研究, 可以更好地帮助用户理解SOA的应用类型, 并结合SOA架构的优势, 确定业务建设下一步的方向。
四、基于SOA的电子政务系统设计优势
SOA的体系结构可以基于现有的系统投资来发展, 而不需要彻底重新创建新系统。如果将开发力量集中在创建服务, 利用现有的技术结合基于组件的方法来开发软件, 将可获得如下几个方面的好处:
(1) 利用现有资源。通过使用适当的SOA框架, 可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口名称, 服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种匿名性使组织能够利用现有资源, 通过合并运行在不同的操作系统中, 用不同的编程语言开发的组件来创建服务。原有系统提供的功能, 可以通过服务来封装并提供给新的系统或其他系统进行访问。
(2) 商品化基础架构。利用SOA框架, 可以使不同的政务网站应用程序之间, 基础架构的开发和部署变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的SOA框架内。这样的组件集合将被作为服务部署在现有的电子政务平台上。
(3) 减少成本。随着业务需求的发展和新的需求的引入, 通过采用SOA框架和服务库, 为现有的和新的应用程序增强和创建新的服务的成本大大减少。
(4) 持续改进业务过程。SOA允许清晰地表示流程流, 这些流程流通过在特定业务服务中使用的组件顺序标志, 这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中, 流程操纵是以一定的模式重组部件 (构成业务服务的组件) 来实现的, 这将进一步允许更改流程流, 而同时监视产生的结果, 促进了业务过程的持续改进。
(5) 以流程为中心的体系结构。现在的体系结构模型和实践往往是以程序为中心。通常, 流程信息在组件之间传播, 应用程序很像一个黑匣子, 没有粒度可用于外部, 重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中, 应用程序是为过程开发的, 流程可以分解成一系列步骤, 每一个步骤表示一个业务服务。实际上, 每个过程服务或组件功能都相当于一个子应用程序, 将这些子应用程序连接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。
五、结 语
综上所述, SOA的技术属性和电子政务的宗旨十分吻合, 使用SOA架构实现电子政务将达到事半功倍的效果。当然这并不等于采用了SOA架构, 就可以解决在电子政务中存在的所有问题。SOA和电子政务都在飞速地发展, 处于不断完善的阶段, 一些理论和实践的问题还处在探索阶段, 但是无论如何改变, SOA可以完善和解决传统电子政务中存在的诸多弊端, SOA可以在电子政务建设中发挥出巨大的优势。
摘要：针对我国电子政务系统存在的可扩展性差、容易形成信息孤岛等问题, 本文提出SOA能较好地实现电子政务系统中的业务协同与信息共享。在介绍SOA的基本结构, 分析我国电子政务的现状与问题的基础上, 探讨SOA在电子政务中的5种应用模式及基于SOA的电子政务系统设计的优势。
关键词：面向服务架构,电子政务,应用模式
参考文献
[1]赵育梅.中国电子政务发展中出现的问题及对策研究[J].北京邮电大学学报:社会科学版, 2004 (2) :68-72.
[2]Eric Newcomer, Greg Lomow.Understanding SOA with Web Services[M].中文版.徐涵, 译.北京:电于工业出版社, 2006:162-177.
[3]Andy Lin, Som Sengupta.使用应用程序平台跨越SOA障碍[J].bea dev 2 dev专刊, 2004, 4 (8) :26-30.
[4]姜国华, 李晓林, 等.基于SOA的框架模型研究[J].电脑与信息技术, 2007, 15 (6) :37-39.
[5]Olaf Zimmermann, Pal Krogdahl, Clive Gee.面向服务的分析与设计原理[EB/OL].http://www.ibm.com/developer works/cn/webser-vices/ws-soad1/, 2004-06-01.
基于SOA架构的供应链平台设计 篇6
供应链是指由原材料的供应商、制造商、分销商、零售商以及终端消费者等成员,通过与上下游成员的连接而组成的链状或网状结构。随着供应链的不断发展,供应链协同成为一种趋势,受到理论界和企业界的高度重视,提出了应对供应链协同的种种策略。它的实现以协同机制为前提、以协同技术为支撑、以信息共享为基础,从系统的全局观出发,促进供应链企业内、外协调发展,在提高供应链整体竞争力的同时,实现供应链节点企业效益的最大化。
随着供应链竞争的不断加剧,供应链企业的管理水平也不断提高,呈现出以下一些新趋势:物流与信息流结合日趋紧密;质量管控主体由单一企业转变为供应链;供应链企业数量逐步精简。
在信息化建设的过程中发现,由于编程语言、数据标准和通信协议的异构问题已经严重阻碍了企业内部和企业之间实现业务协同的进行[1]。为适应当今时代对企业供应链信息化的新要求,需要建立新型的供应链平台。新型供应链平台需要最大限度地消除业务和软件技术之间存在的巨大鸿沟,快速响应业务上的需要。在市场需求的不断刺激下,面向服务的体系架构(Service Oriented Architecture,SOA)设计方法应运而生。SOA改变了以技术为中心的信息系统建设模式,让IT技术重新回到业务支撑的角色,提供了一种把原有组件按一定的标准封装为具有文档形式接口描述的服务,使得服务的提供者和服务消费者之间是一种松耦合的关系[2]。这带来了业务流程重组的巨大优势,因为SOA提供了对企业业务的快速反应和敏捷性要求的支持[3]。
2 面向服务体系结构
2.1 SOA概念
SOA(Service Oriented Architecture,面向服务架构)是一种为实现业务与技术的完全分离从而实现与具体技术无关的架构思想。它将信息系统模块化为服务,并通过服务的重新编排组合实现新的或者更好的业务流程[4]。它包含了松散耦合、粗粒度、位置和传输协议透明等基本要素,从而达成敏捷的、不受限制的业务集成目标,具有复用性、抽象性、正式性和明确性等特点。这样的架构能从根本上解决企业部门间信息互通共享的问题,避免了信息孤岛的出现,从而在沟通合作不断增强的扁平的世界创造出更多的价值。
2.2 SOA服务架构
SOA为解决企业业务系统集成中的各类异构问题提供了一种解决方案,其核心概念是业务重用与企业级的互操作[1]。SOA架构本质上是服务/客户端模式,客户端消费服务可以通过WSDL来实现,即服务通过WSDL发布并对外提供服务,客户端通过基于HTTP之上的SOAP协议来调用服务[3]。
2.3 企业服务总线
在SOA架构下,服务提供者和服务消费者通过一个公共的通讯框架进行通讯,这个公共的通讯框架就是企业服务总线(Enterprise Service Bus,ESB)[3,5]。通过ESB,每个服务组件可以和许多个其他类型的服务进行通讯交换。ESB是SOA架构的基础设施,提供服务提供者和服务消费者的服务命名和查找规则,具有安全、事务控制、消息机制、服务管理和监控等功能,支持异构环境的服务、消息以及基于事件的交互。ESB为基于Web服务、J2EE、.NET和其它标准的应用提供一个基于XML标准的信息通路,使得来自不同硬件平台、不同操作系统和不同语言开发的应用能够以一种松散耦合的方式连接在一起,构成具有复杂逻辑、功能更为强大的合成应用[1]。
3 基于SOA的供应链平台体系设计
随着市场化的不断深入,供应链管理要求灵活高效的供应链协同平台。通过研究,该文设计了基于SOA供应链管理协作平台。
3.1 平台体系架构
供应链管理协作平台的架构设计需要支撑供应链信息高效交互,并包含有信息集成环境、功能软件、信息采集与传输软硬件等基本内容。该文通过梳理供应链管理流程,明确面向供应链制造过程协同的信息流和信息源建设需求,结合上述各项关键技术,并结合SOA的思想方式,设计了供应链平台。该平台体系架构图如图1所示。
本文对其平台架构分析如下:
1)表示层。本层提供供应链平台的入口,是用户与平台交互前台。它包含供应链平台门户入口,平台商业智能数据挖掘分析及报表呈现,以及为供应链的关键业务活动提供全程实时监控。
2)服务层。本层将供应链平台所设计的功能以及已有系统的各个功能模块封装为服务。包括清单管理、采购管理、库存管理、质量管理、物料管理等所有服务均可按照实际的业务过程来进行配置和优化。
3)总线层。本层是供应链平台的核心部分之一,主要包括企业总线、业务过程和规则引擎三个部分。通过总线层,应用服务组合优化配置,实现各种业务流程整合集成。
4)组件层。本层用以实现相关的业务逻辑,包括数据访问组件、业务逻辑组件等。数据访问组件是将分布在不同服务器上的异构数据源,通过一个完整的数据定义,将各种数据对象描述成统一数据资源视图;业务逻辑组件采用图形化的方式将运算逻辑、服务组装成更大粒度的组件[2]。
5)基础设施层。本层是整个供应链平台的基础性部件,提供平台的运行环境以及开发环境,支撑平台的平稳可靠运行以及二次开发。
6)数据交换层。本层为整个供应链平台提供统一标准格式的数据,为平台的运行和维护提供数据交换服务,保证数据流的高效运行。
7)安全管理层。本层为供应链平台提供统一的安全认证服务,包含有用户管理、单点登录和访问控制,为平台的平稳运行提供重要保障。
3.2 平台功能分析
此平台按照功能划分可分为:基础软件应用平台和集成的通用功能服务。这些通用的功能服务包括模型服务、文件服务、报表服务、监控服务、消息服务、知识服务等。具体的服务功能如图2所示。
模型服务:提供业务对象模型化,业务节点模型化等面向对象设计功能,支持业务对象间关系调整、业务对象管理功能。
文件服务:对平台内文件的创建、删除、更新、查看操作和文件传送、文件加密、文件加锁等功能进行统一安全管理。
报表服务:提供灵活的查询分析及高级分析,以及对商业智能的分析结果按照定制模板生成各种专业报表。
监控服务:根据需要,通过本服务,只需简单配置,即可实现灵活实时地对供应链各业务活动进行监控。
消息服务:提供创建、发送、接收和展示消息的服务,并通过定义一组公共应用接口和相应语法,保证了各消息服务方便快捷地通信。
知识服务:将平台里的各种数据转化为知识,以支持企业的商业智能分析,帮助企业业务决策。
4 总结
随着新形势下市场竞争的不断激化和信息化的加速发展,企业内部众多的信息管理系统需要统一的平台进行整合,以形成企业内部供应链平台的一体化,从而打破企业内部的消息壁垒,实现企业信息资源方便高效快捷的互通互享,提升企业的经济效益。
本文将SOA架构运用到企业供应链平台中,把企业核心业务模块封装成一个个标准的服务,根据实际的业务需要进行组合编排调用。该文详细地设计了对基于SOA的企业供应链平台架构,并实现了该平台的主要功能服务模块。基于该SOA架构的供应链平台已按本文设计在上海某企业得到相当成功的应用,为企业带来了供应链成本的降低、供应链服务水平的提高,进一步发挥了企业信息化的巨大优势,取得了良好的经济效益。
摘要：SOA是一种将信息管理系统模块化为服务的架构风格,可简单地通过服务重新编排组合来灵活应对业务流程上的不断变化,从而为企业信息化的深入开展提供了强有力的保障。该文利用SOA思想,设计了基于SOA的企业供应链平台架构,实现了该平台的主要功能服务;在实际的应用中,降低了供应链成本,提升了供应链服务水平,取得了良好的经济效益。
关键词：SOA,供应链平台,企业信息化
参考文献
[1]隋新,朱云龙,南琳,等.基于SOA的供应链管理平台设计与实现[J].计算机工程与设计,2012,33(1):147-152.
[2]曲建华,徐广印,应继来,等.基于SOA的物流公共信息平台设计研究[J].河南农业大学学报,2012,46(1):103-107.
[3]胡德华.SOA之道:思想、技术、过程与实践[M].上海:上海交通大学出版社,2011:4-15.
[4]Brown P C.Implementing SOA:Total Architecture in Practice[M].Beijing:China Machine Press,2009:1-4.
SOA架构模式 篇7
关键词：SOA,医疗信息共享
1、引言
现有的医院信息系统大多采用面向对象模型的3层体系架构, 甚至还有部分系统停留在双层体系架构之上。这些体系架构都属于紧耦合的应用系统集成方式, 由于各个集成系统之间紧密集成, 降低了应用系统的灵活性和扩展性, 增加了整个系统维护的难度, 阻碍业务的流程调整和优化, 不利于医院业务长期发展, 而基于SOA的医疗信息系统集成结构具有松耦合、定制灵活的特点.并且由于统一的集成模式, 使得信息共享的一致性成为可能。
2、面向服务的体系结构SOA
面向服务的体系结构 (SOA) 是一个组件模型, 它将应用程序的不同功能单元 (服务) 通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的, 它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
3、医疗信息共享平台方案设计
如何设计一个横向能够有效地承载不断增加的多个医院异构系统在同一平台上的信息交换与共享, 纵向能够承载应用的不断深化和提升, 是技术上需要考虑的核心问题。
3.1 框架设计
在设计中, 基于SOA理念设计的医疗信息共享平台, 其技术架构为一个六层的分层服务组合框架, 包括:医院信息访问网关、企业服务总线、基于HL7 RIM的临床数据存储模型、工作流引擎、公用基础服务组件和业务服务组件、应用服务项目和信息访问门户组成。每个服务都是相对独立的应用, 并采用基于消息的松耦合技术, 通过服务总线实现应用之间的业务协作。
最底层是部署在各家医院的前置机, 作为医院信息访问网关, 负责与医院各业务系统的交互。基于IBM适配器技术的医院信息访问网关由应用适配器、前置服务代理、消息传递服务三部分核心模块组成。应用适配器是通过业务对象来描述系统的交互接口模型。由适配器方式采集后的数据, 通过前置服务代理模块实施数据的清洗, 封装为XML消息格式;然后通过IBM的MQ传输链路, 实现前置机至中心端的消息传递服务, 完成数据上传工作。针对医学影像传输, 是在中心端架设FTP服务器, 由前置机将影像定期传至中心端服务器, 并以文件形式存储。
第二层企业服务总线作为整个架构的核心, 负责聚合应用接口层接入的整合点, 进行服务之间的协调中介。本项目是采用IBM的MB (Web Sphere Message Broker) 产品作为共享平台的企业服务总线解决方案, 其主要功能:一是提供消息转换功能, 对MQ上传的数据进行清洗和标准化处理;二是路由, 对转换的数据指定输出, 决定每一个具体的业务操作或数据究竟连接到哪里, 如何配置到指定的数据库或应用服务等;三是内嵌对Web Service的支持, 支持访问已有服务 (Web Service) 的交互, 支持把消息处理流程暴露成Web Service, 并且内嵌对服务注册和管理中间件交互和访问的支持:四是统一的消息监控、日志管理, 可以在MB处理流程中增加监控节点, 日志节点, 以MB为依托做到统一管理, 目前的MB平台提供一些基本的监控和日志查看功能, 将各类服务管理起来。
第三层是在企业服务总线基础上, 采用基于HL7 RIM的Oracle HTB (Healthcare Transaction Base) 产品作为临床数据存储模型, 负责管理和存储不断发展变化的临床数据。整体模型分为三部分, 每一部分自成体系, 通过每次医疗卫生活动进行关联。核心部分为临床医疗活动, 一方面, HL7 V3 RIM模型对医疗业务做了高度抽象, 可以对任何一个具体的RMIM模型连接与加入新的属性;另一方面, 由PMI模块完成对患者与病历的关联关系管理;再一方面, 方便的在医疗活动中加入新的活动, 以适应临床数据的复杂性和不确定性。
第四层通过基于IBM Smart Workflow成熟资产的工作流引擎设计, 负责提供整合应用程序的方法, 以及提供将应用程序封装为更大粒度服务的方法。业务需求的变化有两个方面, 一是业务本身发生变化, 二是业务流程发生变化, 将这些变化管理起来, 管理可持续优化的业务模型, 是工作流引擎的关注点。
第五层在上述基础上, 提供各类组件服务。一是公共基础服务组件;二是对医疗信息共享平台涉及的业务进行分析和抽象, 形成业务服务组件, 包括:患者基本信息调度服务、患者就诊记录调度服务等, 为上层的业务功能构建提供服务。
最顶层是在服务组件之上提供基于IBM Portal/WAS技术的门户功能, 实现信息发布调阅服务及用户管理认证服务。
3.2 医疗机构应用服务封装与组合
第二层ESB (企业服务总线) 作为整个架构的核心, 负责聚合应用接口层接入的整合点, 进行服务之间的协调中介。将各医疗机构的各种业务系统需要通过ESB节点适配器组件来连接ESB总线, 通过各系统与总线的业务流程和数据交换来实现各业务系统之间交互服务。
3.2.1 应用服务分析
采用自下而上的方式, 列举出医院中实际运行的系统, 并将这些系统对应到候选服务的列表, 运用SOA的思想, 细化功能模块, 将功能模块做为服务暴露出来, 以供其它应用程序通过ESB总线调用。
在设计过程中可使用工厂模式和适配器模式, 这些模式能够有效地加强系统的结构灵活性, 减少系统后期的维护复杂性。以下举例工厂方法在SOA架构平台的应用。如图1所示:
图1是信息共享平台中工厂模式的典型应用, 图中的Service Factory类就是一个工厂类, 其功能是根据配置或输入参数制造出所需要的实体类。LISWeb Service和Hl SWeb Servlce是两个实体类, 分别是检验系统和医院信息系统暴露的类封装。
3.2.2 服务调用流程
完成医疗机构应用封装并接入ESB后, 业务系统之间就可以实现应用调用。以LIS系统通过调用HIS系统病人基本数据服务的情况为例, 调用过程如下:假设医院的HIS系统己经将病人基本数据服务注册到ESB服务总线上。服务请求者 (LIS系统通过适配器组件用WSDL描述需要访问的服务, 用SOAP消息向ESB总线发出查询病人基本数据请求;LIS系统发出的请求经系统认证授权, ESB总线会根据请求查询到总线上注册病人基本数据服务, 并将LIS系统发出的消息转换成HIS系统发布服务所要求的数据格式, 并将该服务请求向HIS系统发出相应的SOAP请求消息;经ESB总线发出的请求消息通过适配器组件传递给HIS系统, HIS系统则根据该消息将病人的结果通过适配器组件以HIS系统发布的Web服务转换成符合HL7标准的XML文档, 然后封装成SOAP消息;该SOAP消息会传递回ESB总线, ESB总线则将结果转换为LIS系统所能识别的数据格式并以SOAP消息封装传回给LIS系统。
3.2.3 新增业务绑定实例
基于SOA灵活的架构使得任何新增的业务环节, 都可以以服务的形式发布, 其它业务流程只需要经过ESB总线进行调用。以为病人转检增加审计环节为例, 如下图2是在病人转检的业务流程中增加审计环节时, 系统框架中的企业服务总线与工作流引擎的服务组合过程实例。
病人转检的业务流程中需要增加审计环节时, ESB (企业服务总线) 可配置一个对审计数据库的整合模式, 连接到相应的审计数据库后, 可按标准数据格式进行交互式操作 (读取或插入数据) ;交互过程中, 直接在基于工作流引擎的流程管理平台上配置一个节点去映射这个动作即可。
通过这种服务组合方式, 可轻松应对业务需求的变化, 直接实施IT系统的转向支撑。
4、小结
本文针对当前医疗信息系统的整合重点, 建立协同的医疗信息共享平台做了重点讨论, 设计了基于SOA的医疗信息共享平台架构, 并讨论了实现方法。对构建区域型的医疗信息系统共享提供参考。
参考文献
[1]毛新生, SOA原理方法实践[M], 北京:电子工业出版社, 2007
[2]梁爱虎, SOA思想、技术与系统集成应用详解[M], 北京:电子工业出版社, 2007