走向面向构件 (程序员)

本文出自《程序员》杂志，2005年第四期，“黄柳青”专栏。

引言

--------------------------------------------------------------------------------

软件一直是一个年轻的、技术驱动的行业。在早期，软件是计算机硬件系统的附属品。那时，硬件是计算机的主体，软件只是帮助硬件做“工作”的一些指令而已。软件表达的方式也是很硬的。有一台机器，象老式打字机的样子，但不是将字符打在白纸上，而是在硬纸片上穿出对应的孔。一段程序就象用三副扑克打拖拉机一样，厚厚的一叠哦！

虽然有了C++、Java、J2EE、.Net和无所不在的互联网应用，虽然软件不只是自成体系的一个行业，而且其繁荣程度甚至超过了硬件（硬件的进步太快了，反而失去了人们的关心和尊重？），但是软件的本质却没有发生变化：软件是硬件计算的一种描述，每一个高级的软件语句或多或少地对应着若干条机器指令。

随着软件系统的日益渗透，商业系统的日益庞大，这里面的问题也是越来越严重。现在的一个企业应用，常常会涉及企业的每一个部分，会由几十人编写几十万到几百万行代码来完成。另一方面，现代企业是在一个不断变化的动态环境中生存和发展的，因此，企业应用就需要不断地维护——即部分地改写一些现有软件。由几十万上百万的代码式变化因子，组成的不断变化的系统，其复杂度是人类历史上没有见过的。软件的安全性和质量可靠性，常常成为现代无所不在、无所不能的信息化系统的一个严重问题。

或许，我们可以抛开从计算机诞生之时就时时抱着的机器指令情节！

或许，我们不需要知道字节、指针和线程！

我们可以从商业业务的角度，从功能规格的角度来设想新的企业级软件系统！

面向构件和相关的企业构件总线技术（参见图1），正是一门学术界追求已久、企业界十年磨就的利剑。面向构件技术整合了传统的构件技术、模型驱动技术和面向服务技术，是软件行业的一根定海神针。我们很高兴在这个专栏里面，通过一系列的主题论讲来介绍正在世界上趋于流行的面向构件的理论和实践纲要。

 

什么是构件？

--------------------------------------------------------------------------------

在软件行业中，“构件”这个词是用得最多、含义最模糊的概念之一。比如，它可以用于ActiveX或Java Beans之类的用户界面构件，也可以用于数据库管理系统之类的重要架构，还可以用于所有可重用的软件。

我们在这里所谈的构件，是指某种自成一体、并有一个（或一组）清晰接口的软件。同时，我们还隐含地说明，构件应具有清晰的运行时和上线内涵。也就是说，该构件具备可供运行时访问的接口；并且，在软件开发生命周期的某个时间点，该构件可独立交付和安装。另外，我们还要求一个构件能方便地跟其他构件合并或组合，从而提供有用的功能——通常情况下，单个构件只有跟别的构件协同工作才能达到其功效。

构件是一种能插入到某系统中的物件。既然它们是能插入的物件，那么，必然有供它们插入的物件。关于软件构件的难点，不仅在于必须懂得如何建立一个有清晰接口的、自成一体的、有用的软件，还在于要保证在应用某合适的构件时有相应插口可供使用。比如，水壶是厨房的一个构件。如果它需要500V电源和五脚插座才能工作的话，那么这个水壶就没什么用处。当然，我们可以为水壶做一个专用的变压器，可是那样太不实用了。由此可见，可供构件插入的技术性承接，跟构件提供的接口同等重要。

在考虑构件时，大家有时会太多关心构件技术，而忘记了构件的使用者。其实，设计构件必须考虑到某类有一定技能的使用者（但常常很少注明）。比如，有些构件是供开发人员使用的，有些则是供终端用户使用的。

总的来说，我们可以用四个要素来陈述软件构件模型：构件本身、该构件的插口、构件与其他构件协作的能力、以及构件的使用者（参见图2）。

1．构件是一种自成一体的软件结构，它具有特定的用途，具备运行时界面，能自动上线，并且在建立前就知道特定的构件插口为何。

2．构件插口是某种软件，它可为支持性架构提供精确定义的、清晰的运行时界面，构件必须适合该架构。具备设计时界面是必要的，但还不够，因为在运行时该界面不存在，除非已另有软件来实现它，也就是说，已另有架构来实现它。

3．建造一个构件是为了跟别的构件组合且协同工作的。

4．构件插口和相应构件是为某些具备一定技巧和工具的使用者设计的。关于最后一点，我们还应注意以下两个问题：
构件用户可能并不具备建立该构件必需的技巧或工具。这意味着构件产品是分层次的，这样一来，某人的最终产品可能成为其他人的构件。
人们常常无法做到在建立构件的同时建立相应的插口——架构——来适合该构件。 
  
