SOA

SOA（通用12篇）

SOA 篇1

摘要：SOA相关技术和标准规范的日趋成熟, 为其国内电子政务领域中的应用提供了坚实的理论和技术基础, 并逐渐在电子政务领域中得到越来越多的应用。通过江西省电子政务统一应用平台的案例分析, 介绍SOA相关技术和标准规范在电子政务中的实践和作用, 以便为国内其他电子政务的SOA应用, 提供具体的案例参考。

关键词：SOA,电子政务,标准规范,企业服务总线

1 引言

国内电子政务建设取得了很大的成果, 但建设中仍然存在一些问题, 如信息孤岛、数字鸿沟、信息资源贫乏、不同地域和部门的信息化发展水平不平衡等问题, 而SOA在基于松耦合服务架构解决异构应用间的信息共享、集成及协同方面, 有着天然的优势, 因此, SOA在电子政务中的发展, 首先从信息共享开始, 逐步向业务协同发展。

但由于SOA涉及相关技术和标准规范较多, 在电子政务的信息化建设中的实施效果和方案选择上, 不同部门和厂商都有所不同, 给用户造成了一定程度的困惑。本文通过江西省电子政务统一应用平台案例的介绍, 为用户和实施厂商提供相应的参考。

2 SOA应用需求

2.1 业务背景

2002年底, 江西省电子政务统一网络平台建成并投入运行。省、市、县各级政府部门, 依托统一网络平台开展本部门纵向和横向业务应用系统建设, 如党委办、政府办、发改委、财政、税务、工商、质监、教育、司法、统计等30多个部门依托全省电子政务统一网络平台开展电子政务应用, 取得了很好的效果。

随着全省各部门业务应用系统建设的加强, 应用系统的跨部门协作不断增加, 部门间横向信息交流越来越多, 各部门对于部门之间的数据交换、信息共享和业务协同提出了更高的要求。但以往数据交换平台的建设, 往往过于注重交换的结果, 忽略了平台的架构, 造成系统之间紧耦合、平台无法复用、接口无法复用的局面。

例如, 在不同地区和部门开展的电子政务信息整合建设中, 存在着“急用先行”的原则, 在急需联合审批时, 建立“审批交换平台”, 在需要法人、人口等基础信息时, 建立“基础数据平台”, 随着政府对外服务业务的不断增长, 还要建立“企业征信数据交换平台”、“住房数据交换平台”、“交通管理数据交换平台”、“食品监管数据交换平台”等。这些“一事一建”的交换平台, 虽然很好地支撑了当时的业务应用, 但缺乏整体规划和架构, 随着业务发展, 当有新的业务协作事项时, 很难进行重用, 只能另行建设, 不仅造成重复建设, 还使得系统间接口混乱, 相当于把小的“信息孤岛”变成僵硬的“交换孤岛” (如图1所示) , 制约了政府信息资源的充分整合。

2.2 SOA应用需求

为了避免上述紧耦合的“交换孤岛”现象发生, 江西省信息中心提出, 必须采用SOA设计理念和技术方法, 建设江西省电子政务统一应用平台的设想, 即:建设覆盖省、市、县三级政府部门的数据交换平台, 一是促进不同系统间接口技术的服务化, 二是为这些服务搭建一个调用关系松耦合的架构, 从而支撑数以千计用户单位开展跨部门、跨层级的业务协作, 充分整合各地各部门的信息资源, 实现各级政务部门业务应用系统的互联、互通、互操作, 支撑全省电子政务应用的持续、深入发展。

采用SOA方案的整体要求如下:

●重视SOA治理:全省统一规划、统一规范、统一架构, 避免各级单位独立建设带来的格式各异、接口混乱、无法重用、难以扩展的局面;

●加强SOA建设和管理:施行统一部署、统一监控、统一管理的集中管理模式, 总体上降低各级政府部门信息整合的建设、管理、应用的成本;

●支撑SOA应用:支撑好征信应用、网上审批、电子监察、公安社会信息共享等跨部门业务协同。

3 SOA总体方案设计

3.1 总体建设内容

根据前述业务需求及SOA应用需求分析, 江西省电子政务统一数据交换平台的总体建设内容, 如图2所示。

(1) 建立江西省电子政务数据交换与信息资源整合的标准规范体系, 为省、市、县各级政府部门的信息资源整合需求提供业务管理与技术实施指导和约束。

(2) 建立覆盖省、市、县三级的信息资源整合总线, 形成全省稳定、可靠、高效的信息交换通道, 承载任意部门间的数据交换和服务整合业务的运行。

(3) 建立全省信息资源整合平台, 支持各级部门信息资源发布与使用的编目管理和安全管理, 支持数据交换流程的快速定制与部署运行, 支持服务的创建、接入、代理、组合、编排等多种形式的快速整合与部署运行。

(4) 建立全省信息资源整合的统一监控管理系统, 支持省、市、县三级接入系统的参数、数据交换流程的统一配置、远程部署, 支持上级管理中心对下级管理中心、接入系统及其所属信息整合业务进行全面的监控和配置管理。

3.2 总体设计方案

该项目遵照SOA设计理念, 开展江西省信息资源整合规划和平台的整体架构。在采用基于企业服务总线 (Enterprise Service Bus, 简称ESB) 实现分布式应用松耦合架构的基础上, 选用安全可靠又切实可行的技术产品, 确保平台高效、安全、可靠的运行。同时, 为了适应不同地区用户的技术能力, 尽量屏蔽复杂的技术概念和技术细节, 保证江西省统一数据交换平台很好地支撑业务应用的开展。

整体技术架构如图3所示, 江西省电子政务统一数据交换平台主要由前置桥接系统、资源目录系统、安全管理系统、数据基础通讯设施、信息整合总线、数据交换与服务整合平台、监控管理系统组成。

(1) 前置桥接系统是用户业务系统接入信息资源整合平台的桥梁, 各委办局业务系统通过桥接系统发布或订阅数据与服务, 交换与整合平台完成协议适配、路由选择、数据传输、格式转换等工作。

(2) 资源目录系统为信息资源发布和使用者提供发布、编目、查询、订阅等功能, 为各部门间信息资源整合建立沟通机制, 为全省信息资源的规划、管理提供支撑。

(3) 安全管理系统为参与交换的单位及其发布的信息资源提供包括身份、认证、授权、加密传输等功能在内的通用安全控制机制, 并提供按照业务交换类别划分应用域的方式, 对参与交换的单位和数据进行管理。

(4) 通讯基础设施, 保证处于不同网络中各委办局的应用系统间可靠传输数据, 为跨层级数据交换和服务调用提供路由中转, 需要采用高可靠、高效率的消息中间件, 本项目各个接入节点和中心路由节点均采用了东方通消息中间件Tong Link/Q 7.2。

(5) 信息整合总线, 也称作企业服务总线 (ESB) , 负责前置系统发布数据或服务的接入、服务组合、流程编排、协议适配、路由、传输、转换等工作, 采用东方通应用集成中间件TI4.0作为ESB服务骨干。

(6) 数据交换与服务整合平台, 主要是为方便用户应对不断增加的数据交换、服务整合需求, 将主要的应用整合模式抽象成整合模板, 尽量屏蔽掉底层技术实现细节, 使用户通过少量配置工作, 就能完成快速接入资源整合系统, 发布/调用资源, 创建/组合服务, 编排交换流程, 部署与运行整合应用等一系列复杂的工作, 并提供业务流程开发工具, 真正发挥SOA架构敏捷、灵活的优势。

(7) 监控管理系统, 分为省、市、县三级中心监管体系, 基于JMX (Java Management Extensions, 即Java管理扩展) 标准接口技术和TLQ的消息传输机制, 实现了上级中心可以创建、更改下级中心及所属节点的系统参数配置和交换流程配置, 监控管理系统基础通讯设施、业务数据交换运行状况、度量系统运行健康指标、统计业务数据交换数量等功能。

4 服务分析和设计

4.1 IT资产分析

该项目需要整合的信息资产, 涉及江西省市县三级不同委办局的应用系统和信息资源的整合, 信息资源和应用系统种类繁多, 因此我们参考《SOA服务分析与设计标准》资产分析方法, 对江西省各级委办局的应用系统和信息资源进行梳理, 结合重点应用系统的业务和服务需求进行可共享重用的信息资产服务化分析, 以完成相应的信息资源资产和业务服务的梳理。

