基于SOA服务架构的ORACLE接口集成方案的研究与设计
基于SOA的电子政务遗留系统整合方案
３．３定义并抽取服务
删、改、查。这些元服务又可以经过组合内聚性更强的服务，比如公务员信息录入等。在完 成了逻辑上对服务的分类和定义后，就可以对服务进行抽取工作了。在抽取服务这一过程中， 要涉及到许多代码的操作，因此也被称为“遗留代码的打捞”。这实际上是最大限度地从遗留 应用程序“打捞”代码（以便重用）。整个“打捞”过程分为两步：首先，要从现有遗留代码 库中收集代码，必须找到这些代码并确定其具有重要价值。在确认代码的价值后还需要标识 语句，然后就确定各个语句在哪个代码单元（程序、段落等）中。最后仅从原始位置复制这 些单元，并带上其引用的变量。这一过程通常被称为代码剥离（ｃｏｄｅ ｓｔｒｉｐｐｉｎｇ）；最后是提取 代码，并将其重新封装为具有自己接口的独立模块的过程。
２
电子政务遗留系统现状及其解决方案
我国的电子政务建设从世纪年代末开始起步，经历了政府办公自动化、“三金”工程、政
・基金项目：国家自然科学基金资助项目（Ｎｏ．７０８０２００８），北京理工大学基础研究基金资助项目（Ｎｏ．２００７０８４２０１４）． 作者简介：陆可（１９８３一）．男，硕士。研究方向：信息系统的理论和方法。 尹秋菊（１９７３一）．女，副教授。博士。研究方向：电子商务、信息系统理论与方法、客户关系管理。
在ＳＢＥＧＡ中，一些特定的操作可以抽取为最基本的服务一元服务，比如最基本的增、
３．４为服务封装接口
封装经过抽取所获得的代码。封装流程的目的是为了得到从遗留代码中提取的组件的 Ｗｅｂ服务描述语言（Ｗｅｂ
Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ
Ｌａｎｇｕａｇｅ，ＷＳＤＬ）接口。此方法要求将每个
条目转换为方法，将每个参数转换为ＸＭＬ数据元素。此方法将其参数和结果作为引用添加 到数据元素描述中。数据结构成为了包含一个或多个子元素的复杂元素。方法和参数都构建 到ＸＭＬ模式中。一项服务既可能是服务请求者，也可能是服务的提供者。这是由ＳＯＡ的 松耦合的特点所决定的。因此，在对服务进行接口封装时，不仅应该封装其作为提供者的接 口，也应该封装其作为服务请求者的接口。
soa设计思路
soa设计思路（原创版）目录1.SOA 设计思路的概念和背景2.SOA 设计思路的核心原则3.SOA 设计思路的具体实践方法4.SOA 设计思路的优势和应用案例正文1.SOA 设计思路的概念和背景SOA（Service Oriented Architecture，面向服务的架构）设计思路是一种软件设计模式，旨在将应用程序拆分为相互独立的服务，以便这些服务可以在不同的系统之间进行交互和共享。
这种设计模式源于 20 世纪90 年代，随着互联网的普及和企业对 IT 系统灵活性和可扩展性的需求不断提高，SOA 逐渐成为一种广泛应用的软件架构方法。
2.SOA 设计思路的核心原则SOA 设计思路的核心原则包括：(1) 服务独立性：SOA 设计要求将应用程序拆分为相互独立的服务，这些服务之间应尽可能减少依赖关系，从而提高系统的灵活性和可扩展性。
(2) 服务抽象：每个服务都应该提供一个清晰的接口，使用户或其他服务能够方便地调用。
服务接口应简单明了，易于理解和使用。
(3) 服务可重用：SOA 设计鼓励重复使用现有的服务，以降低开发成本和提高开发效率。
同时，可重用的服务有助于提高系统的稳定性和可维护性。
(4) 服务松耦合：SOA 设计要求服务之间的接口应保持松耦合，即使服务的内部实现发生变化，也不会影响其他服务的正常运行。
3.SOA 设计思路的具体实践方法(1) 服务识别：首先，需要识别企业中的各种业务功能和服务，为后续服务化提供基础。
(2) 服务定义：在识别到服务后，需要对服务进行详细定义，包括服务的输入、输出、功能等。
(3) 服务实现：根据服务定义，实现具体的服务功能。
(4) 服务注册与发现：将实现的服务注册到服务注册中心，方便其他服务发现和调用。
(5) 服务治理：建立一套服务治理机制，对服务的生命周期进行管理，包括服务的创建、启动、停止等。
4.SOA 设计思路的优势和应用案例SOA 设计思路的优势包括：(1) 提高系统灵活性和可扩展性：通过拆分应用程序为独立的服务，可以降低系统间的耦合度，方便进行修改和扩展。
Oracle Service Bus服务总线
轻松转换到企业 SOA Oracle Service Bus 特性和优势
z 采用无代码服务集成，可更快集成、快速推向市场，并提高开
配置驱动的服务与智能内容和 发人员的效率
基于身份的路由集成
z 根据市场规则的变化，通过快速配置路由规则来迅速响应市场需求
基于 XQuery 或 XSLT 的动态 消 息 转 换 （ 支 持 XML 和 非 z
Oracle Service Bus 整体构建为支持 SOA 的基础架构，加强了易用性和互 操作性。它仍然全面支持 SOA、Java 2 平台企业版 (J2EE) 和 J2EE 连 接器体系结构标准。通过 WS-Reliable 消息传递 (WS-RM) 以及最新的 WS-Security 更新，Oracle Service Bus 增强了此类行业标准支持。
相关产品 z Oracle SOA 套件 z Oracle 事件驱动的体系结构套件 z Oracle 数据集成套件 z Oracle 的 SOA 治理解决方案
平台和要求 Oracle Service Bus 可在以下平台上运行：
平台和要求 支持的标准 协议和连接 平台（OS 版） 数据库 浏览器
z SOAP 1.1、SOAP 1.2、WSDL 1.1 和针对 SOAP 1.2 的 WSDL 1.1 绑定扩展
主要优势
Oracle SOA 套件实现了 SOA 所承诺的可见性、灵活性和速 度。每一个组件都使用了同类最 佳的工具，提供了行业领先的功 能。紧密集成的综合套件降低了 总拥有成本。 Oracle SOA 套件的“热插拔” 体系结构支持将其无缝集成到现 有的 IT 环境中。因为可逐步采 用 Oracle SOA 套件中同类最 佳的组件，所以它们可用于解决 已发现的业务问题，并扩展到企 业部署。
SOA实施方法论及流程介绍
SOA实施方法论及流程介绍SOA（Service-Oriented Architecture）是一种软件架构设计模式，可以将应用程序的功能划分为可重用的服务，服务之间通过标准化的接口和协议进行通信，从而实现松散耦合和复用性。
SOA的实施需要遵循一定的方法论和流程，下面将对其进行介绍。
1.准备阶段：在准备阶段，需要明确定义业务目标、需求和范围，并确定可行性分析。
这包括以下几个步骤：a.定义业务目标：明确业务需求和期望的业务效益。
b.定义需求和范围：从业务需求出发，确定系统功能和服务的需求，并划定实施的范围。
c.进行可行性分析：评估技术和资源的可行性，确定是否可以成功实施SOA。
2.分析和设计阶段：在这个阶段，需要对系统进行详细的分析和设计。
这包括以下步骤：a.建模和分析：通过业务流程、数据流和用例图等模型，对系统进行建模和分析，确定服务的边界和功能。
b.设计服务接口：根据需求和分析结果，设计服务的接口和协议。
c.设计服务实现：确定服务的实现方式，可以选择开发新的服务，或者重用现有的服务组件。
d.设计服务治理策略：确定服务的治理策略，包括服务注册、发现、安全、监控和管理等方面。
3.开发和集成阶段：在这个阶段，根据设计来开发和集成服务。
具体步骤如下：a. 开发服务：根据接口设计，实现服务的代码。
这可以是使用不同的编程语言和技术来完成，例如Java、C#、Web服务和RESTful服务等等。
b.集成服务：将开发好的服务进行集成，确保服务之间可以互相调用和协作。
c.测试服务：对开发和集成的服务进行测试，包括功能测试、性能测试和安全测试等。
4.部署和管理阶段：在部署和管理阶段，将开发好的服务部署到生产环境，并进行服务的管理和维护。
具体步骤如下：a.部署服务：将开发好的服务部署到服务器上，并进行配置和参数的设定。
b.管理服务：监控服务的运行情况，包括资源利用率、性能指标和错误日志等，及时处理异常情况。
c.维护服务：定期对服务进行维护，包括升级和修复。
基于SOA技术的BOM集成研究
进行定义 ，使得构建 在这样 的系统 中的服务可 以使用 统一 和 标准 的方式 进行通信 。简单来讲 ，Ｓ Ａ能够 以程序化 的 、可 Ｏ
访 问软件 服务 的形式 公开业务 功能 ，以使 其他 应用程 序可 以
缩 短软件 的开发及实施 周期 ，一 种面 向服 务 的体 系结构 Ｓ Ａ Ｏ （ ｒｉｅＯ ｅｔｄＡ ｃｉ ｃ ｒ）的软件设计 方法被提 了出来 。相 Ｓ ｖｃ ｒ ｎｅ ｒｈｔ ｔ ｅ ｅ ｉ ｅｕ
对 于面 向对 象和基 于构件 的软 件复用方法 ，Ｓ Ａ提供 了构建 Ｏ
松散耦合 的分布式 系统的方法 ，能够达 到更高 的复用度 和更ห้องสมุดไป่ตู้ 好 的扩充性 。
电脑 编 程 技 巧 与维 护
基于 Ｓ Ａ技 术的 Ｂ Ｍ集成研 究 Ｏ Ｏ
梁 明
（ 中国航空无线 电电子研究所信 息中心，上海 ２ ０ ３） ０ ２ ３
摘 要 ：Ｂ Ｍ数据 贯穿于产品设计 、工 艺和制 造的全过程 。针对现 有 Ｐ Ｍ 与 Ｃ Ｐ Ｏ Ｄ Ａ Ｐ系统 ，采 用基 于 Ｓ Ａ技 术的集 Ｏ
SAP与Oracle的比较(完整版)
目录1.公司情况 (2)1.1公司介绍 (2)1.2市场表现 (3)1.3公司文化及管理理念 (5)1.4在中国的情况 (5)2.行业应用 (7)2.1市场占有率 (7)2.2解决方案（解决方案图） (8)3.功能对比 (10)3.1财务 (10)3.1.1产品成熟度 (10)3.1.2通用产品功能比较 (11)3.2EAM-企业资产管理 (19)3.2.1产品成熟度 (19)3.2.2通用产品功能比较 (20)3.3工程项目 (26)3.4燃料管理 (33)3.5人力资源 (35)3.6技术 (43)4.生态环境 (44)4.1实施资源 (44)4.2客户交流活动 (45)5.总结 (45)6.国内电力行业案例 (45)1.公司情况1.1公司介绍SAP是全球第一大企业应用软件供应商，其产品在企业管理中得到广泛和深入应用，从1972年在德国成立以来，一直专注于企业管理软件的开发和应用。
Oracle第一大数据库软件公司，全球第二大独立软件公司，从上世纪90年代后期开始涉足企业应用软件领域。
基本情况对比如下：因进行了大量收购，目前Oracle的正面临产品整合的技术难关，市场普遍认为要将这些软件进行技术整合具有很高的难度，甚至是不可能完成的。
计划在2009年发布整合后第一代产品，市场猜测目前计划被延误。
Oracle公司正集中大部分的技术研发力量进行产品整合工作，因此在新产品功能开发上的研发投入相对较少。
SAP公司目前的研发重点是基于以前的ERP功能，在新的以服务为导向的技术架构下（SOA），开发更加完善和友好，更加灵活的下一代ERP产品，并已经有部分产品发布。
从以上情况，可以看到：1、SAP是一家专注于企业应用软件的公司，Oracle是以数据库管理软件为主业的公司，企业应用软件在Oracle业务和研发投入上占到近20%的比率。
在人员、研发投入、收入等方面，SAP在企业应用软件上都大约是Oracle的4到5倍；2、从财务状况、各方面稳定性指标看，SAP表现似乎更稳定；3、Oracle通过持续不断的并购来维持营业收入的增长，在产品整合与研发上存在一定的不确定性。
基于SOA的城市地理信息共享研究
基于SOA的城市地理信息共享研究摘要:针对传统信息共享模式中存在的诸多问题,基于SOA共享模式,采用数据分布式存储和发布,服务集中管理,数据通过服务共享的方式来实现城市空间信息的共享。
关键词:SOA 空间地理信息分布式共享随着全球信息化建设的发展和Internet技术突飞猛进,传统GIS正向着信息共享的网络GIS发展。
由于政府和公众GIS数据的多样性和复杂性,目前政府、单位、企业、个人所建立的空间、非空间数据库以及应用系统之间彼此封闭、孤立,没有统一的标准,各自采用不同的数据格式、数据存储和数据处理方法,造成了相互之间信息无法进行共享。
目前我国对空间数据主要还是采用数据拷贝的方式进行空间数据共享,信息共享通常以政府部门为主导,其信息共享多采用集中共享模式、集中和分散相结合模式、分布式存储与集中共享模式、分散共享模式来建设[1]。
其中存在诸多问题。
1 数据共享中存在的问题1.1 重复建设空间信息资源的建设分布在各个部门及相关单位,由于缺乏统一的规划和标准,没有对城市信息进行整合的基石,即空间基础信息,各个部门各自为政,业务系统条块分割、自成体系,不能很好的实现互联互通和信息的交流与共享,造成大量的重复建设和资源浪费。
1.2 多源、异构空间数据存储格式的多样性,各部门的空间数据以不同的空间参考、不同的格式存放,给共享交换带来障碍。
目前元数据标准制定与数据库建设还是以部门为单位,例如数据库,各部门使用的数据库最多为MSSQLServer和Oracle,两者占了76％,其他种类的数据库系统占24％。
异构、异地数据库已成为数据实现无缝共享、交互与集成的最大障碍之一。
业务部门的信息化建设由各个部门设计并实施,没有从业务关联以及整体角度考虑与其它系统的信息交流与信息共享。
1.3 数据现时性不高经济的发展、城市建设与城市改造使得城市的空间信息变化非常迅速,但与之对应的数据更新却相对滞后,甚至有的数据根本就没有更新。
详谈SOA及其在企业电子商务中的应用情况
详谈SOA及其在企业电子商务中的应用情况一、SOA的概念SOA(Service-Oriented Architecture)即面向服务架构，最早作为一种软件系统的开发方法，现在更多的作为一种软件架构，或是企业信息化建设和实现电子商务的一种方式。
SOA 可以理解为一个组件模型，它将不同架构的软件提供的服务联系起来，类似于粘合剂的作用，可以把企业不同的系统数据相融合。
由于系统平台、架构、技术和版本等因素，不是所有的信息系统都可以实现资源共享。
很多企业会出现不同种类的操作系统、应用软件、系统软件和应用基础结构相互交织，或者同一公司拥有开发于不同时期、架构不同平台和技术上的诸多软件等情况。
一些已投入使用多年的信息服务用来处理当前的业务，当企业业务增长后，从头开发一个新的环境或者重新实施一个新的ERP项目几乎是不可能的。
如何才能让企业对业务的变化做出快速的反应，利用对现有的应用程序和架构的投资来解决新的业务需求，应对突发的业务变化，为客户、合作伙伴及供应商提供新的互动渠道，并呈现一个可以支持有机业务的构架，无疑是给企业提出的一个巨大挑战。
SOA正是在这种挑战下脱颖而出的。
二、SOA的特性SOA可以灵活的为服务提供者与消费者选择实现技术和部署位置。
只要服务接口保持稳定，抽象出来的接口就能让提供者和消费者独立演变。
所以基于SOA的信息化系统可以提供与业务更贴合的信息化服务，更便利的解决跨行业、跨部门的信息资源互联互通，推动重要信息资源的开发利用，并可以支撑和促进各行业相关的业务变革和发展。
事实，实现接口的稳定性是SOA面临的最大挑战。
因为业务服务接口的作用不只是确定了系统的边界。
业务服务对业务流程的一部分进行了封装，建立了被封装部分和其余部分之间的接口。
以“销售订单管理服务”为例，它封装了业务流程中创建和维护销售订单的部分。
由此看出，在定义业务服务时，既是为系统也是为业务流程搭建架构。
可见信息与业务流程的运转息息相关，即便最简单的服务也管理着一些信息。
基于SOA的高校CRP系统研究与设计
基于SOA的高校CRP系统研究与设计摘要：针对高校信息化建设中的数据共享和交换、资源的集成与整合以及应用系统的统一访问等问题，基于SOA集成模式和ERP集成理念，提出了一个高校资源规划（CRP）模型，并设计了其体系结构。
研究了采用ICE中间件实现CRP模型中用户统一访问平台的方法，以及基于XML的异构数据交换和信息分类编码平台的实现方法。
关键词：数字校园；SOA；CRP；ICE中间件；XML标准格式0 引言随着信息技术的迅猛发展，“数字化校园”时代已然来临。
针对校园信息化进程中出现的诸如教学资源杂乱和无序、可集成性差、信息孤岛严重、数据无法共享和交换、各类应用系统缺乏统一入口、人性化不够等问题，国内外学者对此进行了探索，并提出了一些解决方案。
如张晞等对高等院校CRP系统的基本特点、机制和功能进行了一定的探索；蒋东兴等提出了大学资源计划（URP）的“1+N+1”模型，即1个基础平台、N个应用以及1个门户；季一木等结合SOA 理念，对该模型进行扩展后，提出了CRP的“1+1+N+1+1+N”模型，即1个统一访问接口、N个应用子系统、1个基础支持平台、1个异构数据适配器以及N个不同数据库；张杰宏等提出了“1+1+N+1+1+N”的URP模型，即1个平台、N个应用系统、N种不同权限的用户以及1个公共门户；彭炜实现了URP模式下的统一身份认证系统等。
上述研究为校园信息化建设奠定了基础，拓宽了思路。
然而，针对高等院校信息化建设的相关研究却比较少见。
高等院校的“数字化校园”建设有其独特性，本文以广东科技技术职业学院为研究对象，以校园内部一体化管理、校内外一体化应用等理念构建一个集管理、交流、互动为一体化的CRP平台，通过该平台覆盖全院所有应用系统，为学院全体师生提供跨部门、跨系统的信息共享和交换服务，基于校内、校外网络环境实现全院决策科学化、办公现代化和信息资源网络化等目标。
1 CRP平台设计1.1 信息集成基本框架本文基于SOA（Service Oriented Architecture）集成模式，参考已有研究，提出如图1的三层信息集成框架。
BEA+SOA实_
SOA实施策略与参 实施策略与参 考架构. | 1内容BEA SOA 实施策略 BEA SOA 参考架构信息与存取服务 共享业务服务 表示服务 复合应用 基础架构服务| 2SOA的巨大威力“面向服务的架构 面向服务的架构(SOA)是一种 战略，能将企业应用中的分散功能 是一种IT战略 面向服务的架构 是一种 战略， 组织成基于标准的互操作服务； 部门可快速地组合和重用这些服务 组织成基于标准的互操作服务；IT部门可快速地组合和重用这些服务 以满足业务需求 业务需求。
，以满足业务需求。
”销售工程 B2E B2C支持合作伙 合作伙伴客户共享服务管理和安全 共享应用和业务服务 基于标准的互通性企业应用 业应用| 3数据库 数据库通用服务 通用服务BEA SOA “域模型”方法论SOA化的业务战略 业务流程架构©构建成本 业务和IT优势 主要衡量指标业务策略 和流程参考架构 可管理性/可用性 扩展性成本和效益架构安全性组织设计 资金 技能 角色和职责 标准 运营流程和工具 变革管理组织和管理 项目和应用服务组件基础架构服务 信息和访问服务 共享的业务服务 表示服务 复合应用现有应用 建设中的主要项目 基础架构建规划 | 4BEA SOA分步实施策略SOA 价值增加1数据共享 服务传统的应用开 发与集成系统间数据共享 时间| 5第一步： 向企业内部和外部系统 开放企业信息服务1数据共享服务 例: 产品发货状态外部服务消费者 内部服务消费者客户 A 采购系统Firewall客户 B 采购系统销售门户客服Netcentric Client Server MainframeGet_Shipment_ Status Service一个单一的、 一个单一的、全局的服务可 以向多个基于不同平台的消 费系统提供信息Shipping – ERP| 6BEA SOA分步实施策略SOA 价值增加2基于服务 的门户1数据共享 服务整理数据和业务服务 提供360度展示视图传统的应用开 发与集成系统间数据共享 时间| 7第二步：建立360度信息展示视图2基于服务的门户 例: 销售门户Firewall360 Sales PortalGet_Customer _News在组合应用中整理巩固数据 和业务服务， 和业务服务，为用户提供 360度信息展示视图 度信息展示视图Get_Order_StatusGet_Support_Call_ HistoryTrack_QuotaGet_LeadsERPCall CenterSales Force Automation Legacy System Client ServerMarketing Automation| 8MainframeBEA SOA分步实施策略SOA 价值增加3 基于服务的业务流程2基于服务 的门户有效结合服务 实现业务流程1数据共享 服务整理数据和业务服务 提供360度展示视图传统的应用开 发与集成系统间数据共享 时间| 9第三步： 有效结合服务，实现业务流程3基于服务的业务流程例: 收费流程Verify Product Shipment Status Verify Project Milestone Status Map Against Contract Terms Validate Status with CustomerBusiness Process Service OrchestrationGet_Shipment_ StatusGet Services Burn RateCreate InvoiceGet_Contract_ Burn_Rate Get_Milestone _Status Get_Terms Get_Customer _Validation Create_ InvoiceShipping ERPProfessional Services AutomationContract ManagementCustomer PortalBilling| 10BEA SOA 分步实施策略传统的应用开发与集成数据共享服务基于服务的门户基于服务的业务流程123SOA 价值增加时间系统间数据共享整理数据和业务服务提供360度展示视图有效结合服务实现业务流程•快速•高效•定制灵活的IT 业务•SOA 自我评估•SOA 探索•SOA 概念和技术培训•SOA 深入评估•SOA 实现计划•SOA 技能差距分析•SOA 架构设计SOA 实施SOA规划与设计SOA 探索•SOA 基本服务实施•SOA 解决方案确认基准学习和探索沿着关键里程碑确定路线图了解并填补技能差距确定最终状态实施第一个项目建立参考架构获得业务与IT的回报注重实效的3-5年SOA路线图规划BEA SOA实施策略BEA SOA参考架构信息存取服务共享业务服务表示服务复合应用基础架构服务日程基于服务代码/组件级的功能共享证明是不成功的，这样的共享经常造成功能的重复基于标准传统的IT实现使用的IT技术泛滥，在交换信息时导致有问题注重企业级传统的IT实现使得流程和信息不透明，同时在企业内跨部门的流程和信息管理非常困难注重业务在传统的IT实现方式下，业务用户经常需要多个应用才能完成日常业务活动基于服务的实现方式通过标准对功能的封装，使得共享和交互更加容易基于标准的SOA支持重用和真正的平台无关性基于服务的企业架构加上适当增强的管理提供企业级所需要的服务支撑平台基于服务的方法使得服务组件能够重用、增加业务与IT服务相互支撑SOA 特点层次化的方式表示服务共享业务服务信息与访问服务服务管理服务总线公用服务服务基础架构层非功能性需求复合应用标准开发工具配置管理系统管理网络管理供应业务活动监控目录合作伙伴基础架构服务层公共服务(Common Service)服务总线(Service Bus)服务管理(Service Management)信息与访问服务层共享业务服务层表示服务层复合应用层SOA 层次化结构信息与访问服务基础架构服务层信息与访问服务企业信息系统数据与中间件Payroll DatabasesMiddleWare InteractionsHRMS Performance Expense ERP Content服务管理服务总线公用服务非功能性需求标准开发工具配置管理系统管理网络管理供应业务活动监控目录合作伙伴提供以下系统信息的标准存取方式:企业信息数据信息系统、定制软件和应用面向消息的中间件企业数据的统一表现实体实体可以在全企业范围内得到一致性的使用共享信息数据的完整视图，如: 客户, 员工, 订单,等等信息接入的关键:1.封装(资源接入接口)2.数据集成（数据的完整视图获取）3.标准(应用接口标准)J2CA适配器Web 服务信息与访问服务角色与职责信息与访问服务基础架构服务层信息与访问服务数据库适配器应用适配器数据集成消息适配器企业信息系统数据与中间件Payroll DatabasesMiddleWareInteractionsHRMS PerformanceExpense ERP Content非功能性需求标准开发工具配置管理系统管理网络管理供应业务活动监控目录合作伙伴服务管理服务总线公用服务提供服务给其他层服务调用或用户应用直接使用以适当颗粒度的组织的上层服务能够通过一定的接口合约对这层的服务进行访问公布的接口应该基于一类资源接口不应该专门为消费者需求而设计鼓励服务在不同应用中的重用信息与访问服务共享业务服务共享业务服务信息和访问服务服务管理服务总线公用服务服务基础架构层非功能性需求标准开发工具配置管理系统管理网络管理供应业务活动监控目录合作伙伴企业信息系统Payroll HRMS Performance Expense ERP Content共享业务服务角色与职责提供核心、独立的业务功能服务不需要与遗留信息系统有直接关联的服务核心业务功能的梳理和整合核心业务功能划分合理化－成为可共享的业务功能利用和建于信息存取服务之上共享业务服务共享业务服务信息和访问服务服务管理服务总线公用服务服务基础架构层非功能性需求标准开发工具配置管理系统管理网络管理供应业务活动监控目录合作伙伴企业信息系统数据与中间件Payroll DatabasesMiddleWare InteractionsHRMS Performance Expense ERP Content流程服务复合服务共享业务服务这个层服务的主要目的是协调其他服务，为上层应用提供基础。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ｌ０ ～ ９
２０ 年 １ ０８ ２月 第 １ ２期
Ｓ Ａ分层概念模型如上 图，其中 ： Ｏ 应用组件服务层 ：为参与企业 系统 整合的各 应用 ，在 应用中识别出提供服务 的组件和 Ａ Ｉ 口。 Ｐ接 服务仓库层 ：这些 组件和接 口可 以封装 为服 务 ，这 些 服务 可以发现 和管理 ，并进行 安全控制 。这些 服务就 是封 装的原子服务 ，实 现各应用 的基础功能。 活动承载层 ：通过 流程 ，数据转换 和路 由将 服务仓 库 层提供 的原子服务 进行整合组 装 ，形成 复合 型服务 。另外
还可以对 流程 和路 由进行监控和控制 。
表单 定 制 工 具
企业对象层 ：定义 企业级公 用的业务 对象 ，和应 用级 业务对象 的转换通过 Ｂ （ ｕｉ ｓ Ｃ ｎｅｔ ）实现。 Ｃ Ｂ ｓ ｅｓ ｏｎｃ ｒ ｎ ｏ
行业参考模型层 ：抽象 的非常 “ 高”层 次的流程 汇总 ，
Ｓ Ａ的实现模型如图 ，应用组件服务层应用开发工具 ， Ｏ 就是各系统间的复用 。 行服务安全 ，服务管理和服务连接。
按照 系统 服务框 架 ，开发 出各 服务组件 ，服务组 件的 目的
圆圆圆团 圆 圆 圆
供新的业务服务上 。
３ 应 用 Ｏ ａｌ Ｓ ｒｃ ｅ的 ＯＡ的实现
济效益，一直备受国内外企业管理者的高度关注和推崇。而在 近两年 。出现 了一种技术 架构被誉 为下 一代 ｗｅ ｂ服务 的基础 架构 ，它就是 Ｓ Ａ （ｅｖｅ—ｏｉ ｔ ｃｉｃ ｒ，面向服务架构） Ｏ Ｏ Ｓｒｉ ｃ ｒ ｎ ｄａ ｈｔ ｔｅ ｅ ｅ ｒ ｅｕ 。Ｓ Ａ是一个 Ｊ Ｔ战略 ，它将企业应用 中的分散
［ ｙｗ ｒｓ Ｓ Ａ ｅｒｃ ｒ ｉｃ ｒ；Ｏ Ａ Ｌ Ｋｅ ｏｄ ］ Ｏ ；ｓ ｖ ｅ ｃ ｔ ｔ ｅ Ｒ Ｃ Ｅ ｉ ａ ｈｅｕ
情 ＯＡ分 层概念模 型 报 １ Ｓ 纵 横
图１ Ｏ Ｓ Ａ分层概念模型
收 稿 日期 ：２Ｏ —１ —２ Ｏ８ ０ ２
作者简介 ：李晓堂 （９８一） １７ ，女 ，讲师，研究方 向：软件工程技术 ，网络应用技术 。发表论文数篇。
２０ 年 ｌ ０８ ２月 第 １ 期 ２
基 于 Ｓ Ａ服 务架 构 的 Ｏ Ａ Ｌ Ｏ Ｒ Ｃ Ｅ接 口 集成 方案 的研 究 与设 计
李 晓堂
（ 深圳信息职业技术学院计算机应用系，广东 深圳 ５８２ ） １０９
［ 摘 要］ Ｗｅ 服务作为炙手可热的技术，如何应用到企业的 ｆ ｂ ｒ系统和商业流程之 中、并给企业带来直接的经
Ｒｅ ｅ ｃ ｎ ｓｇ ｆＯｒ ｃｅＩ ｔｒａ ｅＩ ｔｇ ａ ｅ ｓａｒ ｈ ａ ｄ Ｄｅ ｉｎ ｏ ａ ｌ ｎ ｅ ｆｃ ｎ ｅ ｒ ｔｄ Ｐｌｎ Ｂａ ｅ ｎ Ｓ ａ ｓ ｄ ｏ ＯＡ ｅ ｖｃ ｃ ｉｅ ｔ ｒ Ｓ ｒ ｉｅＡｒ ｈｔｃａ ｅ
Ｌ ａ ｍｎ ｉＸｉｏ ｇ
概念性流程。
表示层 ：前 端展示 的应 用 ，通 过 ｐｒ ｌ 对数 据进 行 ｏａ 等 ｔ
展示 。
２ Ｓ Ａ实现模 型 Ｏ
ｗＢ 端 架 ［ Ｅ前 框 夏 （ ｅ－ 性） ｗｂｔ ２特 匝 刃 ，
ＢＰ Ｍ
匪囹 巫 匦翊
臣圃 医幽
管 理平 台
流程 设 计工 具
匝圃 器 匝囫
［ ｂ ￣ｅ］ Ｓ Ａ ｉ ａ ｃｃｔ ｔ ｒ ｎ ｅ ｔ ｉ ｅ ｉ ｎｔｎ ｆｈ ｎ ｒｒｅａｐｃｔｎｔ ８ ｒ Ａｓ ｔ ａ Ｏ ｎＩ ｔ ｔ ａ ｏ ａｉ ｓｈ ｄｓ ｒｏ ｆ ｃｏｓｏ ｅｅｔｐ ｓ ｐｌａｏ ｂ ｅ ｓ Ｔ ａｉ ｈ ｇ ｚ ｅ ｐ ｓ ｎ ｕ ｉ ｔ ｅ ｉ ｉｉ ｏ ａ ｄ
（ ｅａｔ ｎ ｏ Ｃ ｍ ｕ ｒ ｐ ｌａ ｏ ，Ｓ ｅｚｅ ｓｔ ｅ ｆｎ ｒａ ｏ ｅｈｏ ｇ ，Ｓ ｅｚｅ ０ ９ ｈ ａ Ｄ ｐｒ ｔ ｆ ｏ ｐ ｔ ｐｉ ｔｎ ｈｎｈｎＩ ｔ ｔ ｏ ｆ ｍ ｔｎＴｃｎｌ ｙ ｈｎｈｎ５ ２ ，Ｃ ｉ ） ｍｅ ｅＡ ｃｉ ｎ ｉ Ｉｏ ｉ ｕ ｏ １ ８ ｎ
ｓｒｉｅ ｂ ｓ ｄ Ｏ ｅ ｓ ｎ ａ ｄ ｈｅ ｓ ｒｉｅ ｃｎ ｂ ｓｅ ｌｄ ａ ｄ ｒｕ ｅ ｒｍｐ ｙ ｔ ｅ ｖｃ ａｅ ｎ ｔ ｔ ｄ ｒ ，ｔ ｖ ａ ｅａ ｓｍｂｅ ｎ ｅ ｓｄ ｐ ｏ ｔ ｏ ｓ ｈ ａ ｅ ｃ ｌ ｔｅ ｏ ｒ ｔ ｎ ｒｑ ｉ ｍｅ ｔ ｈ ｐ ａ ｏ ｅ ｕｒ ｎ ． ｅ ｉ ｅ Ｔ ｉ ａ ｅ ｉ ｅ ｔ Ｏ ｓｅ ｎ ｅ ｔ ｎ ｍｏ ｅ ａ ｄ ａ ｖ ｎ ｅ Ｏ ｓｔｃ ｎ ｌｇ ｅ ｌ ａ ｏ ｙ ａ ｐｙｎ Ａ Ｌ ｈｓｐ ｐ ｒａｍ ｄ ａ Ａ’ ｏ ｃ ｐ ｏ ｄ ｌ Ｓ ｉ ｄ ａ ｃ ｄ Ｓ Ａ’ ｅ ｈ ｏｏ ｙ ｒａ ｚｔ ｎ ｂ ｐ ｌ ｇＯＲ Ｃ Ｅ． ｎ ｉｉ ｉ
的功能组织成可以共享的基 于标准的服务 ，这些服 务能够迅 速地被 组合 和重用，以满足 业务 的需求。本文针对 Ｓ Ａ Ｏ
分 层 概 念模 型 ，提 出 了应 用 Ｏａｌ Ｓ Ａ 的技 术 实现 。 ｒ ｅ的 Ｏ ｃ
［ 关键词 ］ Ｓ Ａ；服务架构 ；Ｏ Ａ Ｌ Ｏ ＲＣＥ
（ 中图分类号］Ｔ ３９ ［ Ｐ ９ 文献标识码］Ａ ［ 文章编号］１０ —０２ ２０ ）１ — １０ ３ ０８ ８１（０８ ２ ０９ —０
ｍ
匝圃 匝圜
匝 医
匝圜
嘉 团
工 ］／ 开 — ＼ 豳 发 Ｊ 具
加 孽 ｌ Ｉ
圆
匦圜
圆圈Ｉຫໍສະໝຸດ 匿巫 叵巫麴 Ｗｂｅｃ 务。 ｅ ｒｅ ’套 ｖ服 封 Ｓｉ 一
ｌ
。。雠Ｊ服 ｉ ＡｅＥｅ … Ｗ２／ Ｓｂｒ ／Ｓｅ ｐＷ Ｅ务 ｈ ｃ
图２ Ｏ Ｓ Ａ实现模 型