从面向构件开始

1、SOA技术专题SOA技术专题1SOA从面向构件开始1也谈SOA从面向构件开始1关于构件的一点随想2通向SOA美国和中国不同的道路3“SOA”的时代，“面向构件”老了吗？8高效率的中国式报表10SOA从面向构件开始构件，是构造应用软件的标准单元。面向构件，是基于构件的软件开发方法、技术和标准。SOA，面向服务的企业架构，服务成为企业应用的新资源。是与非，应用为本，SOA成就企业架构，软件构件造。远景，SOA从面向构件开始，面向构件从SOA开始。也谈SOA从面向构件开始我们说SOA从面向构件开始，就是SOA通过面向构件去实现，因为面向构件是SOA的自然实现方式。.面向构件的概念着眼于软件的构造，其

2、语义内涵包括：1、层次化。软件呈现层次化构造，整体可以由一系列有内在结构的器官，即构件，构成。而构件可以由更小的构件构成。2、可复用。这些构件可以在不同的软件中以相同的形式出现，完成大致相同的功能。SOA概念着眼于软件的功能，其语义内涵包括：1、层次化。软件的功能呈现层次化复合，综合功能由单项功能复合而成，复杂功能由简单功能复合而成。2、可外化。一个软件需要的功能可以由另一个软件提供。由于“功能外化”可以看作是互联网时代功能复用的一种形式，面向构件与SOA完全同构。因此，我们说SOA从面向构件开始，就是SOA通过面向构件去实现，因为面向构件是SOA的自然实现方式。从实现本质看SOA从面向服务开

3、始而又基于构件的SOA架构体系层次结构中，构件应该是“service component”层的主要技术，其之上的层次是“enterprise service”层。（当然这个可以是系统内，也可以是系统间）;再次看一下JEE（这里聚焦在系统内），对应的就是 服务实现 和 服务接口 这个层，并一定程度上借助Facade Pattern。因此赞成“SOA从面向服务开始而又基于构件的”的说法。关于构件的一点随想如果能让软件用构件的方式来思考问题，而不是java,c,c+这些语言，那么语言这个概念将会被取缔。构件为什么不能成为一种标准呢？关于如何选择粒度大小来构造世界，这是一个棘手的平衡问题。因为世界太复

4、杂，所以如果粒度太大，就会失去灵活性，而以至于不能胜任构造任意一种世界这个任务；如果粒度太小，就是变得太复杂。所以得找一个最佳平衡点：灵活而不致复杂，简洁而不致无用。这个最佳平衡点，建筑业是砖块，而不是泥沙，或者房屋；汉语言是汉字，而不是词汇或者笔画；英语是单词，而不是字母或句子；人类社会是人，而不是器官或者群体；那么软件世界是什么呢？从机器语言，到汇编语言，再到高级语言，这些都不是最佳平衡点，因为他们都是代码级的，虽然现在有面向对象的概念，但是他的实际表现形式还是代码；目前来看只有构件才能胜任这个重任。为什么？构件是图形级的，服务级的。一个构件本身就是一种服务，就像一个汉字、一个单词，它们本

5、身就有自己的意思。所以构件是终极之选。产品EOS(注:EOS是Embedded Operation System嵌入式操作系统;)实现了构件这一理念，所以需要提供的功能和具有的特性要求：构件运行平台，开发平台，特性是跨平台，易使用（比如双击即可执行，所见即所得等等）；构件管理控制中心； 构件库有两种，一种是标准构件库，另一种用户自己开发构件库；用户按照构件接口标准自己开发构件库有两种方式：一是用其他语言开发构件，一是用构件生产构件；构件库就是词汇库。统一的用户界面，开发界面，管理界面；统一的构件接口标准 当然还有很多很多，很细节化的东西，但是最终的目的就是只要用户装上了EOS，一切将变得容易。