该项目需要整合的资产主要包括两类, 一是已有数据信息资源, 如“民声”信息、企业信用信息、人口/法人/地理信息等基础政务数据等;二是现有应用系统, 如网站内容管理系统、全省党政机关公文电子传输系统、省直党政机关计算机密码通信系统、省委组织部高级人才库系统、省委组织部农村党员干部现代远程教育系统、省政务应急指挥平台、省财政厅省级国库集中支付系统、省地税局全省税收征管系统、省司法厅业务管理系统等业务应用系统。

以上应用系统和数据信息资源, 需要在基于服务的思想, 进行充分共享、挖掘和利用, 可构建的服务类型大致有以下几类:

●数据信息资源的共享服务:包括将分布在各级部门的对应数据信息进行抽取、比对、交换等, 构建统一的基础信息数据库, 然后基于这些信息, 提供对应的信息服务。

●业务流程协作的服务化:各级委办局内部的业务流程及跨部门的业务流程协作, 如多部门的并联审批业务等, 都需要将现有应用系统的功能接口进行服务化, 便于将这些服务进行编排, 构建灵活的业务流程。

4.2 公共服务设计

该项目建设的目的, 是通过建设统一的政务应用平台, 整合江西省现有政务IT资产, 为各级江西电子政务应用系统提供公共技术支撑。根据上述的服务需求及服务模式和方式分析, 参照《信息技术面向服务的体系结构 (SOA) 应用的总体技术要求》中“SOA应用技术参考模型”, 并按照SOA服务分析和设计标准规范要求进行分析和设计, 梳理出该项目的公共服务类型及大致内容, 如图4所示。

(1) SOA资源

主要包括两类:应用系统资源和数据资源, 另外有少量的服务资源, 如密码通信服务等, 这些SOA资源, 通过上层的SOA支撑技术与服务, 可以快速接入或再封装为可共享的服务资源, 以便各部门进行共享重用。

(2) SOA支撑技术与服务

主要包括提供服务交互通信及共享交换骨干支撑的企业服务总线TI ESB和数据交换平台Tong DXP、应用基础运行环境Tong WEB、可快速接入异构应用/数据/服务的适配接入服务TI Adapter、提供异构可靠消息传输服务的Tong LINK/Q、服务资源注册管理中心TI RC、提供可管理的各类文件大小规模的自动化文件传输服务的Tong GTP等。

(3) 业务公共服务

除SOA支撑技术中的基础技术服务, 该项目针对电子政务的应用, 还设计开发了一些具体的业务公共服务, 具体内容包括:信息查询服务、地理信息服务、视频点播服务、信息上报下发服务、公文传输服务、电子邮件服务、信息比对服务等。

(4) 电子政务应用

本期建设的政务应用主要包括三个, 即政务信息公开平台、“民声”通道系统和“信用江西”系统, 依托底层的SOA支撑技术平台和公共业务服务, 可快速构建上述业务应用系统。

(5) 质量、安全、治理

该项目还提供SOA质量、安全和治理方面的技术保障, 具体包含内容不再详细描述。

5 结语

当前, 该项目已完成1个省级平台、11个市级平台的系统建设, 支撑着企业基础信息共享、企业征信应用系统、网上审批系统、电子监察系统、公安社会信息共享、一卡通、人口信息库、自然资源信息库、联动应急指挥、宏观经济决策等应用的运行。

通过本项目的SOA成功实践, 建立了江西省电子政务数据交换的标准规范体系, 实现了全省信息资源整合的SOA松耦合架构, 全面支撑了全省电子政务应用的资源整合与发展, 并为我国电子政务领域的SOA应用实践提供了良好的参考。

参考文献

[1]国家标准化管理委员会.GB/T 21062-2007政务信息资源交换体系[S].北京:中国标准出版社, 2008.

[2]王紫瑶, 南俊杰, 段紫辉, 等.SOA核心技术及应用[M].北京:电子工业出版社, 2008.

[3]Dirk Krafzig, Karl Banke, Dirk Slama.Enterprise SOA中文版--面向服务架构的最佳实战[M].韩宏志, 译.北京:清华大学出版社, 2006.

SOA 篇2

适应业务需求的不断变更是中国企业当前IT应用系统建设中面临的首要挑战

近40%的接受调查的中国企业认为这是中国企业IT系统建设面临的最大挑战。现有IT系统的相对刚性使很多CIO在面对频繁的业务变化时步履维艰、痛苦不堪。从技术层面来说，许多软件系统完全采用手工编码的方式，总体架构设计的缺乏却注定无法全面适应系统需求变更的需求。

43%的接受调查的中国企业认为3到5年后公司内一半以上的软件系统将无法继续使用

中国经济的飞速发展和竞争的日趋激烈使很多企业不得不通过不断的变化和业务创新保持持续的竞争力，业务和流程的变化会非常频繁。实际上，由于业务需求的不断变更和软件系统架构的不灵活，43%的接受调查的中国企业认为3到5年后公司内一半以上的软件系统将无法继续使用。

中国SOA的关键任务 – 大量构造新SOA服务

中国企业建设了大量生产型系统，目前正在尝试着整合； 而大量的服务性系统仍有待新建。调查发现，中国企业更多的在进行系统新建或改造优化。57.5%的接受调查的中国企业建设重心在系统新建和系统改造、升级；重心在系统整合的企业只占42.5%.大量的服务需要全新构造才是中国SOA的主要任务，这一点和美国是完全不同的。

基于面向构件开发平台进行定制开发逐渐成为中国企业的一个选择

为了实现中国SOA关键任务，企业和软件开发商在实践着不同的技术路线以构建SOA服务，包括纯代码编写，基于套装软件二次开发或基于面向构件技术平台进行开发。大型套装软件开发周期长，开发费用高，无法有效适应中国企业复杂多变的需求； 而纯代码编写又不利于标准遵从，同时开发效率较低。就这样，面向构件技术渐渐的出现在技术市场。

SOA软件供应商两大阵营互补提供完整SOA解决方案

SOA中间件平台包括面向构件，流程管理，统一服务和软件治理四个关键功能。目前SOA中间件平台的四种关键功能均在市场主流SOA厂商的产品线有所实现。然而不同厂商对以上4种关键功能的实现路线图却不相同。随着市场细分和专业分工不断加剧，不同的SOA产品功能将这些SOA软件供应商分成了两大阵营：企业级应用整合和SOA服务构造。前者包括IBM、BEA和IONA, 而后者以普元为代表。在当前的SOA中间件市场格局下，这两类厂商在一定程度构成互补的关系。

SOA实施路线图1-对于以系统改造优化为主，同时也在大量新建系统的中国企业

中国的金融、电信等IT建设领先的企业是这方面的代表。这些企业通常已经有了一些老应用系统，它们在当前IT建设中通常是系统改造优化和新建系统同时进行。对于这些企业，实施SOA,要考虑对原有系统切割并包装成为SOA服务。对于新系统，则考虑采用粒度更小、组合更容易、架构更灵活的面向构件技术构造。这些服务，通过ESB实现集成和管理。

SOA实施路线图2-对于以新建系统为主的中国企业

对于中国的政府、国防、电力等企业来说，大量的服务型系统还没开始大规模构造。这些企业往往从构造SOA服务开始着手实现SOA架构。然而，65%的接受调查企业也并表示不清楚如何在新建系统时按照SOA架构来创建标准服务。这些企业的最佳实践是首先遵循SOA国际标准，如面向构件技术来构造服务，在实现SOA架构的第二阶段，对多服务的集成通过部署ESB实现。

做出适合自己公司的SOA规划，采用成熟的SOA技术支撑产品，以及获得业务部门的支持等是企业成功实现SOA架构的最重要三个因素

开源SOA的好处 篇3

简单、开放和低成本是开源SOA最大的好处。无论是部署SOA的过程，还是最终取得的结果，开源SOA都能凭借其灵活性，实现高性价比。

构建SOA要把许多不同的程序、应用和技术结合起来，要想结合得天衣无缝绝不是一件易事。兼容性、规模化和灵活性的问题总是让人头疼，而传统软件的授权使用费制度也会限制选择范围并增加成本。如果采用开源技术，则有助于缓解这些问题、加速研发和商业应用的速度。

当人们打消了对稳定性、安全性和配套支持的顾虑后，开源就成了企业级IT重要的一部分。随着越来越多的构架师和开发者理解了开源的技术核心，开源解决方案也越来越常见。

现在，开源使SOA也比专有工具价格更低，能给用户带来更大的价值。

部署SOA的6个阶段包括理解业务流程; 评估IT; 设计SOA; 实施SOA服务; 整合SOA和管理的基础设施; 完善流程。在每个阶段中，开源SOA的好处能够逐一体现出来。