在我们关心的企业级应用层次上，除了以上谈到的基本要素外，企业构件还应具备如下两个特征：
可应对“企业级挑战”。此类构件在构思时就明确应对企业级分布式系统的挑战，这包括并行处理、安全、事务管理、数据库访问等许多问题。
它们“以单一形态代表某种业务概念”。这些构件并非一堆涵义不明的代码，它们明确代表了信息系统中对应的业务概念。
 

什么是面向构件的软件开发？

--------------------------------------------------------------------------------
 
面向构件的开发是一种软件开发手段，在开发周期的不同阶段和不同方面——包括需求分析、结构、设计、建立、测试、上线、支撑性技术架构、项目管理等，都以构件为基础。
该定义把面向构件开发的外延，从运用面向构件的思路建立软件，扩展到了整个软件开发周期——它的所有阶段和所有方面都以构件为中心。如果希望构件可随时用于组装，这些构件必须作为项目的零件来建造，此时面向构件显得特别有优势。确实，尽管这些构件尚未面世，用构件法来构思信息系统，仍是目前控制大型分布式系统开发复杂度的最佳方法。
 
面向构件软件生产的必要条件
当前，任何一个成熟行业的主要目标都是建立高效的生产能力。对于软件来说，我们把这样一种高效软件生产能力称为“软件工厂”。以成熟的面向构件的软件行业特征为基础，我们可以推断，对于一个“灵活的软件构件工厂”，以下是其必要条件：
必须通过大力降低开发、上线、个性化成本，以及向大型的高性能和可扩展系统演变，来降低软件开发方面的“制造成本”。换句话说，我们关注的不仅是分析—设计—开发这个生命周期，而是软件产品的整个寿命。
必须能快速回应“业务需求”的变化和“技术变化”。必须能以“订单生产”的方式，来应对某个垂直领域或某个特定客户的具体需求。必须能交付“高度个性化”和“可配置”的产品和流程。
必须能支撑建立既“高度模块化”又“高度整合”的软件。这两个术语听起来好象是矛盾的，但实际上并非如此：软件构件必须有精确定义的边界，同时归属于一个明确的结构。
必须存在“标准”，对构件规格和互动，进行技术和功能的双方面指导。
假设这些必要条件都满足，高效工厂存在，在这样一个工厂里进行面向构件开发的好处就可以罗列出来了。
 
 
面向构件软件生产的好处
承前启后。我们认为面向构件是一种软件制造中非常全面的手段。它涵盖了软件开发中的方方面面：从构思和生产个体构件，到经济地把构件组装成系统或联合系统，以及这些系统和联合系统的演变。作为一种手段，面向构件建立在所有最成功的技术、原理和过去的最佳实践基础上，从而得出一种涉及大型软件生产及其产业化支撑的软件开发理论和实践。面向构件不仅保留过去所有手段的优点，而且还在包括面向对象手段和分布式对象手段的同时，解决了其局限性。
能控制开发的复杂度。目前，领先的机构在采用面向构件时，主要是在大型系统开发中运用该手段，利用其以结构为中心和以可重用性为中心的特点，来控制项目的复杂度和风险。面向构件提出了完美的方法来划分业务域。面向构件能控制用构件组装大型系统产生的复杂度，而非建立这些构件。
改变了信息系统的本性。也许最重要的一点要归结到影响深远的关联性，它引起软件的本性——也即应用的本性——产生根本性变化。它从根本上撼动了概念，我们需要重新对应用作定义。在运行时，构件变得高度可见，这样一来就影响到了软件建立、组装、上线、测试、演变、市场推广、和销售的方式。面向构件的开发不仅是一种开发手段，还是一种上线手段，并由此引出新的市场推广方式和软件解决方案的购买方式。
使自治开发零件成为可能。用一套类似于自治配备单位的方式构造信息系统，可支持高度并行开发、测试和上线这样一个新的充满挑战的机会。挑战来自于不同的结构层，还有用自治构件真正实现并行开发所需要的概念。
能控制上线复杂度。把整个开发流程组织在构件周围，是一种能降低开发所有阶段的复杂度和成本的有效机制。在系统演变期，这样的成本降低效果更为显著，因为大量的系统改变或修正仅仅影响到某个构件。
涵盖开发的方方面面。面向构件的开发可以通过类似以下手段实现：在开发的所有方面都运用同一套精炼的统一概念。例如，企业内部的分布式构件及其延续性可用这种方法定义；通过这样的手段可以同时进行数据库建模和构件建模，只要两者之间没有实质性分离，就可以适用同一套原理。
涵盖整个软件生命周期。面向构件理论针对和顾及了完整的软件生命周期。它不仅涵盖了非常重要的开发周期，也涵盖了维护、上线、个性化等工作。整个软件供应链都受到以构件为中心手段的影响并得到简化。我们甚至喜欢采用面向构件的思路来编写用户手册和在线帮助。
缩短了上市时间。成熟的面向构件开发，会显著减少软件开发上市前所需要的时间。当使用构件框架和面向构件的模板时，这一点尤为显著。它使得通过现成的构件组装新系统变得高效和简便，把开发时间减少到我们今天看来难以置信的程度。
 

面向构件的体系结构

--------------------------------------------------------------------------------
 
认识任何复杂的事物，都应采取分而治之、然后综合的方式。我们从以下三方面，来认识面向构件的体系结构。
 
构件的计算层次
计算机科学，是一门将计算自动化的学科。于是，站在计算层次角度，对以构件为基本计算单元的面向构件理论进行考察，是再顺理成章不过的事情了。
按照计算层次的不同，我们可以将构件分为：页面构件、展现逻辑构件、业务流程构件、业务逻辑构件、运算逻辑构件、数据构件等。值得说明的是，应当对基于互联网的企业应用予以足够的重视，这一点在构件的分类中也有所体现。
 
构件的系统层次
我们还有必要考察构件的系统层次，因为我们希望拥有更大粒度的“积木”，这样可以将面向构件的优势发挥到最大化。构件的系统层次包括：构件接口、构件、构件包、构件子系统、构件系统、构件库等。
我们认为，分别从计算层次和系统层次对构件进行分类，是极具实践意义的——它们分别刻画了构件所承担的职责和构件的重用粒度（参见图3）。
 
 
建设面向构件的软件工厂
 
面向构件的开发过程并不制造所谓“白马非马”的神话，它所包含的要素和一般化的软件开发过程要素没有本质区别，都涵盖了需求、建模、设计、开发/组装、测试等。那么，面前构件的开发过程强大在何处呢？由于所有阶段都是以构件为基础，过程的每一步都可以从“积木式”的工作方式中受益。当这种“积木式”软件工厂影响到了软件建立、组装、上线、测试、演变、市场推广、和销售方式之后，当它连软件的市场推广方式和软件解决方案的购买方式也统统颠覆之后，就没有人会否认面向构件理念从根本上撼动了软件开发概念这一点了——工程的概念已经不完全合适了，再工程才是更能反映软件业界现实的词汇。
当然，要建设面向构件的软件工厂，仅对面向构件的理论体系、以及面向构件的开发过程有深入了解是不够的，我们还必须借助面向构件的技术支撑系统、以及面向构件的应用系统架构的力量。
前面谈到，面向构件开发的外延已经日益扩展到软件开发的方方面面。比如，建模、组装、开发、调试、发布、部署、运行、和管理环境等等，这些方面的工作都会受到面向构件理念的冲击。而正是面向构件的技术支撑系统，为面向构件开发的梦想提供了“工厂级”的强大支持。以建模为例，当前模型驱动开发对生产力的提升，已经得到业界的广泛认同；而面向构件技术将模型驱动这个强有力的杠杆整合进来，用于支持构件的“可视化创建”和“可视化组装”等。可以说，模型驱动和面向构件的结合所产生的“组合效应”，极大地简化了构件工厂的工作方式，提高了生产率。
商务和技术上的瞬息万变，岂能只看作是要防范的威胁，其实它也带来了莫大的机遇。企业构件总线技术是历经企业界十年磨砺的一柄利剑，它本质上是一种微内核架构模式的具体应用。微内核这种架构模式，就是为“应付变化”而生的，面向构件的技术支撑系统当然不会忽视它，而是将它作为“拥抱变化”的核心思想之一加以贯彻，企业构件总线就是具体体现。
面向构件的应用系统架构在技术层面，给予面向构件的技术支撑系统以有力支持。比如，数据总线、消息队列、面向服务、模型驱动、以及胖瘦客户端等技术，都在面向构件的应用系统架构中有出色表现。
 
面向构件的体系结构小结
 
综上所述，要全面认识面向构件的体系结构，必须从多角度进行深入考察（参见图4）。
我们从构件的系统层次、构件的计算层次、以及面向构件软件工厂的建设三个方面进行了纲要性地论述。值得说明的是，这三个方面是正交关系，将任何一个方面孤立出来代替对面向构件的全面理解，都是有失偏颇的。
 
 
面向构件走向成熟

--------------------------------------------------------------------------------
 
近年来，多方面的因素正促成面向构件技术的日趋成熟。
纵观商业企业的“生态环境”，未来将越来越不可预测，这是新经济最具挑战性的方面之一。而旧有的技术不能满足商业企业“随需应变”的要求，日显颓势。
另一方面，近年来的软件技术发展迅猛，并日趋成熟。比如应付软件本身复杂性的架构技术和框架技术，比如作为分而治之思想最新发展的AOP技术，比如分布计算方面的Web服务技术，再比着力提升开发抽象层次的模型驱动技术，等等。
企业界也非常活跃，面向构件的整合平台不断推出，其运营支持体系也日新月异。
总之，由于软件技术的成熟、企业应用的现有技术不能满足需求、以及面向构件的整合平台和运营支撑体系的推广等多方面的综合原因，面向构件的软件工厂正在走向成熟。
 
作者介绍：
黄柳青，普元软件公司创始人，董事兼首席技术官(CTO)。是面向构件领域的专家与先行者。