soa技术十篇

时间:2023-03-26 10:41:31

soa技术

soa技术篇1

协同技术的发展趋势

人员和人员之间在计算网络设备支持下的工作协同又可分为通讯协同和流程协同。通讯协同指的是传统上人们之间通过网络化电子化的通讯手段而进行的信息交流和共享,如电子邮件、即时消息、IP语音和视频实时交流、短信彩信的信息传播、日程计划、网上讨论区、项目管理和任务跟踪等。

上述相关通信手段及其软件技术实现,是主流上被大家所公认的协同技术和协同平台的主要表现形式。

自从计算机支持的协同工作的概念产生,通讯协同就是协同技术中一个非常重要而且迅猛发展的领域。现在,从通讯协同的角度,除了我们在设备和多媒体技术上的快速发展外,更朝向了通讯交互过程中的知识共享、传播的发向发展,发展了很多更便于人们沟通和交流的新技术模式。

例如,目前迅速发展的Web2.0技术,其中的Blog和Wiki就是对传统讨论区和信息方式的一个革新,大大加强了人们之间的协同沟通联系。对于企业内一个复杂业务的完成,仅仅提供协同上通信手段的支持是不足够的,它往往需要在业务流程的框架和控制下,协调不同阶段、不同角色的任务参与人,在时间和空间分配的角度下,展开协作。这是一种复杂的高级协同场景,也是现在越来越重要并已逐渐走向实用的工作流协同技术。

基于工作流的协同技术已经成为协同技术中最受关切的技术领域。不光是人与人的协同,系统间的协同、人与系统的协同,它们的核心的实现技术也是工作流,只不过在技术实现过程中还有不同的侧重点罢了。

即使是通信协同手段,现在也更多的要考虑它们在流程协作场景中的应用能力,是否具有流程协作参与能力已经成为通讯系统软件工具的一个越来越重要的参考指标。

基于流程的协同,是目前协同技术发展乃至软件多方面技术发展的关键领域。其中,采用Web服务技术,来实现来实现业务流程交互和集成,用SOA已成为基于流程协同实现的主流趋势。

流程协同技术基本分类

流程协同的核心技术是工作流协同技术,而且在流程协同中,也往往划分人和系统之间交互的不同场景。我们根据人员组织机构和系统间的关系,进行如下分类:系统工作流协同、业务应用系统间的流程集成、以文档交换为中心的工作流。

面向服务的组合型工作流,如以BPEL语言标准为流程定义和描述语言,SOA架构的工作流系统。这种工作流,可以很好的来跨越组织和系统的边界,例如实现企业间的供需链应用。

商业规则驱动的工作流,如以规则引擎的推理预算为驱动,控制流程的流向和执行。

人员工作流协同是用户界面的页面流,如用户在操作系统是的用户界面导航和界面生成。人员和人员间的工作流,如办公系统中的公文撰写和审批等。一个突出的特点就是,企业的组织机构、人员角色、权限控制等成为此类工作流的重要控制信息。

上述分类的流程协同技术,在历史上,根据所解决问题的种类,形成了许多各有侧重的工作流软件产品:有的侧重于文档内容管理中流程协作,如IBM内容管理; 有的侧重于人员任务申请和业务审批,如慧点科技的Galaxy Workflow; 有的侧重于系统级的业务流程集成,如微软的BizTalk。

这些产品,随着应用的逐渐深入,已经开始相互渗透,如以前擅长处理人员工作流的,现在也要处理系统级的数据交换和业务流程自动化,而以前擅长企业业务系统间流程协同的,现在也努力的提供人员组织机构开发支持,和人员表单的开发支持。

现在的趋势已经明显的表现出,这些流程协同技术将逐渐向统一的方向发展。面向SOA的流程集成描述语言BPEL2.0的已经反映了这一趋势。并且IBM,微软的新一代工作流系统已经达到或将要达到这一统一。因此,我们将看到,未来的流程协同技术,将统一在SOA的大架构下。

基于SOA的流程协同技术

SOA实质上就是一套松散耦合的服务。在必要的情况下,每一项服务都可以进行构造和替换,而相关的费用很低。松散耦合甚至还可以让架构适应一些改变,并不像传统的紧耦合架构表现得那么脆弱;在一个SOA中,您能够使用一种服务替换另一种服务,无需考虑下列技术:接口问题,它在Web服务和XML的通用标准中已经定义。

这就是通过互用性所体现出来的灵活性。灵活性表现为利用现有资产、遗留应用程序和数据库的能力,将他们扩展到SOA中而非进行替换,使其成为整个企业解决方案的组成部分。

最终结果就是具备快速高效发展的能力,换句话说,就是按照业务需求“有机地”进行适应。这就是真正的新特色。

SOA就是最终表现为对业务人员意义重大这一层面上的IT架构。今天的SOA服务能够完成映射为业务流程活动的各部分工作:例如,一个命名为“更新客户订单状态”的服务。这种服务与那些能够参与创造和使用这些服务定义新流程的业务分析人员密切相关,因而能够形成那种服务驱动型的企业。

因为Web服务已将其大部分技术作了摘要,所以几乎不再需要技术说明。公司和IT业能够将关注的重点转移到业务逻辑和通信上。他们最终共享“服务”的通用语言。SOA是让IT更加关注于业务流程而非底层IT基础结构,从而获得竞争优势的更高级别的应用程序开发架构。

SOA对需要使用信息技术解决关键业务问题的企业(包括希望减少冗余架构、创建跨系统的公共业务接口的企业;需要基于角色和工作流对用户提供个性化信息的业务的企业)很有价值。

采用SOA与否有何区别?从SOA的优点我们可以看到,通过SOA结合工作流协同技术,对于以前需要复杂专有架构的、难于实施和高成本的、无法适应变化的业务应用集成和自动化需求,可以获得一个标准的、柔性的、可扩展的、较低成本的、易于部署和实施的实现。

在SOA架构下,我们可以将各种应用功能(即使是异构的应用系统)以Web服务的方式组织起来,通过灵活可变的流程建模和设计,将这些服务串接起来,从而实现一个完整的业务处理流程。甚至,我们还可以将这些已经定义好的流程,继续组织包装成一个Web服务,通过服务注册和服务发现,它们还可以动态的做为子流程元素进一步的作为上一层系统流程的服务单元。这就是SOA架构给我们带来的巨大的灵活性和扩展能力。

以BPEL为标准的基于SOA的流程协同实现,目前已经逐渐走向实际应用。BPEL业务流程集成软件平台,已经在国外的工业界有了非常成功的案例实现,在国内,也可能将在一两年内得到主流应用。

soa技术篇2

关键词:SOA人事管理服务

一、高校人事管理现状