6、构件将是革命性的，一统天下的。所有的一切，在目前看来技术上是可行的。需要的只是努力，把它变为现实。SOA只是东风，构件将是未来。通向SOA美国和中国不同的道路想起宽带刚刚普及的时候，我在硅谷的家中也就开始安装了，不过麻烦的事情是家中有5个电脑分布在5个不同的房间。房子是建于1963年的老房，所以用网络线的连接就成为问题。最快速且便宜的解决方案是布裸线，否则就要开腔凿洞。因此，家中的墙角和房门口的过道均成为网线的的落脚之处，难看之极，但这是当时最简单的解决方案。直到无线局域网的出现，这个问题才得以解决。在中国的小区建设中，宽带的连接成为基本配置，所以老的社区曾经也有同样的问题，而大量的新社区这个

7、问题就不存在了。即便有无线局域网的技术，有线宽带的接口还是都提供的。新社区的好处就是可以在一开始就部署新技术，而不需要走老路。如今，全世界都在嚷嚷SOA，那我们也需要考察美国人怎么部署SOA，中国人怎么部署。研究这个问题，对我们软件公司还是对我们的客户都是有极大帮助的，以免再一次被我们的“主流”厂商误导。因为，美国人如何部署SOA决定美国SOA产品的特征，中国人怎么部署决定中国SOA产品的特性。SOA的核心是把业务流程功能模块构件化，并对外提供标准的服务，基于这些服务，企业内部的不同业务部门或是不同企业之间的业务整合就更加容易一些。SOA的出现是由于互联网技术的出现，将原来各自为阵的EAI(E

8、AI:企业应用系统集成)_市场标准化。在美国由于多年的应用系统建设，企业的业务流程大多数以非标准的形式被掩藏在各种各样的应用系统之中，比如CRM系统，ERP系统，HR系统，信用评估系统等等。所以实现SOA架构的第一步是将那些掩藏在个应用系统之中的业务功能模块切割开来，加以包装之后成为标准的服务构件，然后还要将分散在不同系统中的数据整合包装成为数据服务，最后根据业务的需要同过BPEL(注：关于BPEL的介绍：Q。什么是BPEL；A: BPEL是一门用于自动化业务流程的形式规约语言。 用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BP

9、EL规范的平台或产品上执行。 所以，通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程，BPEL使得他们保护了他们在流程自动化上的投资。尽管以前想使业务流程定义标准化，但BPEL已经引起了史无前例的兴趣，而且它最早在软件供应商中获得大量认可。 Q: BPEL、WSBPEL和 BPEL4WS之间的区别是什么? A: 除了历史参考文献不同外，没有什么其他的不同。这些名字都涉及到相同的未决标准。“BPEL4WS”是起初规范的名字，它由BEA、IBM和Microsoft编写和公布的。“WSBPEL”目前是规范和未决标准的名称。当这个规范提交到OASIS时,出于Web服务相关标准的努力，按照O

10、ASIS命名方案更换了这个名字。尽管如此，大部分团体仍然简单地称这个标准为“BPEL”。 Q: 什么是 BPELJ？ A: BPELJ 是BPEL和Java 语言的组合，它允许一起运用这两种编程语言来构建完整的业务流程应用程序。通过允许BPEL和Java一起工作， BPELJ使得每种语言可以做它最擅长的事。BPELJ优于BPEL，但没有它那么有竞争力。 Q:如何把BPELJ和 BPEL联系起来，它们之间区别在哪里？ A: BPEL基本上向编程发展，它支持业务处理流程的逻辑。这些业务处理流程是独立的应用程序，这些应用使用Web服务作为实现业务功能的活动。BPEL 不会成为一门通用的编程语言。然而

11、，有人认为BPEL将和用来实现业务功能的其他语言（少部分的编程）结合起来。为了方便BPEL和Java 结合起来，BPELJ对BPEL做了一些小的改动并且做了一些扩展。 Q: BPEL不是针对业务分析员吗? 如果是，为什么把Java加进来? A: 有这么一个普遍的误解，那就是BPEL想达到非程序设计人员或者所谓的“业务分析员”也能使用的程度。这个错误的概念部分根源于市场上许多针对于这组用户的业务流程管理工具这样的一个事实。无可置疑，工具供应商为构建BPEL和BPELJ流程提供了广泛的可视化接口，但是语言本身的目的是为了开发人员。 Q: BPELJ如何工作？ A: 通过允许在BPEL流程定义中包含

12、Java代码段（称为Java片断），BPELJ使得Java 和BPEL能够相互协作。 Q: 难道不应该考虑允许使用任何语言（C#、JavaScript和Java等）来设计代码片断吗？ A: 这个片断背后想法是有代表性，我们希望它能用于许多不同的语言。然而，要集成BPEL和一门特定的语言包含的不仅仅是用XML包装目标语言。集成变量绑定、事务管理、调用路径等问题必须周全地定义，然而，每种语言是用不同的方法解决这些问题，对所有语言进行统一的绑定是不现实的。所以， BPELJ集中解决 BPEL 和 Java的这些集成问题。我们期待着解决其他的语言的集成问题 。 Q: 难道BPELJ 没违反“ BPEL

13、中活动是Web服务，数据是XML,数据结构用XML架构描述”这一原则吗？ A: 并不是世界上所有的服务都是Web服务，它们也不应该是。用J2EE更适合紧密耦合的系统，在这种系统中，容器提供的功能如安全和事务是特别有价值的。那些把业务逻辑部署成J2EE组件的人员应该能够在业务流程中充分利用这些组件，BPEL是描述这个过程最好的一门语言。 一些人争论说在程序片断中用Java来完成少量计算和数据操作非常合适，但是应该通过XML/Web服务视图强制所有服务调用。这是一个特别站不住脚的观点。如果您有一个用Java代码片断写的流程，很明显，有一个Java开发人员参与创建这个流程。 这意味着您可能有下面的设

14、想：有一个开发人员熟悉用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

15、能平稳迁移到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:

16、对于在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介绍#)将分散的服务连接成为新的服务。所以美

17、国实现SOA的方法为：1。对原有业务流程的提取和包装成为服务构件（SCA）；2。对原有数据的整合包装成为数据服务（SDO）；3。用BPEL实现新的流程。这个做法的可行性基于一个重要前提：原有的业务流程可以被切割包装（代价问题），原有的数据可以在一定程度上被标准化包装成为服务，如果所有的系统都需要通过人工切割和包装则代价太大，必须存在一次切割多次复用的情况，否则切割的环节无法产品化。由于美国企业的应用系统大量采用了有限厂商的产品比如SAP，ORACLE，SIEBLE等，一定程度的标准切割是存在的，尤其是多年的EAI实践，为切割的标准化打下了基础。尽管如此，大量的基于人工服务的切割还是必须的，所以

18、，印度人有饭吃。而这些切割的工作与中国软件外包企业多半无关。因此，我们可以预见美国制造的SOA产品将把具有标准切割及打包功能作为重要的卖点，也是产品的价值所在。市场决定产品的特征，就这么简单的逻辑。中国的SOA如何实现呢？我们的预见是多半是把系统按照SOA提供的标准来建设，主流是把系统建设成为SOA标准的系统，而不是切割和包装，那些需要切割和包装的系统绝大多数依赖于服务而不是产品。作出这个判断基础两个前提：11。原有的系统很少；22。那些已经存在的系统很少是能够被标准化切割的；因此，在中国开发SOA产品最重要的特征是如何在一个标准的平台上（框架内）构造企业所需要的所有标准服务，并且容易管理和发

19、展（变化）。中国市场(客户)面临的主要问题有如下几条：还没有采用SOA架构标准；原有的系统难以切割，业务流程难以提取；复杂的数据难以整合；新建的系统没有统一的技术架构，产生更多的标准化问题。考察中国的市场我们可以作出如下的预言：11。SOA将被主流市场接受成为标准的体系结构；22。美国主流的SOA产品在中国会水土不服；33。原有系统将主要依靠服务来切割，或者推倒重来；44。大量的新建系统将采用标准的小颗粒构件构造流程级别的标准服务构件；5。5。普元面向构件的中间件将成为SOA主流中的中国主流。“SOA”的时代，“面向构件”老了吗？引子“SOA”这个词已经不算是新了，在“2004 BEA中国大会

20、”上，BEA就已经是满场宣扬这个概念。经过这几年IBM、Oracle、BEA、SAP等大公司的努力和推进，被越炒越热，很多软件厂商都在“生拉硬攀”与“SOA”的关系。2005年底，SCA标准组织的成立更进一步促进“SOA”迈向了标准化，而普元作为唯一的中国厂商也加入了这个国际化的标准组织。表明了普元未来的产品将靠近国际标准，“SOA”也将成为其产品的一个重要特征。普元所一直倡导的“面向构件”也悄然的变为“SOA从面向构件开始”。“SOA”逐渐成为软件行业的时代主流，而“面向构件”技术是否已经有些衰老了呢？构件技术在软件行业的认知，尚处“少年”假如制造业和建筑业对构件技术的认知和应用水平比作“高

21、中”的话，那么我们的软件行业的构件技术最多处于“小学”水平。从计算机制造业来讲，为什么不同厂家的CPU、主板、硬盘、内存、显卡、机箱、电源、显示器、键盘和鼠标能够“DIY”成为一台计算机？为什么这个计算机可以选用不同厂家的操作系统？为什么时隔一段时间后，用户可以轻易的对显卡和CPU等部件进行升级？归根结底是“构件技术”起到了关键的作用，CPU和内存等所有这些部件都已经作为“构件”被标准化。软件行业对构件技术的认知和应用水平的“低下”决定了当前应用软件还不能象制造业那样“随需构建”。“面向构件”技术非但没有老去，反而是刚刚开始。新技术的出现促进了“面向构件”技术的发展“USB”技术的出现使我们的

22、计算机可以以更加高效和便捷的方式接入更多的外部设备，也造就了很多以“USB”为接口的硬件“构件”的诞生。(诸如USB台灯、USB风扇、USB手机充电器等等)同样，对软件产业而言，XML技术、Web Service技术、AOP、Ajax、IOC等技术的涌现和不断成熟，也促进了构件技术的不断发展，应用了新技术的构件也随之不断的产生。一个USB的构件(设备)能否应用于一台计算机是由这台计算机的“架构”决定的。而每种构件都有其所依赖的条件和环境。这些条件和环境都定义在了“架构”中。“构件”必须匹配“架构”当你想把一个USB设备直接的接在一个不支持USB技术的计算机上时，这显然是做不到的。计算机的“架构

23、”限定了其可以使用的构件范围。软件的架构不仅仅决定了应用的层次，组成，和通讯机制，模块间的耦合关系，同时也决定了其所采用的技术和标准。这些技术和标准同样也就制约了构件的使用，这里讲的“标准”主要是指某种技术的特定版本，标准（版本）决定了构件能否使用，能否发挥其最大效用。这就如同“USB2.0”的设备能在“USB1.0”的接口上兼容，却不能发挥高速传输的特性一样。因此，“构件”必须匹配“架构”，“架构 + 构件 + 环境 = 应用”。这里的环境包括了软件环境和硬件环境。“SOA”就是一种架构，以SOA为架构的应用设计和实现不是一定要运用“面向构件”技术，而单一引用“面向对象”技术的应用所提供的细

24、粒度的复用将无法满足“SOA”对粗粒度的业务组件复用的需要。结合了“面向对象”的“面向构件”技术将能够满足“SOA”架构对各种粒度的组件复用的需求。随着架构技术发展到SOA，那么我们的“面向构件”也应该是基于SOA的构件技术。对普元构件技术的认知普元是国内乃至世界上最早将构件技术运用于产品的软件公司。在普元EOS产品已经大量的运用了“面向构件”技术。在EOS的5.X及更早的版本中，普元的构件是建立在其EOS独有的架构基础之上的，所有的EOS构件也都是服务于其EOS架构中的展现引擎、业务引擎、工作流引擎等核心上的。专有的架构和专有的构件及缺乏标准，使其很难成就第三方构件市场。而随着普元加入SCA国际化标准组织，并且努力打造符合SOA的EOS产品，普元的“面向构件”技术则上升到了一个新的高度。一方面使其产品架构得到了很大提升，另一方面，其构件的标准化也会赢得更多第三方构件厂商的支持。结论“SOA”的发展带动了“面向构件”技术，“SOA”代表了应用的架构，代表了整体结构；“构件”代表了应用的组成，代表了局部和构建单元。“架构”和“面向构件”代表了软件技术发展的两条主线，解决的是两个不同领域的问题，两种技术是并行发展，在发展过程中必定是相辅相成。声明：本文仅代表笔者个人的观点。高效率的中国式报表时间：2007年03月29日星期四 09:30-11:30地点：在线形式