SOA与Web服务：通往EAI的坦途
SOA与Web服务精品PPT课件
消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连 接
当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单）， 而非一组离散的参数
4、分级
粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用 性设计困难
采用不同的粗粒度等级来创建服务 这种服务分级包含了粒度较细、重用性较高的服务，也包含粒
度较粗、重用性较差的服务 在服务分级方面，须注意服务层的公开服务通常由后台系统
（BES’s）或SOA平台中现有的本地服务组成 在服务层创建私有服务是非常重要的 正确的文档、配置管理和私有服务的重用对于IT 部门在SOA服
的
除了B2B 协议外，外部用户还可以访问以Web服 务方式提供的企业服务
2、随时可用
当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应 同步应用——门户应用
对所使用的服务具有很强的依赖性 部署在前台，最终用户易受服务提供者短缺的影响 很多情况下，利用分布式服务提供者，这样可以响应更多的用户请求 使用者通常是基于其自身理解或使用习惯
务层快速开发新的公开服务的能力具有重要影响
5、松散耦合
松散耦合组件服务旨在将服务使用者和服务提供者在服务实现和客户如何使用服 务方面隔离开来
服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分 离的实体而存在
这是服务实现能够在完全不影响服务使用者的情况下进行修改
大多数松散耦合方法都依靠基于服务接口的消息
IT基础结构及业务功能的方法 是一种在计算环境中设计、开发、部署和管
理离散逻辑单元（服务）的模型
SOA 的基本特征
1. 可从企业外部访问 2. 随时可用 3. 粗粒度的服务接口 4. 分级 5. 松散耦合 6. 可重用的服务 7. 服务接口设计管理 8. 标准化的服务接口 9. 支持各种消息模式 10. 精确定义的服务契约
SOA介绍及解决方案
什么是SOA1。
背景IT行业就是术语和缩写流行的行业，各大厂商都喜欢隔三差五地推出一些新概念。
为了不落人后，大家都喜欢争先恐后地跟进。
有深入研究、务实研发的供应商，能够将概念落地，不断推出创新的产品和服务，赢得竞争优势.但“贴标签”的也大有人在，而且趋势是越贴越多,跟风炒作，“鱼目混珠，泥沙俱下"，以至于“混绕视听”了。
SOA就是这俱多“三字母”缩写的概念之中的最流行和热门的一个。
但目前,SOA概念和解决方案，话语权方面基本上被国外巨头所控制，特别是大的中间件厂商。
但是真正能够完整实现SOA的落地解决方案和案例很少,刻意包装的成分比较多，特别是应用架构方面。
重技术，轻方法论,造成企业实施SOA缺乏足够的架构方法、SOA治理、SOA实施运维方面的最佳实践，因此企业实施SOA缺乏系统的指导。
另一方面，国内的不少软件企业，由于不能提供完整意义上的SOA解决方案,只能提供部分的组件，小部分特性符合SOA思想，所以就任意曲解SOA的含义，随意解析SOA的概念。
以至于国内没有一家软件企业不宣传SOA，不宣称其产品符合SOA架构的.由此造成，许多企业和客户对SOA是非常茫然的，对SOA的价值也转向怀疑和抵触。
这种厂商之间的无序竞争，不利于国内企业的自主创新，也不利于企业导入和实施有效的SOA,实现SOA的商业价值。
本文试图就SOA的来龙去脉,外延内涵和前世今生，来一个全面的阐释。
一家之言,权作业界参考，希望带动大家做一些更深入的思考。
文章比较长，如果兴趣不够，也可以就此打住.2. 为什么需要SOASOA的出现不仅仅是厂商炒作的结果，本质上是两种力量驱动的结果：需求拉动、技术推动.业务需求的拉动,希望解决业务应用的问题;技术发展的推动，使得SOA具备了技术上的可行性，软件技术的发展推动了IT创新的商业价值.2。
1.需求拉动需求拉动方面，主要来自于两种信息化的困境。
一个是“信息孤岛”造成基于系统之间互联互通的整合需求;另一个是业务的变化所导致对IT灵活性，以适应变化的需求。
SOA架构与Web Service接口设计
SOA架构与Web Service接口设计1. 概述Service-Oriented Architecture (SOA) 是一种软件设计模式，它将应用程序设计为服务的集合，这些服务可以通过网络进行互联和交互。
Web Service 是一种基于 SOA 架构的实现方式，它使用标准的 Internet技术来实现跨平台、跨语言的服务通信。
本文将探讨 SOA 架构和 Web Service 接口设计的相关概念和要点。
2. SOA架构的优势SOA 架构的核心思想是将复杂的应用系统拆分成多个可重用的服务，每个服务代表一个特定的业务功能。
这样做的好处包括： - 松耦合性：服务之间通过消息进行通信，彼此独立且不直接依赖，可以灵活地组合和替换，降低了系统耦合度。
- 可重用性：每个服务都是独立的功能单元，可以在不同的应用中复用，提高了开发效率和代码质量。
- 服务自治性：每个服务都有自己的生命周期和状态管理机制，可以独立部署、扩展和维护。
3. Web Service的概念Web Service 是基于 Web 技术构建的分布式系统，它使用标准的SOAP（Simple Object Access Protocol）和 WSDL（Web ServicesDescription Language）等协议来进行通信和描述服务接口。
Web Service 接口设计需要考虑以下几个方面：4. 接口设计原则- 明确接口功能：定义清晰的接口功能和目标，能够满足特定的业务需求。
- 一致性与规范性：遵循统一的命名规范、参数传递方式和数据格式，使得接口易于理解和使用。
- 可扩展性：接口应具备良好的扩展性，能够适应未来的业务变化和需求。
- 安全性：采用合适的安全机制，保障接口的数据传输和访问安全。
- 性能优化：考虑接口的性能需求，如请求响应时间、并发处理能力等。
5. 接口设计步骤a) 确定服务边界：将业务逻辑划分为不同的服务，确定服务之间的关系和依赖。
基于SOA和Web serviee的企业协同系统的应用研究执行力
Ｗｅ ｂ服务设计标准 ，采 用分层模式把企业原有业务 系统以 Ｗｅ ｂ服务 的形 式整合 ，执 行力协 同系统 中不 同子
系统根据企业 需求策略划分为粗 粒度 Ｗｅ ｂ服务使之能与企业原有的业务 系统有效集成．
［ 关键 词］Ｓ Ａ；执行力 ；ｗｅ ｅｖ ｅ Ｏ ｂＳｒｉ ｃ
［ 中图分类号］Ｔ３３ ［ Ｐ９ 文献标 志码 ］Ａ ［ 文章 编号］１０ — ８４ （００ １ ０６ 一 ３ ０８ ３０ ２ １）０ — ｏ０ ｏ
总线 （ Ｓ ）提供 了消息传输的信道、路 由机制以及与 Ｗｅ ｅ ｉ ｓ ＥＢ ｂＳｒ ｃ ｖｅ 的接 口［ 引．
１３ Ｓ Ａ与 Ｗｅ ｅ ｉ ｓ ． Ｏ ｂＳ ｒ ｃ 的关 系 ｖ ｅ
—ｌＤ ｌ — 务 丽册 Ｉ 服ＤＩ Ｕ 筹 注 豸 ｌ
一
ＥＳ Ｂ
。
—
—
务 消 费 者
服 务 提供
者 ＷＳ ＤＬ
Ｗｅ ｅ ｉ ｓ ｂＳｒ ｃ 技术是应用程序通过互联网发布和利用软件服务的 ｖ ｅ
一
种标准机制．具有动态访 问、良好 的封装性与复用性、松散耦合 ，
图１ Ｏ 基础架构 Ｓ Ａ
Ｆ ． Ｓ Ａ ａｃｉｃ ｒ ｉ１ Ｏ ｒ ｔ ｔ ｅ ｇ ｈｅ ｕ
使 用 标 准 的 协 议 规 范 等 优 点 ｊ ．Ｗｅ ｅ ｉ ｓ提供 标 准 化 的 服务 接 ｂＳｒ ｃ ｖ ｅ
１ ２ Ｓ Ａ的构 建技 术 ． Ｏ
基于 Ｓ Ａ的体 系结 构仅 仅是 系统构 建时 的一个设 计 思想 ，如 图 １所示 基 于 Ｓ Ａ的 系统实 现 过程 Ｏ Ｏ
需要诸多技术 的支撑 ，通 常情 况下 ，选 择 ｗｅ ｅｖ ｅ 来实 现 Ｓ Ａ模式 中所 有 的服务 ，而选择 ｂＳｒ ｃｓ ｉ Ｏ Ｓ Ａ 、Ｗ Ｄ 、Ｕ Ｄ 作为实现 Ｓ Ａ的基础架构的基础部件．其 中 Ｗ Ｄ Ｏ Ｐ ＳＬ Ｄ Ｉ Ｏ Ｓ Ｌ用来描述服务；Ｕ Ｄ 用来 ＤＩ 注册和查找服务 ，Ｓ Ａ Ｏ Ｐ作为传输层 ，用来在消费者和服务提供者之间传送消息．Ｓ Ａ Ｏ Ｐ是 ＷＥ Ｂ服务
(人工智能)EAI到SOA
（人工智能）EAI到SOA从EAI到SOAEAI(EnterpriseApplicationIntegration，企业应用集成)SOA(service-orientedarchitecture，面向服务的体系结构)随着点对点集成的数量越来越多，IT业界希望有壹种有效的方法来解决且且替代复杂的壹点到多点和多点到多点的集成方式。
此时EAI的集成方式的提出，迅速被大家认可。
EAI的全称是EnterpriseApplicati onIntegration企业应用集成，是中间件的壹种，可完成企业内部基于各种不同平台、不同方案建立的异构应用集成互联，实现数据和信息于各个系统中同步和共享的壹种方法和技术。
EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成于企业内部的E RP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。
简而言之，EAI是于各个业务应用、业务流程或者说业务竖井上的桥梁。
其将每个业务应用之间俩俩对接的壹点到多点的集成方式又转换成为业务应用只和EAI对接的壹点到壹点的连接方式。
伴随着EAI技术的不断发展，它所被赋予的内涵变得越来越丰富。
当下我们谈到的EAI的集成，具有更为广义的内涵，它已经被扩展到业务整合的范畴，业务整合相对EAI来说是壹个更宽泛的概念，它将应用整合进壹步拓展到业务流程整合的级别。
当前从最普遍的意义上来说，比较宽泛的对EAI概念的理解是认为EAI包括数据集成、应用集成和业务流程集成等多个方面。
EAI本身也会对于传递的数据和信息内容进行规范，EAI壹般采用信息集线器（Hub-Broker）机制，即EAI创建了壹个交换中心，用于转换不同应用程序间的数据和消息。
EAI交换中心使用壹些适配程序将所有进入数据的格式重新转换为壹种EAI交换中心内部和外部适配程序均能够理解的通用格式，且将其称为规范格式。
于EAI这种集中的交换中心的概念下，交换中心将是企业的生命线，企业必需购买更强大更稳定的硬件设备来保证总线的效率和稳定。
SOA和EAI应用比较
SOA和EAI应用比较随着企业信息化建设的不断推进，SOA和EAI在企业信息化建设中扮演着越来越重要的角色。
SOA是一种面向服务的架构，它可以将企业内部的各种业务功能封装成服务，形成服务的组合和重新编排，从而实现企业的业务流程优化和集成化；而EAI则是企业应用集成，旨在使企业内部各种业务应用之间顺畅互通，实现信息的共享和资源的共享。
SOA和EAI的出现是为了解决企业信息化建设中的两大难题：业务集成和技术集成。
SOA和EAI的共同点在于都是为了实现企业内部的各种业务应用之间的集成，以达到业务优化和资源共享的目的。
而他们的不同点则在于技术体系的不同。
SOA是一种面向服务的架构，使用的是面向对象编程的思想，可以将企业内部的各种业务功能封装成服务，形成服务的组合和重新编排，以实现业务的优化和集成化。
EAI则是一种基于应用程序接口的技术，采取了中间件和消息队列等技术手段，以实现企业内部各种业务应用的互通和数据交换。
在企业内部业务集成方面，SOA和EAI都有一定的优势和局限性。
在业务集成速度和灵活性方面，SOA较为优越。
SOA的面向服务的编程思想，使得企业内部各种业务功能都可以拆解成服务，并且以如打的方式重组，形成全新的业务流程。
在这个过程中，SOA具有灵活性和可编程性，使得企业可以更加快捷地对业务流程进行修改和优化。
而在EAI方面，则相对较为局限。
EAI采用的是基于应用程序接口的技术，业务集成速度相对较慢，需要进行接口开发和接口实现，这个过程相对繁琐，也更加依赖于技术人员的水平。
在技术集成方面，SOA和EAI也有各自的优势和局限性。
在技术集成方面，EAI的优势是可以对企业内部各个系统进行二次开发，以实现业务的改进和完善。
同时，EAI采用的基于应用程序接口的技术，使得它具有较高的性能表现和管理能力。
但在SOA方面，它对于技术的集成和管理也有着一定的局限性。
SOA作为一种面向服务的架构，因为是基于服务的，因此在技术的集成和管理上相对简单，也相对灵活。
通俗地理解面向服务的架构（SOA）以及微服务之间的关系
通俗地理解⾯向服务的架构（SOA）以及微服务之间的关系SOA是⼀种软件的应⽤架构⽅法，它基于⾯向对象，但⼜不是⾯向对象，整体上是⾯向服务的架构。
SOA由精确的服务定义、松散的构件服务组成，以及业务流程调⽤等多个⽅⾯形成的⼀整套架构⽅法。
这话是不是听起来，让⼈觉得有点晕，我们就细细品读⼀下。
SOA的架构思想（⼀）SOA架构是⾯向服务的，只不过是基于⾯向对象SOA继承了很多⾯向对象的特点，⽐如说⾯向对象的封装，经常代表很多类封装成⼀个模块，为其他对象调⽤者提供接⼝调⽤，良好的⾯向对象设计就是暴露接⼝，隐藏实现，类⽐到SOA的设计，SOA也需要精准明确地定义好服务接⼝，具体服务内部的逻辑实现都是隐藏在背后的，只不过有两个很⼤的区别：（1）⾯向对象的实现都是基于同⼀个编程语⾔或平台（同构），但SOA服务彻底隐藏了实现上⽤何种语⾔平台的具体细节（异构）（2）⾯向对象的实现其实⼤部分都是本地⽅法之间的调⽤，当然也具备分布式远程⽅法调⽤，但SOA是纯粹提供了独⽴的服务，⾯向分布式的远程服务调⽤。
（⼆）SOA的服务定义是精确的这个怎么理解呢？因为SOA的服务⼀旦发布出来，那么就会有很多其他的异构平台服务进⾏调⽤，这时候的服务接⼝修改就不像⼀个⼈或者⼀个⼩团队之间协作那么容易了，可能涉及到⼀个⼤型企业多部门的信息协作，或者对构件已经形成依赖的⽣态链条。
因此这就牵扯出了SOA另外⼀个特征，那就是服务接⼝的粒度⼀般要设置得⽐较粗。
若提供过多的服务接⼝，服务⼜定义得很细粒度，那么频繁修改是在所难免的。
这⼀点上就注定了SOA架构适合在较重量的环境下存在。
那什么是较重量的环境呢？（1）体系健全、制度稳定的重管理型企业，（2）业务逻辑复杂，服务的独⽴性，开放性需求⼜⼤，服务的稳定性也是刚需。
例如：医院信息化系统架构。
（三）SOA是由松散的构件服务组成为什么是松散的呢？由上述我们可以了解到SOA的服务接⼝是粗粒度的，⽽且组成服务的构件都是独⽴部署并具有独⽴的上下⽂环境，这种形态就是为了降低与其他构件之间的强依赖性。
SOA架构和微服务架构的区别
1.SOA架构和微服务架构的区别首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。
1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。
一个服务通常以独立的形式存在与操作系统进程中。
各个服务之间通过网络调用。
2.微服务架构:其实和 SOA 架构类似微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。
这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想2.ESB和微服务API网关。
1.ESB（企业服务总线），简单来说 ESB 就是一根管道，用来连接各个服务节点。
为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；2.API网关:API网关是一个服务器，是系统的唯一入口。
从面向对象设计的角度看，它与外观模式类似。
API网关封装了系统内部架构，为每个客户端提供一个定制的API。
它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。
通常，网关也是提供REST/HTTP的访问API。
服务端通过API-GW注册和管理服务。
3.SOA架构特点：系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
模 块 按 照确 定 的 顺 序 执 行 。 果 数 据 结 构 如 或 者 业 务 逻 辑 发 生 改 变 ． 必 须 对 所 有相 就 关 的软 件 模 块 据 源 和 消 息逐 个 进 行 修 数 改 。 算 是 有 了Ｅ 中 间 件 ， 种 情 况也 并 就 ＡＩ 这
一
方面 ． 的 数 据 源 也 可 以去 响 应 其 他 服 新
务 请 求 者 提 出 的 类 似 请 求 。可 见 ． Ｏ Ｓ Ａ使 软 件 系 统 向 ” 性 化 ”迈 进 了一 大 步 。在 柔
复合增长 率达２ ．％ ． ２ ４ 预计 将高于 整体 软 件市场的增长速度。
Ｓ Ａ概 念 的 出 现 ． 得 Ｅ Ｉ 个 企 业 Ｏ 使 Ａ这
是 达 成 这 一 目标 的最 经 济 有 效 的 方 法 。
Hale Waihona Puke Ｅ Ｉ Ａ 的理想工具 在 过 去 的４ 年 间 ， 件 架 构 师 总 是 在 ０ 软 与 同一 个 ” 鬼 ”交 战 ． 就 是 软 件 的复 魔 这 杂 度 。 交 战 的 结 果 总 是 不 断 印 证 着 那 句 而 不 变 的 咒 语 ：道 高 一 尺 ， 高 一 丈 。 别 魔 特 是 随 着 硬 件 系 统 、 作 系统 平 台 的 不 断 增 操 加 以及 企 业 网 络 的 飞 速 蔓 延 ． 何 把 这 些 如 不 同 的 信 息 系 统 集 成 起 来 ． 就 是 实 现Ｅ Ｉ 也 Ａ （ 业 应 用 集 成 ） 更 是 令 许 多企 业 的 Ｉ人 企 ． Ｔ 员不堪重负 。 传 统 的 编程 技 术 所 形 成 的 软 件 系统 都 是 刚 性 的 。 就 是 说 ， 旦 开 发 完 成 并 投 也 一 入 运 行 ， 是 固 定 不 变 的 ， 能 在 使 用 过 就 不 程 中进行 调整和 改变 。 业务 流程 中 ． 在 软 件 系 统 严 格 按 照 预 先 设 定 的 目标 ． 功 能 各
企业信息化的永久话题
对 于 绝 大 多 数 企 业 来 说 ， 投 资 都 是 Ｉ Ｔ 日积 月 累 的 过 程 ． 非 一 劳 永 逸 。 业 的 而 企
业务 资料更是在 每时每 刻都在增 加 ， 而且
是 散 布 在 不 同 时 期 同部 门的 信 息 系 统 不 之 中 。因此 ． 业 信 息 系统 一 个 应 该 是 逐 企 渐演变 的生命体 。 当企 业 业 务 对 信 息 系 统 提 出新 要 求 的 时 候 ． 应 该 采 取 渐 进 的方 也 式 对 系 统 进 行 升 级 改 造 。总 之 ． 种 希 那 望 采 取 跳 跃 式 的 方 法 来 使企 业信 息 系统 跟 上 业 务 需 求 的 想 法 肯 定 是 不 切 实 际 的幻 想 。因此 ． 何 将 企 业 中 不 同 时 期 不 同 如 部 门 、 同 地 域 的信 息 系 统 有效 地 集 成 起 不 来 ． 至 把 企 业 直 接 形 成 的供 应 链 中 的所 甚 有 应 用 也 有 效 地 集 成 起 来 ． 个 问题 不 仅 这 过去 、 在存在 ． 且将来也会 继续存在 。 现 而 据 ＩＣ中 国 发 布 的 《 国企 业 应 用 集 Ｄ 中 成 与 Ｗｅ Ｂ 务 市 场 ２ ０ ０ ９ 预 测 与 分 ｂＥ ０ ５２ ０ 年 析 》 告 数 据 显 示 ， 业 对 Ｅ （ 业 应 用 报 企 ＡＩ企 集成 ） 的需 求 增 长 迅 速 ． ０ ４ 集 成 服 务 ２０ 年 器 软 件 平 台 （ Ｓ ） 场 规 模 为 ４ ４ 万 美 ＩＰ 市 Ｓ １０ 元 ， 计 到 ２ ０ 年 达 到 １ １ 亿 美 元 ． 均 预 ０９ ．３ 年
者 。 以 ． 于 Ｓ Ａ的企 业 应 用 系统 可 以 所 基 Ｏ 括 Ｘ 、Ｓ Ｐ ＭＬ ＯＡ 、ＷＳ Ｌ Ｕ Ｄ ． 以用 来 Ｄ 和 Ｄ Ｉ可 建立应 用解决方 案 ． 决 特定 的消息通信 解
等 技 术 在Ｗ ｅ环 境 中 提 供 这 些 服 务 。 ｂ 在 当今 复 杂 的异 构计 算 环 境 中 ． Ｏ ＳＡ 作 为 一 种 重 要 的 集 成 和 架 构 框 架 呈 现 出 来 。 此 之 前 的 方 法 都 很 难 支持 开 放 的 互 在 操 作 解 决 方 案 ． 是 以 私 有 、 用 的Ａ Ｉ 而 专 Ｐ为 基 础 ． 因此 在协 调 和 沟 通 方 面 耗 费 甚 多 。
维普资讯
专 栏
Ｉ ＣｏＬＵＭ Ｎ
Ｓ 与 Ｗ 服 务 Ａ Ｏ ｅ ｂ 通往 Ｅ Ｉ Ａ 的坦途
一 一
Ｅ （ｎｅｐｉｅ Ａｐ ｌ ａ ｉ ｎｅ ｒｔ ｎ， ＡＩＥ ｔｒｒｓ ｐｉ ｔ ｎ Ｉ ｇａｉ ｃ ｏ ｔ ｏ
企业应 用集成 ） 不是一个 新的概念 ， 并 然 而 进 入 上 个 世 纪 九 十 年 代 以后 ，Ａ 的重 要 ＥＩ 性 日 益 倍 受 关注 ， Ｓ Ａ与 Ｗ ｅ Ｂ． 则 为 而 Ｏ ｂ￣ 务 Ｅ 的 发 展 铺 平 了道 路 。 ＡＩ
没有得到根本性的改变。 Ｓ Ａ采 用 服 务 请 求 （ｅｖｃ ｅ ｕｓ） Ｏ Ｓ ｒｉ Ｒｑ ｅｔ ｅ 的软 件 架 构 ． 根 本 上 改 变 了传 统 软 件 的 从
开 发 方 式 。与 传 统 的 软 件 系统 不 同 ． Ｏ ＳＡ
只限定服务所 需的信息并提 出服务请 求 ， 但 是 不 限定 提 供 服 务 的模 块 ． 样 就 完 全 这 可 以在 服 务 请 求 模 块 不 知 不 觉 的情 况 下 ， 由不 同 的 数 据 源 来 满 足 这 个 服 务 请 求 。 另
信 息系 统 的老 问题有 了新 的、更 好 的答
Ｗｅ ｌ ｋ ｈｅ ｎ ｔｗＩｒＬ ｎ ａ ｅｔ ｅ Ｄ ｜
维普资讯
专 栏
ＣＯＩＵＭ Ｎ 、 ． １
这 样 的 系统 中 ． 需 要 根 据 新 的 情 况 修 改 只 服 务 的执 行 者 ， 不 需 要 修 改 服 务 的请 求 而