前三个步骤的重点是业务流程，以及对IT与SOA的设计，开源SOA相对于传统SOA的更廉价、更灵活的定价系统，有助于加快SOA设计进程，而不必担心每个CPU都要付授权费。

在实施SOA的阶段，企业必须决定如何开发和部署应用和数据服务。开源的服务器和数据服务平台非常灵活，在与商业软件同等的开发条件下，开发人员要部署能够增强开发能力和加快开发速度的平台，变得更加容易。而社区则能进一步强化这个平台的特征和品质。

部署SOA的第五步是整个部署过程的“粘合剂”。这个阶段往往会做出一系列重大决定，是部署SOA最关键的步骤。这一点上，开源用灵活的、可大规模应用的特性，又一次证明了自己是高性价比的选择。因为即使项目的规模或某个标准突然改变，开源SOA也不必从头开始。

最后一个阶段，业务流程规则自动化让SOA成为现实。采用一个包括多个整合模型的开源SOA平台——如企业应用整合技术等，在业务流程自动化方面增加了灵活性，节约了成本，能保证部件的再利用。

说了这么多，这些好处如何在实际中体现呢？一家电信公司意识到现有的收费和服务订单管理平台无法满足日趋复杂的电信服务需求，决定选择开源SOA来整合新的收费系统。很快，该公司的服务能力得到了大幅提高，成本反而下降了。现在该公司80％以上的业务都由机器自动处理，几乎不用人工管理。SOA还将以前需要几周的服务时间减少到了几分钟，用户和员工都很满意。

SOA服务管控平台 篇4

本项目完成了企业信息集成平台升级完善的工作方案编制, 制定了企业信息集成平台升级完善项目详细的工作计划;开展了项目前期准备工作, 完成了总体详细设计梳理;完成了平台的扩展优化及提升, 优化了服务管控过程, 提升了平台的易用性, 改进了平台平台监控功能;对平台、服务、流程等运行情况进行了全方位展示, 操作界面进行了标准化改造, 使操作更加规范合理, 全面提升了信息集成平台的技术含量、性能和稳定性;共设计绘制界面原型图335个, 开发70个界面原型程序, 覆盖了“综合管理”、“服务资产管理”、“流程管理”、“活动监控”、“服务管控”共5大功能模块538个功能点, 通过界面原型意见征集, 收集用户意见76条并全部采纳;平台进行了典型业务场景的功能测试, 且顺利通过测试, 基本满足平台升级完善项目的用户需求。

本项目的关键技术和创新点有:

(1) SOA服务化流程引擎。基于SOA架构思想, 通过对服务的组合调用, 实现了流程的流转控制和动态权限管理, 同时, 与服务总线进行了无缝的集成, 提高了流程与外部应用系统的交互能力。

(2) SOA架构应用系统开发框架。服务开发框架对服务之间的交互过程、统一数据结构、事务、安全等进行了封装, 屏蔽了各种技术细节, 开发人员只专注于业务逻辑实现。

(3) 基于Flex的界面动态展现技术。通过编写配置文件完成界面的开发, 采用类动态管理机制解析配置文件并展现, 解决了传统开发界面必须编写代码的模式, 提高了开发效率。

(4) 基于并行队列技术的海量数据采集存储方法。并行队列技术现海量实时数据的快速采集和存储, 解决了大型应用系统在海量数据采集处理方面的瓶颈问题。

(5) 基于约定规则的动态查询引擎。动态查询引擎提供了一个快速的数据查询开发方法, 仅需要按照约定的规则编写接口代码, 无需编写实现代码就能完成数据库的开发工作。

北美精算学会-SOA-考试制度 篇5

soa的考试制度分为二个阶段：

第一阶段是准(asa)。目前对准的考试要求己从1995年7月31日以前的200学分增加到300学分，即除了100系列的11门课程外，还须通过200系列的4门课程。

100系列课程

编号名称学分

100微积分和线性代数30

110概率论和数理统计30

120应用统计15

130运筹学15

135数值分析10

140复利数学10

150精算数学40

151风险理论15

160生存模型和生命表编制15

161人口数学10

165匀修数学10

200系列课程

编号名称学分

200经济保障计划概论30

210精算实各概论25

220资产管理和公司财务概论30

230资产和负债管理原理15

asa考试课程相当于美国大学中的精算教育水平，在美国和加拿大一些大学的商学院内有精算系(专业)，但是许多考生是在取得一定的学分到保险公司和其他机构工作后再继续参加考试，通过每次考试后会报销其费用，并依据其成绩和业绩表现逐步加以提升。asal00系列的11门课程的考试均采用选择题方式，考试时间为1个半小时至4个个时不等。考试成绩满分为10分，及格分数线为6分。然而，一个考生是否通过某一门课程考试以及所获得的分数，要等到该课程全部试卷批完后，把考生按成绩顺序排列后才能确定一个通过的成绩线，这与通常的批分程序不同。并对100课程世界前5名给予奖励。

SOA的“创新梦工厂” 篇6

“全球整合企业对于组织商务活动是一种更好的和更盈利的方法。”IBM CEO塞缪尔•帕米萨诺最近发出了这样的倡导，“但向这种模式转变对于企业领导人来说是一个巨大的挑战。其中挑战之一就是技能，即获得高价值的技能。”而技能的提高，业务整合则是呼声最高的选择。

在国内，公立医院永远是一个人满为患的地方，看病并非易事。如果以后你可以不用亲自去大医院挂号，在社区卫生医疗机构点就可以享受大医院的服务，这就需要这一区域与卫生关联的各机构纵向、横向的数据整合。北京西城区卫生局正在做这样的事情，他们试图在基于IBM的智能SOA（面向服务架构）框架来实现其业务等多方位的整合。

“当时选择SOA，是考虑到SOA可以把不同的服务、不同层次的发展，根据我们的能力合理的部署在一起。”北京市西城区卫生局信息中心的主任朱树宏对于SOA的选择有自己的考虑，“而不足在于，每一个给政府提供服务的企业都会感觉，从项目签下来到项目完成需求改了十次八次，风险也依赖于政府对项目成熟度的控制。也就是说，如果作为政府方不能有效的控制住需求，不能和乙方很好的合作，SOA项目最后的结果就是失败。”

进入今年年底，中国电信上海研究院第二届创意大赛也进入了筹划阶段，这个2006年由上海研究院兴起的创意大赛，希望通过激发员工的创意，使研究院建立起一种注重创新的浓厚的文化氛围，以配合中国电信从传统基础网络运营商向现代综合信息服务提供商转变。与首届创意大赛不同的是，在筹备第二届创意大赛时，中国电信上海研究院同时开始着手建设一套中国电信的创新汇聚平台—“创新梦工厂”。

“创新梦工厂”其实是一个工具，一个能帮助企业更高效、快速地进行创新活动的工具。它由IBM高性能随需应变服务解决方案（HiPODS）团队研制开发，为客户提供Web 2.0型的协作和IT管理功能，使其能够创建并运行从孵化到产品的服务。值得一提的是，“创新梦工厂”中的服务网格环境，也是基于SOA架构提供开发、运行和维护服务。

上面的两个故事，是IBM提了3年之久的SOA在中国的落地样版。前不久，在“IBM 2007 SOA创新高峰论坛”上，IBM软件集团大中华区市场总监刘秋美表示，“不论有没有开始SOA，不管SOA进行到什么程度，IBM都能告诉你具体每一步该怎么做，不管你的企业规模有多大，你都可以成为一个全球整合的企业。”IBM希望以此表示，SOA已经不再遥远。

“我们把一个SOA的演进和成功的推进过程大致分成四个阶段，从刚开始的切入点，到第二阶段的端到端的扩展，再到第三阶段的业务转型，直至最后技术和业务之间完全透明的互相整合。”这就像变形金刚一样，如果是在基础阶段，你会发现有10%的东西事实上是可以重复使用的，5%会变成你的公司资产；第二阶段，你会发现有40%的东西可以拿出来重复使用，20%变成你的资产。依此类推。当到达最后一个阶段时，如果有业务需要重新整合时，你可以很快做出变化。

SOA和EAI应用比较 篇7

SOA与EAI同样能够解决企业集成的问题, 但SOA解决的问题远比EAI解决的IT问题多得多, 产生的影响要深远得多。EAI解决集成的问题往往是在事后, 碰到了集成问题, 才去想办法通过EAI来解决。与之相反, SOA架构解决集成的问题是事先的, 也就是说, 在一开始搭建SOA这一IT架构的时候, 就已经考虑了集成的问题。这是SOA区别于EAI的一个重大不同, 也是SOA能够帮助我们走出“割裂建设和整合”误区的佐证。

