soa技术精选(九篇)

第1篇：soa技术范文

关键词：SOA架构；企业；应用

中图分类号：TP393.09

1 SOA架构的概述

面向服务的体系结构（service-oriented architecture，SOA）作为架构和组织IT基础结构及业务功能的方法，能通过对已有服务的重用，达到降低开发成本、缩短开发周期、优化业务流程的目的。服务目录主要用于收集和整理已有服务的信息，从而达到发现已有服务的目的，服务总线是用松散耦合的集成方式连接不同服务调用者和服务，服务接口定义了服务间相互调用的接口协议，是服务能否正常运作的关键。

2 大型企业面临的典型问题

大型企业的信息化建设，在前期一般重点是完成各项业务信息化的全面覆盖。在这个逐步扩展的过程中，容易缺乏统一的技术框架和规范，加之信息技术的飞速发展导致信息化应用系统大量分散与孤立，标准不统一，软件接口和数据共享难度大，系统的维护难度和成本偏高，资源难以共享的现状。

具体表现为以下几个方面：（1）应用系统条块分割，缺乏业务关联；（2）各业务系统的基础数据自成体系，为集成造成障碍；（3）面向用户的层面缺乏集成，用户权限、密码管理多样复杂；（4）对业务流程优化缺乏有效技术手段。

因此，面临这种状况大型企业迫切需要建立具有较强的整合能力、具备先进技术，能够高效快速实现的信息集成平台，实现业务协同。

3 SOA应用解决大型企业典型问题

SOA是一种应用框架，主要针对日常的业务应用，还可将业务应用分解单独的业务功能和流程，形成所谓的服务。SOA使得用户能构建、部署和整合这些服务，不用依靠应用程序及运行平台，就能业务流程的灵活性提高。这种业务灵活性能促进企业加快发展速度，降低总体成本，实现及时、准确信息的访问。SOA可以帮助获得更多的信息资产重用，更轻松的管理和更快的开发和部署。

为解决大型企业业务应用，建立SOA的企业信息集成平台不仅能有效同步信息技术支撑能力，而且有利实现业务应用需求，并合理有效地动态配置各种资源目的。SOA是一种架构模型，该模型能够通过网络对松耦合的应用组件，按照需求进行分布式部署、组合及使用。此外，SOA能帮助企业完善“信息弧岛”问题，为企业提供应变的服务需求。SOA把应用和资源转变为标准服务，企业按照自己的策略定制流程即可。同时将应用服务化，并对底层集成透明，达到信息技术和企业业务的同步。

4 SOA企业应用方法

4.1 信息化现状评估

根据国际上成功SOA的经验，以SOA能力成熟度标准和关键里程碑评估企业信息化现状。能力成熟度标准是指SOA平台的建设应达到的能力要求，涵盖技术、标准、架构、组织保障、管控、应用效果等方面。关键技术要求是指SOA平台的建设应采用的关键技术和标准。

4.2 业务服务域设置

建立业务服务域的意义在于为SOA提供业务分层、细分管理；为划分服务的责任归属提供依据；是对信息化规划中相应内容的执行、具体实施和实践；满足共享和交互需求。SOA可以提供一个可被服务请求者和服务提供者通过Web服务平台调用的转换服务，这有助于两个服务层数据模型间的数据转换。XML Schema是目前表达SOA服务层数据模型的最好的技术，因为它开放、基于标准，可以扩展。

业务服务域功能：业务服务域在SOA整个架构体系中应该发挥的功能有借助平台实现管理服务功能，提供不同服务域之间的服务访问交互、转换及控制功能。来自不同的服务域的服务可能会采用不同的数据模型，也可能采用类似但又不同的数据类型进行通信。要实现业务服务域的核心功能定位，一方面要明确业务服务域所涵盖的核心数据，另一方面也要明确通过哪些核心业务活动才能实现这些数据的产生，因此业务服务域也必须具备对这些核心业务活动的流程支持。

4.3 SOA技术架构

SOA技术架构从IT技术实现的角度，描述了支撑SOA所需的技术组件、技术服务及它们之间的联系。技术架构也描述了这些组件和服务如何互动来实现一些典型的应用场景。应用集成平台的技术架构可进一步分为开发环境、执行环境和运维环境，分别描述在开发、执行和运维时所需要的技术组件和服务。

SOA目标架构对组成SOA架构的各功能模块以及它们之间的关系进行描述。目标架构应该是一个全面的、成熟的SOA架构，它提供一个可以促进和简化服务设计、管理和部署的环境。每一个设计出来用于被整个企业共享的服务都应该至这个SOA架构中。SOA目标架构应该被用于指导未来所有的应用开发和改造的一个重要的指南。当然，此目标架构也应该随着企业需求的改变和业界标准的演进而变化。

SOA架构的核心模块包括企业服务总线、业务流程管理、数据交换平台、企业门户、数据仓库、服务管理和监控工具、安全基础设施和服务开发环境等。该架构中的每一个组件均支持一个企业SOA环境中的特定需求。

4.4 SOA部署模式

SOA平台负责应用系统间的信息交互和流程流转，因此SOA平台的建设模式与应用系统的建设模式紧密相关。更近一步的说，应与应用系统的部署层级紧密相关。在未全部实现“应用系统大集中”的情况下，存在两类部署模式，即集中式部署和分布部署。此种在应用部署模式上的差异会直接导致SOA平台建设所选择的部署模式的不同。对应这两种应用建设模式，SOA平台建设也可以分为两种模式，即集中部署模式和分布部署模式。下面以分布式部署模式进行说明。

对于分布式部署模式来说，其特征是一、二级都有自己的数据交换平台、企业服务总线和业务流程管理模块，分别处理一级应用系统间和二级应用系统间的信息共享和业务流程交互；此外，通过一、二级企业服务总线的互连实现跨业务层级的集成需求。

一级服务总线保存所有二级服务总线的信息，并可向二级服务总线请求部署在二级服务总线上的服务；二级服务总线仅保存一级服务总线的信息，可以请求一级服务总线上部署的服务，但其不与其他同级进行交互。因此，总线间的连接拓扑可以视为以一级服务总线为中心的辐轴结构。

服务目录的管理可考虑采取“统一部署、分级管理”的方式实现。一级提供统一的服务目录管理平台，供一级和二级其服务使用。二级仅有和管理部署在二级服务总线上的服务的权限。此种方式简化了服务目录管理，实现服务高度的完整性和准确性，并消除了服务目录间互相更新同步的复杂性。通过服务目录的统一部署和同步，所有服务信息在内部共享，从而使得跨组织的集成成为可能。

5 结束语

总的来看，采用SOA面向服务架构的业务将在效率、响应和适应上得到提升，采用SOA架构的企业IT可以实现复杂性降低、重用增加和遗留集成。SOA带来的开发的高效率、服务的高可靠性和服务的高质量，都会最大限度地提升业务机会。当然SOA的建设也应该在遵循规范有序的架构方法之外，结合企业本身业务和信息化特点进行自己的探索。

参考文献：

[1]李银胜.面向服务架构与应用[M].北京：清华大学出版社，2008.

第2篇：soa技术范文

【关键词】大港数字油田；综合应用平台；信息集成；服务总线；SOA

引言

经过多年的数字油田建设，大港油田建立了覆盖勘探、开发、油气生产、集输、视频监控、经营管理等专业系统，较好地解决了专业信息化问题，为油田公司核心业务的发展提供了有力支撑和技术保障。

由于种种原因，过去分专业路建设的系统相对独立、专业性强，集成度差、多次登录、分散授权、快速准确获取所需信息难度较大、缺乏面向业务的综合信息汇总与统计分析、缺乏支持部门间横向协同决策等问题，信息集成迫在眉睫，解决企业信息集成的关键技术就是SOA-面向服务架构。

1、SOA技术概括

SOA-面向服务的架构，是面向过程、面向对象、面向组件、面向方向技术之后，软件技术在设计理念、架构体系和管理体系的一次飞跃，通过多年的发展，其标准规范体系和技术支撑体系不断完善，在在企业级应用集成中得到广泛的应用。