近年来,我国人事制度改革飞速地推进了高等院校的发展,随之而来的便是人力资源的日益庞大、人员结构的复杂程度逐渐增强。传统的人事管理方法不仅繁冗复杂,而且低效。一般都只包括人员和机构档案的管理、简单的考勤管理和工资管理,缺少作为人事管理软件所必需的人员招聘与任用、培训与开发、绩效考核、员工职业生涯规划、分析和决策支持等功能。并且一旦企业内部发生人事调动,工资变化时,用传统的人事管理方法来处理这些事物的话,将会变得十分复杂和繁琐。

在高校管理工作中,人事管理工作的重要性便日益显现出来。因此,针对目前高校人事管理信息化的需求和面临的复杂情况,可以采用基于面向服务架构SOA(Service-Oriented Architecture)来设计系统结构,科学合理地管理高校的人事信息及扩充的人力资源信息。

二、SOA概念和实现方法

1. 概念

近两年,出现了一种技术架构被誉为下一代Web服务的基础架构,它就是SOA(Service- Oriented Architecture,面向服务的体系结构)。是由 Gartner公司在1990年提出的,它根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用,是目前最流行的一种架构模型。

所谓的SOA就是一个组件模型,由不同的功能单元(称为服务)组装而成,服务之间靠定义良好的接口和契约联系起来,这使得构建在这样的系统中的各种服务以统一和通用的方式进行交互?接口采用多方兼容的方式进行定义,独立于应用系统的硬件平台、操作系统和编程语言。SOA的起源和核心都在于Web服务,Web服务就是使用封装的XML消息在两个通话方之间进行交流的一种方式,而SOA使用了大量的通用协议来完成所谓面向服务架构的工作,是一个很好的应用集成解决方案。

2. 实现技术

具体实现SOA的技术有很多,包括Web Services、Session Bean、JINI等。但随着Web Services技术越来越被重视,其已经成为实现SOA的主要构架技术。它是建立在开放标准和独立于平台协议基础之上的分布计算单元。Web Services用XML进行数据的描述和交换,使用SOAP协议在服务提供者与服务消费者之间进行通信,通过WSDL协议定义服务接口,使用UDDI协议进行Web Services注册和查找。这些特性使得Web Services成为目前实现SOA的最好方式,而Web Services以分散的形式存在于不同的系统中。

目前Web Services技术是实现SOA最主要的方法,是基于网络的、分布式的模块化组件,它执行特定的任务,遵守具体的技术规范,这些规范使得Web Service能与其他兼容的组件进行互操作。实现Web Services的主流开发平台有J2EE平台和Microsoft. net平台,J2EE平台开发的系统因具有平台无关性、安全性、可伸缩性、不同供应商实现方案之间的可移植性等若干优点而得到了广泛的应用。

Web Service是一种新的Web应用程序分支,它们是自包含、自描述、模块化的应用,可以在网络中被描述、、查找以及通过Web来调用。它定义了应用程序如何在Web上实现互操作性,它可以使用标准的互联网协议,像超文本传输协议HTTP和XML,将功能体现在互联网和企业内部网上。

任何平台都有它的数据表示方法和类型系统,而要实现互操作性,则Web Service平台必须提供一套标准的类型系统,用于沟通不同平台、编程语言和组件模型中的不同类型系统。Web Service平台主要通过一些协议来实现分布式应用程序的创建,主要有以下这些协议:

1. XML

可扩展的标记语言XML是Web Service平台中表示数据的基本格式。是一种流行的、独立于中间件的格式,可以在不同应用程序之间进行数据和文档的交换。除了易于建立和分析外,XML主要的优点在于它既与平台无关,又与厂商无关。

2.SOAP

SOAP (Simple Object Access Protocol,简单对象访问协议)是Web Service 的标准通信协议,采用标准化XML 格式传输消息?它是用于交换XML编码信息的轻量级协议。它有三个主要方面:XML-envelope为描述信息内容和如何处理内容定义了框架,将程序对象编码成为XML对象的规则,执行远程过程调用(RPC)的约定。Web Service希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用来打破软件应用、网站和各种设备之间的格格不入的状态,实现“基于Web无缝集成”的目标。Web Services标准的成熟和应用的普及为广泛地实现SOA 架构提供了基础,Web Service技术实现了服务接口的传输和调用的标准化,服务接口和服务实现的分离,以及Web 服务组件的可重用性?

3.WSDL

WSDL(Web Service Description Language,Web Service描述语言)就是用机器能阅读的方式提供的一个正式描述文档,WSDL就是这样一个基于XML的语言,用于描述Web服务的所有相关内容,如所提供的服务的传输方式、服务方法接口、接口参数、服务路径等,生成相应的完全文档,给使用者,从而使第三方可以很容易的调用该服务。因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的。

4.UDDI

UDDI(Universal Description,Discovery and Integeration,通用描述、发现与集成服务)是一个分布式的互联网服务注册机制,它集描述(Universal Description)、检索(Discovery)与集成(Integration)为一体,其核心是注册机制。它是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的Web Service注册,以使别的企业能够发现的访问协议的实现标准。

UDDI 基于现成的标准,如可扩展标记语言(Extensible Markup Language,XML)和简单对象访问协议(Simple Object Access Protocol,SOAP)。UDDI同时也是Web服务集成的一个体系框架,它包含了服务描述与发现的标准规范。UDDI规范利用了W3C和Internet工程任务组织(IETF)的很多标准作为其实现基础,比如扩展标注语言(XML),HTTP和域名服务(DNS)这些协议。

三、应用SOA构建人事管理系统

SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚,轻松应对企业商业服务变化、发展的需要。它是对企业各种异构的信息孤岛进行整合的最有效方法,可以实现企业和组织的信息共享,提升人员协同能力以及业务的优化和整合程度,实现有效的业务转型和创新,帮助企业适应外部变化,提高运营效率和反应速度,同时中间件和平台技术的成熟也给SOA在应用层面上的实践提供了有利的保障。

传统的应用集成方法(点对点集成、企业消息总线或中间件的集成(EAI)、基于业务流程的集成)都很复杂、昂贵,并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问题。在SOA中,围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统,如 RPC、CORBA、DCOM、EJB 和 RMI,也同样如此。可是它们的实现都不是很完美的,在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA的服务既可以定义为功能,又可同时对外定义为对象、应用等等。任何业务功能都被作为提供的一个服务使用,应用程序的不同功能(服务)通过这些服务之间定义的结构和合约联系,应用系统可以看作是一系列服务的集成,这使得SOA可适应于任何现有系统,并使得系统在集成时不必刻意遵循任何特殊定制。

SOA 帮助企业信息系统迁移到"leave-and-layer"架构之上,这意味着在不用对现有的企业系统做修改的前提下,系统可对外提供 Web 服务接口,这是因为它们已经被可以提供 Web 服务接口的应用层做了一层封装,所以在不用修改现有系统架构的情况下,SOA 可以将系统和应用迅速转换为服务。