对于EAI与SOA具体而明确的差异, 在此不做过多的理论纠缠, 只是针对笔者经验来说说自己的感觉。

1 EAI方法进行企业信息整合的分析

EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构, 来联系横贯整个企业的异构系统、应用、数据源等, 完成在企业内部的ERP、CRM、SCM、数据库、数据仓库, 以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了EAI, 企业就可以将企业核心应用和新的Internet解决方案结合在一起。

EAI (企业应用集成) 将进程、软件、标准和硬件联合起来, 在两个或更多的企业系统之间实现无缝集成, 使它们就像一个整体一样。尽管EAI常常表现为对一个商业实体 (例如一家公司) 的信息系统进行业务应用集成, 但当在多个企业系统之间进行商务交易的时候, EAI也表现为不同公司实体之间的企业系统集成, 例如B2B的电子商务。

上述方式属于紧耦合的应用系统集成方式。这种紧耦合的集成方式将影响系统的灵活性和扩展性, 阻碍业务的流程调整和优化, 不利于企业业务发展。为解决上述问题, 需要一种面向功能层的企业系统集成方式。该方式不仅能保证原有系统的数据安全性和逻辑安全性, 而且还能实现各系统之间的松耦合, 方便系统流程的重组和优化。SOA生逢其时。

2 面向服务的体系结构 (SOA) 介绍

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

3 采用SOA进行企业信息系统集成

3.1 采用SOA进行企业现有信息系统集成的步骤

(1) 提取各个应用系统中需要对外暴露的功能模块。这些功能模块通常都是一些能够清晰完整地表现其业务价值的软件实体, 该软件实体包含了它所能提供的所有服务。 (2) 将这些功能模块表现为服务组件的形式。定义服务的描述信息、服务的接口以及调用服务所需要的定位信息等。将软件实体的概念模型转换成实际的服务模型。 (3) 将已实现的服务发布到服务注册器, 供其他服务调用者进行查找和绑定。这个步骤可以视企业集成的具体情况选择使用。 (4) 绑定和调用服务, 将各个应用系统集成起来, 实现企业应用在功能层面的集成。

3.2 实施建议

整合是分阶段、循序渐进、逐步实现的。如果把企业的所有经营活动看作是一个个服务, 那么整合就是要将企业内外部的各种服务有机地联结起来。首先可以只需创建单独的服务;接下来不仅可以创建服务, 而且可以开始将业务功能集成到SOA中;第三步涉及将企业IT基础设施转换到SOA模型;最后则集中于转换业务模型, 以使之成为适应需求变化的模型。

对具体的整合对象, 按照建模、装配、部署、管理四个阶段实现整合。在建模阶段, 可以定义业务模型或流程、软件模型和SOA模型。之后就可以创建一组服务, 这组服务可以与已发布的通用接口一起重用;在部署阶段, 开发人员可以提取创建的服务, 并把它们放在一个可执行、可管理的环境之中;在使用阶段, 根据软件模型来装配应用程序, 并且测试其软件质量以及非功能性需求, 比如性能、可伸缩性等等;最后的管理阶段是一个长期的过程, 在这个阶段中, 可以监控并管理安全性和使用, 以及在许多与可能已经为SOA制订好的服务级协定或策略相对应的方面比较其性能。这一阶段几乎和技术没有任何关系, 所有事项都与企业的业务相关。建模业务流程的程度将依赖于预期实现的深度。另外, 这个程度还依赖于设计者在开发团队中担任的角色。如果是企业架构师, 将会对实际的业务服务进行建模;如果是软件开发人员, 将可能对单个服务进行建模。

这样由小及大, 逐渐在企业业务中进行整合扩散, 并形成整个企业的IT转型, 最终通过全面整合实现随需应变的企业IT架构。

3.3 基于Web服务体系结构的SOA企业信息系统整合

XML是一种扩展标记语言。Web服务的描述语言就是用XML形式描述的, Web服务的数据也是以XML格式进行交换的。可以说XML是定义Web服务协议规范的基石。

WSDL服务描述语言采用XML Schema定义。WSDL能对各种语言实现的服务进行描述, 具有语言无关性。

DD I是通用描述、发现和集成协议。UD D I使得全球统一定位、发现服务成为可能。

4 结论

SOA提供了标准化的架构, 一个应用对应的服务也能适用于其它应用, 企业开发新应用的速度将得到大大提高, 同时对旧有系统也可以包装成服务, 服务之间为了满足新业务的需求可以进行组合, 从而实现信息系统资源的整合;EAI所要实现的目标完全为S OA所包容, 如果用户已经建立了EAI, 可以将其纳入分布式SOA架构这个体系之内, 加上端点, 加上封装, 就可以进入SOA网络。

从以上的分析来看, SOA从实现企业应用集成的技术层面来看, 其实关注的是逻辑操作层和流程层的集成。进行数据复制和文件传输不是SOA技术手段要解决的。可以说在很长一段时间里, 传统的EAI产品和SOA产品各有各的用处, 相安无事, 甚至EAI产品仍然主导企业应用的集成。直到用户真的能够实现以业务组件化 (CBM) 为前导的流程重组后, 才能体验到SOA为企业带来的深远影响与巨大价值。

摘要：本文首先分析了传统EAI整合企业信息系统的方法, 接着从概念、基本原理几方面论证了SOA方式的优异之处, 然后具体描述了SOA整合企业信息系统的过程, 最后得出SOA、EAI在很长时间内将会共存的结论。

关键词：EAI,EAI信息整合原理,SOA定义,SOA信息整合原理

参考文献

[1]吴建平:CERNET2面对下一代互联网挑战[J].中国传媒科技, 2006, (04) .

[2]郭宏蕾, 闫先东.软件重用:技术和管理分析[J].软件世界, 1996, (01) .

[3]IBM构建灵活的EDI平台[J].软件世界, 2006, (08) .

敏捷方法与SOA的结合 篇8

近年来,关于SOA实施必要性的讨论甚嚣尘上,似乎SOA是包治百病的良药,企业只要实施了SOA,就能提高业务灵活性,从而增强企业的竞争力。然而在大多数实施了SOA的企业中,需求的变化还是不断的出现。针对这一问题,笔者提出利用敏捷方法实现SOA技术的新的开发模式。

2、企业实施SOA的优势与问题

2.1 SOA的优势

1) SOA可通过互联网服务器发布,从而突破企业内网的限制,实现与供应链上下游伙伴业务的紧密结合。通过SOA架构,企业可以与其业务伙伴直接建立新渠道,建立新伙伴的成本得以降低.

2) SOA与平台无关,减少了业务应用实现的限制.要将企业的业务伙伴整合到企业的“大”业务系统中,对其业务伙伴具体采用什么技术没有限制。

3) SOA具有低耦合性特点,增加和减少业务伙伴对整个业务系统的影响较低.在企业与各业务伙伴关系不断发生变化的情况下,节省的费用会越来越多。

4) SOA具有可按模块分阶段进行实施的优势.可以成功一步再做下一步,将实施对企业的冲击减少到最小。

2.2 实施中的问题

1)对SOA概念的理解误差

问不同的人“什么是SOA”,一定会得到许多不同的答案。实际上,SOA是一种无边界服务的汇聚。这些服务之间可以相互通讯,所谓通讯可以是指简单的数据转移,也可以是指两种或多种服务的协同。

然而,某些企业在SOA上只考虑到了Web服务(WSDL),正因为理解上的局限性,因而导致很多“SOA万能”的误解。有些人坚信实施企业服务总线(ESB)就会给你创造一个SOA环境,而有的软件厂商也宣称他们的产品是准SOA,可以提供某些Web服务。但在很多情况下,这些粗粒状的服务都是很笼统的,并且更加倾向于建立技术基础架构,而不会为企业带来新的功能性。对于那些购买了准SOA产品的企业而言,则必须在产品所用技术基础上建立特定的层,以求与公司现有系统结合,反之,如果你不这么做,那么SOA项目的失败率就会大幅蹿升。

2)缺乏商业单位的投入

大部分的SOA项目都是由IT部门中的某人来推动。比如CIO、企业架构师,或IT经理,他们深信SOA或许是一种可以解决以前解决不了的问题的方案,例如服务提供速度过慢、不断积压的项目数量、或者加强遗留系统的要求。这名“推动人员”负责去带领开发人员建立基于SOA原理的应用。但在这一点上,一个最突出的问题就是缺乏商业单位的投入。SOA不是一种可以无视终端用户的体验而直接部署的技术,正因为它同时牵动了多个部门的不同系统,因此更需要商业单位的参与。

