SOA从面向构件开始

SOA技术专题 SOA技术专题 ................................................................................................... 1 SOA从面向构件开始 ........................................................................................ 1 也谈SOA从面向构件开始 ........................................................................ 1 关于构件的一点随想 ................................................................................. 2 通向SOA－美国和中国不同的道路 ........................................................... 3 “SOA”的时代，“面向构件”老了吗？ .................................................... 8 高效率的中国式报表 ....................................................................................... 10

SOA从面向构件开始 构件，是构造应用软件的标准单元。 面向构件，是基于构件的软件开发方法、技术和标准。 SOA，面向服务的企业架构，服务成为企业应用的新资源。 是与非，应用为本，SOA成就企业架构，软件构件造。 远景，SOA从面向构件开始，面向构件从SOA开始。

也谈SOA从面向构件开始 我们说SOA从面向构件开始，就是SOA通过面向构件去实现，因为面向构件是SOA的自然实现方式。

.面向构件的概念着眼于软件的构造，其语义内涵包括： 1、层次化。软件呈现层次化构造，整体可以由一系列有内在结构的器官，即构件，构成。而构件可以由更小的构件构成。

2、可复用。这些构件可以在不同的软件中以相同的形式出现，完成大致相同的功能。 SOA概念着眼于软件的功能，其语义内涵包括：

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调用组件，他