企业架构与面向服务架构
企业架构与面向服务架构
SOA可以帮助企业带来新的动力和在现有的系统上创造新的价值，SOA促进模块化业务服务的开发，而且这些服务可以轻松地被整合和重用，创建一个真正敏捷、灵活和具有强适应性的信息技术基础架构。
全球领先的企业正在利用面向服务架构(Service Oriented Architecture: SOA)来降低其遗留系统、创新应用、和信息技术环境的复杂性。SOA可以帮助企业带来新的动力和在现有的系统上创造新的价值，SOA促进模块化业务服务的开发，而且这些服务可以轻松地被整合和重用，创建一个真正敏捷、灵活和具有强适应性的信息技术基础架构。
SOA是一种企业架构 (Enterprise Architecture: EA)，因此它是从企业的需求开始的。但SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应，并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建一个信息技术(IT)架构，以满足当前和未知的业务需求及不断的变更。
在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA 中任何的瓶颈都会影响到整个IT环境的灵活性。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。
SOA可以使服务的注册、发布、申请和重用变得简单，从而提高开发效率，同时降低了成本。其主要益处为：
*缩短开发时间和降低成本—重用SOA服务并快速地将其组合为新的粗粒度服务
*降低维护成本—可重用服务降低了IT服务的数量和复杂性
*提高服务质量—SOA提升了服务的可重用性，通过不同服务使用者的多个测试周期创建高质量的服务
*降低整合成本—标准化的服务通过协同工作，使分散的服务能够快速、轻松地连接起来
*降低风险—集中注册的可重用服务简化了公司治理和IT治理，并提供了更强的控制，降低不合规行为的总体风险
SOA的敏捷性和灵活性将给企业带来巨大的好处。例如某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值。那么这些服务的顾客(可能在公司内部，也可能是公司的某个业务伙伴)就可以得到这些服务，而不必考虑其后台实现的具体技术。如果顾客能够发现并绑定可用的服务，透过服务注册层的关注分离，这些服务背后的IT系统能够提供更大的灵活性。
但是要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解SOA及企业架构，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙也非常关键。
SOA开发生命周期牵涉到四个角色：工程师、架构师、业务人员、和IT部署人员。除了传统开发工程师和业务人员的交互，加入了架构师和IT部署人员，因为企业须要建立全球参考架构框架/架构。架构师的工作不是定义具体的编码，而是建立一个统一的开发视图，比如选择开发的环境和部署环境。架构师可以跳过开发人员直接到IT部署人员。例如企业发展了一个应用，这个应用可以访问多少个数据库以及哪几个数据库，这是由架构师决定的。
为了协助中国企业落实企业架构和SOA的实践，金蝶在2008年8月29日，邀请全球权威的The Open Group开放标准协会主席及行政总裁Allen Brown首次来华，专为深圳金蝶明珠俱乐部会员举办了一场题为“下一个信息革命”的专题演讲。8月29日上午的论坛期间，Allen Brown和美国维吉尼亚理工大学计算机科学博士、在信息科技方面有超过二十五年的经验的褚幼鸿先生，为参会的深圳十数家优秀企业的CIO及SOA技术研究领域专家分享了几个方面的价值：
世界领先的企业架构框架—The Open Group Architecture Framework (TOGAF)
架构开发方法(Architecture Development Method: ADM)
信息技术架构师和专家认证计划
面向服务参考架构 (SOA Reference Architecture)。
TOGAF及SOA 参考架构提供了一个灵活且可扩展的架构框架，帮助企业完成符合商业目标的信息化。参考架构及框架相当于架构模板，透过模板可快速及最佳实现企业架构。TOGAF及SOA参考架构的效益包含：
增加灵活性：创建服务为基础的信息技术应用，以方便快速转型、重构业务流程、和重用现有应用程序
敏捷性：更快的提供对齐业务的应用
增加收入：提供利用现有的业务能力进入新市场的机会。使用新的和创新的方法，和采用一套松耦合的IT服务，提供新的和更好的商业服务来增加市场占有率。
降低成本：通过合并多余的应用功能和从过时的和越来越昂贵的应用解耦功能，以重用现有的投资
融合：整合横跨竖井的应用和组织
演讲中除了介绍The Open Group组织之外，主题集中在企业架构、架构开发方法和面向服务参考架构。
内容导航
The Open Group于1993年开始应客户要求制定系统架构的标准，在1995年发表TOGAF 架构框架。TOGAF的基础是美国国防部的信息管理技术架构框架(TAFIM)。TOGAF是一种协助发展，验收，运行，使用，和维护架构的工具。它是基于一个迭代(Iterative)的过程模型，支持最佳实践和一套可重用的现有架构资产。它可让您设计，评估，并建立您机构的正确架构。TOGAF的关键是架构开发方法(Architecture Development Method: ADM): 一个可靠的，行之有效的方法，以发展能够满足您商务需求的企业及SOA架构。
TOGAF发展历史如下：
架构开发方法(ADM)为一嵌套及迭代式的信息化、企业架构、及SOA参考架构咨询方法论，其主要阶段如下图：
点击图片查看大图
开源群组架构框架(TOGAF)及架构开发方法(ADM)已被80%的福布斯( Forbes)全球排名前50的公司使用，并支持开放、标准的SOA参考架构。
IBM已将其全球领先及市场占有率第一的SOA参考架构捐赠给The Open Group，以建立全球厂商中立的标准，SOA参考架构图如下：
点击图片查看大图
SOA参考架构可分为九个层次:
Layer 1: Existing Application Assets Layer 现有的应用资产层
Layer 2: The Service Component Layer 服务组件层
Layer 3: Services Layer 服务层
Layer 4: Business Process Layer 业务流程层
Layer 5: Consumer Layer 消费者层
Layer 6: Integration Layer 整合层 (企业服务总线)
Layer 7: Quality of Service Layer 服务质量层 (安全、管理和监控的基础设施服务) Layer 8: Information Architecture Layer 信息架构层 (数据架构(元数据)和商业智能)
Layer 9: Governance Layer 治理层
金蝶是The Open Group在中国的首个会员，在未来双方携手提供企业架构及SOA咨询服务工作，协助明珠俱乐部会员以企业架构框架及SOA参考架构推动https://www.360docs.net/doc/4b9156678.html, 企业信息化工作，同时为会员提供培训及认证IT架构师和IT专家人才等专业服务。
点击图片查看大图
面向服务的软件体系架构总体设计分析
面向服务的软件体系架构总体设计分析 计算机技术更新换代较为迅速，软件开发也发生较多改变，传统软件开发体系已经无法满足当前对软件生产的需求。随着计算机不断普及，软件行业必须由传统体系向面向服务架构转变。随着软件应用范围不断增大，难度逐渐上升，需要通过成本手段，提高现有资源利用率。通过面向服务体系结构可提高软件行业应对敏捷性，实现软件生产的规模化、产业化、流水线化。 1 软件危机的表现 1.1 软件成本越来越高 计算机最初主要用作军事领域，其软件开发主要由国家相关部分扶持，因此无需考虑软件开发成本。随着计算机日益普及，计算机已经深入到人们生活中，软件开发大多面向民用，因此软件开发过程中必须考虑其开发成本，且计算机硬件成本出现跳水现象，由此导致软件开发成本比例不断提升。 1.2 开发进度难以控制 软件属于一种智力虚拟产品，软件与其他产品最大不同是其存在前提为内在逻辑关系。相较于计算机硬件粗生产情况，传统工作中的加班及倒班无法应用到软件开发中，提升软件开发进度无法通过传统生产方法实现。且在软件开发过程中会出现一些意料不到的因素，影响软件开发流程，导致软件开发未按照预期计划展开。由此可见不仅软件项目开发难度不断增加，软件系统复杂复杂性也不断提升，即使增加
开发人手也未必能取得良好效果。 1.3 软件质量难以令人满意 软件开发另一常见问题就是在软件开发周期内将产品开发出来，但软件本身表现出的性能却未达到预期目标，难以满足用户多方位需求。该问题属于软件行业开发通病，当软件程序出现故障时会导致巨大损失。在此过程中软件开发缺乏有效引导，开发人员在开发过程中往往立足于自身想法展开软件开发，因此软件开发具有较强主观性，与客户想法不一致，因此导致软件产品质量难以让客户满意。 1.4 软件维护成本较高 与硬件设施一样，软件在使用过程中需要对其进行维护。软件被开发出来后首先进行公测，发现其软件存在的问题，并对其重新编辑提升软件性能，从而为客户提供更好服务。其次软件需要定时更新，若程序员在开发过程中并未按照相关标准执行会导致其缺乏技术性文档，提升软件使用过程中的维护难度。另外在新增或更新软件过程中可能导致出现新的问题，影响软件正常使用，并可能造成新的问题。由此可见软件开发成功后仍旧需要花费较高成本进行软件维护。 2 面向服务体系架构原理 2.1 面向服务体系架构定义 面向服务体系构架从本质上是一种应用体系架构，体系所有功能均是一种独立服务，所有服务均通过自己的可调用接口与程序相连，因此可通过服务理论实现相关服务的调动。面向服务体系构架从本质上来说就是为一种服务，是服务方通过一系列操作后满足被服务方需求的
面向服务的架构标准SOA
面向服务的架构标准领先技术不意味厂商锁定XML和Web服务正在作为面向服务的架构(SOA)的平台来出现，它既可用于企业内部通信，也可用于企业间通信。作为第一个既支持SOA编写，也支持SOA 利用的Java集成开发环境(IDE)，WebLogic Workshop天生就带上了专有创新的印记。从那时起，BEA通过多种机制，从开放标准到开放源代码，已经实现了对这些创新进行投资保护的承诺，使得开发人员可以充分利用BEA的尖端生产率和集成特性，而不必担心锁定在某一厂商。下面，让我们一起来看看在Workshop中基于SOA的关键创新，以及在每种情况下是如何保护投资的。 什么是SOA? XML和Web服务是当今的热门技术，因为它们在实现面向服务的架构(SOA)上担当了重要的角色。目前独立的、而且通常是相互孤立的应用程序，制约了业务服务的共享，SOA则正在解决这一问题。通过给单个业务操作进行定义或在表层加上“服务访问点”，IT组织能够： ?使IT资源与其业务功能更密切地结合在一起 ?通过以下方法的最佳组合和匹配，建立更加动态、更有效地利用成本的系统 ?购买和自建 ?自制和外包
?更迅速地发布“组合”应用程序(想想“Web流(Web flows)”和“工作流(work flows)”)，提供统一的、面向任务的跨业务视图 ?通过更加细致的增量管理需求和变化，在应用程序生命周期上获得更高的灵活性 ?用提供“业务透明性”的基础架构替换不透明的、“黑盒子”系统更容易—这种基础架构根据流经应用程序的总体信息，提供实时的业务智能。 对象和组件已经成功地在应用内提供了重用性(应用程序的定义是：以单元形式开发和部署的代码)。但是，SOA依赖的是在应用程序之间实现重用。用SOA把不同的应用程序互连起来，这根本不是什么新东西—想想以前定义分布式的、应用间通信架构的一些努力(不用费力想什么新的首字母缩略词)：?同步的(面向RPC)：CICS分布式程序链接(DPL)、分布式计算环境(DCE)、分布式组件对象模型(DCOM)、公共对象请求代理体系结构(CORBA)IIOP、Java 远程方法调用(RMI)、关系数据库管理系统(RDBMS)存储过程，等等。 ?异步的(面向消息的)：CICS临时数据队列(TDQ)、Tuxedo ATM、IBM MQSeries、Tibco Rendezvous、Microsoft消息队列(MSMQ)、Java消息服务(JMS)，等等。 是什么使得应用的集成如何困难呢(而且，由此推出，为什么我们作为一个行业，还必须要实现一个统一的SOA)?这是因为，应用程序是由不同的人们，在不同的地点建立的，而且根据不同的计划部署的。任何方法，只要它
面向服务(SOA)技术架构规范
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
SOA面向服务的软件架构探讨
2007年10月 第24卷 第5期枣庄学院学报JOURNAL OF Z AOZHUANG UN I V ERSI TY Oct .2007Vol .24NO.5 S OA 面向服务的软件架构探讨 袁伟1,2 (1.华东师范大学软件学院,上海200062; 2.枣庄学院计算机科学系,山东枣庄277160) [摘 要]S OA 是一种新型的软件体系架构,本文着重介绍了S OA 的基本特点及其优越性,并对其发展作出展望. [关键词]S OA;服务;软件架构 [中图分类号]TP311.5 [文献标识码]A [文章编号]1004-7077(2007)05-0070-031 引言 近年来,在软件开发领域,S OA (Service -O riented A rchitecture,面向服务软件架构)成了热门的话题.作为一种新的开发理念和I T 生活方式,S OA 以其固有的松散耦合性与灵活的互操作性,受到众多的软件厂商的青睐,据Gartner 的预测,到2008年,S OA 将成为占有绝对优势的软件工程实践方法,它将结束传统的整体软件体系架构长达40年的统治地位.因此研究和应用基于S OA 架构的企业应用系统已经成为目前一个十分重要的研究课题,具有十分重要的现实意义. 2 S OA 概述 2.1产生背景 伴随着I nternet 的普及应用,信息技术的不断发展,在各行业领域内部出现大量基于网络的大量信息系统,这些系统各司其职,但相互之间往往缺乏很好地协作,易形成许多信息孤岛.此外,现代企业面临巨大的市场压力,需要随时应对不断变化的市场需求,客观上要求应用系统能够快速搭建并实施,做到“随需应变”.并且伴随着电子商务的繁荣发展,跨企业供应链协作需求也日益普及.因此,客观上需要有一种技术能够将构建于不同时期,不同类型的异构系统以及跨企业边界的软件系统进行集成整合.而传统软件架构已经无法满足需求,在这种背景下,S OA 面向服务的软件架构应运而生.基于S OA 架构的应用集成可以减少不同类型的I T 系统的依赖性,降低费用和I T 操作的复杂性;提高已部署系统的灵活性,同时排除了抑制业务创新的障碍. 2.2S OA 的定义 S OA 并不是一个新概念,早在1996年,Gartner Gr oup 就已经提出了S OA 的预言,近年来,随着S OA 的技术实现手段,特别是基于标准的集成技术(如W eb 服务和X ML )不断成熟,S OA 得以迅速风行起来. 所谓的S OA 就是面向服务的体系结构(service -oriented architecture,S OA )是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来.接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言.这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互. ? 07?①[收稿日期]2007-07-01 [作者简介]袁伟(1979-),男,山东枣庄人,枣庄学院计算机科学系助教,华东师范大学软件学院2006级硕士研究生,主要从 事软件工程和多媒体技术研究.
基于属性的访问控制(abac)的跨域访问控制面向服务的体系结构(soa)_本科论文
理工学院 毕业设计外文资料翻译 专业：通信工程 姓名： 学号： 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）和面向资源体系架构（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 中。
面向服务架构(Service-OrientedArchitecture
SOA 面向服务架构(Service-OrientedArchitecture，SOA)是一种架构模型，其基本思想是以服务为核心，将企业的IT资源整合成可操作的、基于标准的服务，使其能被重新组合和应用。SOA 的应用对突破企业信息化建设过程中长期存在的瓶颈，诸如信息孤岛、适应需求能力差、重复建设、新应用周期长等问题提供了有力的解决手段。 1.统一规范与标准。突破信息鸿沟制约与传统技术手段不同，SOA技术架构强调统一规划、统一标准、统一管理。通过SOA技术架构的应用，不仅辅助企业各业务部门制定科学合理的整体规划，而且有效解决企业信息化建设中因缺乏统一框架而带来的信息孤岛现象。为解决企业各业务部门间，部门内的互联互通难。资源浪费、重复建设等问题提供有力支持。 2.创新技术理念，提升应用水平SOA以服务为理念，通过面向眼务的方式组织开发，可以更准确地体现用户需求。服务以松耦合的状态存在于整个系统中，并可以随业务需求而变，一方面可以快速深度地满足用户需求。另一方面可以减少企业各业务部门中的业务冗余和重复开发。 3.改变建设模式，降低投资风险SOA基于全新的技术架构来规划产品与组织生产，将极大地变革软件生产和应用模式，从而满足用户的深层次需求。SOA提供了构建IT系统的全新方法，充分采用标准的软件产品和服务组件，最终形成高效开发、标准规范、业界支撑广、技术发展快的应用模式。 MVC
李彦宏首谈“框计算”：全新技术理念驱动产业升级 李彦宏指出，“框计算”为用户提供基于互联网的一站式服务，是一种最简单可依赖的互联网需求交互模式，用户只要在框中输入服务需求，系统就能明确识别这种需求，并将该需求分配给最优的应用或内容资源提供商处理，最终返回给用户相匹配的结果。 “框计算”驱动产业升级 首先，“框”是一个功能强大的需求收集器和分析器。在李彦宏提出“框计算”概念之前，其实个人计算机、互联网上已经有形形色色的各种计算框，词典框、对话框、搜索框……但这些各种各样的“框”，都只是在特定语境下才有意义。比如词霸里的词典框，用户只有在获取单词释义时，才会到这个框里输入内容；同样，用户在词典框里输入别的需求，词典框也不会给用户任何有意义的反馈。而李彦宏所提到的“框计算”的“框”，用户可以输入任何类型的需求，从某种意义上来说，这个“框”是万能的，因而也必须是“智能”的。 其次，由于“框”能在在互联网可选范围内根据用户需求自动匹配最佳的应用和服务，这个“框”又带有典型的操作系统特性。就像微软的视窗操作系统，上面可以运行Office、浏览器、杀毒软件等各种各样的应用软件。目前，词典、计算器、日历等简单应用已经能通过百度框直接运行，视频、杀毒、游戏、购物等互联网应用近期也有可能被框直接启动，如果越来越多的应用确实能在“框计算”平台上运行，“框”将对整个互联网产业的升级和发展产生巨大的拉动效应。 “框计算”的关键技术——需求识别和应用开放 “框计算”平台听起来非常神奇，而要通过“框计算”实现真正的基于互联网的一站式服务，有两个领域的关键技术需要突破。 首先是需求识别领域的技术突破。所谓“需求识别”，就是确定用户究竟要互联网为他做什么，这是互联网科学最复杂和最具技术含量的一个领域，下面又包括语义分析、行为分析、智能人机交互、海量计算处理等子领域。以搜索的用户需求识别为例，如有人希望从互联网得到一个“形容很开心的句子”，这个请求首先被拆成不同粒度的20个语义单位进行分析，后台要经过3亿次计算来识别这个需求，并在100亿个网页资源中检索并进行需求分配，而整个过程却需要在不到十分之一秒内完成。在用户需求识别技术方面，百度目前在全球范围内都是最强的，每天要从搜索框中获取超过10亿次搜索请求，并要一一在极短时间内对这些需求进行识别响应。尽管如此，当“框计算”将用户需求从搜索向其他应用领域极大程度延展时，“框计算”后台对用户需求的识别能力还需要大幅度的提升。 另一个需要突破的领域，就是“框计算”平台上的应用开放。“框计算”平台前端的需求识别能力再强，如果没有合适的应用在平台上及时响应这个需求，用户需求一站式满足的美好理想也不可能完美实现。反过来，要使更多的应用在“框计算”平台上实现就绪，光靠一两家公司肯定是不行的，而需要整个产业的共同努力。一方面，“框计算”平台要足够开放，要建立起足够开放的产业标准和技术接口，让想加入到这个平台的应用服务商能以最简单便捷的方式加入进来；另一方面，“框计算”平台也要能为平台上的应用服务商带来更大的利益，而这主要牵涉到“框计算”上游海量用户资源和需求的分配问题。