面向服务架构SOA（精选10篇）
面向服务架构SOA 第1篇
一、SOA与电力行业的发展形势
1. 电力行业发展形势
电力企业信息化经过几十年的发展, 产品已经涉及电网调度、能量管理、配电自动化、企业管理、营销管理等多个方面。虽然电力系统的信息化建设已经有了一定的规模, 但是由于这些信息系统是在不同时期、不同软件开发商分别完成的、又归不同电力企业或业务部门使用, 导致各部门网络资源无法充分共用, 形成大量分散异构的“信息孤岛”, 很大程度上限制了电力行业信息化的应用和电力事业的发展。
电力企业信息集成的实现技术在业务需求与技术的双重驱动下经历了点对点的集成模式、企业消息总线或中间件集成 (即EAI) 模式、基于分布式通讯技术的企业应用集成模式三个阶段的演变。应用系统之间的互操作通过点对点的函数调用来实现。当只有少量系统需要集成时可以快速实现, 但如果一个EIS发生改变就会打破与它有关的应用集成, 而且每个EIS都要求有足够多的整合点来支持更多的系统集成, 即有n个互相集成的EIS, 就需要n (n一1) /2个不同的整合点。通过面向消息的中间件 (MOM) 来实现应用系统之间的数据互操作, 成为一个集中业务处理的平台, 称为EAI (企业应用集成) , 它基于消息总线/代理或者中间件。基于CORBA、DCOM和RMI等分布式通讯技术的企业应用集成, 虽则可以实现一些复杂的应用集成, 也取得了较大的收益, 但在Web环境中, 它们的体系架构并不适合扩展到Web上, 由于传输、数据定义、访问模型等机制均不一样, 各自的应用不是很容易互连互通, 同时缺乏一种普遍的方法进行描述和定位, 故直接集成的难度较大, 因此整体上还存在一定的局限性。
2. SOA的国内外发展现状
据最新调查显示, 目前IBM占全球SOA市场份额的64%, 远远领先于其他提供商。从整体上分析, 主流厂商所提出的SOA实施方法及应用案例多集中在金融、银行、医疗、卫生等领域。国际上SOA标准整体上缺乏统一, 这些规范及标准仅在各个标准化协会或企业内形成初步的体系, 而且不同组织发布的规范及标准间存在重复甚至冲突的现象。国际上统一的SOA标准体系短时间内还没有成型。
我国SOA起步比国际晚, 但发展迅速。各个行业用户经历了近几年的概念宣贯, 部分CIO已经能较准确地理解SOA的内涵, 并开始着手实施。从2005年至今, SOA已经逐渐成为影响中国IT系统构建的主导思想, 众多国内基础平台厂商、应用软件厂商及系统集成商纷纷推出了基于SOA的软件产品及行业解决方案。2006年, 基于SOA的产品及建设方法已逐步在我国金融、电信、烟草、钢铁制造、电子政务、医疗卫生、军事等行业或领域的信息化建设中得到越来越广泛的应用, 成为解决当前各行业信息化中普遍面临的信息资源共享难、信息孤岛严重、IT系统之间难以协作等难题的有效途径。
二、SOA基本内涵
1. SOA定义
面向服务的体系结构 (SOA) 是指为了解决网络环境下业务集成的需要, 通过连接能够完成特定任务的独立功能实体的一种系统架构。它是一个组件模型, 将应用系统的不同功能实体 (称为服务) 通过定义联系起来, 从而使得开发人员能够调用服务的功能来快速便捷地构造企业所需业务系统。从S0A的定义中, 我们看到两点:SOA不是一种语言, 也不是一种具体的技术, 更不是一种产品, 而是一种软件系统架构;服务是整个SOA实现的核心。
2. SOA的核心和特点
(1) 服务的重用。服务的可重用性显著地降低了企业应用系统开发的成本。为了实现可重用性, 服务只工作在特定处理过程的上下文中, 独立于底层实现和客户需求的变更。
(2) 服务的互操作。在SOA中, 通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。SOA提供服务的互操作特性更利于其在多个场合被重用。
(3) 服务是自治的功能实体。服务是由组件组成的组合模块, 是自包含和模块化的。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。SOA架构中非常强调功能实体自我管理和恢复能力。常见的用来进行自我恢复的技术, 比如事务处理, 消息队列, 冗余部署和集群系统在SOA中都起到至关重要的作用。
(4) 服务之间的松耦合。在基于SOA架构的系统中, 具体应用系统的功能是由一些松耦合并且具有中立接口定义的服务组合构建起来的。松耦合系统的好处有两点, 一点是它的灵活性;另一点是, 当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时, 它能够继续存在。
(5) 服务是位置透明的。服务是针对业务需求设计的, 要想真正实现业务与服务的分离, 就必须使得服务的设计和部署对用户来说是完全透明的。也就是说, 用户完全不必知道响应自己需求的服务的位置, 甚至不必知道具体是哪个服务参与了响应。
3. SOA的优势
电力企业信息化中的“信息孤岛”问题, 迫切需要一种有效的、新的集成方法来克服传统的信息系统集成的缺点。而SOA的特点刚好满足此方面的需要。
SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准, 为企业的现有资产或投资带来了更好的重用性。它能够在最新的和现有的应用之上创建应用, 能够使客户或服务消费者免予服务实现的改变所带来的影响, 能够升级单个服务或服务消费者而无须重写整个应用, 也无须保留已经不再适用于新需求的现有系统。总而言之, SOA以借助现有的应用来组合产生新服务的敏捷方式, 提供给企业更好的灵活性来构建应用程序和业务流程, 如图1所示。
S O A业务流程是由一系列业务服务组成的, 可以更轻松地创建、修改和管理它来满足不同时期的需要, 其优势主要体现在如下几个方面:
(1) 利用现有的资产;
(2) 更易于集成和管理复杂性;
(3) 更快地整合现实;
(4) 减少成本和增加重用。
三、SOA在电力行业的研究与应用
采用SOA架构进行电力系统间现有信息系统集成应按照以下步骤执行 (如图2所示) :提取各个应用信息系统中需要对外暴露的功能模块 (这些功能模块通常都是一些能够清晰完整地表现其业务价值的软件实体) , 将这些功能模块表现为服务组件的形式, 定义服务的描述信息、服务的接口以及调用服务所需要的定位信息等;将软件实体的概念模型转换成实际的服务模型;将已实现的服务发布到服务注册中心, 供其他服务消费者进行查找和绑定;绑定和调用服务, 将各个应用信息系统集成起来, 实现企业应用在功能层面的集成。
从电力行业自身来说, 早在上世纪90年代初, 美国EPRI就开始研究CCAPI (控制中心应用程序接口) , 试图解决EMS系统高级应用的可插拔问题, 项目的研究成果成为后来IEC 61970标准的原型。而IEC 61968标准则是IEC 61970在配网与管理信息系统领域的扩展。IEC系列标准的制订可以看作电力行业在推进信息共享和应用软件共享上所作的努力, 与SOA的理念不谋而合。IEC61970标准旨在通过统一的数据模型和统一的接口规范将不同的开发商, 不同的系统、不同的应用整合在一起, 实现EMS应用的“即插即拔”。IEC61970标准所针对的是EMS系统间的组件标准化, 目标是实现状态估计、调度员潮流等应用与电网参数, 电网拓扑模型、实时数据之间的松耦合。
随着越来越多的电网企业选择实施ERP进行系统建设, ERP产品的提供商为电网企业提供了包含数据集成、流程集成、门户集成等手段的整体解决方案。这些解决方案将IT行业的最新技术与理念融合在一起, 实现了电网企业ERP应用的集成。但是仅仅实现ERP应用的集成, 或者仅仅是实现EMS/DMS组件化已远远不能满足电网企业信息化发展的需求。ERP系统与EMS系统作为同一对象不同维度的管理者, 两系统之间数据与流程集成的需求将越来越高。建立一个基于SOA理念的企业级集成服务总线, 建设一个容纳多种技术层次, 多种应用层次, 贯通EMS与ERP应用的集成平台成为电网企业IT发展的必然趋势。
四、SOA在电力领域的前景展望
基于SOA的电力信息化实践的关键任务是电网企业的公共服务构建。例如, 开发并部署统一编码服务, 开发并部署统一模型服务, 开发并部署数据访问服务, 开发并部署可视化展示服务, 等等。此外, 还包括对现有系统的SOA服务封装, 例如, 对ERP系统进行服务封装, 对EMS提供的数据和服务进行进一步的封装[14]。
SOA并不只是一种技术, 还是一个业务概念, 尤其是对集约化多部门的大企业而言, SOA强调的是应用的可重复利用, 强调的是业务的横向融合, 这需要整体的企业文化与之相适配。实现SOA技术架构的道路同时是实现管理扁平化的道路。对电网企业来讲, SOA所能给予的不仅是一个整合后的实时应用系统, 一个集实时应用、资产管理、电网规划为一体的系统, 更是一个将投资、规划、建设、运行、维护等业务有机融合的体系。这个融合体系所体现的效率是我们推行SOA架构的源泉动力。因此, 可是说, SOA在电力行业以及其他众多行业前景必将拥有极好的发展前景。
摘要：本文针对当前电力行业的发展形势、发展历程及信息化应用现状, 介绍了面向服务架构 (SOA) 的基本内涵、特点以及其在电力行业的应用优势和现状, 阐述了SOA在电力行业的主要研究内容, 并对SOA在领域内的发展前景进行了展望和估计。
面向服务架构SOA 第2篇
1.主要趋势
在年或 20，企业将意识到它们对技术的投资过度、收益甚少，因而将重新审视CRM项目与业务战略的匹配程度。同时，一些生命周期即将结束的老系统也需要升级到新一代的CRM架构。到，大部分组织都需要进行CRM改革，届时将有针对行业特点的CRM软件、面向服务的架构、集成的框架出现。同时，全球个主要组织中的15%将建立起最完美的CRM系统，成功地将顾客生命周期渗透入他们的业务实践中。
7年前，两层的客户端/服务端软件是主流。现在，面向网络的、n层的架构占据了主要地位。现在，CRM行业正处于另一个大发展的中间阶段，许多供应商都在向面向服务的架构挺进。对于企业来说，这种架构发展将直接影响到CRM的升级问题。
CRM的实施方法也经历着大变化。人们围绕着在企业内实施CRM还是进行主机托管这个问题进行了激烈的争论。基本上，所有的企业都希望知道，对CRM进行主机托管到底是否可行。此外，一些新技术的托管也影响着CRM，比如门户技术、业务流程管理、顾客数据集成。随着技术之间的融合，企业需要进行跨功能、跨系统的集成，CRM战略也必须制定出新的有创意的解决方案来。
2.CRM升级
2004年是CRM的“升级之年”，这对CRM供应商、系统集成商来说都是一个好消息。推动企业进行升级的因素有两个：
第一，大部分供应商的最新产品在架构设计方面有了重大进展，但很多企业暂时还没有升级到这一版本。在和，由于 IT资源紧缺，升级到新一代架构困难重重，对业务的投资回报也模糊不清，许多企业的升级计划都搁浅了。但是随着供应商发布新一代web架构的第二、第三个版本，随着企业IT预算的增加，他们开始意识到自己可能会比竞争对手落后几个版本，因此企业在2004年开始认真解决升级的问题，至少是要制定一个在12 个月之内进行升级的计划。
第二个因素是维护问题。一些供应商今年的维护任务大增，因为如果客户不升级到新版本，他们必须对老版本进行维护。而另一些供应商则减少了对老版本进行技术支持的人员，或者完全取消了支持。
现在进行升级的企业诚然要支付一笔升级费用，
但那些拒绝升级的企业可能会失去供应商对旧版本的支持，可能会比竞争对手落后几个版本，他们在维护方面的支出将更加高昂。尽管如此，除了升级还是有其他路可走的，比如更换供应商。
3.CRM实施：集成CRM组合
在决定实施CRM之前，必须仔细考虑这些关键因素：软件是否最适合本企业，成长性、移植性如何，IT成熟度如何，拥有成本如何。主机托管和企业自行维护的CRM软件都能够为企业带来巨大价值，但是企业不能只关注交付模式。企业更应该关心的是，CRM软件能否支持当前的和未来的业务需求和技术需求，是否在IT资源和业务资源约束之内，这是CRM成功的关键。
主机托管CRM供应商，尤其是salesforce.com，在市场宣传方面做得很到位。许多企业都想知道，主机托管的CRM能否满足他们的需求。一般来说，进行主机托管的企业看起来都十分满意他们的决定。虽然能够进行托管的内容十分有限，但许多企业都被这些供应商的定位——“更快/更便宜/更好，而且你不需要为IT烦恼了”迷住了。此外，在许多情况下，长期战略——尤其是CRM业务变革——被短期的、局部的利益取代了。更加快速的实施和获得投资回报是不错，但如果这是以长期利益为代价，那是不可行的。以前CRM行业的经验也说明了这一点。
企业必须选择一种实施方式，在企业内实施软件，还是进行托管，或者将整个功能与系统都外包出去。这里不存在哪种方式更加好的问题，因为不同的方法适用于不同情况。关键是要对各种CRM组合进行集成、管理，并使它们支持企业的CRM战略。
4.新技术及其对CRM的影响
集成仍然是CRM实施中的困难。企业在 CRM软件上的花费只占咨询与实施上的花费的1/3。在CRM的服务成本中，60%是用于集成系统和数据的。虽然有很多工具、方法、技术可用于CRM的集成，但仍出现了许多解决CRM集成需求的新技术和新市场。下面的几种技术尤其值得注意：
门户：虽然门户不是一个新市场，但它们与CRM 的关系越来越密切了。门户是一种将软件、内容、业务逻辑/规则、数据集成为一个统一用户界面的机制。门户框架从业务流程出发，为特定的用户、任务或角色提供了个性化的信息。比如，许多企业都在开发门户，以实现CRM中联系中心的单一集成代理desktop。
BPM：许多企业都在从传统的部门工作流向贯穿整个企业的业务流程转变。虽然现在的BPM产品还是十分分散，需要很多组件集成起来，但BPM的目标是要实现跨功能的业务流程的自动化和持续优化。这对于CRM来说尤其重要，因为销售、服务、营销流程跨越了企业内外的多个部门。
CDI：CDI战略是通过底层的数据聚合、合并、协同来实现顾客的全景视图，同时应用价值标准来衡量顾客，以制定有效的客户关系战略。一个成功的CDI战略能够实现现有和未来CRM投资的价值。简单地说，CDI是CRM战略中的圣杯，因为它能够通过相关的CRM流程实现客户记录的单一视图。
5.结束语
面向服务架构SOA 第3篇
【关键字】面向服务的体系结构（SOA）；服务布署；教学管理系统
随着网络技术的快速发展，为了最大发挥校园网的优势，如何以最小的成本在现有平台的基础上将原有的教学管理系统有效的集成，最大程度的提高工作效率已成为目前高校急需解决的问题。SOA的架构的出现，作为分布式计算的一种新技术可以有效地解决此问题，成为目前高校信息集成的首选。
1、SOA架构的定义及组成
SOA的架构，全称是面向服务的体系结构。采用这种架构的应用程序它主要是通过使松散耦合的接口形式对组件进行分布式部署、组合和使用。采用这种架构的应用程序主要是将功能模块进行服务布署进行实现资源共享。这种架构的模型主要由服务的提供者，服务的发布，以及服务的请求者对服务调用三方面组成。在SOA这种架构的应用程序中，服务是核心，所有的资源共享都是能过服务的形式来完成。
2、教学管理系统的主要工作流程分析
教学管理系统是目前高校普遍使用的日常工作管理系统。该系统以教学为核心，涉及多部门共同协作。下图简要的显示了目前教学管理系统的主要工作流。
3、基于SOA架构的教学管理系统的服务布署
将教学管理系统以SOA的架构形式进行信息的集成，进而实现信息共享。实现这种架构的主要方法就是将教学管理系统中涉及的信息交换转换成SOA架构的模型三要素的形式通过网络进行服务布署。
（1）服务创建（即为SOA架构提供服务）
在基于SOA架构的教学管理系统中，我们只需要将各个系统中功能相似的模块进行封装，创建为Web服务即可。从而实现代码的重用和数据共享。例如，在教学管理系统的主要工作流程中，我们可以看出，教学的核心工作都是围绕学生和教师展开的。因此，学生和教师的基本信息就可以创建为Web服务为各部门所共享。这种创建的Web服务在SOA架构的应用程序中就服务提供者。
（2）服务的发布
在SOA的架构中，我们创建Web服务只是系统集成的基础，重要是将服务通过网络发布，才能实现共享。我们可以使用Windows 2003Server服务器来实现服务的发布。
（3）服务的调用
在SOA架构模式下，将教学管理系统的信息集成，创建服务和发布服务都是为服务的调用打基础。只有服务请求者最终通过网络查询到该服务，才意味着信息共享的成功。服务的调用只需要将请求发送至服务中心，服务中心会自己搜索匹配的信息，然后将结果反馈给请求者，至此，服务调用完毕。在SOA的架构中服务创建者和服务调用者在发布和调用信息时是全双工通信手段，彼此的角色在不同的需求中是互换的。
4、基于SOA架构的教学管理系统的服务的实现
基于SOA架构的教学管理系统能够解决分布式应用程序的系统集成问题，从而解决“信息孤岛”问题。采用SOA架构将原有的教学管理系统需共享的信息以服务的形式进行布署和封装，其实现的过程主要分服务器端和客户端的实现两部分。
（1）服务器端的实现
Web服务的创建使用.Net平台做工具，.Net平台内建了对Web Service的支持，不需要第三方开发工具即可。同时.NET平台还提供了Web服务的测试，可以很方便的验证Web服务是否创建成功。后台数据库我们采用SQL Server 2005，这是一个比较成熟的数据库系统。服务的发布采用Microsoft Windows 2003 server服务器操作系统，该服务器自带了注册中心。服务器环境部署完毕之后，就可以进行应用程序的开发，在对新的教学管理系统的应用程序进行调试、运行，并确定其正确无误之后，将其發布为Web服务。
（2）客户端的实现
在SOA架构下，我们在服务器完成Web服务的创建和发布，实际上就完成了信息集成的主要工作。客户端服务的调用不论平台是否异构只要支持网络浏览器即可。客户端将请求发布到服务器的注册中心，注册中心即可实现数据查找然后通过服务器进行信息传送。
5、结束语
面向服务架构SOA 第4篇
为了保障网络证券交易的安全, 科研工作者们针对这一问题展开了大量研究, 获得了卓有成效的进展。迄今为止, 在密码保护、身份认证、日志审计等各个方面都已形成了成熟的技术和标准;同时, 也能够见到一些安全保障系统范例, 例如:辽宁证券网上交易系统[1]、基于PKI技术的网上证券信息系统[2]、兴安证券网上交易系统[3]等等。然而, 我们综合比较这些解决方案后发现:这些系统或多或少都存在一些不足。这些系统或者只针对网络交易安全的某一个方面使用了某一种核心技术;或者虽然涉及到了多个保护环节, 但防护力度较为分散;或者系统的扩展性不强, 难以根据实际需要进行更新和改进。
证券交易行业需要的是能够保障交易安全并且具有商业价值的完善系统。针对这一需求, 我们开发了这套“基于面向服务架构 (SOA) 的网络证券交易安全系统”。本系统主要有以下四大优势:在技术上, 我们使用了多种先进成果相辅相成的方法, 多角度全方位地保障网络交易的各个方面;在功能上, 根据保护内容的不同, 将系统分为客户防御、身份认证和日志审计三个主要部分, 层次清晰合理;在性能指标上, 我们的系统完全能够满足商业环境中大量数据并发情况下的时效性和稳定性;在系统构架上, 我们根据面向服务构架 (SOA) 的要求, 设计出了一套各模块单元之间耦合度低、便于升级和维护的系统, 系统中的三个主要部分都可以作为独立的部件进行技术更新或移植到其他平台, 具有较强的实用价值和商业价值。
1 背景
1.1 网络证券交易的安全
网络证券交易作为一种“网络交易”形式, 它的安全问题与其他类型网络交易相比, 有许多相似性, 但也具有自身鲜明的特点。总体来说, 包括了以下几个基本的安全问题[4]:
1) 保证证券交易系统运行的安全, 即保证证券交易系统在信息处理和传输时的安全。这一问题主要侧重于保证系统正常稳定地运行, 避免因为系统的崩溃或损坏而对系统内存贮、处理和传输的信息造成破坏和损失, 同时要避免因故障而引起的信息泄露。
2) 保证证券交易信息系统的安全。这包括用户身份认证和授权, 用户存取权限的控制, 交易行为的可追溯和抗抵抗, 资金的异常阻止, 二次鉴别, 计算机病毒防治和数据传输加密等等。
3) 保证证券交易内容的安全。这主要侧重于保证交易信息的保密性、真实性和完整性。避免攻击者利用系统的安全漏洞进行窃听、冒充、诈骗等有损于合法用户的行为, 本质上是保护用户的利益和隐私。
1.2 保障网络交易安全的对策
针对网络证券交易安全问题, 一个能够保障安全并投入商业使用的系统, 应具有保密性、正确性和完整性、身份的确定性、不可抵赖性四个基本特点。为满足这些特点, 目前系统一般采取如下几种对策[5]:
1) 安装防火墙, 防止黑客入侵及攻击;
2) 安装防病毒软件;
3) 采用身份认证和数字签名支持第三方CA认证体系, 确保网上委托身份识别的安全性;
4) 使用128位强加密算法和数字签名, 确保委托数据的安全, 防止数据在传输过程中被截获修改;
5) 网上委托站点和券商交易系统相互独立, 有明确的接口, 访问券商交易系统的接口转换程序由券商编制, 源代码由券商保管;
6) 在Internet与证券公司网络的网关上采用并口隔离技术。并口通信使用的是专用协议, 而不是通用的TCP/IP协议, 其优越性在于既能完成正常数据交换功能, 又能非常有效地隔离一切来自Internet上的对证券公司网络的攻击;
7) 所有与委托有关的程序全部在券商的营业场所内运行, 电信局方面只运行与行情有关的程序。
8) 交易数据处理的可监控和防抵赖。
9) 行情主站和委托主站自动互为备份, 确保在系统和线路出现故障或大行情突然来临时, 不会因并发量过大而导致通道堵塞, 不影响客户的交易。
在重点分析了以上几种对策的安全性、可行性和适用性之后, 我们决定同时采用上述1、2、3、4、8方案。这些方法不仅代表了计算机网络安全方面的先进技术, 同时也适于系统的实现和投入商用;为了能使整体功能进一步强化, 除上述方法之外, 我们还增加了反逆向分析技术、拥有自主产权的SSL加密技术、基于数据挖掘的监控预警等多种技术手段, 将系统的功能划分为“防盗取口令”、“防非法登录”、“预警与日志审计”三个清晰的层面, 构建起可靠的“三重防护”模式;除此之外, 针对用户的习惯和操作环境特点, 在保障安全级别不降低的前提下, 我们将一些安全策略的选择权交给用户, 实现了系统的灵活性, 这也是我们的一大创新。
1.3 面向服务体系构架 (SOA)
面向服务的体系结构 (Service-Oriented Architecture, 缩写为SOA) 是一个组件模型, 它将应用程序的不同功能单元 (称为服务) 通过这些服务之间定义良好的接口和契约联系起来[6]。接口是采用中立的方式进行定义的, 它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。这种体系结构, 与传统的面向对象模型不同, 它的各个模块之间是松耦合的。松耦合保障了各个模块之间的相对独立性, 模块内部的修整对外不会造成使用的变化。
SOA具有平台无关、低耦合、可以按模块分别实施等特点, 比较适合部件功能划分清晰, 同时需要频繁更新的系统。对于我们所研究的证券交易安全系统来说, 根据商业使用的反馈进行系统版本的升级、部件的更新是很普遍的, 而且, 各个部件也都可以作为独立的标准化产品推向市场, 因此, 采用这种设计方式是非常合理的。
以下几个小节将详细地介绍我们开发的系统。其中第3小节从整体设计出发, 展示了系统的整体构架;第4小节将以系统的“身份认证”模块为例, 详细介绍了这一子平台的特点;第5节系统测试, 通过实验数据证明我们系统的可靠性;第6小节总结了这一系统的研究意义和经验, 希望我们的工作能够为后继的研究者们提供一些参考价值, 最后一部分是参考文献。
2 系统构架
根据所需防护部分的不同, 依照“子系统内部紧耦合, 外部松耦合”的设计原则, 我们将系统划分为:防盗取口令的客户端防御层, 防非法登录的身份认证层, 以及负责预警与日志审计的监控预警层这三个层次, 又根据具体的使用需要, 将各项防护技术进行进一步整合为五个子系统, 分别是客户端防护子系统、安全加密子系统、身份认证子系统、集中日志管理子系统和安全预警子系统。本系统开发遵循先进的SOA系统架构, 各子系统分别为独立的功能实体, 具备自我管理和恢复能力, 子系统间耦合度低。各子系统包含一组粗粒度、标准化、可重用的服务接口, 通过这组接口向外提供功能调用。同时各子系统包含精确定义的服务契约, 保证系统的通用性、可拓展性和联合协作性。在该架构下, 子系统功能被封装起来, 子系统间仅通过标准化接口进行通讯, 方便系统内部维护、系统间功能的调用, 以及系统的更新、升级和扩展。
从技术来讲, 客户端防御层包含防木马病毒解惑键盘消息技术、基于代码混淆的反跟踪技术、基于暴力破解模型的用户冻结技术、基于搜索引擎的“钓鱼”网站识别技术和SSL加密技术。身份认证层包含硬件信息绑定认证、CA数字证书认证、动态口令认证、通讯密码认证技术。监控预警层包含基于数据挖掘的入侵技术、上次登录IP时间回显技术、基于路由跟踪的用户IP定位技术和异常情况预警和反击。
从功能上来讲, 客户端防护子系统和安全加密子系统用来对客户终端以及数据传输的安全进行保护和监控, 集中日志管理子系统是对于服务端的管理和监控。身份认证子系统是对整个系统认证过程的加强和保护, 安全预警子系统起到对整个系统的预警和保护的作用。系统整体构架如图1所示。
这5个子系统分别侧重与网上交易安全的不同方面, 组合后涵盖了整个网上交易过程中的所有流程。在广度上, 本系统囊括了整个交易系统部署过程中的各个方面, 在深度上, 每个环节采用的技术都是领先技术或行业标准。其中“身份认证”是保证网上交易安全最为重要的环节, 同时, 也作为一个完整的子系统设计实例, 以下我们将重点对该子系统进行描述。
3 身份认证子系统
身份认证子系统用于判明和确定网上交易双方身份的真实性和合法性, 是保证交易安全性的重要环节, 也是网上交易盗买盗卖防范系统的中枢部分。身份认证包括用户向系统出示自己的身份证明 (通讯密码、动态口令、数字证书等) 和系统通过某种认证手段查核用户身份证明的过程, 用户只有通过了身份认证才能获得访问某些资源的权限。
3.1 常用系统身份认证方式
目前常用的系统身份认证方式有基于口令的认证、基于数字证书的认证、基于生物特征的认证和综合认证方式。
3.1.1 基于口令的认证
口令是用户和系统相互约定或者系统制定的一段代码。只要用户输入正确密码即得到身份认证。根据口令产生方式的不同可分为静态口令认证和动态口令认证。
1) 静态口令认证
静态口令[7]指在某一特定的时间段内没有变化, 可以反复多次使用的口令。用户进入系统时输入用户名密码, 系统将其与保存的用户信息进行比较, 从而判断用户身份的合法性。它的优点在于使用简单, 无需任何附加设备, 成本低, 速度快。但它同时包含许多安全隐患, 口令容易被窃取、截获和破解, 对于重放攻击也毫无抵抗力。
2) 动态口令认证
动态口令认证[8]是指每次进行身份认证和交易确认时输入的口令都是动态变化的, 且不重复。动态口令由一种称为动态令牌的专用硬件使用密码生成芯片运行专门的密码算法。根据当前时间或者使用次数产生, 且每个密码只能使用一次。
用户使用时只需要将动态令牌上显示的当前密码输入客户端计算机, 即可实现身份的确认。它具备抗截获攻击能力、抗实物解剖能力和抗穷举攻击能力, 避免了静态密码在传输和存储过程中可能出现的安全问题。
3.1.2 数字证书认证
数字证书[9]是一种能在网络上进行身份验证的电子文档;它由权威公正的第三方机构CA中心, 又称为证书授权 (Certificate Authority) 中心签发;它包含用于识别通讯各方身份的一系列数据。数字证书根据存放介质的不同, 分为软件证书 (存放于电脑本地浏览器) 和硬件证书 (存放于USB Key介质中) 。
用户经过证书存储介质向服务器提供用户证书, 服务器端由此解析并验证用户真实身份;而服务器向客户端返回服务器证书, 从而证明服务器的真实性。数字证书采用PKI (Public Key Infrastructure) 公开密钥基础架构技术。以数字证书为核心的加密技术可以对网络传输信息进行加密和加密、数字签名和签名认证, 从而确保网上传递信息的机密性和完整性。
目前存在数字证书的一种简化方式称为通讯密码。它对静态密码采用PKI公钥体系技术和SSL协议进行加密和传输。
3.1.3 生物特征认证
生理和行为特征统称为生物特征, 常见的生物特征有指纹、掌纹和DNA图像等。生物特征识别技术具有不易遗忘、防伪性能好、不易伪造或被盗、随身“携带”和随时随地可用等优点, 是最可靠的身份认证方式;但这种认证方式过度依赖硬件安全性, 推广起来成本较高。
3.1.4 综合认证方式
综合认证方式即双因素认证方式, 它将之前提到的两种或两种以上身份认证要素结合成为更安全的认证方式。常用的双因素认证技术有动态口令与静态口令相结合认证方式、静态口令与数字证书认证、静态口令与生物认证。双因素认证技术可以提高认证的可靠性[7]。
3.2 身份认证子系统设计
各个认证方式之间不仅安全级别不同, 在应用场合, 历史应用遗留等方面同样有很大的不同, 这些不同决定了每种认证平台都有存在的必要性。为了方便用户操作并且提高了管理人员的操作效率, 本系统对一些普遍使用的认证方式进行了有效整合。用户在进行网上交易时, 可根据实际情况选择不同认证方式。
综合考虑网络证券交易本身的特点、系统安全性、用户需求、运行成本和实现复杂度等因素, 本系统选择包含通讯密码、动态口令、数字证书等已有的先进认证技术, 同时创新性地引入了硬件绑定认证技术。硬件绑定的主要思想是将用户的电脑特征码或手机信息 (手机号码或手机硬件信息) 和用户账号绑定, 并且保存在网上交易委托认证库中;用户登录时只有通过了系统对硬件信息的验证才可以进入账户。这种方式安全性比较高, 但可能使用不便, 特别是对一些可能会使用多台电脑的用户。
除了多种认证方式的创新与融合, 本子系统还引入了信息回显, 入侵检测等新的认证保护机制, 并且在信息传输时使用了在充分研究分析国内外先进技术的基础上自行研发的SSL加密技术, 进一步提高用户账户和认证信息传输的安全性。
网上交易客户登录时, 委托服务器将用户的登录信息 (包括所选择的认证方式) 转发给统一安全认证服务器, 随后服务器向认证数据库发送请求, 查询并检测用户登录信息。若用户采用通讯密码认证方式, 则返回其加密的私钥数据;若用户采用了第三方认证方式 (如动态口令认证) , 则返回该账户绑定的第三方认证系统识别码 (如动态口令卡的硬件序列号) , 认证网关程序再向第三方认证系统校验用户的登录信息。
依照SOA系统架构, 身份认证子系统将具体系统实现部分封装起来, 通过标准化接口实现子系统间的功能调用, 从而降低了与其他子系统的耦合度, 方便子系统的维护和管理, 同时提高系统的可拓展性。子系统定义了一系列标准化的接口协议, 通讯消息采用STEP协议长连接格式。这些接口包括连接认证、安全密码认证及修改、自动开户、连接测试、各认证方式接口、IP回显信息查询等。
4 系统测试
我们对实现后的系统进行了测试。在目前的实验结果中, 系统单台设备平均处理能力不低于500笔/秒;单台设备峰值处理能力不低于1500笔/秒;周边应用客户端认证响应延时<200ms;系统可用性不低于99%。总体来说, 取得了较好的实验效果, 在安全层面上能够达到行业标准。
5 结论
网上证券交易的安全性一直是人们关注的话题, 也是金融行业不可或缺的一部分。我们针对金融行业交易安全开发的这一套系统, 涵盖了网络交易过程中最容易发生问题的各个方面, 采用了多种先进反入侵技术集成、多种认证方式集成、多种系统保护机制集成的方法, 功能完善;建立了合理的系统构架, 模块之间耦合度低, 安全性强, 便于维护和移植;投入测试之后结果良好, 可投入商业使用。
科技发展日新月异, 诚然, 我们的系统也存在许多可以进步的地方。我们仍不断追求着更安全、用户使用更便捷、处理速度更快的网络证券交易安全系统。在今后的研究工作中, 我们还将不断研究加密、认证、日志审计的核心技术, 随时进行系统的更新和完善。同时, 也正如其他同行提出的, “证券业网上交易系统安全体系的建立, 不是某个环节或者单一层面的问题, 而是从设施、技术到管理的, 整个经营运作体系的方案”, 我们所做的工作, 只是在保障网络金融交易安全道路上的一小步, 希望这项工作能够为行业的发展和稳定提供一些帮助, 也为其他研究者提供借鉴参考。
参考文献
[1]王淑清, 齐景嘉.兴安证券网上交易安全方案[J].金融理论与教学, 2006 (1) .
[2]杨童.基于PKI技术的网上证券信息系统的安全解决方案[J].电脑知识与技术, 2009 (7) .
[3]王淑清, 齐景嘉.兴安证券网上交易安全方案[J].金融理论与数学, 2006 (1) .
[4]戴宗坤, 罗万伯, 唐三平, 等.信息系统安全[M].北京:金城出版社, 2002.
[5]姚前, 陈舜, 谢立.综合安全管理监控技术在网上证券交易中的应用[J].计算机应用研究, 2005, 22 (4) .
[6]毛新生.SOA原理.方法.实践[M].北京:电子工业出版社, 2007.
[7]尉永青, 刘培德.电子商务环境下主要的身份认证方式分析[J].商场现代化, 2005 (7) .
[8]张方田, 王开义, 刘忠强, 等.农资电子交易平台的身份认证研究与实现[J].农机化研究, 2010, 32 (6) .
面向服务架构SOA 第5篇
[关键词]面向服务；协同管理；业务逻辑层
[中图分类号]C36 [文献标识码]B [文章编号]1672-5158（2013）06-0259-01
1 引言
本论文引用面向服务架构（SOA，Service Oriented Architecture）的理念，将协同管理软件的业务逻辑层按照“高内聚，低耦合”的原则进行划分，形成17个相对独立的服务，每个服务处理一类具体的业务需求，这些服务协作起来在服务分析器的有效调控下，对用户请求进行有效及时的响应。从而提高软件部署的灵活性，响应效率，实现负载均衡。
2 面向服务的煤炭企业协同管理软件
2.1 服务的划分
煤炭企业协同管理软件将该企业的人、财、物等资源进行集中管理和统一调度，为领导者提供决策，其管理的范围比较广泛，实现的业务功能比较全面，经过各方面的综合考虑，某煤炭企业协同管理软件业务分为17个子服务，分别是OA办公子服务、人事管理子服务、财务管理子服务、资产管理子服务、审计管理子服务、纪委监察管理子服务、团组织管理子服务、党组织管理子服务、社保管理子服务、劳资管理子服务、安全管理子服务、车辆管理子服务、档案管理子服务、项目管理子服务、工会管理子服务以及企业文化管理子服务，具体如图2-1所示。
协同管理软件17个子服务内部内聚度高，服务与服务之间耦合度低。它们之间业务功能划分也相对比较明确，相对于煤炭企业来说，每个服务处理一类具体的业务，而每个业务也相对集中某一个或几个部门，这样有利于集中管理；另外这些子服务之间的粒度大小也相当，在系统运行过程中，用户的访问均衡的分散到这17个子服务中，实现了任务分摊，负载均衡。
2.2 服务的工作机理
协同管理软件的17个子服务要协同起来工作，必须还有一个服务分析器，服务管理器负责接收用户的访问请求，判断由那个服务处理，进而调用该服务进行处理，并将处理结果反馈给用户。
面向服务的煤炭企业协同管理软件工作机理是这样的，用户通过浏览器发出访问请求，服务分析器接收访问请求，判断该访问请求属于17个子服务哪个处理的业务范围，进而调用对应的服务进行处理，对应服务响应接收到的用户请求，处理相关业务并且根据需要传输数据库处理命令给数据库，数据库执行对应的数据库语句并且将处理结果返回给对应的服务，服务对结果进行加工处理后反馈给服务分析器，服务分析器进一步反馈处理结果给浏览器，让用户进行结果的查看操作。如图2-2所示。
2.3 服务的部署
面向服务的煤炭企业协同管理软件最大的优势就在于部署灵活上，可以根据软件的运行情况随时调整部署模式。
首先将服务分析器和服务分开部署在不同的服务器上，服务分析器就专心的进行任务的分析和转发，而17个服务到底部署在几台计算机上合适，其实是相对灵活方便的。
（1）17个子服务部署在一台服务器上。
协同管理软件在煤炭企业刚投产运行时候，访问的用户量并不是很多，有些部门因为硬件或者网络等原因退后使用，这是如果把17个子服务分开部署，则对计算机资源无疑是个浪费，因此可以将17个子服务部署在同一台服务器上，但是工作机理是不变的。这样其实和没有进行服务划分的软件系统一样，反而比没有划分的复杂，但是随着后面用户访问数的增多，则划分服务的协同管理软件优势则显示出来。
（2）17个子服务部署在几台服务器上。
煤炭企业协同管理软件的普及使用使得访问其的用户越来越多，此时有几个服务需要处理的业务则不断增长，如人事管理、财务管理、资产管理等，而有些服务处理的业务仍比较少，如审计、纪委监察等，此时对于业务访问请求多的服务应该分开部署在不同的服务器上，而业务处理少的服务则几个合并部署在一台服务器上。
（3）17个子服务部署在17台服务器上。
对于一个大型煤炭企业，协同管理软件运行几年后几乎企业所有员工都需要使用该软件，此时软件的每一个服务都有不少的用户访问请求，对于前面几种部署的那几个服务也需要分开部署，从而实现17个子服务分别部署在17个服务器上，这样每个服务器只管属于自己服务业务范围内的访问，从而实现17类业务的并行工作。
依据煤炭企业协同管理软件的访问情况来动态调整服务的部署方式，使得在不浪费资源的前提下实现任务分摊和负载均衡，防止访问瓶颈，提高响应效率。
3 结论
大型煤炭企业协同管理软件采用面向服务的模式进行架构，将业务逻辑层分成17个相对独立的子服务，这些服务在服务分析器的有效管理下协同工作，分摊任务，对外提供统一接口，来及时高效的响应用户的访问请求。本文虽然研究的是煤炭企业的协同管理软件，但是对其它大型企业分布式环境下相关软件的架构和开发都有一定的借鉴价值。
参考文献
[1]赵艳妮；分布式工时软件平台架构关键技术研究[D]；陕西师范大学；2008
[2]杜攀，徐进，SOA体系下细粒度组件服务整合的探士[J]计算机应用，2006（03）
[5]高俊，沈才梁，陈暄，一种面向服务体系结构的服务组合方案求解方法[J]，计算机应用研究，2011（11）
基于SOA的服务契约架构设计 第6篇
服务契约是对服务接口的抽象, 是服务元数据描述文档的组合。对于较早的自行实现的SOA, 服务契约只是简单地在Word 和Excel表中定义, 而在基于CORBA、Web、语义Web实施的SOA中, 出现了IDL、WSDL、SCDL、OWL-S服务契约, 针对服务描述信息的丰富程度不同, 目前的服务契约可分为两大类。
2基于语义、语法、服务质量的服务契约WOQ
本文依据“问题抽象”和“分而治之”的方法论, 提出了解决服务契约问题的模型。将服务契约内容进行分离, 即分为语法部分、语义部分、服务质量描述部分、XSD Schema定义部分、策略部分和法律文档部分。然后对同一服务的6种信息分开描述, 最后再在契约文件中将6者结合在一起。这样, 通过对契约的内容进行抽象处理, 得到一个直观简单的WOQ服务契约, 如图1所示。
在WOQ服务契约中仍采用主辅结构框架, 主体部分由WSDL、语义Web描述和服务质量描述部分组成, 辅助部分与WSDL服务契约相同, 这里就不再叙述, 下面重点讨论WOQ服务契约的主体部分结构。
根据WOQ服务契约, 主体部分应包括3大模块:描述服务的语法信息模块、描述服务的语义信息模块和服务质量信息描述模块, 下面先定义每个模块所对应的文件及功能。
2.1服务语法信息描述模块 (即WSDL文件)
该模块的主要作用是描述服务的语法信息, 主要有服务的物理信息 (即与服务调用有关的具体细节) , 例如网络协议、信息格式、参数类型和结构等。为了保持与当前标准的兼容, 没有扩展或者修改WSDL规范, 而是将其作为服务描述模型的基础。
2.2服务的语义信息描述模块 (即OWL-S语义信息模块)
该模块由三部分组成, 分别是Service Profile文件、Service Process文件和Service Grounding文件, OWL-S模块的作用主要是对服务的语义信息进行描述。
(1) Service Profile文件。
Service Profile提供了服务的基本描述信息和有关的性能属性, 包括服务提供者的有关信息, 服务本身的分类、名称等信息。
(2) Service Process文件。
Service Process文件主要用于描述服务中各个子操作的信息。Service Process主要描述操作的基本信息和语义信息, 而Service Profile则主要描述总体服务和其中具体参数的基本信息和语义信息, 两者结合起来就完整地描述了服务的操作和参数信息。
(3) Service Grounding文件。
Service Grounding文件主要描述了用于访问具体服务的具体细节, 包括服务的WSDL文件地址、具体的调用操作和输入输出参数类型格式等信息。Grounding可以看作是抽象描述到具体服务的映射过程, 起着在WSDL和Service Process描述的桥梁作用。
2.3服务质量信息描述模块 (即QoS 模块)
本文设计的QoS模块主要包含QoSProfile、QoSAttribute、Metric和Value4个类。下面分别对这4个类进行详细说明。
(1) QoSProfile。
QoSProfile是QoS模块中一个最顶层的概念。通过它的hasQoSAtrribute属性可以定义一个服务所有的QoS参数 (QoSAttribute) , 如图2所示:
(2) QoSAttribute。
QoSAttribute是用来描述所有QoS参数的超类, 它有3个子类CommonQoSAttribute、DomainQoSAttribute和Special QoSAttribute, 分别通过hasQoSAtrribute的3个子属性hasCommonQoSAttribute、hasDomainQoSAttribute、hasSpecialQoSAttribute与QoSProfile相关联, 如图3所示。其中CommonQoSAttribute对应所有服务都需要具备的QoS参数, 比如价格、时延、可靠性和声誉等。DomainQoSAttribute针对的是领域相关的QoS参数, 比如在书籍领域中, 书的包装是“精装”还是“简装”等。SpecialQoSAttribute可以用来描述某个服务特定的QoS参数。这种分类方法可以使服务提供者在发布QoS信息的时候, 以及对服务请求者提出QoS需求的时候, 有据可依, 有迹可循。
在QoSAttribute超类中, 可以表示QoS参数的度量方法、单调性和在整个QoSProfile中所占的权重等。而在复合QoS参数中, QoSAttribute还负责描述该QoS参数与其他QoS参数的聚合关系, 如图3所示。
(3) Metric。
Metric用来描述QoS参数的度量方式。度量方式分为两类, 一种是单值度量方式 (SinglValueMetric) , 另一种是区间度量方式 (IntervalMetric) 。如图4所示:
单值度量方式可以描述一个确切的单值, 还可以描述一个模糊的单值。这个能力是由isExact属性来提供的。当它的布尔属性为true时, SingValueMetric描述的是精确的单值, 如200毫秒。当isExact 为false时, SinglValueMetric描述的是一个模糊的单值, 如200毫秒左右。区间值度量方式是用来描述一个区间的。hasUpperValue和hasLowerValue 两个属性分别用来定义区间的上下界。如果仅有hasLowerValue属性, 可以认为IntervalMetric表示的是一个上届是无穷大的区间。同样如果仅有hasUpperValue属性, 就认为IntervalMetric表示的是一个下界是无穷小的区间。
(4) Value。
Value用来表示QoS参数的度量值。主要类型有数值型 (NumericalValue) 和语言 (linguisticValue) 两种。如图5所示:
与传统的QoS参数表示方式一样, 数值型用来描述用整数和实数表示的QoS参数, 其中hasValue属性用来描述参数的数值, hasUnit用来描述该值的单位, 语言型用来描述那些无法用数据来衡量的QoS参数, 这些大都是程度副词, 像快、很快、慢和很慢等。
3WOQ服务契约的优点
(1) 良好的开放性和可扩充性:
主要表现在基于本体和可扩充服务质量模型。
(2) 全方位描述服务:
遵循通用服务契约描述模型, 突出服务行为约束、条件和服务质量模型, 避免潜在的服务组合不相容, 这些服务应具备的约束和条件为服务组合提供了部分共享上下文, 可以有效地指导和监督服务组合。
WOQ服务契约不是将服务视为简单的功能“黑盒”, 而是通过清晰暴露服务的行为前提和后果, 避免服务请求者发现和选择与自身存在行为前提、后果相互制约的服务, 从而服务发生服务组合不相容的情况。
4结束语
本文提出一种全新的服务契约WOQ, 全方位支持服务的功能和行为的约束及服务质量描述, 避免潜在的服务组合不相容, 为实现服务发现、组合等操作的智能化创造了良好的条件。
摘要：基于契约先行的开发方式, 设计并实现一种轻量级的组合服务契约, 将服务契约设计从语法层提高到语义层, 从而丰富了服务契约架构设计的内容, 有助于利用SOA进行企业信息高效集成的顺利实施。
关键词：契约先行,面向服务的架构,Web服务,描述语言
参考文献
[1]叶宇风.基于SOA的企业应用集成研究[J].微电子学与计算机, 2006 (6) .
[2]毛新生.SOA原理、方法和实践[M].北京:电子工业出版社, 2007.
初探面向服务的SOA数字化校园 第7篇
关键词：SOA组件,Web技术,高校数字化
一、引言
随着高校信息化进程的不断深入,各种信息系统渗透到各高校诸多环节。由于软件专业化及高校的特殊性,所有系统很难由同一软件商供应,而高校校园的集中化管理却需要跨越不同系统的业务流程,实现数据交互与共享。如何将来自不同厂商、各具特色的专业系统进行有效的应用整合,如何运用SOA构建数字化校园成为高校信息部门的重要任务。
二、SOA概述
SOA观念不是新的,CO RBA和DCOM就很类似,但是,这些过去的面向服务架构都受到一些难题的困扰:首先,他们是紧密耦合的,这就意味着分布计算连接的两端都必须遵循同样API的约束。例如,如果一个COM对象的代码有了更改,那么访问该对象的代码也必须做相应更改。其二,这些面向服务架构受到厂商的约束。Microsoft控制DCOM自不必说,CORBA也只是一个伪装的标准化努力,事实上,实现一个CORBA架构,经常都是在某个厂商对规范的实现上进行工作[1]。
作为面向服务的体系架构,是一种功能组件化的设计模型。它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它屏蔽了不同平台、编程语言、操作系统和硬件架构之间的差异,实现了应用程序的简单集成。这意味着+系统的灵活性得到了前所未有的提升,同时、使应用程序的重复利用成为可能,开发成本得到了降低。SOA架构的核心组件包括服务提供者、服务使用者和一个中立的服务总线机构,集成系统的所有业务功能都以服务形式在总线中注册,以便使用者能正确调用,也便于管理人员能对其统一控制与协调,避免在系统集成中产生点对点式的复杂网络交互[2]。
三、Web Service技术
Web Service是一种基于服务组件的开放的软件平台,是面向服务的Internet应用,通过对Web Service的构建,人们期望得到一个可编程的Internet。Web Service将软件模块看成一种Internet Intranet上的服务单元,借助XM L和广泛应用的Web协议,实现分布式的计算和异构平台的信息集成。[3]
基于Web服务的SOA采用基于XML的W SDL(Web Services Description Language)来定义和描述服务,用于描述服务请求者所要求绑定到服务提供者的细节以及服务本身的属性、功能、参数等。服务描述的重点在于与下面几部分交互所用的操作:服务、调用操作的消息、构造这种消息的细节。W SDL不包括服务实现的任何技术细节。服务请求者不知道也不关心服务究竟是由Java代码,C#,COBOL,还是由某种其他的程序设计语言编写的。他可以描述使用HTTP的SOAP调用。由于他的扩展机制,他也可以定义其他类型的交互,比如通过JMS提交的XML内容、直接方法调用、由管理遗留代码的适配器处理的调用(CI-CS)等。W SDL的通用定义允许开发工具创建各种类型的交互的标准接口,同时隐藏他是如何由应用程序代码调用服务的细节。
四、目前高校信息系统的现状
在目前校园网络的建设中,存在如下明显的问题[4,5]:(1)字化校园的构架结构五花八门,缺乏统一性指导(2)各部门信息系统成为信息孤岛,互不相通,影响了网络功能的发挥:(3)信息系统和信息的匮乏,与硬件投资不匹配。高等学校数字化校园建设与教育信息化、校园网络建设等密切相关。在教育信息化发展历程中,已从早期的CAI到近年轰轰烈烈教育信息化,现在正在跨入一个崭新的阶段信息化的教育阶段:而网络技术的应用也经历了从接入为王到内容为王再到应用为王的跨越[6,7]。笔者正是根据现阶段高等学校实际需求,立足于信息化教育时代要求,突出高等学校对信息技术的全面深入应用,帮助高等学校从观念、技能和习惯上迅速实现教学与信息技术的融合,实现信息化教育的跨越。
五、应用SOA实现校园的数字化系统
数字化校园由信息基础设施、应用支撑系统、信息资源系统几部分组成。数字校园的信息基础设施包括:网络基础、网络基本服务。在园区网环境下建设的校园宽带网络是数字校园的信息基础设施,没有网络,就不可能形成数字的空间。网络基本通信服务,包括电子邮件、文件传输、信息发布、身份论证、目录服务等,是网络应用服务的基础。数字校园的应用支撑系统包括:应用环境系统、应用软件系统、应用活动系统。数字校园的信息服务系统包括:建立数字化的信息资源体系、建立信息服务系统,成为校园内外用户的主要应用界面,为用户提供各种服务,如信息查询、信息流通、后勤服务、电子邮件等。首先对主要系统(教学系统、办公系统、学生管理系统)进行了集成与整合,其中教学系统全面管理我院教学管理工作。教学管理以班级管理为核心,在传统基础上结合数字化需求,将教学管理全过程信息进行数字化[8]。
六、结语
数字化校园从理论研究到实践开发,有一段逐步成熟的过程,体现在实际建设中,就应遵循循序渐进,逐步提高的大原则,在建设中探讨,在探索中前进。建设过程中应该遵从如下要求:
数字化校园的建设要与学校教学改革、科研发展、学科建设等各个方面的工作结合起来,把学校各项工作的数字化纳入全校数字化建设的规划中。
要实现高效、有序、无障碍的应用集成,必须制定数据的标准格式。比如在提供Web Services时,尽量使用XML Schema中支持的类型,否则在信息交换时会出现序列化和反序列化异常。系统集成的底层结构、软件、硬件以及异构网络的特殊需求都必须得到集成,可采用平台集成工具(如VM虚拟机技术),以保证各系统能快速安全的转换。
(3)应用集成不宜求快求全,应该一步步实现,稳扎稳打。作为集成平台的服务总线与标准的建立也不是一日之功,总线或平台本身也可以分层实现,并尽量采用松耦合的连接机制,便于日后的扩展与调整。加强对数字化校园的管理研究和认识,在各个应用项目实践的基础上,总结新模式下的规律和特点,在探索、总结和实践中不断提高,把数字化校园的建设作为一个长期的发展目标,并不断进行完善。注重实施的效果。
参考文献
[1]吴家菊,刘刚,席传裕基于W eb服务的面向服务(SOA)架构研究[J]现代电子技术2005,(14).
[2]陈巍,刘旻基于面向服务架构整合医院信息系统的研究[J]临床医学工程2010,(5).
[3]李安渝1Web Service技术与实现[M]北京:国防工业出版社,2003.
[4]梁正和,张新华,张国宝等基于同一架构的集成的数字化校园设计[J]通信学报,2006,27(11A):181～183.
[5]Kurose J F,Ross K W Computer Networking:A Top Down A pproach Featuring the Internet[M]Beijing:Higher Education Press,2005.
[6]赵国生,王惠强,李明军等可生存性网络的形式化建模与分析方法[J]通信学报,2006,27(11A):48～52.
[7]邓世昆,杨红伟,杨勇等昆明新区呈贡大学教育城域网规划设计[J]通信学报,2006,27(11A):295～298.
面向服务架构SOA 第8篇
关键词：医院信息系统,医疗服务管理平台,SOA架构,服务注册
0 前言
随着医疗信息化的发展,在医疗卫生服务过程中,大家迫切希望建立适用的共享卫生信息系统,使医疗服务人员能及时获取必要的信息,提升医疗服务质量。医院信息系统是分阶段由不同厂商建设的,并采用不同技术实现,普遍存在“信息孤岛”现象。杨宏桥等[1]通过Web Service和XML技术建立了一种基于SOA的医疗信息系统集成基础架构,实现了全局一致的医疗信息共享模式。辛小霞等[2]提出SOA区域医疗信息共享平台框架,说明了框架的可用性及有效性。孙万驹等[3]研究了Web Service技术框架构建SOA应用软件,优化临床路径。张丽等[4]采用Web Service技术实现SOA架构,实现了远程挂号、远程开单、远程诊断结果获取等功能。
目前大多采用Web Service技术实现SOA架构,ESB即企业服务总线,它弥补了传统的基于Web Service集成技术点对点连接的缺陷[5]。本文提出的SOA医疗服务平台是基于JBOSS ESB开源产品,实现了SOAP(简单对象访问协议)、JMS(Java消息服务)、HTTP(超文本传输协议)三种协议服务的注册、审核、管理。服务使用申请及审核、调度、异常监听等动能,即提供统一的服务访问接口。
1 SOA技术介绍
SOA(Service Oriented Architecture,面向服务的架构)是一个组件模型,它将应用程序的不同功能单元服务通过定义服务间良好的接口和协议联系起来[6]。其接口是采用中立的形式进行定义的,独立于实现服务的软硬件平台,这样使得系统中的服务可以以一种统一、通用的方式进行交互。SOA作为一个技术架构,决定了不依赖某个特定的技术和平台环境来实现。我国SOA应用目前主要是帮助人们解决“信息孤岛”,以系统集成的途径整合已有系统实现信息共享[7,8]。
ESB(企业服务总线)从SOA发展而来,是传统中间件技术与XML、Web服务等技术结合的产物。ESB是在SOA架构中实现服务间智能化集成与管理的基础架构。
JBOSS ESB是JBOSS推出的ESB的实现, 也是JBOSS的SOA产品的基础,JBOSS ESB是一个基于消息的中间件,且是面向服务的。服务是指具有实现业务逻辑的服务,也可以是一个实现路由,或者数据转化的服务。
2 基于SOA的医院服务管理平台设计
基于SOA的医院服务管理平台,可统一规划管理服务、建立SOA资源库,进而整合医院业务系统服务,最终形成医院信息服务库,供各信息系统使用。通过服务的重用,提高系统资源的利用率。基于SOA的医院服务管理平台框架设计,见图1。
SOA服务平台包括服务注册中心、ESB服务总线、服务控制器、服务调度器、异常监听器、服务访问接口。其中ESB服务总线、服务调度器、服务控制器、异常监听器基于JBOSS ESB改造,而SOA服务平台服务注册、服务访问是基于Web和ESB服务总线,以接口的方式进行开发的。
2.1 服务注册中心
服务注册中心用来存储管理服务平台下的所有服务及服务描述。服务注册中心提供服务分类、服务注册、服务存储、服务发布、服务开启、服务停止、服务检索等功能。服务注册中心是基于Javaweb与Tomcat开发部署的Web项目,支持SOAP、JMS、HTML三种协议的注册,这三种协议是最常用的协议服务,能满足医院服务平台实现临床信息系统数据共享与交互的目的。Web Sevice接口可发布为SOAP服务,如医院信息系统(HIS)提供给其他系统的基本信息类(如医院信息、患者信息、科室信息等)接口,不用针对每个系统做一个接口。消息类服务可发布为JMS服务,如检验科向临床科室发送危机值、CT室向临床发送患者检查预约消息等。Web页面可发布为HTTP服务,HTTP服务真实URL是不可见的,如Web病历查询服务。
SOA服务注册中心包括普通用户、管理员、审核员三类角色。① 普通用户:具有查询服务、注册服务、修改服务、升级服务、注销服务、查看发布服务、订阅JMS消息、取消订阅、查询订阅、修改订阅的权限;② 审核员:具有查询服务、审核服务、审核订阅权限;③ 管理员:具有服务管理权限,服务管理包括查询服务、发布服务、取消发布,启动服务、停止服务等。
2.1.1 服务注册
服务注册包括服务编号、服务分类、服务名、服务版本、服务提供商、服务描述等基本信息,及服务的元数据信息(如访问地址、配置文件等),服务注册成功后,服务数据存储于数据库中。
2.1.2 服务审核
审核员对注册的服务进行审核,包括通过和不通过审核,并填写审核意见。
2.1.3 服务发布
审核通过后由管理员发布,服务发布时系统将存储于数据库的服务元数据取出并生成ESB服务发布到JBOSS ESB服务器中。ESB服务以名称为服务编号.esb的文件夹存在于JBOSS ESB服务器中。取消发布,将ESB服务从JBOSS ESB服务器中移除。
2.1.4 服务启动
服务发布成功后,才能启动服务;启动状态的服务才可以被使用。
2.1.5 服务检索
服务使用者可登录SOA注册中心,查询发布的有效服务,可订阅需要的服务,订阅通过审核后,可查询到服务编号,及调用服务所需参数。
2.2 ESB服务总线
ESB服务总线主要包含转换器、消息路由器、消息过滤器、连接器。
ESB服务总线的主要功能:客户端通过服务调用接口与ESB管道连接;监听器通过监听管道获取客户端消息、消息过滤、消息转换、消息路由,交由服务端消息处理;获取服务端返回消息,将消息转换并通过管道返回给客户端。
ESB功能的实现由SOA服务实例(或者叫SOA服务)来完成。一个SOA服务实例对应一个SOA服务配置文件。消息的接收、转发,消息格式的转换,消息的路由等功能都写在SOA服务配置文件里。SOA服务配置文件包括两部分:管道(Providers)和服务(Services),Providers包含各种类型的Provider,Provider节点下可配置多个管道,用于消息的传输。Services由多个Service组成,一个Service对应一个ESB服务,Service节点下包括Listeners和Actions。Listeners下监听器用于监听对应的管道,Actions下的Action用于处理相应接口请求,可以实现过滤器、转换器、路由器功能。
2.3 服务调度器
服务调度器是服务平台的核心,它负责接收服务访问接口的服务请求,由它来负责调用相应的服务,再将调用结果返回给服务访问接口。服务调度器的功能包括接收服务请求、查询服务注册中心、动态路由服务请求消息、传输服务处理结果。服务调度器是基于JBOSS ESB开发的服务项目,服务调度器支持HTTP协议和SOAP协议两种方式调用SOA服务。服务调度器功能示意图,见图2。
2.4 服务控制器
服务控制器是基于Javaweb与JBOSS开发的Web项目。服务控制器由Web Service技术实现,对外不可见。它实现服务的实际发布(发布服务时配置文件修改、统一分配端口),以及取消发布、启动、停止等,并提供接口供服务注册中心调用。所有操作在服务注册中心的服务管理中完成。
Web Service接口参数为:操作类型、SOA服务唯一编号。其中操作类型包括:发布服务、取消发布、启动服务、停止服务。返回参数为XML格式字符串(0 为返回正常;1 为返回错误;2 为操作类型错误;3 为服务ID为空;9 为服务接口异常)。
2.5 异常监听
异常监听是在服务调度器请求外部服务时,实时监听外部服务的响应情况,当外部服务请求出现网络不通、请求超时等异常时,监听器会捕捉到异常,并进行异常处理,之后再由服务调度器将异常情况组织成标准处理信息返回给请求客户端。异常监听器逻辑流程,见图3。
异常监听器在服务发生异常时,对异常信息进行记录、处理,以便后续对服务的改进、完善。
2.6 服务访问接口
服务访问接口负责接收服务请求者的请求,并将其转发到服务调度器,再接收服务返回结果,并将结果返回给服务调用者。服务访问接口为SOA服务平台对外提供的统一访问接口,支持两种不同的访问协议(HTTP、SOAP),满足不同场景的使用。
SOAP统一访问接口参数:服务编号为Soa Id、方法名为Method、参数键值对象为Params,均为字符串类型。
HTTP统一访问接口:http://localhost: 端口号/ 服务编号/http/soa,当有参数传递时,在服务访问url地址后添加“?参数名1= 参数值1”当有多个参数时,采用“&”连接,直接用于浏览器。
3 总结
SOA服务平台屏蔽了不同技术不同协议系统之间的数据共享与交互问题,提供统一的服务访问接口,使得临床信息系统能够采用相同的方式访问已启动的服务;提供异常监听器,保障服务使用过程中出现异常后,能够正确提示调用系统,并提醒管理员解决问题;提供ESB服务总线、服务控制器、服务调度器保障服务的调用、响应及异常监听等整个SOA服务平台的正确运转。依托服务的松耦合性和重用性,使医疗服务平台提高了医疗信息化建设的效率,简化了开发与维护工作,降低了开发与维护成本,提升了医院管理与服务水平。但是如何梳理医疗信息资源、编排流程以真实再现业务实际,需要进一步研究。
参考文献
[1]杨宏桥,吴飞,刘玉树.基于SOA的医院信息系统集成研究[J].医疗卫生装备,2008,29(1):38-40.
[2]辛小霞,吴汝明,邹赛德,等.一种基于SOA的区域医疗信息共享平台框架模型[J].中国数字医学,2010,5(11):33-35.
[3]孙万驹,何安勇,朱海燕.SOA技术在区域医疗机构信息共享中的应用研究[J].计算机应用与软件,2013,30(7):255-258.
[4]张丽,常建国,郭凌,等.基于SOA架构的医联体信息系统研究与实现[J].中国医疗设备,2014,29(2):59-61.
[5]林泳孳,黄晨晖.面向企业应用集成的ESB框架的研究[J].计算机应用,2010,30(6):1658-1660.
[6]叶云.基于SOA的应用系统的设计与实现[D].长沙:中南大学,2010.
[7]俞晓锋.基于SOA的企业信息系统集成架构研究[D].长春:吉林大学,2014.
面向服务架构SOA 第9篇
目前,福建省公共气象服务专业化、集约化支撑能力不足,信息采集、数据共享、产品加工和行业服务系统等较为分散。新常态下,不论是政府部门还是行业和公众,都对气象服务提出了更加个性、多样化的要求,急需构建省市县统一框架的一体化服务平台,加强精细化气象服务数值模式的应用,形成快速循环精细化预报服务产品加工制作能力。完善公共气象服务产库,实现服务单位与直属业务单位的信息共享以及省市县三级气象服务信息的共享,加强省级对下级单位的指导与技术支撑,同时也为气象部门在全国部署实施气象云工程、发展“智慧气象”奠定基础。
2 系统技术路线
平台使用JAVA EE技术开发,基于面向服务体系架构模式(Service-Oriented Architecture,SOA)搭建组件化业务平台[1,2]。基于SOA的先进技术架构和设计方法,结构化程度高,灵活性、兼容性、集成性、开放性,符合技术发展趋势,提供开放和标准的接口,可通过多种方法与第三方系统灵活对接,能实现不同应用系统的互联互通。采用统一架构,所有应用模块都基于统一的数据库,能够根据客户的要求进行不断的扩充。平台的展示层、业务逻辑层、持久层都能灵活地配置和扩展[3],当业务基础平台升级时,业务组件不需要随之升级[4]。
数据库系统采用ETL引擎(数据采集、数据清洗等),数据存储、数据解析、数据加工、预处理技术等与国省级气象数据无缝集成。数据服务以XML Web Services等松散耦合的、基于消息的技术,这些应用程序通常通过传递业务文档而不是传递对象进行通信,为区分保持逻辑与数据本身,本系统将构建两种不同的组件类型。(1)数据访问逻辑组件,数据访问逻辑组件从数据库中检索数据并把实体数据保存回数据库中,数据访问逻辑组件还包含实现数据相关操作所需的所有业务逻辑。(2)业务实体组件,数据用来表示产品等现实世界中的业务实体,并利用XML来表示这种业务实体。
3 数据中心建设
3.1 数据中心结构
1、数据存储技术
数据存储方式包括Oracle数据库,Redis内存数据库,自定义流文件格式等,Oracle采用RAC集群架构。
2、数据同步技术
数据同步技术用于同步Oracle库、Sql Server库等异构数据库中的数据,主要应用在数据采集子系统中;采用日志分析技术,对数据库重做日志进行分析,抽取数据变动记录,从而进行同步;采用触发器模式,在源数据库中建立触发器,当数据到达时,通过触发器立即进行数据同步;采用轮询模式,对源数据库进行定时轮询,当数据到达时,则开始进行数据同步。
3、消息协作技术
消息协作主要指在不同机器、不同系统模块间进行消息通信,互相协作,完成某项具体业务功能,主要通过消息总线技术实现;消息总线是一种通信技术,可在不同机器间互相传递消息、文本等。消息总线采用消息生产者与消息消费者的模式,消息生产者指消息的发送方,消息消费者指消息的接收方,例如当数据采集平台采集完某类数据时,可及时将信息发送至数据计算与分析平台进行处理,可降低系统的延迟时间;使用消息总线技术,各平台、各模块间将大大降低耦合度,使整个系统可做到插件式开发,并可在不同机器间进行任务协调。
3.2 数据采集处理
数据采集子平台负责对原始数据进行采集,并根据数据存储子平台定义的标准将数据进行转换、同化,而后将数据入库。
1、数据采集
数据采集组件负责收集各类原始数据,并将收集到的数据提交数据同化与入库组件进行同化与入库,其包括各类数据采集器,并依据业务情况进行不断地扩展。
2、数据同化与入库
数据同化与入库组件负责将数据采集组件收集到的数据按照数据存储子平台定义的规范与标准,进行转换、同化并入库。
数据同化与入库组件由数据采集组件调用,包括各类产品同化及入库适配器,并依据业务情况进行不断地扩展。
3、Cimiss云平台数据对接
Cimiss云平台提供了全国统一的气象专业数据服务,接入Cimiss数据对完善平台的数据类型具有重要作用。在本平台中,将Cimiss作为数据源进行采集并接入。
Cimiss主要包括以下数据类型:地面资料、高空资料、海洋资料、辐射资料、农气资料、数值模式、大气成分、历史代用、气象灾害、雷达资料、卫星资料、科考资料、服务产品。
4、数据处理
数据处理负责对采集后的数据进行分析、处理、算法实现、融合等,并产生最终可应用的产品数据,主要包括“数据解析系统”、“数据融合系统”、“数据预处理系统”等。
3.3 数据质量控制
数据质量控制指根据业务规范、一定规则、算法,对异常数据进行标记(质控码)、剔除、修正等操作,以提高数据的准确性与真实性。
数据质量控制规则或算法可根据实际业务不断的新增、扩充与修正,以提高质控的准确度。数据质量控制贯穿数据解析与分析、数据管理等过程,其中在数据解析过程中,系统将自动进行质控并记录,在数据管理过程中,将由人工进行手动质控并记录。
数据质量控制包括自动控制与手动控制,自动控制包含在数据采集与数据处理分析过程中,由系统根据事先配置好的规则自动完成,并进行相应的记录,手动控制主要指由人工进行干预与修正,并进行相应的记录。
4 系统总体设计
4.1 技术架构
系统的技术架构在标准规范体系和信息安全体系约束和保障体系支撑下,可分为运行支撑、数据中心、产品加工、省市县服务产品共享、应用支撑、行业业务应用、用户层和运维系统。
运行支撑层主要是构建平台的网络环境与运行环境,是支撑平台运行的基础。通过安全系统、网络系统、主机系统、存储系统等硬件设备的支撑,为平台提供安全保障、网络联通、服务运行、数据存储等方面的支持。
数据中心是系统的核心部件,主要是对气象数据和行业数据进行采集、分析、存储、管理等,并提供对外的数据通讯接口。
产品加工发布系统主要负责服务产品的加工、订正与发布,该系统所需要的模块包括加工组件、素材管理、模板管理、订正平台(主要针对特殊需求,例如森林火险等级)、人工干预机制以及发布管理。
省市县服务产品共享系统主要包括公众服务产品共享模块、专业服务产品共享模块、行业数据共享模块以及行业指标共享模块。
应用支撑层为各系统提供公共基础模块组件的支撑,包括消息中间件技术、分发引擎、日志组件、Web Office组件、身份认证模块以及GIS引擎等。
运维系统对整个系统的运行情况进行监控,包括数据源监控、数据维护、产品监控、用户活动监控、服务器状态监控、异常报警监控以及子系统运行监控。
4.2 系统业务流程
系统架构设计划分为数据中心、产品加工系统、省市县服务产品共享系统、监控报警系统和运维子系统。
数据中心负责将省信息中心数据、国家公服中心数据、CIMISS数据、CMACast数据、行业数据、指标数据等数据进行采集、存储、融合、解析。并建立行业基础数据存储、行业指标数据存储、服务产品数据存储、运维数据存储和地理数据存储。系统具备数据标准化输出机制以及数据备份机制。提供以Web Service技术为支撑的高性能数据接口。
服务产品加工发布系统的主要工作是气象服务产品的生产,提供包括气象服务产品的自动加工、人工订正、阀值设置等功能。加工系统生成的产品分为公众服务产品和专业服务产品,在日常业务中产品处于自动加工状态。当灾害性天气来临前,由系统报警提示或值班人员启动转换模式,将自动状态变为手动业务实施人工干预,对服务产品进行订正和分发。系统分发的渠道包括微博、微信、FTP、网络共享磁盘、电子邮箱Note邮箱、传真和短信。
服务产品共享系统采用B/S架构建立省市县级服务产品共享网,市县级服务人员通过FTP将各类产品,指标数据上传至省服务中心数据服务器,省级服务人员通过产品发布系统将数据上传至数据服务器,系统通过规范的产品分类管理将对公众服务产品、行业服务产品、行业数据以及行业指标进行省市、县级的信息共享,并通过用户身份验证方式实现产品使用级别与权限管理。
运维子系统作为系统运维人员的主要工作平台,是系统稳定运行的保障系统。提供包括数据源监控、服务器监控、产品监控、数据维护、异常报警维护、用户活动与反馈监控、用户与权限管理的运维支撑。
手机App、水电气象服务系统、保险气象服务系统等专业服务系统通过高性能Webservice数据接口获取相对应的数据支撑。Webservice设计面向需求,具有规范、集约、可扩展等特点,所有应用系统通过统一的Webservice接口调用。
4.3 系统网络拓扑
气象内网部署数据中心、产品加工发布系统、省市县服务产品共享系统、监控报警系统以及运维系统。国家气象中心、国家公共服务中心、省气象台、省信息中心等各种数据源部署在气象内网。气象内网与互联网间的数据通讯通过DMZ区隔离。外网应用的Web服务器以及数据通讯接口服务亦部署在DMZ区。DMZ区与气象内网之间通过网闸隔离,DMZ与互联网之间通过防火墙隔离。内网部署数据中心确保数据安全、保证数据存储能力、数据处理能力。互联网应用服务器和接口服务器部署于DMZ区,实现行业系统、网站与气象服务器对接,并按照服务中心外网统一规划统一部署。
DMZ中文名称为“隔离区”,也称“非军事化区”。它是为了解决安装防火墙后外部网络的访问用户不能访问内部网络服务器的问题,而设立的一个非安全系统与安全系统之间的缓冲区。该缓冲区位于内部网络和外部网络之间的小网络区域内。
5 结束语
基于SOA架构的气象服务一体化业务平台,基于统一的数据和产品访问接口,系统采用一套数据流程、一个数据环境、一套监控系统,实现了专业预报、服务一个平台。系统基于标准的数据格式及解析方式,通过指标设置、产品定制以及专家数据支持加工生成公众服务产品以及专业服务产品,为全省公共气象服务提供有力的技术支撑。
参考文献
[1]凌晓东.SOA综述[J].计算机应用与软件,2007(10):122-124.LING Xiao-dong.SOA review[J].Computer Application and Software.2007(10):122-124.
[2]徐效宁,邢雨桐.基于SOA的软件体系架构测评研究[J].软件平台与应用,2008,21(15):25-27.
[3]Hojaji F,Ayatollazadeh M R.AUT SOA governance:a new SOA governance framework based on COBIT[C]//3rd IEEE international conference on computer science and information technology,2010.
面向服务架构SOA 第10篇
1 SOA架构及Web技术
分布式聚类算法需要自我展示的平台, S O A架构就是面向该服务的首选;技术是必不可少的, Web技术做为配合才能发挥最佳效果。
1.1 SOA架构
SOA全称为Services-Oriented Architecture, 是一种面向服务的架构。服务是其基础, 它需要借助计算环境完成业务功能。其基本结构及操作为服务发布、发现和绑定。这点和Web服务有相通之处。
1.2 Web技术
Web全称为Web Services, 是一款能被能被URI所识别, 以XML形式来表现的应用软件。但是在功能方面得到了更新与改进, 其分布式计算模式面向服务, 成为SOA的一种实现技术。
1.3 二者之间的联系
Web Services与SOA相似, 本身虽然分为服务提供者、注册中心和请求者三大内容, 但在SOA架构中扮演了十分重要的角色。具体关系见图1:
2 SOA架构下的分布式聚类算法设计
在SOA架构下进行分布式聚类算法设计是改进后的DBDC, 主要分为局部和全局两种聚类算法:
2.1 局部聚类算法
局部聚类算法包括三方面内容, 即局部聚类、代表点选取及聚类结果的调整。采用的是D B S C A N算法进行本地数据聚类, 根据SDBDC算法改进的代表点进行算法选择, 对全局聚类模型接收后, 对本地数据按照一定规则进行调整标识。
2.2 全局聚类算法
与局部聚类相反, 全局聚类算法是将各局部站点传输来的局部模型, 采用DBSCAN算法整合为全局聚类的数据集后, 再传给各局部站点。局部与全局的关系如图2:
2.3 Web服务设计要求
介绍了分布式聚类的过程, 需要在SOA架构下进行操作设计, 以Web服务的形式来实现, 对Web的服务设计需要注重一下几点:
首先, Web服务要做到客户满意, 就需要注重自身的灵活性与敏捷性, 可以借助封装、信息隐藏及松散耦合等机制, 最小化的降低其服务之间的依赖性;其次是Web的服务粒度, 要在保证内聚、一致完整的前提下尽量放大;再次是命名上一定要浅显易懂, 设置为与上下文无关的无状态模式;还有就是在设计Web服务时, 要考虑到与SOA相一致, 能与现存的部分组成服务组合, 达到服务级别更高, 功能更全。
3 SOA架构下分布式聚类算法的Web服务实现
上节根据分布式聚类算法的工作流程对SOA架构下的分布式聚类算法的Web服务模型做了设计, 部署服务在Axis环境下分为即时和定制两种方式, 前者只要将Java类的源文件后缀改为.jws并复制到Axis的app目录下, 就会自动生成相应的WSDL文件。但定制部署就复杂多了, 需要通过wsdd, 即Web的服务部署描述符来完成。下面就介绍一下利用Axis的Admin Clent类来进行定制的Web服务操作的基本过程:
对DBDC-S类编译成class文件, 然后复制到Axis的/WER-INF/classes内, 然后对Web服务的局部及全局的wsdd文件deploy.wsdd分别编写, 随后利用Axis工具发布Web服务, 基本格式如下:>javaorg.apache.axis.client.Admin Client deploy.wsdd.
在浏览器中查阅的情况如图3:
4 Triana下的分布式聚类分析实验
对于S O A架构下分布式聚类算法的W e b服务实现, 下面将从Triana的实验过程进行验证其是否具有实用性。
为此, 我们准备了四台计算机, 其中三台为局部挖掘, 一台为全局挖掘, 然后将这四台计算机按照要求构建为一个分布式聚类分析的环境。这样各站点都发布了Web服务, 局部站点和全局中心都部署了Web服务, 通过这些Web服务的URL地址, Triana可以发现并调用这些分布式聚类算法的Web服务。实验结果证明, SOA架构下分布式聚类算法的Web服务是可以操作的。实验结果见表1:
5 结语
分布式聚类算法实用性强, 在S O A架构下实现W e b服务具有可操作性, 希望在今后的生活生产中得到普及。
摘要：信息化技术的发展, 数据挖掘技术为人们提取网络资料提供了便利。本文结合SOA架构及Web技术, 提出了基于SOA架构的分布式聚类算法的Web服务模型。通过对DBDC及SDBDC的优化整合及改进, 将SOA架构与之结合, 运用Triana测试表明, 该系统对于大规模数据进行聚类是有效的。
关键词：SOA,分布式聚类,Web,DBDC,SDBDC
参考文献
[1]杨恒宇.基于SOA的WEB应用系统的研究与实现[D].合肥工业大学, 2006年.
[2]丁兆青, 董传良.基于SOA的分布式应用集成研究[J].计算机工程, 2007年10期.
[3]朱晓娟, 李敬兆.基于SOA&Web Service的企业应用集成研究[J].电脑知识与技术 (学术交流) , 2007年01期.
由小编渡星河整理的文章面向服务架构SOA10篇(全文)分享结束了，希望给你学习生活工作带来帮助。