SOA 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息,而且还覆盖来自于如安全、内容管理、搜索等 IT 架构中的功能和数据。因为基于 SOA 的应用能很容易地从这些基础服务架构中添加功能,所以基于SOA的应用能更快地应对市场变化,为使企业业务部门设计开发出新的功能应用。

SOA构建方法位于高校教学资源系统整合业务需求和底层技术之间的抽象层次中,独立地对每一个服务功能模块进行定义,而每一个独立部署的教育资源服务模块不依赖具体的开发平台和系统,各个系统的功能需求通过服务的流程化组织得到实现,从而实现各种异构系统及资源的集成和软件复用。

SOA在高校人事管理应用中的优势:

1.低成本

SOA是实现高校信息系统之间数据和业务无缝衔接的理想方案,结合高校现有的服务,将有用的资源进行改造,开发出功能更强大的服务,简化了系统集成,可以快捷、容易地对业务需求的变化做出反应。使得软件的开发周期大大的缩短,降低了开发成本?另外,面向服务架构是平台和语言无关的,因此不必考虑实施环境是何种平台系统和设备,与其它的系统集成技术相比,面向服务的集成构架是解决高校信息系统集成的理想选择。

2.灵活多变

SOA具有灵活而功能强大的服务层,利用服务层中粗粒度的、可被动态发现和绑定的服务,能够在保持原有系统正常使用的前提下,从现有的服务中重新组合成新的服务,缩短软件系统分析?设计?开发等所需的时间,快速地构建松散耦合的、具有跨平台处理信息能力的应用系统。

四、国内SOA的应用现状

中国企业在实现SOA架构时,往往需要面对原有系统改造优化或新建系统这两个层面。金融、电信等IT建设领先的企业是“以系统改造优化为主,同时也在大量新建系统”的代表企业。在IDC的调查中,对于如何将已有系统进行分割并形成SOA服务的考虑,超过67%的中国大中型企业更多是希望把原有系统切割并包装成为SOA服务。这一方面涉及大部分承载着核心业务的已有系统,任何更改都会对企业运营带来很大的不可控风险;另一方面,企业出于利旧的考虑,也不愿意轻易将原有系统推倒重来或新建系统替代。因此,在对待已有系统的处理上,这些企业往往会出于某种考虑而采取这样一些方法:

1.如果功能容易切分,可以采用对已有系统进行切割和封装的方法。

2.如果功能不容易切分,则把整个系统包装成一个服务提供,或者推倒重来,用新方法构造服务。

五、结束语

鉴于SOA的应用所能带来的价值,我们可以看到SOA应用是一股不可阻挡的潮流,通过SOA的分布式、大规模、异构环境下的整合能力,提高业务的敏捷性,能够解决在异构环境下,企业各IT系统的应用集成,即不同应用系统之间的互通互联,使得企业的IT和业务可以更好地结合在一起。

当SOA的理念、方法静下来时才是它的具体应用和实践开始走向深入的时候。当未来,企业的信息化项目都是SOA的架构风格之时,人们就不需要一遍一遍地去强调SOA的概念了,伴随着SOA应用的普及,SOA也将不再神秘。期待更多的软件厂商不断推进SOA 架构标准化,进一步完善和细化基于SOA 架构的相关产品,加快企业信息化建设的步伐。

参考文献:

[1]马文龙,余文利,廖建平.一种基于SOA 的高校信息系统集成模型设计与实现[J].计算机时代,2010,(2)

[2]顾云锋.基于SOA和Web服务的高校信息系统集成研究[J].计算机与现代化, 2009,(10)

soa技术篇3

论文摘要:本文主要针对吉林移动现有系统存在的某些弊端展开分析讨论,同时结合soa技术对目前存在的问题提出解决建议。

1前言

soa,面向服务的体系结构。简单的说,soa 是服务的集成模式,它将不同的业务作为链接服务或可重复业务任务进行集成,可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内,也可能分散于各地且采用不同的技术,通过对来自部门的服务进行组合,可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时,这些服务可以将自己组装为按需应用程序——即相互连接的服务提供者和使用者集合,彼此结合以完成特定业务任务,使您的业务能够适应不断变化的情况和需求(在有些情况下,甚至不需要人工干预)。

2 吉林移动应用系统现状

目前,中国移动所开发应用的系统有很多,除了办公系统以外生产系统主要分为三类:第一类是basic system(基础系统),这类系统主要是监控设备是否正常运行的。而这些系统都是设备厂家自己开发的,是因厂家的不同而不同,镶嵌在设备本身的,没有办法控制。第二类系统是application system(应用系统),主要是采集由各个厂家设备的基础系统所提供的一些诸如告警,设备配置等信息,而后经过分析形成一些指标。通过各种指标我们可以了解所有设备的运行情况,解决和处理问题。最后一类系统是presentation system(呈现系统),此类系统是对各种应用系统的呈现,向管理层提供各种报表数据等,管理层通过这些数据报表进行分析,从而进行有针对性并且行之有效地决策。

目前,这三类系统除基础系统以外所有的系统都是中国移动与不同的软件公司合作开发的。由于开发商,开发时间,开发的水平的不同,导致系统有很大的独立性。各个系统都有其独特的运行平台,运行环境,维护起来也不方便。部分系统向上层呈现时出现数据格式不一致等等问题。并且,随着时间的流逝,客户的不断增加,设备的不断扩容,系统的需求不断增多,导致现有的系统已经不能满足继续扩展的需要,要重新开发新的系统所花费的代价是可想而知的,原有系统的丢弃也是资源的一种浪费。

此外,应用这三类系统的人也不同,不同的人根据工作需要,所要关注的内容不同,有很多时候一个人要关注四套以上的系统。这样首先要熟悉四套系统,每天关注的时候也要同时打开四套系统过滤出需要的信息既费时、费力不说,有时候还会导致一些疏忽。怎么才能解决诸如此类的问题呢?soa。

3应用soa技术的解决方法

前面提到了soa是面向服务的体系结构,是将所有的功能都作为简单的web服务(也叫原子服务)。一个复杂的功能可能有很多的原子服务组成。这些被组合在一起的复合服务可以作为更高一级的复合服务中的一个原子服务。

在soa理念中,所有的服务是自包含的,具有定义良好的接口,允许这些服务的用户了解如何与其进行交互。从技术角度而言,soa 带来了“松散耦合”的应用程序组件。正是得益于这个松散耦合特性,才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率,可以在增加功能的同时减少工作量。

不难看出,一旦拥有了soa,不同部门,不同人都可以按照自己的需要定制自己所需要的服务,对于不需要的服务可以过滤下去。

这样可以提高工作效率,并且不易疏漏一些细节问题,因为我需要关注的东西都在系统所提供的一个web页面上。此外soa还具有一定的灵活性,比如一旦工作调动我可以在我的定制服务中删除并增加一些服务,这样不会因为部门的调动,再重新熟悉一些没有接触过的系统。

