SOA从面向构件开始.doc_第1页
SOA从面向构件开始.doc_第2页
SOA从面向构件开始.doc_第3页
SOA从面向构件开始.doc_第4页
SOA从面向构件开始.doc_第5页
已阅读5页,还剩6页未读 继续免费阅读

VIP免费下载

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

SOA 技术专题技术专题 SOA 技术专题1 SOA 从面向构件开始.1 也谈 SOA 从面向构件开始.1 关于构件的一点随想 2 通向 SOA美国和中国不同的道路 .3 “SOA”的时代, “面向构件”老了吗?.8 高效率的中国式报表10 SOA 从面向构件开始从面向构件开始 构件,是构造应用软件的标准单元。 面向构件,是基于构件的软件开发方法、技术和标准。 SOA,面向服务的企业架构,服务成为企业应用的新资源。 是与非,应用为本,SOA 成就企业架构,软件构件造。 远景,SOA 从面向构件开始,面向构件从 SOA 开始。 也谈也谈 SOA 从面向构件开始从面向构件开始 我们说SOASOA从面向构件开始,就是SOASOA通过面向构件去实现,因为面向构件 是SOASOA的自然实现方式。 .面向构件的概念着眼于软件的构造,其语义内涵包括: 1、层次化。软件呈现层次化构造,整体可以由一系列有内在结构的器官,即构 件,构成。而构件可以由更小的构件构成。 2、可复用。这些构件可以在不同的软件中以相同的形式出现,完成大致相同的 功能。 SOASOA概念着眼于软件的功能,其语义内涵包括: 1、层次化。软件的功能呈现层次化复合,综合功能由单项功能复合而成,复杂 功能由简单功能复合而成。 2、可外化。一个软件需要的功能可以由另一个软件提供。 由于“功能外化”可以看作是互联网时代功能复用的一种形式,面向构件与 SOA 完全同构。 因此,我们说 SOA 从面向构件开始,就是 SOA 通过面向构件去实现,因 为面向构件是 SOA 的自然实现方式。 从实现本质看 SOA 从面向服务开始而又基于构件的 SOA 架构体系层次结构中,构件应该是“service component”层的主要技术, 其之上的层次是“enterprise service”层。 (当然这个可以是系统内,也可以是系 统间); 再次看一下 JEE(这里聚焦在系统内) ,对应的就是 服务实现 和 服务接 口 这个层,并一定程度上借助 Facade Pattern。 因此赞成“SOA 从面向服务开始而又基于构件的”的说法。 关于构件的一点随想关于构件的一点随想 如果能让软件用构件的方式来思考问题,而不是 java,c,c+这些语言,那 么语言这个概念将会被取缔。 构件为什么不能成为一种标准呢? 关于如何选择粒度大小来构造世界,这是一个棘手的平衡问题。因为世界 太复杂,所以如果粒度太大,就会失去灵活性,而以至于不能胜任构造任意一 种世界这个任务;如果粒度太小,就是变得太复杂。所以得找一个最佳平衡点: 灵活而不致复杂,简洁而不致无用。 这个最佳平衡点,建筑业是砖块,而不是泥沙,或者房屋;汉语言是汉字, 而不是词汇或者笔画;英语是单词,而不是字母或句子;人类社会是人,而不 是器官或者群体;那么软件世界是什么呢?从机器语言,到汇编语言,再到高 级语言,这些都不是最佳平衡点,因为他们都是代码级的,虽然现在有面向对 象的概念,但是他的实际表现形式还是代码;目前来看只有构件才能胜任这个 重任。为什么?构件是图形级的,服务级的。一个构件本身就是一种服务,就 像一个汉字、一个单词,它们本身就有自己的意思。所以构件是终极之选。 产品 EOS(注:EOS 是 Embedded Operation System 嵌入式操作系统;)实现 了构件这一理念,所以需要提供的功能和具有的特性要求:构件运行平台,开 发平台,特性是跨平台,易使用(比如双击即可执行,所见即所得等等) ;构件 管理控制中心; 构件库有两种,一种是标准构件库,另一种用户自己开发构件 库;用户按照构件接口标准自己开发构件库有两种方式:一是用其他语言开发 构件,一是用构件生产构件;构件库就是词汇库。统一的用户界面,开发界面, 管理界面;统一的构件接口标准 当然还有很多很多,很细节化的东西,但 是最终的目的就是只要用户装上了 EOS,一切将变得容易。 构件将是革命性的,一统天下的。所有的一切,在目前看来技术上是可行的。 需要的只是努力,把它变为现实。SOA 只是东风,构件将是未来。 通向通向 SOA美国和中国不同的道路美国和中国不同的道路 想起宽带刚刚普及的时候,我在硅谷的家中也就开始安装了,不过麻烦的 事情是家中有 5 个电脑分布在 5 个不同的房间。房子是建于 1963 年的老房,所 以用网络线的连接就成为问题。最快速且便宜的解决方案是布裸线,否则就要 开腔凿洞。因此,家中的墙角和房门口的过道均成为网线的的落脚之处,难看 之极,但这是当时最简单的解决方案。直到无线局域网的出现,这个问题才得 以解决。 在中国的小区建设中,宽带的连接成为基本配置,所以老的社区曾经也有 同样的问题,而大量的新社区这个问题就不存在了。即便有无线局域网的技术, 有线宽带的接口还是都提供的。新社区的好处就是可以在一开始就部署新技术, 而不需要走老路。 如今,全世界都在嚷嚷SOA,那我们也需要考察美国人怎么部署SOA,中国 人怎么部署。研究这个问题,对我们软件公司还是对我们的客户都是有极大帮 助的,以免再一次被我们的“主流”厂商误导。因为,美国人如何部署SOA决定 美国SOA产品的特征,中国人怎么部署决定中国SOA产品的特性。 SOA的核心是把业务流程功能模块构件化,并对外提供标准的服务,基于 这些服务,企业内部的不同业务部门或是不同企业之间的业务整合就更加容易 一些。SOA的出现是由于互联网技术的出现,将原来各自为阵的 EAI(EAI:企业 应用系统集成)_市场标准化。 在美国由于多年的应用系统建设,企业的业务流程大多数以非标准的形式 被掩藏在各种各样的应用系统之中,比如 CRM 系统,ERP 系统,HR 系统, 信用评估系统等等。所以实现SOA架构的第一步是将那些掩藏在个应用系统之 中的业务功能模块切割开来,加以包装之后成为标准的服务构件,然后还要将 分散在不同系统中的数据整合包装成为数据服务,最后根据业务的需要同过 BPEL(注:关于 BPEL 的介绍:Q。什么是 BPEL;A: BPEL 是一门用于自动化 业务流程的形式规约语言。 用 XML 文档写入 BPEL 中的流程能在 Web 服务 之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合 BPEL 规范的平台或产品上执行。 所以,通过允许顾客们在各种各样的创作工具和执 行平台之间移动这些流程,BPEL 使得他们保护了他们在流程自动化上的投资。 尽管以前想使业务流程定义标准化,但 BPEL 已经引起了史无前例的兴趣,而 且它最早在软件供应商中获得大量认可。 Q: BPEL、WSBPEL 和 BPEL4WS 之间的区别是什么? A: 除了历史参考文献不同外,没有什么其他的不同。这些名字都涉及到相同的 未决标准。 “BPEL4WS”是起初规范的名字,它由 BEA、IBM 和 Microsoft 编 写和公布的。 “WSBPEL”目前是规范和未决标准的名称。当这个规范提交到 OASIS 时,出于 Web 服务相关标准的努力,按照 OASIS 命名方案更换了这个 名字。尽管如此,大部分团体仍然简单地称这个标准为“BPEL” 。 Q: 什么是 BPELJ? A: BPELJ 是 BPEL 和 Java 语言的组合,它允许一起运用这两种编程语言来 构建完整的业务流程应用程序。通过允许 BPEL 和 Java 一起工作, BPELJ 使 得每种语言可以做它最擅长的事。BPELJ 优于 BPEL,但没有它那么有竞争力。 Q:如何把 BPELJ 和 BPEL 联系起来,它们之间区别在哪里? A: BPEL 基本上向编程发展,它支持业务处理流程的逻辑。这些业务处理流程 是独立的应用程序,这些应用使用 Web 服务作为实现业务功能的活动。BPEL 不会成为一门通用的编程语言。然而,有人认为 BPEL 将和用来实现业务功能 的其他语言(少部分的编程)结合起来。为了方便 BPEL 和 Java 结合起来, BPELJ 对 BPEL 做了一些小的改动并且做了一些扩展。 Q: BPEL 不是针对业务分析员吗? 如果是,为什么把 Java 加进来? A: 有这么一个普遍的误解,那就是 BPEL 想达到非程序设计人员或者所谓的 “业务分析员”也能使用的程度。这个错误的概念部分根源于市场上许多针对 于这组用户的业务流程管理工具这样的一个事实。无可置疑,工具供应商为构 建 BPEL 和 BPELJ 流程提供了广泛的可视化接口,但是语言本身的目的是为 了开发人员。 Q: BPELJ 如何工作? A: 通过允许在 BPEL 流程定义中包含 Java 代码段(称为 Java 片断) ,BPELJ 使得 Java 和 BPEL 能够相互协作。 Q: 难道不应该考虑允许使用任何语言(C#、JavaScript 和 Java 等)来设计代 码片断吗? A: 这个片断背后想法是有代表性,我们希望它能用于许多不同的语言。然而, 要集成 BPEL 和一门特定的语言包含的不仅仅是用 XML 包装目标语言。集成 变量绑定、事务管理、调用路径等问题必须周全地定义,然而,每种语言是用 不同的方法解决这些问题,对所有语言进行统一的绑定是不现实的。所以, BPELJ 集中解决 BPEL 和 Java 的这些集成问题。我们期待着解决其他的语 言的集成问题 。 Q: 难道 BPELJ 没违反“ BPEL 中活动是 Web 服务,数据是 XML,数据结构用 XML 架构描述”这一原则吗? A: 并不是世界上所有的服务都是 Web 服务,它们也不应该是。用 J2EE 更适 合紧密耦合的系统,在这种系统中,容器提供的功能如安全和事务是特别有价 值的。那些把业务逻辑部署成 J2EE 组件的人员应该能够在业务流程中充分利 用这些组件,BPEL 是描述这个过程最好的一门语言。 一些人争论说在程序片断中用 Java 来完成少量计算和数据操作非常合适, 但是应该通过 XML/Web 服务视图强制所有服务调用。这是一个特别站不住脚 的观点。如果您有一个用 Java 代码片断写的流程,很明显,有一个 Java 开发 人员参与创建这个流程。 这意味着您可能有下面的设想:有一个开发人员熟悉用 Java 调用组件, 他想用 Java 操纵组件的输入和输出。迫使那个人把所有的调用看成好像是调 用 Web 服务一样,这会产生一层混乱,阻止考虑业务逻辑。 Q: 这意味着现在用在 WebLogic Integration 8.1 上的流程定义无效了吗? A: 根本不会,BEA 在 2003 年策划并倡导了 JSR 207,把流程定义(命名为 “JPD” )提交给 WebLogic Integration 8.1,并把它作为小组工作的初始基础。 BEA 和 IBM 已经提交 BPELJ 给 JSR 207 工作小组考虑。BPELJ 和 JPD 有很多相同的地方,事实上它已经开始详细设计使得今后 JPD 能平稳迁移到 BPELJ 上 。 Q: 如何把 BPELJ 和 JSR 207 联系起来? A: BPELJ 已经提交给 JSR 207,并建议考虑使用 BPELJ 作为 JSR 工作的基 础。 Q: 这对 BPEL 意味着什么?它将会作为一个标准分裂出来么? IBM 和 BEA 正在放弃 BPEL 么? A: 根本不会。BPELJ 是一个完全在 BPEL 标准的核心思想和意图之内的延伸。 为了提供一个完全的流程设计环境,一直以来都希望 BPEL 能和其他的语言结 合。IBM 和 BEA 都承诺支持 BPEL 并且继续作为 OASIS 的主要的贡献者, 正在努力达到语言的标准化。 Q: BEA 对于 BPEL 和 BPELJ 的产品计划是什么? A: 对于在 2004 年春季时间范围内的 WebLogic Integration 8.1,BEA 将提供 一个 BPEL 导出工具 ,在下一个重要的 WebLogic Integration 发布中充分支持 最终 BPEL 标准。 BEA 也在下一个重要的 WebLogic Integration 发布中对 BPELJ 提供充分的支持。 Q: 如果我现在用 WebLogic Integration 8.1 会怎样呢?我能迁移到 BPELJ 吗? A: 是的,在下一个重要的 WebLogic Integration 发布中, BEA 将为从 JPD 自动迁移到 BPEL/BPELJ 上提供工具。-BPEL 介绍#)将分散的服务连接成 为新的服务。所以美国实现SOA的方法为: 1。对原有业务流程的提取和包装成为服务构件(SCA) ; 2。对原有数据的整合包装成为数据服务(SDO) ; 3。用BPEL实现新的流程。 这个做法的可行性基于一个重要前提:原有的业务流程可以被切割包装 (代价问题) ,原有的数据可以在一定程度上被标准化包装成为服务,如果所有 的系统都需要通过人工切割和包装则代价太大,必须存在一次切割多次复用的 情况,否则切割的环节无法产品化。由于美国企业的应用系统大量采用了有限 厂商的产品比如 SAP,ORACLE,SIEBLE 等,一定程度的标准切割是存在的, 尤其是多年的 EAI 实践,为切割的标准化打下了基础。尽管如此,大量的基于 人工服务的切割还是必须的,所以,印度人有饭吃。而这些切割的工作与中国 软件外包企业多半无关。 因此,我们可以预见美国制造的SOA产品将把具有标准切割及打包功能作 为重要的卖点,也是产品的价值所在。市场决定产品的特征,就这么简单的逻 辑。 中国的 SOA 如何实现呢?我们的预见是多半是把系统按照 SOA 提供的标 准来建设,主流是把系统建设成为 SOA 标准的系统,而不是切割和包装,那 些需要切割和包装的系统绝大多数依赖于服务而不是产品。作出这个判断基础 两个前提: 11。原有的系统很少; 22。那些已经存在的系统很少是能够被标准化切割的; 因此,在中国开发 SOA 产品最重要的特征是如何在一个标准的平台上 (框架内)构造企业所需要的所有标准服务,并且容易管理和发展(变化) 。中 国市场(客户)面临的主要问题有如下几条: 还没有采用 SOA 架构标准; 原有的系统难以切割,业务流程难以提取; 复杂的数据难以整合; 新建的系统没有统一的技术架构,产生更多的标准化问题。 考察中国的市场我们可以作出如下的预言: 11。SOA 将被主流市场接受成为标准的体系结构; 22。美国主流的 SOA 产品在中国会水土不服; 33。原有系统将主要依靠服务来切割,或者推倒重来; 44。大量的新建系统将采用标准的小颗粒构件构造流程级别的标准服务构件; 5。5。普元面向构件的中间件将成为 SOA 主流中的中国主流。 “SOA”的时代,的时代, “面向构件面向构件”老了吗?老了吗? 引子 “SOA”这个词已经不算是新了,在“2004 BEA 中国大会”上,BEA 就 已经是满场宣扬这个概念。经过这几年 IBM、Oracle、BEA、SAP 等大公司的 努力和推进,被越炒越热,很多软件厂商都在“生拉硬攀”与“SOA”的关系。 2005 年底,SCA 标准组织的成立更进一步促进“SOA”迈向了标准化,而普 元作为唯一的中国厂商也加入了这个国际化的标准组织。表明了普元未来的产 品将靠近国际标准, “SOA”也将成为其产品的一个重要特征。普元所一直倡 导的“面向构件”也悄然的变为“SOA 从面向构件开始” 。 “SOA”逐渐成为软件行业的时代主流,而“面向构件”技术是否已经有 些衰老了呢? 构件技术在软件行业的认知,尚处“少年” 假如制造业和建筑业对构件技术的认知和应用水平比作“高中”的话,那 么我们的软件行业的构件技术最多处于“小学”水平。 从计算机制造业来讲,为什么不同厂家的 CPU、主板、硬盘、内存、显卡、 机箱、电源、显示器、键盘和鼠标能够“DIY”成为一台计算机?为什么这个 计算机可以选用不同厂家的操作系统?为什么时隔一段时间后,用户可以轻易 的对显卡和 CPU 等部件进行升级?归根结底是“构件技术”起到了关键的作 用,CPU 和内存等所有这些部件都已经作为“构件”被标准化。 软件行业对构件技术的认知和应用水平的“低下”决定了当前应用软件还 不能象制造业那样“随需构建” 。 “面向构件”技术非但没有老去,反而是刚刚开始。 新技术的出现促进了“面向构件”技术的发展 “USB”技术的出现使我们的计算机可以以更加高效和便捷的方式接入更 多的外部设备,也造就了很多以“USB”为接口的硬件“构件”的诞生。(诸如 USB 台灯、USB 风扇、USB 手机充电器等等) 同样,对软件产业而言,XML 技术、Web Service 技术、 AOP、Ajax、IOC 等技术的涌现和不断成熟,也促进了构件技术的不断发展, 应用了新技术的构件也随之不断的产生。 一个 USB 的构件(设备)能否应用于一台计算机是由这台计算机的“架构” 决定的。而每种构件都有其所依赖的条件和环境。这些条件和环境都定义在了 “架构”中。 “构件”必须匹配“架构” 当你想把一个 USB 设备直接的接在一个不支持 USB 技术的计算机上时, 这显然是做不到的。计算机的“架构”限定了其可以使用的构件范围。 软件的架构不仅仅决定了应用的层次,组成,和通讯机制,模块间的耦合 关系,同时也决定了其所采用的技术和标准。这些技术和标准同样也就制约了 构件的使用,这里讲的“标准”主要是指某种技术的特定版本,标准(版本) 决定了构件能否使用,能否发挥其最大效用。这就如同“USB2.0”的设备能在 “USB1.0”的接口上兼容,却不能发挥高速传输的特性一样。 因此, “构件”必须匹配“架构” , “架构 + 构件 + 环境 = 应用” 。这里 的环境包括了软件环境和硬件环境。 “SOA”就是一种架构,以 SOA 为架构的应用设计和实现不是一定要运 用“面向构件”技术,而单一引用“面向对象”技术的应用所提供的细粒度的 复用将无法满足“SOA”对粗粒度的业务组件复用的需要。结合了“面向对象” 的“面向构件”技术将能够满足“SOA”架构对各种粒度的组件复用的需求。 随着架构技术发展到 SOA,那么我们的“面向构件”也应该是基于 SOA 的构 件技术。 对普元构件技术的认知 普元是国内乃至世界上最早将构件技术运用于产品的软件公司。在普元 EOS 产品已经大量的运用了“面向构件”技术。 在 EOS 的 5.X 及更早的版本中,普元的构件是建立在其 EOS 独有的架构 基础之上的,所有的 EOS 构件也都是服务于其 EOS 架构中的展现引擎、业务 引擎、工作流引擎等核心上的。专有的架构和专有的构件及缺乏标准,使其很 难成就第三方构件市场。 而随着普元加入 SCA 国际化标准组织,并且努力打造符合 SOA 的 EOS 产品,普元的“面向构件”技术则上升到了一个新的高度。一方面使其产品架 构得到了很大提升,另一方面,其构件的标准化也会赢得更多第三方构件厂商 的支持。 结论 “SOA”的发展带动了“面向构件”技术, “SOA”代表了应用的架构, 代表了整体结构;“构件”代表了应用的组成,代表了局部和构建单元。 “架构” 和“面向构件”代表了软件技术发展的两条主线,解决的是两个不同领域的问 题,两种技术是并行发展,在发展过程中必定是相辅相成。 声明声明:本文仅代表笔者个人的观点。 高效率的中国式报表高效率的中国式报表 时间:时间:2007 年年 03 月月 29 日星期四日星期四 09:30-11:30 地点:在线形式地点:在线形式 主题:高效率的中国式报表主题:高效率的中国式报表 主讲人:丁向武主讲人:丁向武 94 年从清华进入一路之隔的软件所学习软件工程,毕业后在软件所从事分布年从清华进入一路之隔的软件所学习软件工程,毕业后在软件所从事分布 式对象研究,参与了多个政府研究项目的研发。进入中科国际后,开发了多个式对象研究,参与了多个政府研究项目的研发。进入中科国际后,开发了多个 大型分布式软件项目。大型分布式软件项目。04 年进入普元,从事软件产品开发。在近十年的项目年进入普元,从事软件产品开发。在近十年的项目 开发经历中,积累了丰富的软件开发经验,对企业级软件的开发有自己的理解。开发经历中,积累了丰富的软件开发经验,对企业级软件的开发有自己的理解。 目前在普元主持开发报表产品。目前在普元主持开发报表产品。 课程简介:课程简介: 在目前的企业级软件市场中,报表产品有很多,国外的产品如在目前的企业级软件市场中,报表产品有很多,国外的产品如 Crystal、StyleReport、FormulaOne 等,国内的产品有润乾、数巨、等,国内的产品

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论