如果商业部门无法用SOA方式来思考问题,那么整个链路中就会断了一个环节,导致SOA无法实现预期成效。

3)缺少预算

展开一个SOA项目是极耗成本的。首先是技术成本,你需要搭建一个平台,然后就是学习曲线上的成本。当然,你可以通过聘请有经验的专业人士或服务伙伴来完成。不管使用哪种方式,你都必须将其计入你的预算内。为一个带有高度商业价值的项目去申请预算一直都很难,而在目前的经济气候下,去为一个无法看到立竿见影回报的项目去申请预算更是难上加难。

4)项目执行

大部分SOA项目都使用瀑布式方法来管理和执行,即定义项目的时间跨度(比如9-1 2个月内)来完成SOA基础架构的定义、编码和实施。

以这种从上至下的方式来实施SOA不但无法提供及时的价值,也难以让商业应用高效运转,原因有二:第一,少有最终用户的参与而提高了失败的风险。第二,这一方式没有考虑到要求和环境总是在不断变化。因此使用在SOA实施中的技术也必须足够灵活并支持变革。

3、SOA与敏捷方法的结合

实施中的问题的前面3个问题都可以通过其他方法可以解决,唯独第4个方法在解决上面有一定的难度。针对这一问题,笔者提出使用SOA和敏捷方法结合的方式来解决这一问题。

SOA是一种架构,强调业务必须能满足市场要求,而且通过构建各种服务,可以消除重复,并达成“重用”这一很难捉摸的目标。团队通过构建“服务”而非“应用”,来平衡企业内部和外部的工作。

敏捷是一种方法论,强调事物是变化的,软件开发团队必须拥抱变化,并对变化做出反应。通过引入技术性和非技术性实践,团队可以使业务敏捷起来。敏捷方法的整体目标以人为主和欢迎变化。敏捷方法是“适应性”而非“预测性”的,目的是成为适应变化的过程。

SOA软件开发方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发,在计划制定完成后拒绝变化。敏捷方法是“面向人”的而非“面向过程”的,强调软件开发应当是一项愉快的活动,试图使软件开发工作能够利用人的特点,充分发挥人的创造能力。

SOA是一个方面,是架构层面的因素,可以让企业架构变得更加松耦合,让业务更快的发展起来。敏捷方法是另外一个因素,它能够给SOA的架构提供一种迭代的开发方式,让它能够快速地产生价值,SOA和敏捷有这样一种奇妙的共生关系。一份研究报告上说在美国采用SOA的企业同时采用敏捷方法的比例比其他的企业要高出一倍以上。公司必须一边改造一边使新的应用产生价值,所以往往会采用迭代的方法,所以敏捷就成了自然而然的选择。

4、结论

(1)架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认a变化是必然的b组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论。

摘要：近年来,SOA的概念被一些国际IT企业大吵特吵,然而企业实施的SOA方案并不能令人满意,敏捷方法的提出令这一问题有所改善。

关键词：SOA,敏捷方法,方案

参考文献

[1]Dirk Krafzig Karl Banke Dirk Slama著。Enterprise SOA中文版:面向服务架构的最佳实战.清华大学出版社,2006

[2]王紫瑶等编著.SOA核心技术及应用.北京:电子工业出版社,2008

[3]Frederick P Brooks著,汪颖译.人月神话.北京:清华大学出版社,2001

基于SOA银行服务渠道的整合 篇9

基于上述情况, 银行服务渠道整合平台应运而生, 它是未来几年银行信息化建设的重要工程, 旨在建造统一的信息服务平台, 平台集成各类生产、管理和决策等重要信息系统, 使系统与系统之间无缝集成。服务渠道整合平台隔离交易表示逻辑和业务逻辑之间的紧耦合关系, 实现交易级别的共享和重用, 它以金融产品主动营销为导向, 以客户最佳服务为目的, 以安全控制管理为保证, 并为银行提供统一的服务体验和现代化的技术支撑。

一、银行服务渠道整合理念

银行服务渠道整合平台通过打破传统的不同数据资源、不同业务应用、不同地域间的界限, 形成全行统一的数据结构, 统一的交易构件, 统一的访问流程, 从而达到银行业务服务的高度统一。渠道业务是客户使用银行产品和服务的途径, 网上银行、手机银行、电话银行等新兴的渠道业务蓬勃发展;ATM, POS, 柜面等传统的渠道业务功能也在不断扩充。通过整合这些渠道业务, 形成统一的银行服务渠道平台, 是银行服务渠道整合的主要思路。与此同时, 银行服务渠道整合要结合客户关系管理来进行实施, 通过对客户需求、行为的理解和预测以及对客户群体的划分来设计产品和服务, 在适当的时间把适当的产品通过适当的渠道推荐给适当的客户, 建立统一和便捷的服务渠道, 实现客户关系管理一站式的“管家”服务。

服务渠道整合平台的设计理念基于SOA架构, 利用信息总线等技术, 实现银行数据整合平台、业务整合平台和渠道访问平台的无缝集成, 给予客户统一的服务体验。SOA是当前的一种主流架构模型, 它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用, SOA的构建过程如图1所示。

参考SOA架构模型, 银行服务渠道整合平台设计为一种粗粒度、松耦合服务架构, 服务之间通过简单、精确定义接口进行通信, 不涉及底层编程接口和通信模型。银行以前的业务应用系统都是按业务种类分别开发、分别使用, 如核心业务系统、资金管理系统、信贷管理系统等, 形成各个系统各自独立;不同系统采用的数据资源不尽相同, 数据结构也有一定的差异;数据存储也各自系统采用不同的存储方法。银行服务渠道整合平台首先整合数据资源, 构建了统一的数据平台, 集成了银行目前所有的主流业务系统, 进行交易组合和重用, 实现业务处理简易化、组合化, 统一的客户访问渠道。基于SOA的应用整合图如图2所示。

二、银行服务渠道整合平台功能设计

银行服务渠道整合需要具有动态适配、即插即用的体系结构, 并能进行交易级的定义、组合和提供, 实现各类功能的融合, 只有系统结构分层, 把一个交易的处理流程分为几段, 才能把共有的交易处理流程片断提炼出来, 形成一个各渠道共享的交易处理平台;而只有共享的交易处理平台, 才能实现渠道功能的融合、统一客户体验及提供个性化服务。一般可从以下几方面进行设计。

(一) 功能分层设计

渠道整合平台要支持层次结构, 银行服务渠道整合平台逻辑上一般分为6层架构, 即为数据整合层、原子交易层、交易驱动层、渠道访问层、服务渠道层和信息安全基础设施。这6层相互衔接和融合, 构成了统一协作的层次结构, 相邻层次之间是数据耦合的关系, 不相邻层次之间是无直接耦合的关系, 同层内部支持横向扩容, 功能分层渠道整体功能有机分割, 具有动态部署、即插即用的体系结构, 同时集成了多种协议和标准, 构成具有松散耦合结构的标准服务体系。

(二) 交易重用设计

渠道整合的目的之一是减少重复开发和资源的重复浪费, 所以应实现交易级重用。原子交易接口为不同系统和不同用户提供统一的服务访问通道, 提供一种友好简单的操作引用, 从而可以随时随地、安全有效地获取所需要的原子交易服务。不同渠道支持的交易只要功能相同, 就尽可能用同一个交易逻辑处理代码。交易复用的好处是显而易见的, 首先, 可避免重复开发造成的资源浪费;其次, 能够实现新业务需求的快速开发部署;最后, 隔离了交易表示逻辑和业务逻辑之间的紧耦合关系, 使业务和渠道分离。

(三) 功能融合设计

功能融合需要整合内部原有的应用和资源, 以及外部系统互连, 提供统一的协作和交互平台, 能够兼容原有的系统, 无缝集成企业内部和外部的资源, 实现各类功能之间的协同工作。渠道整合平台要支持不同渠道间交易处理的共享, 渠道整合后, 渠道之间的功能要进行融合, 为客户提供综合服务。渠道整合之前, 服务请求从某个渠道输入, 服务请求的结果就从那个渠道输出;渠道整合之后, 各渠道功能融合。在实现渠道功能融合的基础上, 进一步扩展基于应用协议层的协议技术, 支持更多、更广泛的内部资源和外部资源。

(四) 统一客户体验设计