正如图二所示,web服务组合系统就像一个插排一样,提供各种标准接口,下层的服务像插头一样,可以合适的镶嵌在其中。由于web服务组合与底层系统是通过接口相互交互的,故其工作方式是跨平台的透明模式。当然在web服务组合系统中存在很多模块如安全控制模块,用户人登陆模块,用户定制模块,服务注册中心,传输协议等等。通过这些模块的定义可以有效的控制整个网络。

从业务的角度来说,面向服务的体系结构的重点在于开发能帮助您完成业务任务的技术,而不是通过技术约束来规定您的行动。例如,一个集团下发的故障工单的处理过程(包括集团电子运维,省端电子运维,呈现系统,应用系统,基础系统核查等等)可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就其实质而言,此过程包含一系列人工活动,例如:

 接口人员受理故障工单,转派相应责任人;

 相应责任人查找呈现系统、查找应用系统、查找基础系统,最终确定故障原因

 回复工单至接口人;

 回复工单至集团侧;

这只是一个简单的工单处理过程,在企业中还有很多诸如文件审批,财务报表等等一些业务。总之各个部门之间存在着千丝万缕的联系。面向服务的体系结构基于这些实际活动或业务服务进行组织,而不是形成公司所维护的不同的信息竖井 (silo)。通过实现 soa,可以带来大量好处,包括以下各个方面:

 更高的业务和 it 一致性

 基于组件的系统

 松散耦合的组件和系统

 基于网络的基础设施,允许分散于各地且采用不同技术的资源协同工作

 动态构建的按需应用程序

 更高的代码重用率

 更好地标准化整个企业内的流程

 更易于集中企业控制

soa技术篇4

“这不仅仅需要采集各种各样的信息,而且还要求这些数据能够以各种格式保存,从表单文件到SQL数据库或者网页。”Richard Keller表达了他的期望。但数据采集工作仅仅是开头。一旦Keller得到了这些信息,他还需要判断这些以不同格式保存的数据之间有什么样的关系。

“如果你在两个不同的数据库中,都有一个名为‘temp’的字段,那么假设它们都代表同样的意思,具有同样的单位,可以直接进行整合,这是否合情合理呢?”Keller说,“实际上,它们可能一个代表‘温度’,而另一个则意味着‘临时’的取值。所以,为了恰如其分地合并这两个字段,你不得不完全理解这些数据的真实含义。”

在NASA和其他大型机构――不管是政府部门还是企业,整合各种数据都面临着很大的挑战,但是为了能够方便地在内部或者与外部的合作伙伴共享信息,这又是一个不得不面对的问题。数据整合的挑战也是NASA及其他很多大型机构转为使用具有语义整合能力的SOA的一个重要原因。SOA由能够通过网络提供相互操作性能力的各种服务组成。尽管SOA以业务为中心的特性能够激发人们的热情,但它能够让网络服务的整合与动态选择成为可能,这一特点让无数人产生了浓厚的兴趣。这就让语义技术有了用武之地,它能够用尽可能接近自然语言的模型来处理各种如生物学和经济学一样的专业问题。

语义技术

具有内置推理能力的SOA平台,能够帮助企业迅速作出决策,这是基于其服务能力和根据预定义条件获取相关信息的。从SOA本身而言,它并不具备这种能力,但加上语义技术的帮助,能够充分地发挥出彼此的特长,帮助企业作出准确及时的决策。

语义整合技术是基于底层可靠的服务和数据来作出判断的。然而,这些技术目前还没有完全发展成熟。Progress Software公司的DataXtend Semantic Integrator等工具可以使用普通数据模型追踪这个问题,并验证数据交换的可靠性。

支持本体论的SOA

所谓语义整合技术,就是要在各种纷繁复杂的原始数据中找出其共同具有的匹配模式。如果能够做到这一点,那么就可以将这种模式定义为一个原模型,然后将几个原模型根据它们之间的关系连接起来。一种先进的语义整合方法就是Ontology(本体论)。本体论是对一个领域的结构化表述――用它我们可以处理如生物学或者经济学之类的专业领域问题――其表述的基础是面向对象的类及各种类之间的相互关系,这些类和关系可以使用基于XML的网络本体论语言来定义。

使用本体论,任何一个领域都可以被划分为各种类,然后再描述这些类之间的相互关系。支持本体论的SOA将这一建模技术进行了扩展,在SOA的各种服务之上建立了一个层模型,其中包含了与服务域相对应的各种本体论类。这些对应关系是在建立本体论的设计阶段就确定的,然后在运行的时候通过服务请求的语义相似性实现。这里面还用到了策略思想,用来建立查找语义相似性的逻辑。

要建立支持本体论的SOA,有以下四个步骤:

第一步:分析业务流程。

业务流程通常都包含一系列基于条件的任务执行。这些条件可能需要语义能力来展现其智能化的路由选择。我们将这些地方定义为“可变点”,或者是需要推理能力来实现语义特性的区域。

每个任务可能都具有几个可变因素,或者对于每个可变因素,都可能具有多个可能的取值。而且未来的业务需求可能会引入新的可变因素,或者已有可变因素有新的取值可能。例如,早期人们认为物理形态只有固态和液态两种,而随着科学的发展,人们才逐渐认可了气态是另一种物理形态。因此,在定义本体论模型时,每一个变量都对应一个数据字典,可以不断地进行扩展,以保证能够满足未来新的业务需求。

第二步:建立本体论模型。

本体论是用术语概念和关系来定义。本体论的概念实现为类。本体论中的关系被定义为术语的“对象属性”和“数据类型属性”。从可变点组件到本体论模型中元素的映射,能够帮助建立其本体论模型。

要准确地识别出业务流程中的任务和可变点,从而最终将它们映射为本体论模型中的元素,建立起有用的模型,必须要有足够的业务知识。开源的本体论建模编辑器和基于知识模型的框架工具,如Protege可以用于本体论建模。

第三步:创建上下文相关的参与者。

接下来要做的是,创建运行时的组件,它们在执行时按照条件调用本体论模型中的元素,并根据上下文具体条件执行不同的分支。实现这一点的一种方式是使用基于Java语言的技术。使用业务流程执行语言(BPEL)和模块的概念,业务流程会被封装为一个线性流程。而使用本体论的运行时组件则映射为决定正确服务调用的端点。

通过定义“策略”和“断言”,能够实现充分的语义特性。“策略”会决定流程的可用性,并决定端点调用的服务,定义哪个地方可以使用什么服务。“断言”包含了本体论中映射的所有可能变量取值。运行时对包含端点的判断是基于“断言”与“策略”二者之间的最佳匹配原则的。

第四步:实现网络服务。

网络服务提供最终的业务服务。他们是最终的执行点,包含了实际的业务功能。作用于网络服务的策略,是需要包含新服务端点任务的必要组成部分。