SOA是一种新型的软件体系架构模式，它是在计算环境下设计、开发、应用、管理分散服务单元的一种规范，它将应用程序的功能单元（称为服务），通过服务间定义的接口和契约联系起来。根据需求可以将松散耦合的粗粒度服务进行分布式部署、组合和使用，使系统变得更有弹性，能更灵活、更快地响应不断改变的业务需要。

SOA架构的关键特性：一种粗粒度、松散耦合服务架构，服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。

2、大港数字油田建设中SOA应用情况

2.1数字油田总体架构

数字油田综合应用平台是数字油田多系统的集成平台，也是数字油田建设成果的集中展现平台。根据油田信息系统实际情况，采用数据、功能、服务和流程集成的策略，实现信息系统在各个层面上的集成，按照业务需求进行功能拆解与模块化处理，通过数据资源池、功能资源池、服务资源池的建立，构建大港油田数据服务总线（DSB）及企业服务总线（ESB），打破信息孤岛，实现功能重构、信息共享及应用集成。

2.2SOA的实施策略

根据中石油统建系统和大港油田自建系统的实际情况，应用SOA技术建立生产管理、协同研究、经营管理、辅助决策四个平台，通过个性化定制，构成数字油田综合应用平台，按照油田主营业务，完成相关服务的调用。

2.3生产管理平台

生产管理平台，集勘探、油藏、采油与地面工程、生产运行等业务于一体，业务覆盖钻井、生产、油气集输、产能建设、电力管理、生产监控、安全、应急管理、修井等全业务领域，初步实现了计划、运行、实时监控、动态跟踪、完成情况分析、优化调整等一系列生产管理活动的闭环管理，有效支撑了勘探开发生产经营与管理。

2.4经营管理平台

贯穿计划、财务、合同、物资等经营管理业务流程，实现了ERP、FMIS、AMIS、HR、CMS等经营管理类信息系统有效集成及高度汇总，为各级管理提供了高效、快捷、准确的经营指标分析。为油田公司、二级单位两级提供经营统计分析功能，集成了经营管理及生产管理跨业务信息，有效盘活了ERP等系统的信息资产，满足领导、职能部门及各单位生产经营管理者业务需求。

2.5协同研究平台

是集油藏研究、工程工艺研究于一体的基础环境平台，该平台建立在数据集成、环境集成的基础上，通过建设统一的数据模型及数据交换平台，面向研究人员实现研究成果共享继承利用的协同工作平台，服务于提高钻井成功率，提高最终采收率，提高新工艺新技术研究应用水平，提高油田开发决策水平的辅助支持，是集勘探开发、钻井实时决策、方案自动生成、效果跟踪分析、方案优化调整全过程闭环管理于一体的智能化平台，该平台目前处于设计阶段。

2.6辅助决策平台

基于数据仓库和商务智能技术，逐步建立支持勘探开发研究、生产管理、经营管理辅助决策系统，实现面向各类主题业务的信息自动汇总、关键指标预警、对标分析、方案跟踪优化调整等功能，提高智能化水平。

2.7个性化工作平台

按照业务职责、安全管理及权限控制，建立了上至公司领导、下至基层操作员工的个性化工作界面，全部实现单点登录、一次认证，实现了信息的高度集成与权限个性管理的有效统一。

3、结束语

目前大港油田基本完成了自建系统和统建系统在系统层面、数据层面、功能层面和服务的集成和资源整合；构建了覆盖有油田公司和二级单位两个层面的生产、经营数据资源池；构建指标体系和报表体系，实现指标数据的定制、同比、环比和异常变化提醒；按照生产经营业务流程，重新组织集成资源，实现生产管理流程化；通过图形化分析和数据钻取功能，为各级领导提供生产、经营辅助决策支持。通过个性化定制，满足各级用户个性化工作需要。

基于SOA架构的公共服务平台的建设是数字油田标准规范体系的技术保障，是规范专业系统建设，实现专业应用服务化、专业数据共享化的前提条件。公共服务平台的建设，将彻底改变大港数字油田专业系统的建设模式，最大限度地发挥信息化对油田勘探、开发、生产、经营管理业务的支撑作用。

参考文献

[1]蒋璐瑾.Web信息集成技术研究与实现[D].华南理工大学，2010年

[2]刘涛.基于SOA架构的企业应用平台研究与开发[D].长春工业大学，2010

[3]陈新发.数字油田建设与实践—新疆油田信息化建设[M].北京：石油工业出版社，2008.7.

第3篇：soa技术范文

关键词：SOA；架构;IT

随着中国经济的不断增长，企业级应用的需求不断变迁和提升，客户对软件功能和性能的要求也越来越高。在长时间的建设过程中，企业建成了形形色色的各类系统，这些应用系统主要以业务条线或职能领域的驱动方式进行建设，随着这种建设模式的持续，应用系统越来越多，对于这些系统的使用者和建设维护者而言，也带来了越来越多的问题和挑战。

一、企业IT现状分析

一般来说，由于企业IT部门规模有限，无法完全自主开发来响应业务部门的需求，只能是借助开发厂商的力量来建设应用系统，企业IT部门则主要负责项目控制、需求沟通、质量控制、系统维护等工作。在这种IT建设模式下，企业建成了形形色色的各类系统，同时，企业不可避免地遇到了越来越多的困惑：

·业务需求总是在不断变化，而僵化的IT架构往往无法跟上变化的脚步，IT部门如何能够通过建立更加灵活的IT架构，快速响应不断变化的业务需求？

·不同的开发厂商使用不同的技术架构和开发平台，企业IT系统整体呈现出架构非常发散、技术规范不统一、系统内部模块耦合性强、功能与数据交织、系统修改复杂度高等特征， IT部门无法深入掌握应用系统，如何规避被开发厂商锁定的风险？

· 随着业务发展和管理提升，应用系统之间互操作和数据交互的需求越来越多，IT部门如何保证各系统之间良好的整合能力？

·各应用系统在不同时期由不同团队基于不同技术建设而成，形成了不同的应用“烟囱”， 而且各个系统操作风格差异很大，业务用户在不同系统之间需要频繁登录和切换，信息分散，占击层次深，操作不便，如何通过IT模式的转变，提升操作用户体验和工作效率？

· 面对大量的应用系统建设的需求，如何有效的保证系统实施的速度和质量？

·随着IT系统复杂度越来越高，IT部门在新系统实施和老系统维护之间疲于奔命，如何改变IT部门被动的局面？

二、SOA核心技术介绍

第4篇：soa技术范文

关键词：Web；服务；SOA；SOAP；策略

中图分类号：TP39 文献标识码：A 文章编号：2095-1302（2014）08-0076-04

0 引 言

SOA是一个体系结构概念，与具体的技术无关，Web服务是一种实现方式，也可以基于其他技术来实现SOA，比如OSGi（Open Services Gateway initiative）、CORBA（Common Object Request Broker Architecture，公共对象请求体系结构）、DCOM、RPC等。而且，Web服务不仅仅限于实现SOA，通过将一个方法公开为Web服务，可以实现过程式的RPC。

1 SOA和Web服务

最初，Web服务被描述为一种连接技术。这种方式由于是基于已有的HTTP协议之上，因此具有简单、安全和无障碍的特点。SOAP与WSDL的出现和应用可以说是软件技术史上的一个里程碑。

Web服务之前的CORBA、MQ、EJB、COM/COM+等技术可以很好地解决在某种特定平台或技术之上的分布式计算问题，它们都很强大。然而，业务全球化和企业国际化导致信息现代化必须面临“不同系统平台、不同组件技术和不同技术下的遗留系统整合”的现实情况。而Web服务提供了一种技术，即不管什么平台、什么技术和什么开发语言，它能够通过WSDL技术和标准将不同平台、不同技术和不同开发语言下的业务服务出去，客户端可以通过基于HTTP的SOAP协议来远程调用。由于访问是基于HTTP，因而远程调用可以突破防火墙，实现互联网级别的远程调用。因此，目前软件技术已走向了“无技术”时代。所谓“无技术”时代并不是不要任何技术，而是通过Web服务实现了企业级应用系统基于平台无关性、技术无关性和语言无关性的开发、整合、部署和运行的全新时代。

SOA与Web服务的关系如图1所示。

2 关键技术研究

2.1 服务的连接与集成（Integration）

服务的主要形式是点对点（Point-to-point）和中心辐射（总线式）方式。点对点方式就是服务消费者与服务直接连接。每个服务消费者必须确保与所有相连的服务接口保持一致（例如同步或异步、SOAP或REST、服务的版本、安全性问题等）。图2所示是点对点服务的连接方式。

点对点方式适用于以下环境：

・服务和服务消费者的数量较小

・采用同质技术体系

・预期在业务和技术上变化很小

近年来，ESB往往被视为构建SOA的基石之一。实践证明，ESB是企业构建真正的SOA架构应用所必须的基础设施。ESB可以理解为一类产品，即在服务消息者和服务之间连接和中介所有通信和接口的中间件产品。也可以理解为一种模式，具有多个厂商和开源实现。实际应用中，一般从一个厂商或开源实现开始，根据业务需要增加扩展或定制。

服务使用Web服务或其他标准或适配器连接到一个公共的骨干背板上。ESB管理接口的相容性、服务的路由（基于内容、可用性、负载或其他规则，可能是动态决定，可能是一对多或多对一的聚合）以及数据转换问题（格式和业务语义）。可以促进系统的松耦合。减少连接的复杂性。

ESB适用于技术上异构、变化快速和大规模系统如果具体的把ESB产品和传统EAI里面的消息总线类产品（如ActiveMQ）做个比较，两者差异就很大了，主要有三方面。第一，ESB以SOA面向业务的哲学为基础，所以它主要是通过配置来建立 ，而不是通过编程建立；第二，ESB必须有能力在不同的协议之间建立互通机制，包括传统的消息机制（JMS）和Web服务接口（WS）；第三，除了消息（服务）方式外，ESB还必须为SOA服务治理提供服务的生命周期管理，而非简单的过滤、转发、路由，包括服务、注册、使用、推广、效益统计、升级等。

2.2 服务与发现

服务（publish）指在目录服务（directory service）中和更新Web服务的信息。服务发现（discovery）指客户使用发现服务（discovery service）发现已注册的服务。发现服务是目录服务的一种特例。包括静态和动态两种。服务和发现均可以基于人工，注册库是自动方式的一种。

Repository（翻译为资源仓库或存储库）和Registry（注册中心）经常混用，通常都指用来注册服务的一个中心位置。如果严格区分的话，区别在于Repository除了注册服务及其元数据外，还可以注册任何其他制品；而Registry一般仅用于服务的定位。存储库比注册中心包含的内容更为丰富，目前一般采用存储库的较多，因为同时可以实现治理（Governance）的一些功能。服务注册本就属于SOA治理（SOA governance）的范畴。

通用描述、发现与集成（Universal Description，Discovery and Integration，UDDI）标准旨在为Web服务提供一个平台中立的注册表。UDDI可被用作私有或公开的注册表。然而，UDDI的术语相当晦涩和复杂，它的动态发现功能过于想当然，UDDI Registry的实现比较少。如今只有少数企业用户在使用UDDI，公共的注册表就更少了。现实当中，除了少数几个商业产品（在那里它的复杂度用户看不到），很少用到UDDI。UDDI的失败并不意味着对注册表的需求也随之消失，大多数公司转而寻求别的替代。可以使用简单的数据库或轻量目录访问协议（Lightweight Directory Access Protocol，LDAP）应用，甚至在Wiki上保存一个目录。开源注册表方案，如MuleSource的Galaxy及WSO2的Registry，试图填补这一空白。

2.3 BPM、服务编排与编配

BPM（业务流程管理）是设计、制定规则、控制、分析操作过程的软件，涉及人、组织、应用、文档和其他资源。在寻求良好的性能、对变化迅速的市场及时响应、发展软件等方面，SOA和BPM是天生的“伴侣”。BPM工具和技术在设计和编排SOA服务时，非常有用。目前，有如下几种BPM标准：

BPEL-WS规范在2003年4月提交给了OASIS（Organizationfor the Advancement of Structured Information Standards，结构化信息标准促进组织）并更名为WSBPEL（Web Services Business Process Execution Language）规范， 2007年4月WSBPEL2.0版本，除了Microsoft、 BEA、 IBM、 SAP 和Siebel，Sun Microsystems和甲骨文公司也相继加入了OASIS组织。除去政治因素，BPEL的流行还在于Web正成为分布式系统架构的平台以及SOA的雄起，SOA强调服务的分解和解耦，而BPEL则对这些Web服务进行编制，两者密不可分。但BPMN到BPEL的转换存在着先天上的缺陷，原因是BPMN是基于图的，而BPEL是基于块的，BPEL是一个结构化（块[Block]）和非结构化（控制链和事件）的混合体。这个缺陷导致有些BPMN建模的流程无法映射到BPEL，两者的双向工程更是存在问题。这个缺陷成为人们反复诟病的对象。许多支持BPEL的产品为了解决这一问题，不得不在用户建模时做出种种限制，让用户绘制不出无法转换的模型。

BPMN2.0正式版本于2011年1月3日。BPMN2.0正式将自己更名为Business Process Model And Notation（业务流程模型和符号），相比BPMN1.x，最重要的变化在于其定义了流程的元模型和执行语义，即它自己解决了存储、交换和执行的问题，BPMN由单纯的业务建模重新回归了它的本源，即作为一个对业务人员友好的标准流程执行语言的图形化前端。BPMN2.0一出手，竞争就结束了，XPDL、BPEL和BPDM各自准备回家钓鱼。看起来胜利者似乎是BPMN，但看看BPMN2.0的领导者，就会发现最后的胜利者还是IBM， Oracle和SAP这些大厂商们，他们提交的草案明确要赋予BPMN2.0以执行语义，这迫使BPDM团队撤回了其提交，并将他们的提议与BPDM团队想法合并，这就是BPMN2.0最后内容的由来。

BPMN的目标是期望通过一套统一的建模、执行模型填起业务人员与开发人员之间的那道鸿沟

服务编排（choreography）：在编排的业务流程中，流程的每个节点都自己决定接下来怎么往前走。举例来说，每个节点可能都在自己的虚拟机里运行，从某个内向（in-port）的队列接收消息，执行处理，然后决定往哪个向外（out-port）的队列发送消息。从某种意义上来说，节点并不知道自己在更大的流程中扮演什么样的角色。在编排的服务中，并没有“流程实例”的概念，而是采用存在于流程节点内部某处的消息。

服务编配（orchestration）：编配的业务流程是集中管理的，通常还是在单个虚拟机内。拿BPEL来说，每一个流程启动，都会创建这个流程的“实例”，交给BPEL引擎管理。如果是长时间的流程，该实例则有可能被持久放在数据库（这个处理过程叫做“脱水”）。

2.4 服务安全

对Web服务的威胁涉及网络基础设施、应用和托管系统。要使Web服务安全，需要一组基于XML的安全机制来解决有关消息层次的安全性、认证、基于角色的接入控制、分布安全策略的执行等。

Web服务需要点到点还是端到端的安全机制，决定于威胁的程度和面临的安全风险。“端到端”是指从最初的请求者到最终的接收者，传统的面向连接的点到点安全机制不能满足Web服务的终端到终端的安全需求。但是，安全性需要在风险和对抗措施的成本之间进行折中，如果风险可以容忍，那么点到点传输层的安全机制也是可用的，只要它能够提供足够的对抗能力。

传统的网络安全机制，如传输层的SSL和TLS、VPN、IPSec、S/MIME等，都可以用于Web安全保护，但它们都是点到点的安全技术，对端到端的安全性是不够的。

现在，Web服务的应用拓扑包括大量移动设备的组合、网关、、负载均衡器、外包数据中心等，并且是全球分布、动态配置的系统。所有这些系统依靠消息处理中介的能力去转发消息。中介设施的数据接收和转发超越传输层，数据的完整性和安全性信息可能丧失。这一情况迫使任何消息处理器要信任前一个中介设施的安全性评估，并且完全相信它们对消息内容的处理。一个全面的Web服务安全性体系结构所需要的是端到端的安全性。成功的Web服务安全性解决方案应当同时成功地对传输层和应用层实现安全保护，提供全面的安全性能力。

信息系统通常采用的安全性保护技术，可以用于Web服务，包括以下方面：

（1）认证。认证是对服务请求者和提供者身份的检验，有时候还需要对双方进行互相认证。可用的技术包括：口令、证书、LDAP、Kerberos、PKI；

（2）授权。控制请求者接入资源，并规定请求者的接入权利。通常采用最小接入权限的策略；

（3）数据完整性和机密性。一般使用数据加密和签名技术；

（4）交易正确性；

（5）不可抵赖；

（6）端到端的消息完整性和机密性；

（7）安全的消息传输。保证信息安全性、消息的加密和签名技术；

（8）审计踪迹。可以通过对资源的监测和守护而得到。

（9）安全策略的分布执行；

（10）跨领域的身份标识。支持不同领域身份标识的映射；

（11）安全的发现机制；

（12）发现与信任。

2 Web服务架构示例

以服务发现为例，完成服务。下面是SOAP服务使用的详细过程。

通过WSOL ESB完成，目前SOAP服务到ESB，必须提供正确可用的WSDL文件。提供方式有两种：第一是给管理员提供可访问WSDL的URL；第二是把WSDL以纯文本文件发送给管理员。

发送URL方式可以访问WSDL所在URL的协议，必须是HTTP/HTTPS协议。例如：http：//yczy.zys.zbb.hj/wiki/ws.php？wsdl，这样，管理员可以在ESB上导入此URL所包含的WSDL内容，从而创建相应的SOAP Web Service。

发送WSDL文件，发送的WSDL文件必须是纯文本文件，内容为XML。这样才能为系统进行解析处理。下面是WSDL的示例作为参考，主要代码如下：

3 结 语

通过构建面向服务的应用支撑环境，各级保障部门、各个业务系统的信息服务，都能够通过服务的包装，成为随取即用的IT 资产，以服务的形式对外，以松耦合原则实现共享，并可将各种服务快速整合，开发出组合式应用，达到“整合即开发”的目的。

参 考 文 献

[1]韩丁，沈建京，万芳，等.基于SOA的服务构件封装技术研究[J].计算机工程与设计，2009（7）：202-205.

第5篇：soa技术范文

关键词：SOA；电子政务；系统架构

中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)14-3312-04

SOA-based E-government System Architecture and Key Technologies

WU QIU-ping

(Information Network Center，CPC Guangzhou Municipal Party，Guangzhou Administration Institute，Guangzhou 510070，China)

Abstract: The e-government information has become an important part of the construction and has achieved considerable development, however, the lack of uniform standards and specifications to plan And the limitations of the system architecture to today's e-government information silos and the security threats facing other problems. In this paper, using SOA architecture building construction program of e-government system and launched an in-depth research.

Key words: SOA; e-government; system architecture

电子政务是政府管理手段的变革，将现代信息和通信技术运用到其管理和服务职能中，以实现政府工作流程与组织结构的重组优化，从而改变传统工作中时间、空间与部门分隔的制约，使其全方位地向社会提供规范、优质、透明的服务。国家行政学院和国家信息中心于2006年5月18日至19日联合举办了“2006中国电子政务论坛”，国家行政学院公共管理教研部汪玉凯教授在论坛中指出：“在经历了基础设施建设和应用系统建设热潮之后，电子政务建设目前面临的一个迫切问题是信息资源整合。” [1] 与其他信息系统一样，电子政务系统对系统建设思想和软件技术的要求也日益增长。

1 电子政务系统建设现状

近年来，随着我国信息化建设的发展，我国政府信息化工作取得了长足进展，政府部门利用先进的信息技术、网络技术和软件技术，建立并实现了部门之间、部门内部以及面向社会的基于信息共享、业务联动的各类政府业务信息管理系统、管理信息系统与辅助办公系统。但从电子政务系统建设的现状来看，电子政务在信息共享与互联互通上还存在明显的不足。目前电子政务信息化建设缺乏规范性，信息化进程与可持续发展的原则相违背，在整个建设过程缺乏统一的规则，甚至在有些部门还出现了使用多个异构系统同时进行工作的情况，完全没有扩展性可言。

当前我国电子政务发展的主要难点可以归纳为：1） 电子政务的一体化问题；2）信息孤岛问题。此外，当前政府信息化中的另一个至关重要的问题是信息安全，目前我国电子政务系统存在以下安全隐患：1）无法控制工作人员访问政务网以外的网络资源而导致机密文件意外泄露；2）无法控制一些机密信息通过如U盘拷贝、打印、电子邮件等方式或途径的外泄；3）来自内部主机和用户之间的相互攻击和非法访问无法防止和控制；4）无法严格限制终端用户接受安全检查，如终端主机系统自身的安全性、终端用户对网络资源的访问权限等；5）网络病毒的泛滥对终端电脑的攻击得不到有效的控制，如稍有不慎，就会导致电脑中毒，严重会导致电脑系统瘫痪甚至信息盗用。

开发性、虚拟性和网络化是电子政务的自身特点，因此对电子政务系统的信息交换、传输和处理的安全性提出了更加严格的要求。

2 基于SOA的电子政务系统架构

现阶段各政府职能部门常常根据自身的情况和需要，建立自己的业务系统。这些业务系统往往是采用不同的技术标准、不同的软硬件平台，并由不同的软件提供商开发。这些跨平台异构系统形成一个个信息孤岛。面向服务的架构SOA能够实现异构平台的信息集成，支持跨政府部门内部和各部门之间端到端的集成，而且通过服务的重新组合形成新的服务，如图1。

电子政务系统在将政府信息化建设息息相关的各种核心业务应用及多种结构化和非结构化信息，通过Web方式整合在一起，对内、对外分别实现政府领导及公务员内部的协同办公、政府与其服务对象之间的交互服务能通过多种途径〔如PC、手机、PDA等〕以唯一的接入点，访问与之相关应用，获取有针对性的信息，从而达到信息、数据与应用资源的共享及政府服务的便捷应用，因此，电子政务系统总体设计如图2所示。

系统利用XML技术，将政府各职能部门的数据源整合（包括公检法信息库、工商税务信息库、社会保障信息库等），从中抽取数据并进行分析、挖掘，向政府人员、广大企业、公众等提供信息服务。

3 电子政务系统的实现

3.1 根据实际需求，将电子政务系统分为五层

即:表示层、处理层、服务层、数据访问层与数据层。相互关系如图3所示。

1）表示层设计

表示层位于系统的最上层，为新架构下的电子政务系统提供用户交互界面，负责处理用户的输入和向用户的输出，但并不负责解释其含义。表示层以基于portal的系统来构建,可以用来向用户提供用户接口服务。根据用户需求和权限的不同，以网页或的桌面应用程序的形式提供不同的客户端界面。客户端界面提供了用户调用业务逻辑层Web服务的接口和参数，对不同的使用者进行权限和界面划分，为不同用户提供相应的Web服务调用界面。用户根据界面提供的接口和相应参数完成对Web服务的调用，这个调用是完全透明的，在Web服务执行结束后将会自动返回结果。由JSP，HTML等技术实现，通过浏览器向用户显示，并通过对服务层各服务的调用来实现其相应功能。

2）请求处理层设计

处理层又叫做业务流程层，是整个系统模型中最重要、最复杂的一层，包含了整个企业应用的全部业务流程。处理层对用户界面层的请求进行响应，并负责在服务层中调用数据访问层与数据库中的数据进行交互。在该层中，各种服务早已封装好，可以直接调用来构建应用系统中的业务流程。处理层中的业务流程将通过调用一个或多个Web服务来实现。

3）服务层设计

服务层是电子政务系统中最重要的一层，在这层中将运用底层功能组件来构建系统所需要的不同功能的服务。在服务层中，服务被划分为公有的和私有的服务。公有服务是指那些在系统外部可用的服务，也可能是企业外部的，它们是一些典型的、有业务意义的服务。私有服务没有任何的业务意义，它们的存在是用来支持业务服务的并且对于其他系统来说没有一点可用性。

4）数据访问层和数据层设计

数据访问层中包含了对数据层的数据访问的逻辑，与业务逻辑分开，此层的重复利用的可能性非常大，因为几乎所有的系统都要与数据库进行交互，而且对数据库的操作基本上相同。数据访问层中数据访问逻辑调用相应的Web服务来实现对数据库的操作。

数据层中存放了与电子政务相关的业务数据和历史数据，这些数据存放在一个或者多个数据库中。数据层对数据库的操作命令完全来自于数据访问层，执行结束后将结果返回到数据访问层。

3.2 构建电子政务信息资源共享云计算实现模型

亦可构建电子政务信息资源共享云计算实现模型,就是设计云计算模式下的电子政务信息资源共享实现理论方案。结合电子政务信息资源共享实际要求,电子政务信息资源共享云计算实现理论模型可由资源层、管理中间件层和服务层等3层构成。

4 实现电子政务系统的关键技术

4.1 对业务逻辑的调用接口

服务对业务逻辑的调用接口通过Java Interface定义。接口中对服务实现方法进行抽象定义，并在实现中对方法进行具体实现。

以GetTotalGradesService服务为例，首先定义其接口IGetTotalGradesService,并通过接口定义服务中可供调用的方法。如下所示：

public interface IGetTotalGradesService{

public getTotalGradeByUserID(int userID);

public getTotalGrades();

接口定义了两种方法getTotalGradeByUserID和getTotalGrades，其中getTotalGradeByUserID可以允许客户端通过用户ID调用特定用户的总成绩值，getTotalGrades允许客户端调用所有用户的总成绩列表。服务GetTotalGradesService实现这个接口并对这两种方法进行具体实现，客户端需要调用此服务时，就可以根据接口的定义进行调用了。

4.2 服务的注册及

将服务部署到Mule时要通过配置Mule的XML配置文件来定义服务和服务的调用I/O。以TeachingServiceBroker为例，对Mule的各项配置如下所示：

1）对服务进行定义

implementation="zzj.soa.math.TeachingServiceBroker">

定义的元素为，其中name属性制定服务的名称，这里定义为TeachingService；implementation指定具体实现该服务的类为zzj.soa.math.TeachingServiceBroker。

2）对服务的调用I/O进行定义

定义了服务，还需要定义对其调用的方式，包括进入方式((inbound)和出站方式(outbound)。这实际上是定义服务的端点(endpoint) Endpoint可以通过多种方式进行，如WS, JMS, System I/O Stream等。本文通过使用AXIS插件将服务暴露为Web Services后用SOAP消息进行传递。定义如下:

transformers="HttpRequestToSoapRequest"/>

定义中利用AXIS插件将服务到http:/llocalhost:8181 /services，服务部署

成功后就可以通过localhost:8181/services/ TeachingService的方式访问服务了。

3）对Transformer的定义

对上面使用到的Transformer进行具体定义:

className="org.mule.prov

. soap.transformers.

HttpRequestToSoapRequest"/>

定义的元素为

将配置文件定义好后放入项目目录中的WEB-INF文件夹中，并需要在项目的web.xml配置文件中定义环境变量。多个配置文件需分别定义。

Tomcat启动时会自动加载web.xml中的定义并将以上服务注册入Mule组件中，客户端就可以通过Mule调用该服务了。

4.3 Web Service的实现

WebService负责按照客户端提交的请求，并按照业务逻辑提取、过滤和处理数据，并将处理完的数据包返回给客户端进行显示，相当于程序架构中封装了业务逻辑层。本文中主要设计用户身份验证WebService和业务数据WebService。在系统中都是作为类来实现。以下用“用户身份验证”为例进行说明：

Public Function GetAuthorizationTichket(ByVal sUserCode As String,ByVal sPassword As String) As String

’如果用户名和密码不正确则返回空

Dim auth As New Authorization

If Not auth.CheckUserPwd(sUserCode,sPassword) Then

Return Nothing

End If

Public Function GetUserInfo(ByVal sTicket As String) As UserInformation

If Not IsTicketValid(sTicket) Then Return Nothing

Dim UserCode As String=FormsAuthentication.Decrypt(sTicket).Name

Dim auth As New Authorization

Return auth.GetUserInfo(UserCode)

End Function

Description用于简要描述可以通过Web调用的方法或特性的功能。Description特性的值添加到WSDL和web Service帮助页中，使服务请求着能够直观的了解Web Service的功能。

建立Web Service作为一个公共域服务的时候，Web Service将会有多大的吞吐量是未知的，可能是一个小时只有一个用户，也可能每分钟会吸引几十个用户。在这种不可预测的情况下，可以利用缓存来提高数据读取效率。

4.4 WS-BPEL JBI服务引擎

在一个组件的第一个“开始”之前，调用“init”方法进行启动前初始化。

服务引擎初始化(SE Initialization)

class ProviderEngine implements Component, ComponentLifeCycle ...{

DeliveryChannel channel;

ServiceEndpoint serviceEndpoint;

public void init(ComponentContext context)

throws JBIException

... }

// Obtain reference to delivery channel

channel = context.getDeliveryChannel();

// Activate service endpoint (SEVICE2,ENDPOINT2)

serviceEndpoint = context.activateEndpoint(SERVICE2, ENDPOINT2);

}public Document getServiceDescription(ServiceEndpoint ref) ...{

Document result = null;

// return WSDL describing services offered by me through the given

// service reference.

if (ref.getServiceName.equals(SERVICE2) &&

ref.getEndpoint Name.equals(ENDPOINT2) ) ...{

//... create or find the WSDL

}return result;

}

// ...

4.5 消息传输(Message Delivery)

通过一个SOAP绑定组件提供一个面向外部消费者的服务消息传输，可从两角度实现：

1）从绑定组件角度

2）从服务引擎角度

4.6 网络安全保障

以下从网站环境安全和可靠性保障设计二方面阐述网站安全保障设计。网站环境安全包括网站安全域边界控制、域内安全和安全管理三个方面。安全通过以下措施解决：

1）利用防火墙解决安全域划分及安全域边界控制问题

根据信任域差异，通过一台防火墙将网站划分为两个不同的网络安全域。即政务外网区域和局域网域。通过制定严格的安全策略可以很方便地实现对外网办公区、局域网区域进行隔离与访问控制，并且可以实现单向或双向控制，可以有效保障网络安全。

2）利用入侵检测和放病毒解决域内环境安全问题。

入侵检测设备类似二层交换机一样，采用一进多出或多进多出的方式，同时与不同网段相连接，进行数据交换；实时监测各网段之间的各种流量，提供从网络层、应用层到内容层的深度安全防护,见图4。

3）利用安全管理软件解决网站安全管理问题。

防火墙提供Web管理方式（通过网口）、CLI命令行管理方式（通过串口），同时还支持远程拨号（PPP）管理方式。上述三种管理方式是一直打开的。另外，防火墙还提供通过SSH登录对防火墙以命令行方式进行远程管理的功能，可以方便的实现分级权限的安全管理、日志审计和日志服务器和流量整形和带宽管理。

4）利用双机系统提高网站系统的可靠性与可用性。

防火墙提供全面的系统状态监控，可以让管理员清楚地了解网络中接口流量统计、最大连接数量的IP等信息，并且能够及时发现被网络蠕虫病毒感染的主机，配合连接限制，进行实时阻断。

5 结束语

通过建立SOA架构，充分调动起政府各部门电子政务信息形成随取即用的资源，以松耦合原则实现共享，并可将各种服务快速整合，开发出组合式应用，实现对电子政务需求的快速响应。把政府政务系统中的各个组件接口用面向架构的设计和实施方法封装成公开的服务,然后通过业务流程编排将这些服务捆绑成一个可以作为单独应用程序可共同使用流程 ,最后以表现层的政务门户的形式为用户提供调用这些公开服务与流程的接口，真正意义上实现了电子政务系统高效、安全、信息共享和系统的互联互通。

参考文献：

[1] 国家信息安全工程技术研究中心,国家信息安全基础设施研究中心.电子政务总体设计与技术实现[M].北京:电子工业出版社,2003.

[2] 祝江斌.中国电子政务建设存在的问题与对策研究[J].理论与实践,2007(6):102-104.

[3] 冯方回,蔡鹏程.SOA是电子政务的基础架构[J].软件世界,2007,6(20):79-81.

[4] MELL P,GRANCE T.Draft NIST Working Definition of Cloud Computing[R].NIST,2009.

第6篇：soa技术范文

最近，SOA在国内是一个热门话题。SOA确实是一个很好、很新的技术架构，但它并不能解决一切问题。SOA（面向服务的架构）强调的是“服务”，而“服务”是指具体的业务（功能）。使用SOA，业务人员可以直接通过业务语言进行思考和交流，可以（在不同的业务合作伙伴间或部门间）精确地描述业务目标。对于单个应用系统，SOA并不一定是最好的解决方案，但单个应用系统可以成为SOA中的一个重要的服务。

国内SOA发展与全球同步

实际上，欧美国家也还在探讨：SOA可以带来什么好处、可以解决什么问题、如何推广和使用SOA等问题。SOA在国外的实现还不是很完善，应用案例也不是很多。国内的SOA技术发展可以说与欧美国家同步，这对国内软件的发展是一个巨大的机遇。软件平台提供商和应用开发厂商可以站在SOA技术的最前沿，在市场上有更强的竞争力。

当前，用户需要更多地了解SOA，需要理解这一正在高速发展中的技术，也需要贡献出实际的应用需求。对于技术提供商（包括平台厂商和应用开发厂商），需要积极跟踪最新的技术，企业之间需要更多的交流和合作，同时需要更确切地了解用户需求，以尽早开发出稳定可靠的产品。

对于SOA的应用还有些问题需要关注。首先，应用好SOA需要以业务为驱动，是为了解决实际业务问题。其次，SOA是一个架构，它并没有确定具体的实现方案，对于SOA的应用模式可以有很多种，可以有不同的技术实现，如简单的应用Web Service技术，应用ESB（企业服务总线）技术，或是通过XML表单来进行互操作。

国内应用SOA的主要需求

中国用户对于SOA应用的需求是多种多样的。我们曾经成功部署过一个政府部门的电子政务项目。用户的总体需求是建设一个符合SOA的企业应用集成（EAI）平台，以满足该部门目前信息共享和将来业务扩展的需要。首先，本质上来说，用户要实现的是一个企业应用集成系统，而且其中数据集成的需求占了相当大的比例。另一方面，用户确实需要克服诸多难点：应用系统建设时间长短不一，网络主机环境各异，软件实现方式各异，各个系统在数据和流程冗余度边界无法明确，系统由不同的集成商设计、开发，各类关键数据归属问题有待确定等。显然，SOA在企业应用松耦合集成方面具有独有的优越性和先进性。但是，对于SOA能够为用户带来什么样的好处，以及具体如何实现SOA才能够发挥其优点，都还十分模糊。

从我们实施过的SOA应用案例来看，通过SOA解决传统的数据/信息整合问题，还是占第一位的需求。其次的需求是企业应用或应用服务的整合，大体属于传统EAI的范畴。目前较少有涉及复杂的服务编排、服务流程自动化的应用需求，这一块是较靠后的需求。

事实上，这与东方通提出的、企业信息系统实施的BOA（面向业务架构）技术架构提出的应用技术需求层次的分析是相一致的，从BOA的架构可以看出，SOA与传统技术（传统技术包括传统的消息中间件，交易中间件，应用服务器，EAI等）是很好的互补，共同完成对于用户应用系统的支撑。SOA可以建立一个总体框架，可以连接服务，可以将服务进行编排处理，但服务仍需要依靠传统技术来解决。

推进SOA应用的建议

首先，实施SOA不是一件容易的事情。要将SOA的理念落到实处，需要软件开发商凭借自己在该领域的知识和经验，与用户、伙伴共同努力去实现。其次，业务集成从来不是买来产品就万事大吉， 整合业务系统或者通过现有系统建立新的业务系统，这些都需要全面规划，需要有方法论加以指导，需要实施咨询顾问的工作。而且，国内项目的一些特有情况还会给实施增加更大的难度，比如需求不确定并且容易失去控制。在实际项目中，咨询服务在这些方面起到了不可替代的作用。

第7篇：soa技术范文

对于IT供应商,SOA是未来产品的发展方向,是不可能放弃的战场;对于用户来说,能够“随需应变”的SOA也许会带来与以往不同的应用模式,更加灵活、便利;对于国内的独立软件运营商来说,SOA也许是一个IT势力重新洗牌的机会。

最近几年的SOA市场一直很是活跃,IBM一直高举着SOA的大旗,除了着力推广理念和成功案例,还在国内构建了SOA生态系统,培育市场。不仅国际供应商在SOA市场表现活跃,国内的软件厂商也不甘落后。普元、东方通等都在以其中间件产品为SOA化着陆点。

值得注意的是,目前这个领域还没有出现垄断性的力量。从这个角度说,SOA是中国中间件软件乃至软件行业的一个市场机会,因为SOA很可能将推动软件产业一次新的结构性变化,将会涌现新的赢家、新的垄断势力、新的技术领袖,重新划分IT势力。 因此,中国工程院院士倪光南一直对SOA青睐有加,他曾经把SOA标准与构件技术结合比喻成一颗 “银弹”。

所以,在业内流传着一句话,SOA得标准者得天下。

标准之路

早在2005年11月,IBM、BEA、Oracle、SAP等公司就曾共同了SOA的技术规范:服务构件架构(SCA)和服务数据对象(SDO)。

2007年5月29日,随着倪光南院士、普元软件CEO刘亚东、OSOA专家Edward Cobb和Oracle公司SOA资深工程师Jeff Mischkinsky掀开SCA和SDO全球路演的幕布,SOA国际标准正式登陆中国。

对此,为SOA终于有了国际标准欢喜雀跃的有之,提出反对意见的也有不少。

有人说,SCA/SDO目前还只能称为规范而不是标准。SOA的技术架构没有标准,但SOA有相关技术标准。如果OASIS将SCA/SDO规范提交给ISO组织或国际电联,通过之后才能成为标准。

也有人说,其实SOA的架构没有标准。SCA不是SOA的标准,而是编程模式,在SOA环境中的一种新编程模式。对于把SCA说成SOA国际标准,这其中有很大的炒作成分。

而在不久前,在上海召开的“2009年SOA标准化国际研讨会”上,中国电子化标准研究所(CESI)了《中国SOA标准体系研究报告(征求意见稿)》。意味着SOA有了标准,而且这个标准中国占了先机。

CESI SOA领域负责人袁媛表示,《中国SOA标准体系研究报告(征求意见稿)》的,意味着中国在国际范围内率先规划出SOA标准体系,这是我国SOA标准化工作中的里程碑事件,奠定了SOA标准工作与产业、应用融合的基础。

该标准体系对SOA基本概念、SOA软件开发、SOA产品互操作、SOA工程项目实施、SOA质量与产品测评等方面有了全面、明确和体系化的标准项目规划,将为后续我国SOA国家标准的制定、测试验证环境建设、标准应用实施提供指导和依据,并推进我国信息化借力SOA思想和技术向纵深发展。同时,《中国SOA标准体系研究报告(征求意见稿)》也将作为我国对SOA国际标准工作的又一个重要贡献、提交至国际标准化组织ISO/IEC JTC1。

SOA有了中国标准

在《中国SOA标准体系研究报告(征求意见稿)》中,中国SOA标准体系包含SOA标准技术参考模型、SOA标准体系框图、SOA标准明细表三个核心部分。SOA标准技术参考模型从系统工程的角度抽象概括出SOA标准的技术框架,并从技术角度规定了SOA标准的涵盖范围及对象,使得技术人员及用户能直观了解具体SOA标准的实际应用场景和相互关系,是制定SOA标准体系的基础。而SOA标准体系框图及明细表则由五大类别的标准组成,分别是SOA基础标准,SOA体系结构与互操作标准,SOA工程标准,SOA质量与测评标准,SOA行业/领域应用标准。

其中,SOA总体标准是指SOA的总体性、框架性、基础性标准和规范。此部分标准的研制策略以自主制定为主,对应并支撑SOA技术参考模型的总体规划和要求。

SOA技术支撑与互操作标准是指SOA技术实现所需的关键技术规范和保证SOA产品互操作性的技术标准与规范总称,主要包括服务描述、注册及发现标准、服务管理标准、服务展现标准、SOA技术产品的接口规范等。此部分标准的研制策略是基于对国际或国外标准的梳理,结合国内产业需求来修改采纳国际标准或自主研制。对应并支撑SOA技术参考模型的“服务/资源”和“应用支撑服务”。

SOA工程标准是指支撑和确保SOA工程项目建设所需的实施过程指南、重要设计和评估方法以及相关管理的标准和规范。此部分标准的研制策略以自主制定为主,对应并支撑SOA技术参考模型的“SOA工程管理体系”

SOA质量与测评标准是指从技术角度对实现SOA应用的服务的质量以及SOA软件产品进行功能、性能、标准符合性及互操作性等方面的测试评价标准和规范。此部分标准的研制策略是基于对国际或国外标准的梳理、结合国内产业需求来修改采纳国际标准或自主研制。对应并支撑SOA技术参考模型的“SOA质量与测评体系”。

SOA行业/领域应用标准由典型行业或领域的SOA应用标准研究制定。如金融、电子政务、烟草、钢铁等行业或领域的SOA标准体系、标准应用指南等标准。此类别标准的研制工作将由我国各行业相关标准化委员会或行业协会来主导制定,对应并支撑SOA技术参考模型的“行业/领域应用”。

SOA标准体系是指SOA领域内多种类、多层次的SOA标准所组成的相互联系的有机整体。这套体系对统一用户与企业对SOA的理解,加快SOA项目实施的规范化,以及增强SOA系统间的互操作能力等方面具有重要意义,也被普遍认为是决定未来企业IT架构和方向和SOA相关企业及产业的核心因素。

促进良性发展

根据CESI 2008年的《SOA标准体系框架》研究报告统计,目前国际上相关标准协会及企业公布的SOA相关标准规范有84项,尚以Web Services标准为主、缺乏能支撑SOA工程和应用的标准,并且这些规范及标准仅在各个标准化协会或企业内形成初步的体系、不同组织的规范及标准间存在重复甚至冲突的现象。官方的国际标准组织JTC1在SOA标准方面的工作范围、工作组织方式正在讨论和确定之中。因此,国际上统一的SOA标准体系短时间内还不能成型。

袁媛表示,中国的SOA标准体系之所以能够较早的确立,和这一标准的研发方式以及参与各方的支持是分不开的。在国内标准的制定过程中,作为亚太唯一的SOA国际标准组织成员和国际SOA标准的制定方之一,中国公司普元软件扮演了特殊的作用。普元软件一方面与CESI积极分享了国际SOA标准的参与经验,一方面通过自身在国内的企业应用实践与国际标准的融合,成功实践了SOA标准落地的工作。

OSOA(开放SOA组织)专家,普元软件创始人之一黄柳青表示,中国SOA标准体系的确立,一方面使得中国的SOA厂商能够按照统一标准和规范开发产品,一方面使得用户在产品和方案选型时有了可衡量的准线,对国内SOA产业的良性发展有重要价值。

与SOA有关的标准化组织

1、结构化信息标准促进组织(OASIS):OASIS是一个非赢利的国际协会,致力于电子商务相关标准的制定和推广,也是目前制定Web服务标准最多的一个组织。

2、开放SOA合作组织(OSOA):OSOA是一个非正式的厂商联盟,使得各厂商能够共同开发一个语言中立的编程模型。该编程模型帮助企业软件开发人员能够最大限度地发挥SOA架构的特性和优势。

3、万维网联盟(W3C):W3C成立于1994年,主要负责制定Web相关标准和规范,比如HTML、CSS等。

4、Web服务互操作组织(WS-I):WS-I是一个开放的厂商联盟,鼓励任何对Web服务有兴趣的厂商加盟并贡献自己的力量。

第8篇：soa技术范文

“在全球企业整合的过程中，如何保持业务的敏捷性并让IT适应业务的变化已经成为了企业所必须要面对和解决的问题。”IBM大中华区副总裁及大中华区软件集团总经理Bete Demeke说，“IBM正在不断地加强对用户和整个SOA生态系统的支持能力，并帮助用户通过SOA打造新时期的竞争力。”

“智能SOA”

勾画“SOA演进图”

“‘智能SOA’是在整个SOA演进过程中所产生的一个结晶。”IBM软件集团大中华区市场总监刘秋美说，“事实上，SOA的理念是希望业务和IT能够一起向前推进，并以服务的方式呈现出来，而在这其中就包括了一个向前推进的概念。那么，要如何才能更好地把SOA向前推进呢？”

在了“SOA生命周期理论”、“SOA切入点理论”以及“SOA开发参考架构”之后，IBM又进一步地把SOA的概念升级到“智能SOA”，并很好地诠释了要如何推进SOA的问题。可以说，“智能SOA”是IBM推出的又一重要的SOA指导性方法论。在“智能SOA”的概念中，把实施SOA的阶段定义为“SOA演进图”，并把这个演进过程分为基础整合（Foundational）、跨部门扩展（Extend End- to-End）、企业转型（Transforming）和随需而动（Adapt Dynamically）四个阶段。

基础整合阶段是指企业在特定的部门或单一的业务流程中进行整合；跨部门扩展阶段是企业多个部门或者多条业务流程已经进行了整合，并能进行高效的合作; 处于企业转型阶段的企业已经实现了整个企业范围内的各组织的高效合作，企业已经全面迈向了全球整合企业，并能够利用IT使整个企业的投资回报呈现出战略性优势，从而全面实现业务模式的创新；随需而动阶段，这是SOA发展的最高阶段，此时的企业已经到达了一种无需IT介入就可进行重大组织和业务变革的阶段，企业已经成为可以自动响应市场因素的灵动企业，即所谓“IT无形化”。

当有记者问到企业究竟在什么时候开展SOA是最佳时机时，Bete Demeke的答案是任何时候。“当企业在业务上有驱动的时候，就是一个最好的SOA启动点。当企业或者业务要扩展时，比如企业要进入到一个新的市场，或者要推出新的产品等，可以说，业务的转型是最重要的驱动因素。”Bete Demeke说。

“很多人都存在一个误区，认为SOA只适合大型企业，事实上并不是这样。SOA适合处在不同发展阶段的企业，有的用户可能处在比较高的发展阶段，而有的用户可能起点比较低，但不同的发展阶段可以采用不同的应用模式，并可以把SOA的进程不断地向前推进，即使是在基础整合阶段的企业也可以通过‘SOA演进图’看到未来的SOA路线是怎么样的。”IBM中国开发中心SOA设计中心总经理沈丽琴说。

沈丽琴还介绍说，对于基础整合阶段的用户而言，企业应该选择针对性强、经过验证，且投资回报率高的项目切入SOA，这样可以解决企业不知何从入手的困惑；而对于跨部门扩展阶段的用户来说，企业要对重要的核心业务流程进行创新和优化，并实现更高的SOA投资回报。

“对于中高级发展阶段的SOA用户来说，尤其要关注如何保证流程的完整性这个问题，这主要包括了交易完整性、信息完整性和交互完整性三个方面，也就是IBM所说的SOA的三个关键点。”刘秋美强调说，“随着业务模块化的不断增多，企业可能会面临对IT系统以往的稳定性和安全性的牺牲。因此，企业在实施SOA进入高级阶段时，保证企业IT架构的‘正确与安全’非常关键。”

当然，‘智能SOA’理论还是着重强调了SOA绝对不是一个单纯的IT问题，企业必须从业务角度和IT角度两方面出发去分析自己的需求，根据自身现状和业务需求确定合适的SOA阶段性目标，并考虑到SOA发展的连续性，制定合适的SOA发展目标和战略，从而保证持续有效的投资回报。

建立SOA生态系统

“为了能够帮助SOA更好地落地，IBM进行了整个IT生态系统的建设，包括‘SOA合作伙伴联盟计划’、联手政府和教育界共同培养人才以及‘创新8’游戏落地中国等。”IBM大中华区策略与地区合作伙伴部总经理李永财介绍说。的确，SOA发展到今天，能否具备一个良好的生态体系已经成为了SOA能否在中国顺利落地的关键因素。

此次全新的“SOA合作伙伴联盟计划”是IBM为中国合作伙伴量身定制的技术与资源支持计划，该计划融合了IBM在SOA方面的全面支持，包括技术、销售、技能培训以及市场等多个方面。

据IBM大中华区副总裁渠道及市场部总经理钟郝仪介绍，大联盟的成员分为三个层次，基础成员、高级成员和顶级成员，今年IBM的目标是，基础成员达到100家，高级成员达到30家，顶级成员达到5家。

在今年6月份，浪潮成为了第一家顶级成员；8月份，IBM宣布和用友共同搭建SOA创新中心，用友成为了IBM SOA的第二家顶级成员。在此次大会上，IBM又宣布，中国五大外包软件公司之一的软通动力成为了第三家顶级成员，并且软通动力已经和IBM一起成功实施了两个SOA项目。

“我们现在最大的障碍是人才，拥有SOA的人才已经成为了把SOA推向成功的关键。”软通动力高级副总裁黄显勇说。李永财也强调说：“在成立SOA创新中心的同时，培养人才是SOA落地的关键，而因为培养人才需要时间，所以一定要早投入，IBM在2004年开始的‘百千万’计划和2006年开始的‘英才孵化’计划都是为了实现这个目标。”可以说，SOA的顺利落地需要充足的技术人才和丰富的实施经验作为保证。

今年，IBM也在积极和政府教育部门合作，与教育部联合设计了SOA课件，包括面向服务的应用整合实践、面向服务和开源技术的应用与开发、大型企业信息系统非功能架构基础、SOA和实用案例等为大学SOA教育做好准备。同时，IBM还联合西安交通大学共同投入中国教育部投资的专门研究基于IBM开源和SOA平台上的SOA解决方案的项目。此外，IBM还了针对广大软件开发人员的众多工具和资源，协助开发者进一步开发SOA相关技能。

链 接一

关于SOA的三大误区

SOA是一个以技术为支撑的商业战略，人们对SOA有三大错误认识。

误区1: SOA是新事物。事实上，SOA是技术发展的产物，而技术则源于对各种信息来源（不论是源代码还是平台）进行整合的需求。

误区2: SOA需要花钱购买。SOA是技术运用所支持的一种商业战略，而技术是由组织和合作伙伴及客户共同享有的。

误区3: SOA只适用于大型企业。SOA能帮助任何规模的企业更有效地参与竞争并节约时间、资金和资源，更大程度地利用传统应用上的现有投资。

链 接二

IBM围绕SOA完成的收购

2005年10月，IBM完成了对DataPower的收购，使其将软硬件技术融入到了一个“设备”，这有助于简化和加速SOA部署，并提高了其安全性。

2006年8月，IBM完成了对Webify的收购，使其获得了丰富的垂直行业经验，这有助于其创建针对医疗和保险行业的SOA。

2005年5月，IBM完成了对Gluecode的收购，这进一步地拓展了其开放源代码SOA战略。

2005年12月，IBM完成了对Bowstreet的收购，这为客户和合作伙伴提供了一款灵活的门户解决方案，该解决方案可提供面向服务的架构产品。

第9篇：soa技术范文

2007年各大国外软件巨头在中国竞相推广SOA，2008年由于软件领域涌现了众多新技术热点，SOA相形之下声势略减。然而对于由技术推广初期步入纵深发展阶段的SOA而言，2009年开始的未来三年是SOA生命发展周期的重要阶段，对于一整套彻底改变企业IT的核心基础架构、对于一种已广为企业IT主管所认知、认可的技术理念而言，应用落地是关键，SOA在各行业的规模化应用是未来三年关注的焦点。国外厂商是否有更为有效的推广策略？国内ISV能否认同并加入SOA提供商阵营？众多SI在多大程度和速度上愿意基于SOA在行业应用解决方案中进行增值开发？这些都将决定SOA应用在中国的普及，也是我们2009年以及未来三年关注的重点。

下面分析并展望2009年SOA拓展应用的几个焦点：

首先是SOA引导下的中间件和业务基础平台应用中的用户顾虑是当前的突出矛盾。2009年IBM、Oracle、SAP等要有针对性地克服几大用户顾虑来推广SOA架构的中间件和业务基础软件平台。用户在考虑几点主要问题：

1.除电信、金融行业以外,有相当数量的企业的业务需求和内部管理并未形成对SOA的IT系统架构的迫切需求，也就是说企业的业务运营和生产没有达到向用户提供随需应变的服务的水平，因此他们无需部署SOA的IT系统；

2.企业已有系统较为庞大而复杂，改变整体架构并不是轻而易举的，作出这样的决策需要多方面的努力和很大的决心及投入；

3.SOA技术、产品、标准都处于发展阶段，尚不成熟，不同厂商的解决方案也存在差异，这会令用户产生顾虑；

4.即使在新系统中采用SOA，用户也存在对SOA价值认可程度不足的问题。厂商的有效做法是引导加尝试应用，当SI和ISV在中间件和业务基础软件平台采购、应用、布署时都会提到SOA时，用户自然也会基于未来发展趋势的考虑开始有所倾向。

其次是国内中间件和业务基础软件平台提供商对SOA的推动态度。尽管当前SOA已成为以IBM、SAP、Oracle为代表的典型软件厂商共同关注、推广、建设应用的主题，但是就像十年前ERP市场的真正全面启动一样，SOA在中国的全面发展是要看何时国内软件提供商、乃至中间件以外的其他国内软硬件提供商都能够共同宣传推广SOA，并从产品应用的角度真正向用户进行营销，那时SOA在中国才迎来了市场的全面启动。但2008年除普元积极倡导SOA外，像东方通、金蝶这样的国内典型软件提供商对SOA没有值得提及的市场举措，观望态度依然明显。

第三是产品的标准化或是技术标准的统一。在推动SOA的过程中，几家典型提供商所采用的技术、标准、产品、甚至是方法论模型都不尽相同，这对于企业用户未来系统的应用发展将是不可想象的。中间件是为了屏蔽底层软件平台的异构、不同应用系统集成兼容的问题，SOA更是从根本的系统架构上来全面部署企业的IT系统，而不同提供商所采用的技术标准都不统一，那么用户即使应用了SOA，在后续发展中依然会面临种种问题，可以说这个问题不解决，谈SOA有点为时过早，而这需要的是所有提供商的共同努力，同时也需要企业用户从需求出发来要求提供商积极推动标准的制定和统一。或许Oracle与BEA的并购在2009年能为融合统一带来契机。（文/曹宇杰）

影响力指数：8

创新力指数：7