比特网(ChinaByte) 03月14日专栏 (邹震) 在SOA中，服务将以构件形态呈现。关于这一点，2007年5月全球发布的SOA国际标准中，关于SCA和SDO的描述已写得非常明白了。但长期以来，甚至到了今天，人们对于SOA与构件的关系的争论，却从来就没有停止过。
四年以前，当BEA、IBM等公司力推SOA概念时，国内以杨芙清为代表的中国软件资深专家却在不断地推介构件技术。一时间，SOA与构件技术被对立起来。
构件是一种软件开发技术，它的基本理念是将软件开发过程中会重复用到的部分封装起来，等到有新的同样的需求时调用。确切地说，SOA则是一种开发思想，通过服务对企业的应用需求进行展现。
在产生分歧后的第三年，业界已经公认构件是SOA的一种实现手段，SOA通过包容消除了和构件的分歧。但当SOA与构件的分歧消除以后，由于SOA是面向服务，所以相当数量的用户对构件和服务的关系又产生了误解。
事实上，构件与服务确实是既有区别，又有相同之处，甚至将构件和服务这两种被赋予了不同意义的“软件模块”进行相同定位也不为过。
从实施角度来看，构件与服务全都强调复用，通过这两种实现方法，也都可以降低用户的软件系统实施成本。而从开发角度来看，二者也都遵循软件设计最经典的思想“高内聚低耦合”，同时技术和手段也没有限制。
而另一方面，二者也确实存在着太多的不同。
首先，从使用周期来看，当企业的业务发生调整时，服务自然而然地也就中止了。而构件则不同，构件可以应用在多个软件系统中。从这点可以看出，构件与服务并不在一个应用层次上。
其次，二者在用户的系统中使用条件也不一样。构件只是一个代码包，所以必须配合系统中其他代码才能使用。而服务只要符合Web Service标准，经过部署就可以直接运行。
再次，二者的针对的对象是不同的。服务存在于业务架构之中，而构件则是针对业务架构，它的出发点首先要考虑的是需要实现的功能。虽然构件也被划分成“通用构件”和“领域构件”，但领域构件也只是限于实现某个领域的技术需求。
最后，二者的服务对象不尽相同。构件起源于软件产业内部，它的服务对象是软件厂商，而服务则源起于软件用户的需求，它最终会服务于企业。
事实上，构件到现在还存在一个致命的弱点，就是由于缺少标准的定义和规范，我们甚至还不能够严格地说出到底什么是构件。与构件的情况相反，SOA和服务则从定义到实施均有相关的规范标准。这样一来，尽管构件被越来越广泛的应用，但用户对构件的理解往往局限于它是SOA的实现手段。但这却可能只是用户的一种误解。
这源于用户普遍认为SOA是一种思想，而构件是一个个的代码包，但采用构件化开发软件，到了现在也可以上升为一种软件工程的思想。所以，我们可以说，构件确实是SOA的实现手段，但当构件化成为一种软件开发思想以后，SOA不能够全部包括构件。
确切地说，到目前为止，构件仍然是应用开发层面的概念，适用于企业应用的开发。SOA则适用于集成企业现有的应用系统。尽管如此，二者目前正在走向融合。SOA概念之外，有人提出了构件化的SOA。而企业应用在开发时也越来越强调要符合SOA标准。
软件与硬件长期以来形成了一种容器和水的促进关系。如水般的软件，需要如容器般的硬件来盛载它。但目前，水和容器的平衡关系已经被打破，软件的发展速度极大地落后于硬件的发展速度。这个时候，无论是硬件厂商，还是软件用户，都开始希望软件开发象制造业的流水线一样，通过组装就可以应用。而这种需求确实给构件化开发和构件本身的发展，提供了良好的机会。
另一方面，为了解决应用之间的互通互联，提升软件的复用性，SOA在应用层面也受到了来自软件厂商的极力追捧，以及用户的欢迎。
在软件界，一直存在一个临界点。这个临界点的一边，是软件供应方，他们关注软件的开发技术;临界点的另一方，则是软件用户，他们关注的是软件的实施。但SOA可能会扮演一个破坏者的角色，总有一天会打存这个临界点。这样，构件与SOA也许真的会殊途同归，最终统一成一个概念。
(作者系比特网特约专栏作家，本文谢绝转载。本文仅代表作者个人观点，不代表比特网观点)