改进SOA实施

语义整合被用于各行各业,例如金融服务行业和医疗药品行业,而作为支持本体论的语义整合,其应用范围会更加广泛。我们将建立的支持本体论的SOA体系结构应用在了一个典型的业务领域――禁毒。所有的禁毒活动都需要化学和生物样品,这些样品的管理包括了获取、注册、保存和分发。我们的本体论模型通过动态地调用不同的网络服务实现了对样品获取活动的支持。

这个系统大致是这样的:一个研究员请求样品(上面的第一步),这个请求发出了一个BPEL过程(第二步),其中,这个业务流程模型的BPEL引擎包括了对一个上下文相关调用的请求(第三步),然后这个调用会与本体论模型引擎相互作用,并根据条件查询相关的“断言”和“策略”。结果会根据具体条件选择适当的网络服务执行(第四步)。

soa技术篇5

关键词: SOA; Web Service; 标准文献服务; 管理系统

中图分类号:TP399 文献标志码:A 文章编号:1006-8228(2013)05-71-02

Development of novel standards information service management system based on SOA technology

Luo Qin, Zheng Pei, Xu Fei

(Zhejiang fangda standard information Co.,Ltd, Hangzhou, Zhejiang 310000, China)

Abstract: After fully analyzing working situation and existing problems in standards information management in China, a novel standards information service and management system based on Service-Oriented Architecture(SOA)and Web service technology has been successfully developed and widely applied in various standard-related institutions which are integrated some specific features such as standards title searching, standards documents transferring, standards tracking and other service functions. It significantly improves working efficiency in standards information service. The research results show that SOA technology could be successfully applied to standards information service system as a powerful tool which will provide more effective standards service for enterprises and society.

Key words: SOA; Web Service; standards information service; management system

0 引言

标准文献一直是人们从事科学研究、设计检验和生产管理的重要技术依据,也是人们进行技术交流及贸易往来需要共同遵守的准则。及时掌握并充分利用标准,对于企业提高产品质量、改进生产、促进外贸、获得经济效益起着重要的作用[1]。

在技术文献范畴里,标准具有严格的时效性,有现行有效与作废被代替之分,两者具有明确的实施日期和作废日期。标准的“时效性”决定了标准文献的管理是动态管理。由于我国企业普遍存在标准化技术力量薄弱、专业技术人才缺乏、信息来源采集困难、文献资源加工低效等问题,作废标准的滥用将会给企业生产管理带来重大隐患,造成巨额经济损失[2]。随着信息技术的发展,企业正在利用信息技术手段,结合自身业务流程,建立管理信息系统,规范标准文献管理。然而,企业需要定期收集几十个国家上百个组织的公告来确保所采用标准的时效性,确实无能为力。

随着计算机及网络技术的发展,标准情报研究机构借助信息技术,利用标准馆藏资源,创新标准文献服务模式,由传统服务模式向网络信息服务的转型。本文针对企业在标准管理中存在的问题和未来标准文献服务的发展方向,采用面向服务的软件架构(SOA),研发基于Web Service的标准文献服务系统,为企业提供新型的标准服务模式。

1 标准文献数据的采集

本系统依托标准情报研究机构丰富的馆藏资源,构建标准题录数据库及以标准电子全文库,通过标准号建立一一对应关系。由标准情报研究机构的专业研究人员,通过定期浏览国家权威部门的最新标准信息公告,将其收集整理,利用计算机进行数据加工、数据分析和智能比对,并将标准变更信息更新到题录数据库。同时对购买的纸质文本或电子文献进行加工处理,使其形成PDF格式的电子文本,上传到电子全文库,并通过OCR自动识别技术,对题录数据库中对应的标准数据进行核对,确保准确性。

2 SOA相关技术及其应用

SOA(Service-Oriented Architecture,面向服务架构)是一个组件模型,它为不同的应用程序提供相同的服务,通过定义良好的接口和协议联系起来,它独立于实现服务的硬件平台、操作系统和开发语言,使得这些服务以一种通用的方式进行交互。在SOA定义中,服务是部署在网络中具备一定功能的应用逻辑单元,它包含一组操作集合,并向外界提供访问操作的接口,使其他软件系统通过调用接口实现服务提供的功能[3]。SOA将所有功能都定义为服务,而服务的内部实现对于服务使用者来说是不需要关心的,服务的使用者只需要通过服务提供的接口来调用服务。

本文采用Web Service实现面向服务的架构,Web Service可以执行从简单的请求到复杂的商务处理任何功能。一旦部署以后,其他应用程序可以发现并调用它部署的服务。Web Service是一种应用程序,它可以使用标准的互联网协议,像超文本传输协议(HTTP)和XML,将功能纲领性地体现在互联网和企业内部网上[4]。

3 系统的设计和研发

3.1 功能设计

3.1.1 题录检索服务

使用者提供标准号或标准名称进行检索请求,服务系统根据使用者递交的请求,执行数据挖掘操作并将与之对应的信息数据以XML格式返回给使用者。

3.1.2 文献传送服务

使用者提供文献的标准号并递交请求,服务系统根据使用者提供的标准号,将与之对应标准文献的电子文本,通过二进制文件流的形式回传给使用者。

3.1.3 标准跟踪服务

使用者提交题录清单或者日期区间,服务系统能够根据使用者递交的请求,执行智能分析并将与之对应的题录变更数据以XML格式回传给使用者。

3.2 软件架构及技术实现

整个应用系统采用微软.NET多层架构模式来设计开发和部署运行,开发工具采用Visual Studio 2008,所使用的技术有C#和Web Service,系统的总体架构如图1所示。

数据层整合结构化数据和非结构化数据,为业务逻辑层提供数据服务。结构化数据主要是标准题录信息,采用SQL Server 2008关系数据库进行存储、开发和管理。非结构化数据主要是标准文献的电子文本,以PDF文档格式进行储存。

业务逻辑层为整个系统的核心枢纽。业务逻辑层接收服务层传递的请求指令,处理相关业务逻辑并调用数据层进行数据分析及数据挖掘操作,最终将请求的结果返回给服务层。

服务层是经过封装的信息服务组件集合而成,通过其公开的接口采用Web Service技术向使用者提供服务。服务层实现与企业内部信息系统的对接。

4 系统的应用

系统在中国石油化工集团石油勘探开发研究院、深圳华测检测技术股份公司、华立仪表集团股份有限公司、浙江省电力建设监理有限公司等多家单位实际应用,通过对标准状态以及其他相关信息进行稳定实时跟踪,将被动式标准跟踪和确认的标准管理方式转变成主动式的获知和替换,提升了机构的工作效率,产生显著的经济效益和社会效益。

图1 系统架构

5 结束语

