面向服务的体系架构（基于ESB的SOA实现）
目录
面向服务的体系架构（基于ESB的SOA实现） (1)
1. 摘要 (2)
2. 国内外研究现状 (4)
2.1. 国外研究状况 (4)
2.2. 国内研究进展 (4)
3. SOA框架 (6)
3.1. SOA概念及框架模型 (6)
3.2. SOA特性 (7)
3.3. 实现SOA的相关技术 (8)
3.4. SOA解决方案的缺陷 (10)
4. ESB模型 (11)
4.1. ESB的定义和模型 (11)
4.2. ESB的功能和优点 (11)
4.3. ESB的设计原则和实现技术 (12)
5. 基于ESB的SOA框架设计 (14)
5.1. ESB在SOA中的角色 (14)
5.2. 基于ESB的SOA框架 (14)
5.3. ESB总线各模块功能 (15)
5.4. ESB总线的模块设计 (17)
5.4.1. 总线适配器的设计 (17)
5.4.2. 总线与外部应用/服务的通信方式 (18)
5.4.3. 其他模块的设计 (19)
1.摘要
面向服务体系结构(service oriented Architecture，SOA)是一个组件模型，用开放的标准把企业的业务功能包装成标准的服务。这种服务通过明确的、与实现无关的接口来定义，服务被松散绑定，并且可以通过强调位置透明性和互操作性的通信协议进行调用。为了优化企业的信息系统基础架构，降低服务重用的复杂性，并可靠地集成企业信息系统中存在的各种技术、协议和应用，以实现面向服务的体系结构，需要建立一个以服务为中心的抽象层，以隐藏各种应用和技术带来的底层复杂性，这个服务中间层就是企业服务总线(Enterprise Service Bus，ESB)。
基于SOA进行企业应用系统集成是当前业务集成的主流方式，ESB是广义企业实现面向服务整合的关键。ESB是SOA架构的解决方案之一，是受到业内人士普遍认可追捧的一种基于SOA的架构实现方式。这是一个基于标准的、面向消息的、高度分布式的、具有动态路由功能的系统整合平台。ESB的使用，正在使企业应用服务整合领域内发生新的变革。
现代信息技术的飞速发展，把企业信息化建设带入了自动化与网络化的新阶段。在过去的几年中，大量企业信息化管理系统诸如ERI，、PDM、SCM、OA、CRM等的出现，在降低生产成本，缩短研发周期，提高产品创新性等方面起到了很大作用。所有这些为PLM(产品生命周期管理)建设提供了有利条件和强有力的技术保证。随着企业信息化管理的进一步深入和企业对信息化的更高的要求，企业越来越关注将各类信息化管理软件集成到一个自适应的软件集成平台中。这就是PLM(产品生命周期管理)软件开发的目的所在。
图1-1 概念中的PLM系统模型图
本文首先介绍了面向服务架构的相关技术和理论基础，分析了SOA的主要特性，这些特性包括了SOA框架下服务的松散耦合性、服务的粗粒度设计、基于标准的接口以及所有服务的具体实现、位置和传输协议对调用者来说都是透明的。
其次，介绍了企业服务总线的概念和模型，探讨了它的核心原则，并对ESB服务总线的功能进行了研究。服务的请求者和服务提供者之间是通过一个ESB总线来进行交互的。ESB 提供了服务请求者和服务提供者之间的松散耦合互连，ESB总线充当逻辑中介。ESB是一种中间件，可以为松散耦合的服务和应用提供标准的集成方式。面向服务的解决方案包括了诸如安全性、日志记录、管理和审核等服务，ESB可以代表参与者各方来实现或者执行这些基础服务，使得交互的参与者不再关注此类事项。
再次，设计了一种基于ESB的SOA架构参考模型，采用交互模式设计了一种轻量级的框架，它是符合SOA的一个框架，同时是符合ESB技术实现的框架。其主要优点在于：服务透明化和服务的松散耦合。本文详细介绍了该架构的设计。其中包括：客户层、服务端和ESB总线部分。ESB总线部分主要职责是负责服务的路由和交互。主要由总线适配器、服务处理器、业务代理器、服务管理器、服务注册中心、服务代理等模块组成。日记管理组件和安全管理组件都为服务处理器工作。
2.国内外研究现状
2.1.国外研究状况
在国外，SOA早就已经被提出，但是鉴于当时计算机技术水平有限，没能引起广泛的关注。随着Web技术和WebService技术的逐渐发展成熟，SOA开始受到更多专业厂商的支持。很多著名的IT企业开始加入到SOA技术的开发及实现技术的研究队伍当中，其中有IBM、BEA这类先行开发商，也有Microsoft、Oracle等后来开发商。一些大的开发公司己经能够开发出自己独立完善的ESB平台，例如：
l、IBM websphere的ESB(Enterprise services Bus，企业服务总线)平台
IBM开发出基于WebSphere产品族的ESB平台，构成了IBM SOA的基础架构，提供了ESB的包括消息传递模式、传输协议、中介、消息转换、服务路由、服务集成方式等在内的基本功能，以及对ESB的事务、可靠性、安全性等非功能属性的支持。
2、Microsoft的Indigo平台
Microsoft用于构建面向服务应用程序的代号为Indigo的框架，使得专门用于创建SOA 应用程序的技术得到广泛应用。Indigo允许采用.NET Framework创建面向服务的应用程序，实现了SOAP和其他web服务技术。Indigo在扩展的.NET Framework 2.0基础上，提供了客户端访问服务的创建支持，主要由一组运行于公共语言运行库(CLR)上的类来实现。客户端与服务通过Indigo的内置协议SOAP进行交互。Indigo有三项突出的特性：与多种现有Microsoft技术的统一性，对跨供应商互操作性的支持，以及显式的面向服务特性。
3、BEA的AquaLogic Service Bus
AquaLogic Service Bus(ASB)是BEA公司架构于SOA技术和web服务技术上的ESB产品。主要有五部分组成：配置框架、服务管理、服务安全总线、消息代理和协议。AquaLogic使用面向服务的方法来支持应用程序利用共享的企业安全服务，把分布式的策略决策与集中式的策略控制结合了起来，有效地提高了服务总线的安全性
2.2.国内研究进展
国内对于SOA的研究主要体现在部分中间件产品上，基于SOA的ESB整体解决方案太少，大多数的产品属于协同软件产品或中间件产品。现在，己经有一些公司开发出了与SOA
紧密相关的软件产品。如：
1、Inter Bus是由中和威公司推出的国内第一个支持SOA架构的ESB产品，给企业级的信息系统的应用整合和服务带来了方便。
2、上海(复旦)协达软件科技有限公司也在2008年初推出了基于SOA的协同软件和解决方案。
3、普元EOS通过采用XML企业总线技术、构件技术和可视化开发技术利用己有的构件库来快速的搭建应用系统。EOS包括五个部分：EOS构件库、运行管理环境、开发环境、EOS 工作流和EOS可视化页面开发环境。
这些基于SOA的系统平台共同特性在于，都是基于原有的中间件产品，在外围增加了一些Web服务包装器，再把相关的消息处理机制整合到原有的系统中，实现在面向服务的开发中模块的松散藕合。这与基于SOA原理设计的系统解决方案的企业化、完整性、规模化有着较大的差距。
3.SOA框架
3.1.SOA概念及框架模型
Gartner Group在1996年第一次明确地提出了SOA(Service一oriented Architecture)的理念，但当时的软件技术水平和信息化程度还达不到使SOA思想变成实现的地步，SOA只能成为一个美好的远景。Gartner对SOA的描绘是这样的:“面向服务的架构是一种基于客户机/服务器模式的软件设计方法，其中的应用由服务提供者和服务使用者(也称客户机或服务请求者)双方组成。目前，关于SOA还没有一个统一的、业界广泛接受的定义。从不同的角度，不同的市场策略，会得到不同的关于SOA的解释。一般来讲，比较认同的一种说法是IBM 关于SOA的定义:面向服务的体系结构是一个组件模型，它将应用程序的不同单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA的模型中有三种角色:服务提供者、服务注册库和服务请求者。SOA模型中还包含三种操作即发布、查找、绑定。具有简单、开放和动态的特性。如图3-1所示，常见的SOA 参考模型:
图3-1 SOA架构参考模型
●服务请求者:可以看作是需要其他服务提供给自己服务的一个服务、一个应用程序
或者是一个软件模块。它到服务注册中心去查询自己需要的服务，然后通过传输绑
定服务，并且获得执行服务功能。
●服务提供者:可以看作是能够通过网络寻址找到的应用或服务实体，能够接受和执
行来自服务请求者的请求，它把自己的服务和接口契约发布到服务注册中心，为服
务请求者发现和访问该服务做好准备。
●服务注册中心:可以看作是服务发现的中介，通过它里面包含的所有可用服务的存
储库，为服务请求者提供查找服务提供者提供的服务接口功能。
SOA中的这三种角色不是绝对固定的。一个服务提供者也可能会成为另外一个服务的请求者。每个角色都可以成为服务提供者、服务请求者和服务注册中心中的某一种或多种。
3.2.SOA特性
根据业界对SOA的普遍认识，SOA不是一种语言技术，而是一种组件模型，一种粗粒度、松耦合的软件架构，通过服务间定义良好的接口和契约把服务联系起来。这与传统的软件架构相比较可以得出SOA架构的几点鲜明的特性:
●松散耦合性。
SOA架构中定义的接口是具有中立性的接口(没有强制性的绑定到特定的实现上)，它的这种特征称之为服务的松散耦合。松散耦合系统的好处有两点:一点是它的灵活性，另外一点是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
●粗粒度的服务。
服务粒度指的是服务所公开功能的范围，一般分为细粒度和粗粒度。其中细粒度服务是那些能提供少量商业流程可重用性的服务，粗粒度服务是那些能够提供高层商业逻辑的可重用性服务。选择正确的抽象级别是SOA建模的一个关键问题，设计中应该在不损失相关性、一致性和完整性的情况下，尽可能地进行粗粒度的建模。
●基于标准的服务接口。
SOA的关键在于“服务”。服务是一种部署在网络应用服务器上的实现了一定功能的应用逻辑模块。它本身可以包含一组操作集(一个或多个操作)并向外界提供访问操作的接口，所有的服务都要发布一个标准的接口，将服务和服务客户端都能够理解的并且同意遵守的通信规则。当服务请求者查找所需服务时，它查找到的结果也是那个服务的接口。接口里应包含使用该服务的所有的必要信息。把服务要求的信息传递给服务来利用服务的过程，称之为绑定。
●服务位置、传输协议以及具体实现的透明性。
服务请求者在需要使用他人提供的服务时，完全不需要知道对方提供的服务的位置，也不需要知道该服务的具体实现方式，服务方是不是与其异构等对于请求者来讲都是不需了解的。所有的消息都通过查询服务注册中心这个中介来发送和接收，由中介来负责告诉请求方
所需服务的位置、相关参数等信息并且可以把相关信息进行请求者和服务之间相互传递，其具体实现细节服务请求者也不需知道。
基于SOA的各种特性，来整合企业应用业务服务，以松散的，灵活的方式随时随地根据业务需要，来不断进行业务数据或企业产品生产资源的交流，动态地使企业的生产、运行方式发生变革，会给企业以最快的、灵活的、最节省成本的方式来适应并满足当前瞬息万变的业务需求。
3.3.实现SOA的相关技术
上面讲过，SOA的关键就在于服务。所有的功能都是以服务的形式来展现出来的。服务就是应用系统的基本单元。广义上来讲，SOA的实现技术有多种方式，如：COM、CORBA、Web服务等都是实现SOA的技术。但使用最广泛的仍是Web服务技术。
1.Web服务的定义
W3C给Web服务下的定义：Web服务是由URL识别的软件应用，它的接口和绑定可以由XML构件进行定义、描述和发现。Web服务支持使用通过因特网协议交换的基于XML的消息与其他软件代理直接交互。
2.Web服务的体系结构
Web服务采用了SOA的体系结构，通过服务提供者、请求者和注册中心等实体之间的交互完成服务调用。IBM提出了由服务级别协议(Service Level Agreement，SLA)保证的web 服务体系结构，如图3-2所示。
图3-2 SLM保证的第二代Web体系结构
Web服务是基于开放的因特网标准的，它所依赖的开放标准主要有XML、SOAP、WSDL 和UDDI等。下面简述这些相关的协议标准：
(l)XML
面向服务的软件体系架构总体设计分析 计算机技术更新换代较为迅速，软件开发也发生较多改变，传统软件开发体系已经无法满足当前对软件生产的需求。随着计算机不断普及，软件行业必须由传统体系向面向服务架构转变。随着软件应用范围不断增大，难度逐渐上升，需要通过成本手段，提高现有资源利用率。通过面向服务体系结构可提高软件行业应对敏捷性，实现软件生产的规模化、产业化、流水线化。 1 软件危机的表现 1.1 软件成本越来越高 计算机最初主要用作军事领域，其软件开发主要由国家相关部分扶持，因此无需考虑软件开发成本。随着计算机日益普及，计算机已经深入到人们生活中，软件开发大多面向民用，因此软件开发过程中必须考虑其开发成本，且计算机硬件成本出现跳水现象，由此导致软件开发成本比例不断提升。 1.2 开发进度难以控制 软件属于一种智力虚拟产品，软件与其他产品最大不同是其存在前提为内在逻辑关系。相较于计算机硬件粗生产情况，传统工作中的加班及倒班无法应用到软件开发中，提升软件开发进度无法通过传统生产方法实现。且在软件开发过程中会出现一些意料不到的因素，影响软件开发流程，导致软件开发未按照预期计划展开。由此可见不仅软件项目开发难度不断增加，软件系统复杂复杂性也不断提升，即使增加
开发人手也未必能取得良好效果。 1.3 软件质量难以令人满意 软件开发另一常见问题就是在软件开发周期内将产品开发出来，但软件本身表现出的性能却未达到预期目标，难以满足用户多方位需求。该问题属于软件行业开发通病，当软件程序出现故障时会导致巨大损失。在此过程中软件开发缺乏有效引导，开发人员在开发过程中往往立足于自身想法展开软件开发，因此软件开发具有较强主观性，与客户想法不一致，因此导致软件产品质量难以让客户满意。 1.4 软件维护成本较高 与硬件设施一样，软件在使用过程中需要对其进行维护。软件被开发出来后首先进行公测，发现其软件存在的问题，并对其重新编辑提升软件性能，从而为客户提供更好服务。其次软件需要定时更新，若程序员在开发过程中并未按照相关标准执行会导致其缺乏技术性文档，提升软件使用过程中的维护难度。另外在新增或更新软件过程中可能导致出现新的问题，影响软件正常使用，并可能造成新的问题。由此可见软件开发成功后仍旧需要花费较高成本进行软件维护。 2 面向服务体系架构原理 2.1 面向服务体系架构定义 面向服务体系构架从本质上是一种应用体系架构，体系所有功能均是一种独立服务，所有服务均通过自己的可调用接口与程序相连，因此可通过服务理论实现相关服务的调动。面向服务体系构架从本质上来说就是为一种服务，是服务方通过一系列操作后满足被服务方需求的
ICS 备案号： Q/CSG 中国南方电网责任有限公司企业标准 面向服务的信息技术架构（SOA ）框架规范 中国南方电网责任有限公司 发 布
目次 前言............................................................................ III 1范围. (1) 2规范性引用文件 (1) 3术语与定义 (1) 3.1面向服务的体系结构 (1) 3.2服务 (1) 3.3企业服务总线 (1) 3.4企业资源规划 (1) 3.5企业应用集成 (1) 3.6企业信息门户 (1) 3.7SOA项目 (1) 4总则 (1) 4.1持续发展原则 (1) 4.2先进性原则 (2) 4.3实用性原则 (2) 4.4操作性原则 (2) 5SOA架构模型 (2) 5.1服务体系 (2) 5.1.1服务体系设计依据 (2) 5.1.2服务体系图 (2) 5.1.3服务体系各层定义 (3) 5.2应用体系 (4) 5.3服务部署体系 (5) 5.4技术标准规范体系 (6) 5.4.1技术标准规范体系图 (6) 5.4.2服务开发技术标准规范 (9) 5.4.3服务集成技术标准规范 (13) 5.5SOA架构模型特征 (14) 6SOA服务设计与开发 (14) 6.1服务识别 (14) 6.2服务定义 (14) 6.3服务设计 (16) 6.3.1总体设计原则 (16) 6.3.2访问服务 (16) 6.3.3数据服务 (17) 6.3.4业务服务 (17) 6.3.5流程服务 (17) 6.3.6综合服务 (17) 6.3.7展现服务 (17) 6.4服务实现 (18) 6.4.1服务封装原则 (18) 6.4.2服务封装方式 (18) 7SOA服务集成 (18) I
理工学院 毕业设计外文资料翻译 专业：通信工程 姓名： 学号： 11L0751156 外文出处： 2012 International Conference On Computer Science And Service System 附件： 1.外文资料翻译译文；2.外文原文。
附件1：外文资料翻译译文 基于属性的访问控制(ABAC)的跨域访问控制面向服务的体系结构 (SOA) 摘要传统的基于角色的访问控制模型(RBAC)不能满足面向服务的需求架构(SOA)的分布和开放，基于属性的访问控制(ABAC)更多细粒度访问控制，更适合SOA是敞开的环境。本文提出了一种ABAC-based跨域访问控制系统中，安全域的与主题、对象属性、权力的环境属性访问决策的基础，消除集成基于SOA框架的约束RBAC，某种程度上提高了可伸缩性和可变更性的系统，解决了跨域访问控制的问题。 关键字：SOA，基于属性的访问控制(ABAC)，访问控制 1. 整体介绍 面向服务的体系结构(SOA)是一种组织方法和使用分布式资源的灵活性组织和管理资源的分布不同的管理领域[1 - 2]。越来越高的对信息集成的需求，松散耦合的、开放的SOA从业务和吸引了越来越多的关注学术界[3]。但是SOA的发展也面临着许多问题，比如安全保障，以及如何整合环境检测服务和原始数据[4]。它在特定的SOA安全系统，开放性，跨域访问安全性呈现给我们的是一个巨大的挑战。 基于角色的访问控制(RBAC)是在一个更合适的独立的安全域，不适合跨域访问。基于主体统一服务认证系统[7]，使用不同的方法来处理访问跨域访问，它解决了这个问题在跨域访问企业信息集成一定程度上，但它的基于角色的想法不能最后一个方法实现SOA的开放性和信息集成。 为了解决上述问题，本文提出了一种基于属性的访问控制(ABAC)的跨域访问控制系统，该系统应用的思想属性的访问控制跨域访问控制。该系统消除过程中的缺陷基于角色的访问控制应用于SOA的作用。 2.基于属性的访问控制(ABAC)
基于面向服务体系架构（SOA）和面向资源体系架构（ROA）的业务组件模型多终端多技术平台可复用的组件模型 引言 在《面向服务体系架构（SOA）和业务组件（BC）的思考》（以下简称《 SOA 和 BC 》）一文中介绍了基于面向服务体系架构（SOA）的组件模型，本文按照“分离”的原则，通过比较当前多种流行的客户端和服务器端的通讯机制，进一步把业务组件进行分离，采用面向资源体系架构（ROA）把业务组件界面层和业务逻辑层分离开，构建一个多终端多技术平台可复用的组件模型 多层架构中的通讯方式 软件体系架构是沿着单机到 CS 架构，再到 BS 的三层架构甚至多层架构逐步发展过来的，关于多层架构，本文不再详细介绍，可以参考相关的资料，下面首先来分析一下当前比较流行的客户端技术以及客户端和服务器之间的通讯方式。 基于 MVC 的 J2EE 多层模型 在一个标准的基于 MVC 的 J2EE 的模型架构的代码中，从对象的类别来看，一般包含 BO、DAO、POJO 等 Java 类，另外还包含 JSP、Servlet 等，如下图所示： 图 1. 基于 MVC 的 J2EE 多层模型 POJO：简单 Java 对象（Plain Ordinary Java Object，POJO），一个中间对象，在不同阶段可以转化为 PO、DTO、VO，POJO 持久化以后就是 PO，在应用中的不同层次传递为 DTO，直接用来对应表示层就是 VO。 PO：持久对象（Persistant Object，PO），也称为 Data 对象，对应数据库中的 Entity，可以简单认为一个 PO 对应数据库中的一条记录。PO 中不包含任何对数据库的操作。 VO ：表现层对象（View Object，VO）主要对应界面显示的数据对象。对于一个 WEB 页面，或者 SWT、SWING 界面，用一个 VO 对象对应整个界面的值。根据业务的需要可以和表对应，也可以不对应。 DTO ：数据传输对象（Data Transfer Object，DTO）主要用于远程调用等需要大量传输对象的地方。对象不应该包含业务逻辑，其仅仅需要传递需要的属性，而不是 PO 的所有属性。BO：业务对象（Business Object，BO）主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。通常一个 BO 包含多个 PO，通常需要将 BO 转化成 PO，才能进行数据的持久化，反之，从 DB 中得到的 PO，需要转化成 BO 才能在业务层使用。BO 建议只包含业务方法，属性在 POJO 中。
SOA 面向服务架构(Service-OrientedArchitecture，SOA)是一种架构模型，其基本思想是以服务为核心，将企业的IT资源整合成可操作的、基于标准的服务，使其能被重新组合和应用。SOA 的应用对突破企业信息化建设过程中长期存在的瓶颈，诸如信息孤岛、适应需求能力差、重复建设、新应用周期长等问题提供了有力的解决手段。 1.统一规范与标准。突破信息鸿沟制约与传统技术手段不同，SOA技术架构强调统一规划、统一标准、统一管理。通过SOA技术架构的应用，不仅辅助企业各业务部门制定科学合理的整体规划，而且有效解决企业信息化建设中因缺乏统一框架而带来的信息孤岛现象。为解决企业各业务部门间，部门内的互联互通难。资源浪费、重复建设等问题提供有力支持。 2.创新技术理念，提升应用水平SOA以服务为理念，通过面向眼务的方式组织开发，可以更准确地体现用户需求。服务以松耦合的状态存在于整个系统中，并可以随业务需求而变，一方面可以快速深度地满足用户需求。另一方面可以减少企业各业务部门中的业务冗余和重复开发。 3.改变建设模式，降低投资风险SOA基于全新的技术架构来规划产品与组织生产，将极大地变革软件生产和应用模式，从而满足用户的深层次需求。SOA提供了构建IT系统的全新方法，充分采用标准的软件产品和服务组件，最终形成高效开发、标准规范、业界支撑广、技术发展快的应用模式。 MVC
李彦宏首谈“框计算”：全新技术理念驱动产业升级 李彦宏指出，“框计算”为用户提供基于互联网的一站式服务，是一种最简单可依赖的互联网需求交互模式，用户只要在框中输入服务需求，系统就能明确识别这种需求，并将该需求分配给最优的应用或内容资源提供商处理，最终返回给用户相匹配的结果。 “框计算”驱动产业升级 首先，“框”是一个功能强大的需求收集器和分析器。在李彦宏提出“框计算”概念之前，其实个人计算机、互联网上已经有形形色色的各种计算框，词典框、对话框、搜索框……但这些各种各样的“框”，都只是在特定语境下才有意义。比如词霸里的词典框，用户只有在获取单词释义时，才会到这个框里输入内容；同样，用户在词典框里输入别的需求，词典框也不会给用户任何有意义的反馈。而李彦宏所提到的“框计算”的“框”，用户可以输入任何类型的需求，从某种意义上来说，这个“框”是万能的，因而也必须是“智能”的。 其次，由于“框”能在在互联网可选范围内根据用户需求自动匹配最佳的应用和服务，这个“框”又带有典型的操作系统特性。就像微软的视窗操作系统，上面可以运行Office、浏览器、杀毒软件等各种各样的应用软件。目前，词典、计算器、日历等简单应用已经能通过百度框直接运行，视频、杀毒、游戏、购物等互联网应用近期也有可能被框直接启动，如果越来越多的应用确实能在“框计算”平台上运行，“框”将对整个互联网产业的升级和发展产生巨大的拉动效应。 “框计算”的关键技术——需求识别和应用开放 “框计算”平台听起来非常神奇，而要通过“框计算”实现真正的基于互联网的一站式服务，有两个领域的关键技术需要突破。 首先是需求识别领域的技术突破。所谓“需求识别”，就是确定用户究竟要互联网为他做什么，这是互联网科学最复杂和最具技术含量的一个领域，下面又包括语义分析、行为分析、智能人机交互、海量计算处理等子领域。以搜索的用户需求识别为例，如有人希望从互联网得到一个“形容很开心的句子”，这个请求首先被拆成不同粒度的20个语义单位进行分析，后台要经过3亿次计算来识别这个需求，并在100亿个网页资源中检索并进行需求分配，而整个过程却需要在不到十分之一秒内完成。在用户需求识别技术方面，百度目前在全球范围内都是最强的，每天要从搜索框中获取超过10亿次搜索请求，并要一一在极短时间内对这些需求进行识别响应。尽管如此，当“框计算”将用户需求从搜索向其他应用领域极大程度延展时，“框计算”后台对用户需求的识别能力还需要大幅度的提升。 另一个需要突破的领域，就是“框计算”平台上的应用开放。“框计算”平台前端的需求识别能力再强，如果没有合适的应用在平台上及时响应这个需求，用户需求一站式满足的美好理想也不可能完美实现。反过来，要使更多的应用在“框计算”平台上实现就绪，光靠一两家公司肯定是不行的，而需要整个产业的共同努力。一方面，“框计算”平台要足够开放，要建立起足够开放的产业标准和技术接口，让想加入到这个平台的应用服务商能以最简单便捷的方式加入进来；另一方面，“框计算”平台也要能为平台上的应用服务商带来更大的利益，而这主要牵涉到“框计算”上游海量用户资源和需求的分配问题。