服务渠道整合后, 不同渠道接入的交易功能应该是没有差别的, 相同功能的交易在各个接入渠道的处理方法和处理流程要做到相同, 给客户一致的服务体验。渠道整合平台要实现服务定制功能, 具备灵活的客户化服务能力, 银行销售人员通过渠道整合平台细分客户, 可以为不同层次的客户定制和提供不同级别的服务。统一客户服务体验和客户化服务并不相互冲突, 统一客户服务指客户只要选择了银行的服务, 无论从哪个服务渠道接入服务, 其体验都是相同或相近的;而客户化服务是指客户在选择银行服务时, 可以根据自己的喜好与服务习惯选择和定制服务内容和服务方式。

(五) 动态配置和拓展设计

采用全部参数化配置原则, 实现平台对交易流程、渠道控制、接口转换等的灵活配置管理, 适应未来电子渠道产品扩展的需要, 同时有效减少开发成本、减少业务推广和运行维护成本, 达到降低渠道交易整合平台总体拥有成本的目的。平台同时应具有良好的扩展性, 除了满足网上银行、呼叫中心、手机银行短信渠道等渠道接入外, 还应满足ATM, POS, CDM, 企业银行和多媒体等其他渠道的接入;平台除了具备与主要业务系统连接的功能, 还应具备与ECIF、银联、公积金等其他系统连接的功能。

三、银行服务渠道整合平台采用的技术

(一) 数据集成技术

渠道数据整合平台对数据进行过滤、变换、汇总、合并, 此外它还负责生成数据视图中数据的模式定义与维护。同时进行数据清洁, 保持数据的一致性, 减少数据重复。由于数据中的多视图结构和对专门应用支持的需求, 对数据的管理与维护要比常规视图的情况更复杂。比如, 数据仓库中的数据可能不是同一种数据模型表示 (如底层为关系, 上层为对象) 。这种比常规视图更加复杂的数据存在方式, 会使所采用的转换算法也十分复杂。此外, 在多数据源的情况下, 需要对多视图进行合并与集成。这时, 可能会出现重复数据和产生数据的不一致性, 它们在数据结构和语义上将发生冲突, 这就要求集成器具有解决冲突的能力。

(二) 基于主题的寻址技术

服务渠道整合平台采用基于主题寻址方式, 它减少了网络负载, 有助于消息送达到其所在目的地, 而无需清楚地知道网络地址、协议、硬件与操作系统差异、端口细节, 从而具有网络的无关性和位置的透明度的特征。这种方式规范地为消息和其所在的目的地定义一个简单统一的命名空间。作为数据的生产者将数据安排在消息中, 并用一个主题名标识每个向外发送的消息, 然后发送这些消息。作为数据使用者用监听主题名的方式来接收消息, 监听一个主题名字的数据使用者会自始至终接收所有用这个主题标识的消息。这里的主题名是一个能说明消息目的地和消息内容的字符串, 对主题名字的语法和解释作很少的限制, 系统设计者和开发者可自由建立使用主题名的习惯。基于主题寻址方式支持匿名通信, 支持通配符, 匿名通信让数据使用者无需知道数据在哪里和是怎样产生的, 让数据生产者无需知道数据在哪里使用和是怎样使用的, 生产者和使用者仅仅只需支持用同样的主题名集标志数据。

(三) 服务渠道整合平台的事务处理机制

基于事件驱动交互方式时以实时处理的方式实现系统之间业务的“交易”, 保证交易的完整性, 它在协议的基础框架上实现接口服务, 完成系统之间的协作和通信。在这种模式下, 事务的提供者和请求者之间或者它们的“代理”之间有三种交易模式:推 (push) 模式、拉 (pull) 模式和混合模式。在推模式下, 事务的提供者将服务主动提供给请求者, 而在拉模式下请求者则主动请求提供者提供服务, 在混合模式下, 事务的提供者把服务推给代理, 请求者以拉的方式从代理那取得相应的服务。接入平台负责系统之间的安全、交易等系统级的接入处理, 业务上的服务调用将实现透明化。

(四) 适配器

服务渠道整合平台提供一个消息系统平台, 让每个应用程序与服务渠道整合平台有一个连接点, 使应用程序有即插即用和方便修改的功能, 这种方式也能激活不同情况下不同类型的通信, 例如发布/订阅、请求/回答、安全、认证和传送。每个应用程序和服务渠道整合平台的连接采用适配器实现, 适配器让应用程序插入消息系统中, 这些适配器将应用程序的内部事件转换成消息, 以便通过消息系统和其他应用程序交换消息适配器也将收到的消息转换为要执行的操作。

(五) 基于Web服务的业务流程集成技术

业务流程集成技术需要结合了银行领域的业务特性和相关技术, 对银行业务进行分解和重组, 实现自动化和流程化管理, 基于Web服务的业务流程集成技术, 提出了组合服务存在性的判定依据, 并给出了组合服务的计算方法, 实现了自动组合机制, 当银行的业务流程发生改变时, 通过自动、动态地组合已有的Web服务, 不需要重新开发新的服务, 从而能很好地适应现代企业业务环境的多变性和动态性。Web服务自动组合的关键, 是根据目的服务的描述, 与服务注册中心中Web服务的描述信息进行匹配, 从而发现满足需求的服务。在基于Web服务的业务流程集成模型中, 抽象业务流程逻辑的描述与业务流程功能的实现分离开来, 从而克服了传统工作流技术在实现业务流程集成方面的不足。Web服务组合能将相对简单的Web服务, 按业务流程逻辑组合起来, 从而提供更强大、更完整的业务功能, 因此, 基于Web的金融组合服务, 实现金融业务流程管理自动化, 直接体现银行业务问题, 可支持实时性交易, 同时也可支持长周期、多步骤的业务流程管理。

四、银行服务渠道整合平台实现

银行服务渠道整合平台能使银行内部和外部的用户在保证安全、控制和审计的条件下, 方便有效地访问业务系统和数据;同时实现行内不同系统之间的通讯、协作和协同, 最大限度地发挥出各类系统的价值。服务渠道整合平台在此基础上, 采用当前主流技术和先进的设计理念, 使平台中的业务系统相互融合, 从而具有数据共享、应用集成、服务封装和流程自动化等特点。银行服务渠道整合平台架构基于SOA, 涉及到数据、组件、接口以及流程等企业系统的各个层面, 主要由6部分组成:数据整合层、原子交易层、交易驱动层、渠道访问层、服务渠道层和信息安全基础设施, 如图3所示。

(一) 数据整合层

建立统一的业务数据结构标准, 对数据进行标识并编成目录, 确定数据模型, 实现数据统一的存储、访问和管理。同时建立数据总线, 数据总线是指原子交易之间交换数据的一种协议。有了数据总线后, 原子交易与应用系统之间的接口被规范化, 降低了原子交易与应用系统的耦合程度, 在应用系统中添加或修改原子交易对整个系统的影响将大大降低。数据整合层使得交易定制 (即通过交易驱动器和原子交易设计交易) 规范易行。

(二) 原子交易层

原子交易是指从应用系统中提取的不可再分的业务处理单元, 原子交易的提取是应用分层能否成功的关键因素之一, 原子交易粒度太小, 会导致系统效率降低, 程序设计繁琐等;原子交易粒度太大, 交易的定制不容易实现。

(三) 交易组合层

交易组合层是指定制交易并且驱动交易执行服务程序。在合理地抽取了原子交易后, 使用交易驱动器技术可以极大地简化程序的编码、调试工作, 增加系统的可扩展性。

(四) 渠道访问层

渠道访问层提供公共函数集, 公共函数是完成一定功能的代码集。系统统一公共函数的管理, 避免多个公共函数实现同一个功能的情况, 从而减少了给系统的维护工作带来的不必要的麻烦。

(五) 信息安全设施

信息安全设施提供统一的安全标准接口, 各服务可根据实际情况调用安全加解密函数, 安全加解密对实际服务屏蔽, 服务并不用关心安全加解密函数采用什么算法, 是用硬件实现还是软件实现。

银行服务渠道整合平台作为业务处理与客户服务之间的桥梁, 既实现了前台的业务渠道多样性, 也保证了后台业务处理系统的稳定性。平台负责交易的智能转发, 保证数据的完整性, 完成相关系统的数据交换, 渠道访问层将交易请求以预先定义的格式发送到原子交易层, 原子交易层转发和处理并将结果返回到渠道访问层, 从而实现服务功能。

五、结论及前景

银行服务渠道整合平台将进程、组件、接口和标准等信息化建设各个层面联合起来, 在银行多个业务系统之间实现无缝集成, 为客户提供统一的协同金融服务。