基于SOA技术的新型标准文献服务系统为异构信息系统访问提供了良好的基础构架,能够充分利用现有标准信息资源,促进信息资源的开发利用,为企业提供智能、高效的标准文献服务,是未来标准文献服务的主流方向。随着系统的深入推广应用和用户数量日益渐增,系统可能出现因访问量过大而导致响应速度缓慢等问题,今后将研究采用负载均衡和云计算技术[5]解决系统的性能瓶颈,进一步提升标准信息服务的响应速度和服务质量。

参考文献:

[1] 张妩雅.浅谈企业标准文献管理工作中的重点与难点[J].航天标准

化,2005.3:36-38

[2] 张天林,张思敏.企业标准化难点的原因分析及对策[J].标准科学,

2009.8:15-17

[3] 袁媛,王潮阳,董建.SOA应用的技术参考模型研究[J].信息技术与标

准化,2011.10:21-24

[4] 孙华林,赵正文.基于WebServices的面向服务架构SOA的探索与研

究[J].信息技术,2007.1:51-53

soa技术篇6

【关键词】SOA 电子渠道接口协议 Web services 业务流程超市化运营

中图分类号:TP391.1 文献标识码:A 文章编码:1006-1010(2013)-08-0082-04

1 广东移动电子渠道和NGCRM接口体

系建设背景

广东移动的电子渠道现状是由几个不同时期建立的网站、短信营业厅、WAP、掌上营业厅、自助终端和面向集团业务的ADC等子系统组成的一个集合。各子系统有自己的渠道特点和擅长的业务,分别承担了某客户群的支撑功能。总体而言,各渠道系统在系统功能层面是相互割裂的,各电子渠道和CRM系统之间的划分界面目前也不清晰,缺乏整体数据及功能层面的规划。因此,电子渠道和NGBOSS接口开发基本上是由业务驱动,即针对某个具体业务增加或者修改相应的接口,某一接口基本上只和实现特定的业务功能相对应。目前NGCRM系统接口的直接问题表现如下:

(1)接口通用性和稳定性不强。经常出现的问题是现有接口无法满足某项特定的业务需求而需要临时增加新的接口,这导致目前的接口数量很大且功能繁杂;在业务支撑上表现为接口有时会拖延业务的上线;相关的接口维护部门的工作负荷也增大。

(2)接口没有合理的扩充和版本适应机制。现状往往使设计者在选择支撑方式时倾向于增加新的接口,因为其成本和风险与在现有接口上扩充相比低得多。

(3)电子渠道现状中的竖井模式也增加了接口收敛的难度。不同的电子渠道对接口有各自的需求,在现有接口上扩充不可避免地会影响已经使用的系统,牵一发而动全身,使得设计者和决策者往往倾向于增加额外接口以满足新的需求。

(4)潜在的安全风险还包括:

1)无流控机制:接口的负荷可以直接传导到核心CRM系统,进而影响到一个区域甚至整个广东移动的业务处理;

2)接口的调用方目前没有认证控制:只要是能够接入CRM核心系统的周边系统都可以调用接口;

3)无接口调用的审计机制。

因此,在NGBOSS建设中对电子渠道接口体系在业务能力和架构上进行重新规划已经成为当务之急。

2 广东移动电子渠道和NGCRM接口体

系介绍

随着NGBOSS的建设,电子渠道接口体系的重新规划和设计成为NGBOSS建设的重要组成部分,其方法论确定为:横向整合和纵向解耦。所谓横向整合是梳理各电子渠道共性的功能、数据、流程,结合电子渠道的业务目标,最终明确目标电子渠道系统架构是由哪些通用的业务流程和数据驱动;纵向解耦则是梳理电子渠道系统和CRM系统的配合分工关系,使得电子渠道和CRM分别承载相对独立的业务流程,以此两点为基础,并同样按照包括了功能、数据、流程的分布,最终确定电子渠道和NGCRM两个系统之间的接口体系规划。

本部分首先将涉及电子渠道的业务需求子集作为输入,完成业务流程框架需求分析,进而分解流程,形成接口数据需求分析,最后完成接口梳理。

通过横向整合和纵向解耦确定的NGCRM和电子渠道接口体系,从以往的以单个业务渠道接口协议为主过渡到了以通用流程、数据分解电子渠道和NGCRM的功能为主并在此基础上明确协议,使得大量接口协议具有和单个业务无关的通用性。这种思路明确了NGBOSS的电子渠道系统和CRM系统之间的接口服务调用关系。

广东移动NGBOSS中NGCRM作为业务服务的提供方,提供对电子渠道的统一接口体系。在进行NGBOSS电子渠道接口设计前,根据电子渠道和CRM的解耦分布对需求进行了分解,甄别出涉及电子渠道和CRM之间存在穿越流程的需求点共143个,识别出涉及穿越的流程共21个。在数据方面,接口按照NGCRM数据域划分为:客户服务域、客户管理域、渠道域、资源域、订单域、产品域。

由于电子渠道系统和NGCRM系统之间的交互主要以流程驱动为主,因此电子渠道系统和NGCRM系统的接口设计也以系统流程穿越为主线,数据复制和查询为辅;通过尽量将主要流程进行通用化设计,流程层面的接口的功能体现为对通用服务的调用;按照将业务功能逻辑集中的NGCRM朝着电子渠道轻量化方向发展的思路,在梳理的业务流程和数据流基础上进行了NGBOSS的电子渠道接口设计。

NGBOSS电子渠道接口协议的总体框架如图1所示。

NGBOSS的电子渠道接口按照功能可以划分为受理相关接口、非受理相关接口、产品接口、ADC专用接口:

(1)受理类相关接口目前共有43个,分别提供了包括客户身份认证、各种客户相关信息的查询、订单受理等功能;

(2)非受理相关接口目前共有266个,提供了包括积分查询,各种增值业务查询等杂项功能;

(3)产品接口目前共有2个,提供了产品配置变更查询;

(4)ADC专用接口目前共有12个,提供了ADC工单杂项功能。

3 基于SOA技术的新一代电子渠道接口

协议体系设计

考虑到电子渠道接互的是异构的系统集群,为最大程度地实现跨系统间的业务交互提供服务,NGBOSS基于SOA进行电子渠道接口协议设计,支持SOAP v1.1协议和基于Web Services的HTTP协议传输,提供URL使用Web方式实时提供服务。核心系统NGCRM提供使用基于XML的语言接口定义文件(WSDL)供电子渠道下载。

基于SOA技术的电子渠道接口协议实现了核心的NGCRM系统和异构的平台之间架构上的松耦合,核心系统NGCRM在协议升级时只需要更新WSDL文件,平台可以在此基础上实现对服务的无缝调用;而平台只要按照语言接口定义文件(WSDL)约定调用服务即可,平台内部的演进改造与接口调用无关。

4 NGBOSS电子渠道接口协议体系实施

的效果

