SOA与面向构件

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”的时代，“面向构件”老了吗？

引子

“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的构件技术。

结论

“SOA”的发展带动了“面向构件”技术，“SOA”代表了应用的架构，代表了整体结构；“构件”代表了应用的组成，代表了局部和构建单元。“架构”和“面向构件”代表了软件技术发展的两条主线，解决的是两个不同领域的问题，两种技术是并行发展，在发展过程中必定是相辅相成。