基于SOA架构的银行核心系统 篇10

随着业务的不断发展, 银行企业开始面临着众多的问题, 为了提高工作效率, 更好的做好服务工作, 银行企业开始将信息化技术引入到本专业业务中, 提高了系统效率。而随着信息化的不断深入, 银行业务复杂程度日益增加, 对服务要求提出更高的要求。而由于银行系统作为一个特殊的机构, 特别是银行核心系统, 为了确保其安全性, 在进行业务整合时, 很多资源相对保守, 无法做到有效的利用, 迫使银行系统各个部门成为孤岛, 无法正常相互沟通, 利用更多共享资源, 极大的阻碍了银行核心系统的发展, 而面对激烈的市场竞争, 如何有效的解决这一棘手问题, 已经是商业银行迫切需要解决的难题。而SOA架构, 即面向服务架构作为一种新型信息化服务架构, 可以将信息更好的整合起来, 提高信息共享效率, 加快系统内部各部分的交互工作。应用SOA架构可以有效的减少业务办理流程, 在保证安全性的前提下, 提高工作效率。如在进行银行核心系统应用时, 为了提高贷款业务的办事效率, 可以充分发挥SOA架构的优势, 减少相同的审批工作, 共同利用共享资源, 从而可以有效的提高工作效率。因此, 在信息时代, 将SOA架构应用于银行核心系统, 成为一种趋势。利用SOA架构, 可以更有效的提高银行核心系统的工作效率, 减少复杂流程, 更好的做好服务工作。

SOA架构和银行核心系统解析

1、SOA架构

SOA是一种服务架构模型, 设计的初衷是建立一种服务架构体系, 利用网络、信息技术等先进技术, 将系统内部的各个组成部分进行充分结合, 在保证安全性的前提下, 有效的控制系统内部对交流合作。SOA架构在应用方面主要是将各个服务模块进行结合处理, 加强服务之间的通信, 减少松散耦合程度, 从而可以更好的保证各个模块之间相互协调利用。在SOA的所有结构中, SOA服务层是SOA架构的基础, 服务层在SOA架构中处于底层, 从而可以确保SOA的服务标准有效性。同时, 这种利用网络之间协调特性, 可以有效的控制系统与人之间的交互工作, 加强沟通。

2、SOA的特性解析

SOA作为基于信息技术的服务结架构, 主要有三大特性。

(1) 、耦合度高

为了提高系统的内部交流合作意识, SOA架构在设计时, 加强了内部各个模块的耦合程度, 有效的提高服务通信效率。这种耦合与传统的耦合不同之处在于, 不仅保证系统内部的信息可以得到有效的共享, 还可以加强系统内部各个模块的逻辑操作, 提高系统操作的灵活性, 从而为银行企业的复杂业务发展提高更好的逻辑操作。

(2) 、交互灵活

由于银行核心系统在进行业务发展时, 往往需要多次做服务交互操作, 这就使得很多模块需要提高交互灵活度。而为了提高应用服务灵活性, SOA架构充分发挥粗粒度服务, 即加强调用接口的封装灵活性, 对不同的调用采取不同的调用方式, 根据调用接口的不同, 而相应的改变, 有效的提高服务效率。

3、银行核心系统的特点

(1) 、业务复杂

因为核心系统作为银行中的重要系统, 在应用中需要处理多方面工作, 不仅需要做好贷款、存储等基本业务, 还需要处理好借记、外汇、拖收等高水平金融业务, 这样就决定了银行核心系统的复杂性。

(2) 、审批安全度高

作为重要系统, 在进行操作时需要重视系统的安全性, 因此, 在进行业务审批时, 不仅需要做好效率, 更重视安全性, 在审批时加强审批重要性、多环节操作, 因此银行核心系统的审批安全度高。

基于SOA的银行核心系统结构

1、数据平台操作

作为银行中重要系统结构, 银行核心系统在进行数据操作方面, 每日需要处理海量数据, 对数据进行报表分析、管理等操作。利用SOA架构, 充分利用信息化优势, 将数据处理等操作进行有效封装, 在进行数据操作时, 用户或者工作人员只需调用相应接口既可以完成复杂操作, 这样不仅可以保证数据的正确性, 还可以提高工作效率, 更好的做好服务性工作。

2、安全性封装

作为以服务为核心的SOA架构, 在进行业务操作时, 为了确保业务操作的安全性, 在进行银行核心系统扩展应用时, 主要是通过BSS等系统架构对系统进行划分, 对资金、理财以及客户管理等系统模块进行封装操作, 通过系统的集成化操作, 可以有效的提高系统安全性, 做好安全性封装工作。这种封装方式不仅可以提高系统的整体性, 还可以屏蔽与其他系统的操作, 有效的提高系统安全性。

3、共享性操作

SOA架构在进行设计应用时, 主要是以服务为基础, 对银行核心系统的各个模块进行整体性操作, 通过对银行核心系统的各个业务进行实质分析, 提高联机操作, 在进行设计时, 对支付业务、ESB以及贷款存款等业务进行共享性业务流程提取, 从而可以有效的确保相同审批流程的简单易操作性。SOA架构将各个系统模块所需的流程进行分析汇总, 之后提供模板类接口, 当系统的各个模块进行操作时, SOA架构做相应的接口调整, 从而保证在确保安全灵活的前提下, 实现业务共享操作, 有效的提高银行核心系统的工作效率。

结束语

银行作为一个特殊的机构, 需要重视资金的安全性, 同时为了满足新时代需求, 做好银行贷款、存款等操作, 需要在提高安全性的基础上, 提高工作效率。而为了有效的提高工作效率, 减少业务办理审批流程, 需要在进行业务操作时, 加强服务接口的共性操作。利用SOA架构, 可以有效的提高业务审批效率, 提高安全性, 因此, 将SOA架构引入到银行核心系统可以更好的提高银行服务水平。

SOA 篇11

全球金融危机给云计算带来了更大的发展空间。“云计算能降低成本、加快企业IT实施、迅速扩展。”这个流行语似乎无处不在，至少厂商推销自家的云计算产品时都是这样表述的。

然而，开源SOA提供商MuleSource公司的联合创办人兼首席技术官Ross Mason却觉得这样描述云计算并不切合实际，他认为：“正如SOA当初因被厂商炒作，变得更像是一个营销用语，而不是准确描述架构一样；这一幕又将在2009年的云计算上重演，完全是重炒作、轻实用。”

看到这，也许那些对技术名词极为敏感的人士们会问，“云计算与SOA之间有什么关系？为什么又把这两种名词放在一起呢？”

是的，云计算与SOA有着千丝万缕的联系，有人把云计算称为SOA的“叛逆者”。

作为一种按需交付服务的商业模式，云计算为企业提供了一种快速部署和应用IT技术的方法。但它也给IT人员带来了不小的麻烦。他们很长时间以来，一直致力于SOA的治理行动，多年来对Web服务环境实施生命周期管理的工作刚刚有了一点成绩，如今又要对这些策略进行修改，以应对部署得越来越多的基于云计算的服务了。因为基于云计算的服务很可能根本不在他们的控制范围之内。

从理论上讲，“云”几乎具有交付一切服务的能力，从应用软件到中间件、再到应用平台，从存储、到流程处理再到硬件资源，都可以采用订阅的方式按需交付。然而，在云计算的世界里，IT人员如何才能进行有效的管理呢？

“云”之所以引发了人们对IT治理的关心，是因为“云”让我们把信任的边界从企业内部扩展到企业以外。”换句话说，云让SOA治理复杂化了。

一个新的问题是，如何把云服务与企业内部的应用整合起来？如果没有有效的治理，任何人、任何时候，只要他愿意都可以部署一个新的云服务，他也能调用这个服务，或者能把这个服务集成到日趋复杂的消息系统中。另外，随随便便就部署的那些云服务也可能破坏业已建立的信任关系，然而这种信任关系，恰恰是生产性SOA环境的基础。

SOA的最基本原则是，分布式应用环境必须与平台无关，SOA治理的基础设施也要遵循这一原则。比如，在纯SOA环境中，外部的API应该与具体实现它的平台无关。然而，率先体验云计算的企业常常忽略这一原则，它们把自己的应用建立在一些公共云服务上，而很多服务采用的恰恰是专有的API、专有的开发工具、特殊的虚拟层和特殊的治理策略，虽然很多云服务为符合开放的SOA和Web2.0标准已经做了一定程度的修改，但似乎还不够彻底。