基于SOA电子渠道接口协议为广东移动产品在电子渠道的超市化运营提供了技术保障。NGCRM和电子渠道互相协调,使得产品管理、产品上架、产品销售、产品算费等产品生命周期全流程做到了全配置化,产品实现了超市化运营。

电子渠道和NGCRM协调实现产品超市化运营的流程如图2所示。

在产品管理和上架方面,CRM产品配置服务中心是企业产品数据创建和变更的唯一入口。它向电子渠道后台管理提品创建、变更和产品上架服务,图片、Flash等产品富媒体描述通过CRM产品配置中心数据库向电子渠道产品库同步数据。

电子渠道作为和客户的直接接触点,设计用户界面对产品进行展示,并且在电子渠道上完成产品浏览和购物等相关操作。

用户提交订单后,NGCRM负责后台面向客户产品订购的端到端流程,负责维护和处理CRM订单的开通,并负责维护交易的完整性;向电子渠道用户提供订单流程查询和订单变更功能。

NGCRM管理所有产品的订购关系,并向BOSS的计费系统同步订购关系。实现由产品展示、订单处理到后台计费的全业务流程。

可见,在这种架构下,电子渠道只要专注于提供便捷友好的用户界面即可,至于产品管理和订单处理、计费环境的复杂业务逻辑能力已被NGBOSS承载并封装在开放的标准接口中提供给异构的电子渠道调用,加之前后端系统的协调就实现了产品的超市化运营。

参考文献:

[1] 郑宇晟,黎伟健. 互联网时代电子渠道数据业务发展策略[J]. 移动通信, 2012(21): 81-85.

soa技术篇7

从应用软件厂商来看,用友认为SOA是能够帮助用友实现变革式发展的最好的技术驱动力,即将推出的新一代产品U9将实现100%的基于SOA。新中大表示依靠UP平台和SOA总线技术,将陆续把现有中高端软件产品线全面改造为SOA架构。SAP则把相关的思想和技术全部沉淀在Netweaver中。在中间件层面,我们又看到IBM凭借Websphere等中间件技术优势在不同行业着力打造SOA应用样板,把SOA理念、SOA技术与典型应用有机结合,提高对用户选择的影响力。SOA标准及技术的逐步发展将使企业信息化以服务模块化的方式搭建更加灵活开放的架构,提高IT投资的效率和收益,用户正在期待着SOA成熟的同时谨慎地选择切入点。

SOA的中国式质变

2006年12月20日,“2006长风联盟(电子政务)SOA技术应用大会”成为了中国软件界岁末的最大一次盛会。在加入国际标准组织OASIS并正式成为SOA标准制订的重要参与者之后,长风联盟将此次会议的矛头直接指向了更加具有针对性和可操作性的电子政务应用与实施环节。以此作为分水岭,长风联盟一手主导的SOA中国路线图已然走到了质变的拐点。

与之相对应,此次会议的重点显然与以往有了诸多的不同。据了解,包SOA互操作性框架、SOA电子政务总体技术框架、SOA政务应用解决方案、SOA检测与保障机制以及案例分析等更加贴近应用的话题成为了此次会议的核心。也就是说,在长达一年的酝酿期后,长风联盟在推进中国SOA理念及普遍应用过程中的战略思路、总体目标、推进策略及手段等方面的思考与实践正日益清晰。

这是一个意料之中的结果。实际上 ,早在2005年底,长风联盟就已经在“长风联盟技术发展蓝图”中将SOA(Service Oriented Architecture,面向服务的体系架构)确立为了联盟技术战略方向。在长风联盟看来,处于萌芽阶段的SOA恰恰给了由于在核心技术方面缺乏积淀而导致始终以追随者面目出现的中国软件企业一个摆脱窘境的契机。“中国甚至是SOA成长的最佳土壤,我们没有理由不抓住它”。长风联盟秘书长、北京软件与信息服务业促进中心副主任肖澜如是表示。

全球化节奏与个性化道路

事实也确实如此。随着网络技术的迅猛发展以及用户对于随需应变的信息系统需求的加深,网络服务(Web Service)模式越来越炙手可热,并直接导致了传统软件研究、开发、测试和经营模式的转变。在这其中,SOA这种以Web服务为基础框架的崭新理念更是以一种前所未有的姿态颠覆着产业格局。软件的服务化已是大势所趋,在其基础上更加低廉、更加灵活、效率更高的信息化解决策略日益受到各个行业和企业用户的青睐。

即便是在已经形成了定势产业格局的欧美软件市场,SOA也正以暴风般的速度横扫整个产业。据WinterGreen Researc的预测,全球SOA引擎和组件市场在2008年将达到26.724亿美元,到2009年将达到84.502亿美元;美国专注于软件应用领域的咨询公司Zapthink称,全球SOA的市场规模将会由2005年的44亿美元猛增到2010年的430亿美元;据IDC报告,单日本市场,Web Services相关专业服务市场到2008年将达到523亿日元,2003-2008年,平均年增长率达到57.4%。一切迹象都在诉说着同一个结果:SOA是未来网络化时代软件产业的唯一选择。

soa技术篇8

个人信息∷

洪江:拥有十多年丰富的软件工程实践经验,某软件公司技术总监、首席架构师。致力于软件工程相关领域的研究、应用实践,在业务建模、需求分析、架构设计等有深入理解和研究。领导和指导完成过多个大型复杂项目的业务建模、需求分析和架构设计。

高原山风的文章分类∷

业务建模

工作流

需求分析

架构设计

软件开发及过程改进

项目管理

休闲人生

SOA是一种方法论,一种架构思想,不是具体的软件产品。SOA其实并不是太新的东西,早在很多年前就已经提出了这种思想方法,只是最近才有了广泛性的应用。

SOA是一种分布式处理的技术架构,它要解决的问题领域跟CORBA、DCOM、EJB等早期的分布式技术式一样,但SOA在松散耦合、语言无关、平台无关等方面做的要比后者好很多,并且SOA提出的这种技术架构最大限度的包容了以往的技术,使已有的IT投资得到了保护和重用,让旧式应用与新技术结合起来,使之焕发了新的光彩。

SOA的技术架构包括几个部分:ESB(企业服务总线)、SCA(面向服务组件架构)、SDO(服务数据对象)、BO(业务对象)、BPEL(业务流程编排语言)、BSM(业务状态机)等等。下图是SOA的应用架构示意图。

SOA在开发流程上还界定了不同类别的角色:业务建模人员、服务提供者、服务消费者、流程组装者等。

实现SOA应用所使用的技术并不是什么专有新技术,它其实是利用已有的分布式技术来构造自身的应用架构。例如,SOA应用可以采用Web Service、CORBA、DCOM、RMI等中的任何一种来实现。

换句话说,这些分布式技术都可以作为SOA的实现技术。不过,Web Service技术对SOA支持的最好,也是被广泛应用于SOA的实现技术。