其实，就企业部署云服务来说，最好的方法是有选择性地外包一些特定的应用和基础设施服务，而不是不分青红皂白盲目跟风。因此，在云计算和SOA治理方面，企业首先要清楚自己的哪些服务可以由“云”来提供。

关于云计算与SOA的关系，更多的人愿意相信他们之间有着相互提携的默契。

就目前而言，云计算技术几乎没有任何治理的概念，反观SOA，它的治理技术已经相当成熟了，云计算可以在这方面好好借鉴SOA的经验；除此之外，你可以用SOA思想来部署云计算架构，因为用户需要将自己的应用扩展到防火墙之外，所以一个模块化的架构在企业进行云计算服务部署时就显得非常重要。

基于SOA的云计算体系研究 篇12

SOA (面向服务体系结构) 框架下的云计算（Cloud Computing）体系是一个优势互补的系统。SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。云计算 (Cloud Computing) 是分布式处理、并行处理和网格计算的发展，通过使计算分布在大量的分布式计算机上，使得用户能够将资源切换到需要的应用上，根据需求访问计算机和存储系统。云计算吸收了灵活性属性以及形式和功能的自由原则，该模式可以用于企业内部、企业之间，或公开范围内，所有这些模式仅仅需要一个服务方向；而SOA框架提供了这种应对不同服务方向的便捷的模型。在面向服务的架构策略中加入云计算，二者的优势就会凸显 (安全性、灵活性、性能等) ，以及由此带来的丰厚的经济、社会效益。

1、基于SOA的云计算体系的设计原则与系统架构

1.1 基于SOA的云计算体系设计原则

以下是基于SOA的云计算体系的一些核心设计原则。

1) SOA=架构+基础设施+运行时+交付

2) 需要建立一个SOA生命周期模型

3) 面向服务的需求和供应

4) 实施SOA运行和协调管理

5) 虚拟化服务栈

6) 利用优化的SOA基础设施服务记录

7) 将SOA作为一个服务工具运行

8) 将云计算体系作为一个投资组合进行管理

1.2 基于SOA的云计算体系架构

现今，人们往往重视云计算的应用前景而容易忽视云计算背后的技术。云计算的各部分与企业数据中心的各部分一样，同样包括诸多编程语言、操作系统、数据库、Web服务器、协议和应用编程接口（API）。关键就是确认哪些云服务真正适合自己内部的系统、应用程序和专长技能。而云计算得以推广的根本是必须确保云服务与本企业的基础架构相互集成。这就需要一种易扩展、二次开发费用低的基础架构能够结合两者，而SOA架构在这些方面比较有优势。

2、基于SOA的云计算体系的设计与实现

云的主要精髓在于数据存储和计算的分布化，因而需要在云部署上充分考虑如何满足分布性，以及如何方便的集中管理云--自动化部署，启动，停止等。在此重点说明部署方法和管理方法。

派发服务的功能实现

云中的和云之间的存储和运算点都是需要支持跨机器访问，云应用程序和单机应用程序从功能层面看应该是没有区别的，唯一的区别在于访问方式上有一点点差别。访问云应用时需要访问者给出云应用的名称（NameSpace) 外，还需要给出派发Key，用来确认该任务应该下发给云中的哪个点负责。因此需要一个消息派发服务，即负责管理消息的分布通讯。具体工作是：根据派发规则和云的路由信息（云中各点的IP地址）找到派发目标点；建立和管理链接；发送和接受数据--采用异步IO处理模型应该更有效率；动态更新路由、流量控制、错误上报。

派发服务的算法基础

派发服务的主要算法是DHT（分布Hash) 。

派发服务的部署

派发服务部署可采用多种方式：如做成一个LIB供应用程序（这里说的应用程序就是云的存储或者计算点）自己去调用；或者做成一个单独的服务进程独立于应用程序。具体到应用上，一般对于小数据都建议使用后一种方式传输。但是这样必然增加了进程的通讯负载，对于大数据传输这种消耗可能无法忍受，因此在这种情况下，可以将消息中间件"退化"成一个LIB供计算点内部调用。

派发服务的路由组织

派发服务必须知道云中个点的位置信息才能正确完成消息派发。这些位置信息记录在"路由表"中，路由表信息中需要包含派发规则（可以交给一个动态库完成）；云中各点的ID和其位置信息（即，个体点的Location信息：如IP、Port等）；以及其他诸如超时（Timeout) 等信息。

派发服务的路由查询

云的路由信息作为元数据管理一般的设计方式是交给一个服务点做集中式管理，当发送方发送前访问该路由查询服务获取路由信息。这种传统方式的好处在于路由数据只有单点管理，便于管理，尤其是更新。坏处是需要跨机器的额外查询，增加了交互，影响了性能 (当然可以做一定优化，让访问方在本地缓存以减少访问次数) , 另外一个坏处是系统存在单点，影响了系统可靠性。使用SOA架构的方法是将路由信息下发到路由服务器上，让路由服务自己加载，这种本地管理避免了远程查询过程，带来了性能优化。

3、问题与对策

云计算在根本上可以看作是一种资源代理--以一种更加灵活和透明的方式调配处理能力和存储资源。对于建设初期的小规模云计算应用来说，个人认为以下几个方面是值得大家注意的问题。

3.1 企业网络的星型配置带来了界限

所有云计算应用程序必须支持同一个块"云"中任何用户桌面和服务器之间的连接。大多数企业网络的设计并不支持这种开放式连接，很多企业使用的仍然星型配置，在星型配置中，"云"的边界通常就会是数据中心的边界。解决方法是构建多处分布式的数据中心，同时在这些支持云计算的点和桌面之间的传输路径之间就必须保证有足够的带宽的和很好的服务质量。

3.2 分布式的数据中心如何有效的协调工作

真正的云计算结构将会有分布式的多个数据中心，这些分布在各地的数据中心如何有效协调?用户到底要访问哪个数据中心的应用?这可以借鉴CDN网络的成功经验，CDN是一个经策略性部署的整体系统，能够帮助用户解决分布式存储、负载均衡、网络请求的重定向和内容管理等问题。具体来说就是一方面是提供公共的网络运算中心，让其他企业的应用方案部署在其上，从而实现集中部署/管理。另一方面，对计算性能和用户访问实现分布式就近访问计算，并利用分布式存储、负载均衡、网络请求的重定向、网络访问优化、SSL应用加速等种种技术手段，保持用户的及时、稳定、安全的使用。

3.3 私有云计算设置中的应用程序兼容性

最容易运行在私有云上的是那些计算能力密集，对数据库访问较少的应用程序。接下来就是一些使用静态数据存储（这些静态数据存储可以被复制）的应用程序。最难运行在私有云上的是那些对数据库需要事务性读取的应用程序。任何指定给这样一个应用程序的服务器就必须连接到一个数据库中，因为所需要的信息存储在这个数据库。这种设置带来了后端存储网络性能问题，这将会给云计算带来严重的问题。如果需要多个数据库备份的话，这也会带来数据库的同步问题。针对这一问题的解决方法就是在云计算设计之初就使用SOA框架的理念来运作：针对普通PC平台创建多样化的虚拟桌面接口，把相同的数据存放在外部，将各式各样的应用程序配置在云计算的平台上。

3.4 企业云中的访问、应用程序和数据安全

最后的问题就是云计算应用中的信息安全问题，很多公司使用安全系统来保护特定资源，期望这些安全系统和应用程序有一个静态关系。从根本上来讲，有一些安全机制并不需要。另外，应用程序和桌面之间交互的接口都会在相关索引中公布出来，这也就又给入侵攻击或者拒绝服务攻击提供了一个新切入点。这就要求云计算的相关配置在安装之前需要有一个全备的安全审计，在公司数据提交之前保证的所有组件到位。同时在使用过程中制定更多的相关流程与标准来保证用户的数据安全。

4、总结

本文研究了基于SOA的云计算体系的架构和实现方法，其设计理念是在体系设计之初使用SOA框架下的基于服务的松耦合运营模式的理念，，以服务为基本单元封装各类网络资源，以服务集成为基本手段提供开放环境下的资源共享与集成的高层次抽象模型，从而增加应用的灵活性。现今，云计算体系的研究与建设仍处于起步的阶段，还有许多问题需要进一步的研究，以此，为将来的企业化应用奠定基础。

参考文献

[1].卢致杰, 覃正, 韩景倜, 王立华.SOA体系设计方法研究.工业工程.2004年06期.

[2].于振梅;基于SOA模式的企业架构设计.中山大学学报论丛.2006年08期