SOA的应用案例其实很多,IBM的中间件产品WebSphere Server最新版本本身就是采用SOA来架构的,BEA公司最新的WebLogic Server也是。在具体应用领域里成功使用SOA技术架构的应用有:中远集装箱运输有限公司的EDI平台、山西移动、广州电信等。

soa技术篇9

SOA可谓是这两年软件业谈论火热的话题,但一个普遍的问题是,国内用户对它的态度还很犹豫。微软、IBM、BEA等国际大厂商也无法回避这种阻力。那么,有什么更好的办法来推广SOA,提高用户实施SOA的积极性呢?在参加第十一届软博会期间,北京锐易特的总经理徐征和技术总监李轶强向记者透露了他们的SOA渗透之道。

2000年筹备锐易特公司时,徐征和李轶强就将SOA作为锐易特的发展方向。尽管当时SOA在国内还鲜有人知,从海外求学、工作归来的两位创始人却已经意识到SOA是一种趋势,用李轶强的话来说是“非常值得做”。由此,凭着对国内环境的了解,以及对SOA的信仰,锐易特在“机遇与挑战”并存的现实面前一路走到了今天。现在,反观SOA的大势所趋,不得不说锐易特掌握了先机。

先入的优势是明显的,徐征表示,现在国内不少公司是刚刚理解了SOA的理念然后投入这个领域,而锐易特在方案规划、实施方面都已经拥有了经验,在技术上已经有积累,开发出了针对性的产品套件。最近,其信息整合套件V2.0和通用适配器V2.0还分别荣获了第十一届软博会产品金奖和创新奖两项大奖。另外,2006年锐易特还针对金融、电信、政府和零售等每个行业都建立了两个以上的典型案例,非常具有复制性和可用性,在此基础上,锐易特要大力推广SOA会更具说服力。

对于用户的接受程度,李轶强认为,国内的SOA实施环境并没有人们想象的那样不成熟。“实际上国内对于SOA的需求与问题已经成熟了,最显著的就是“信息孤岛”问题。”信息化建设发展到今天,用户的信息架构中充斥的是来自于不同厂商的系统,这些系统之间的数据共享与连通已经成为CIO正急于解决的问题,而SOA松耦合、可灵活支持业务流程重构、广泛应用标准等重要特点正适应了解决“信息孤岛”问题的需求。

但是,由于SOA理念的接受程度不同,用户的思路并不总是随时跟着厂商走,他们更关注如何解决现实的问题。“他/她最关心的是技术能否解决现存的问题,而不会太在意它是不是SOA。”所以,对于一些厂商大讲SOA理念,而不针对问题提出解决办法的方式,用户很难接受。

soa技术篇10

[关键词] SOA BPM 信息集成 商务流程

一、SOA溯源

企业对于信息技术的运作有两种基本形式:创建信息和调用信息。传统的信息运作方式虽然大大推进了生产力,但又反作用于信息技术,促使企业内外部商务信息的大规模集成。另外,程序语言的发展也经历了如表1所描述的4个关键阶段。

可以看出,IT和程序语言发展的过程实质为逐步降低耦合性的过程,也是接口和接口实现之间逐渐分离的过程。web service实现了松散耦合的服务和粗粒度的服务,它虽然采用的标准的SOAP协议,但其本质上只是一个特定的服务组件。

SOA(Service-Oriented Architecture,面向服务的架构)是在web Service的基础上发展起来的,它最大限度地重用应用程序中的服务,包含且超越了现有的一切技术和架构,其目的就是做到业务和技术的完全分离,实现敏捷的、不受限制的信息集成。因此,可以把SOA看作一种哲学――种描述商务流程、捆绑各种服务、组织IT基础结构的方法论,一种在计算环境中设计、开发、部署和管理“服务”的模型。

二、基于SOA架构的BPM方案

早在SOA诞生之前,BPM(Business Process Management,商务流程管理)产品已经出现并成功实施。处于流程1.0时代的企业通常从头至尾地建立各个业务部门相对独立的流程系统,其间缺乏配合和协同。随着亚当斯密的部门分工理论的没落,快速变化、整合、分布等方面的困难一度阻碍了BPM的应用,使企业逐步丧失竞争优势。在用完整的价值链考察企业竞争力的今天,缺乏灵活性、高昂的变革成本、以IT为中心的传统应用等因素又促使BPM市场急剧增长。同时,IDC提出流程企业应进化到2.0阶段,使用SOA的思想方法和技术架构组装企业的BPM,而BPM的重新崛起在很大程度上又推动着SOA的发展。

BPM主要应用于商务流程自动化 (BPA)、异构系统的无缝整合(EAI)、企业流程建模分析(BPM的核心)和监控企业活动以实现流程持续改进(BAM),每个场合都与SOA关系密切。要从BPM迁移到SOA,跨越信息技术与业务之间的鸿沟,需引入一个服务层,该层包含支持特定业务域的服务线、可跨多个业务域共享的可复用技术服务以及Web Services平台,允许以各种独立于底层服务和技术平台的方式定义和利用服务。从技术层面看,SOA和BPM结合的方法主要有以下两种:

1.BPEL+WSDL:先定义好一个BPEL流程,然后把它纳入到SCA容器中去。在定义构件时,可使用子元素的process属性指明这个可执行的BPEL流程的目标名称。

2.BPEL应用SCA的某个构件。例如,一个BPEL的变量声明可以包含一个SCA的扩展,表明这个变量代表了一个SCA构件的属性。

三、企业商务信息集成

尽管通向SOA的路径仍然十分模糊,架构承诺实现的目标也遥不可及,但仍有很多企业做好了实施路线图并逐步向SOA看齐。以下列举一些SOA项目实施的成功案例。

1.BPM结合条形码解决生产数据方案。某企业的生产过程共有23道工序,BPM系统会根据ERP下达的最新订单信息自动发起流程。CIO希望在流程发起时工人可通过条码终端录入数据进入BPM系统,将流程推入下一环节,最终实现数据采集和报表数据的分析过程。据此,整个BPM方案应基于SOA架构,将现有ERP和制造执行系统中的Bar Code系统相整合,即可解决生产条码整合的问题。

2.商务系统信息集成方案。X公司内部先后实施了OA、ERP、DSS、B2B电子分销、SCM等由不同厂家提供或自主开发的相对独立的系统。随着业务的不断进展,需要进行如下的集成:(1)企业内部商务流程的集成――使企业内部整体的商务流程更加完整和流畅。考虑到业务需求,不同的商务流程之间需要进行实时无缝的链接,因此可通过集成中间件平台,将X公司的各商务系统的商务流程与ERP系统进行整合。(2)企业之间商务流程的集成――使整个供应链的商务流程更加完整和流畅。通过集成中间件平台集成X公司与供应商ABC公司的异构ERP系统。主要定义了产品信息、产品采购、采购订单状态这三个商务流程标准。其中,产品采购商务流程如图所示: