融合面向构件、服务、模型


 2005-12-12 00:00:00       758

在 小学入学开始,老师就教育我们形形色色的真理,而答案都是唯一的、绝对的。我们小学毕业的最后一课上,吴老师问1除以1是多少。在大家毫无疑虑的唱答之后,他在黑板上排出了算式:如果第一步先借一位数,1除以1就等于0.99999...。跳出框框,一个问题原来有新的答案,而不同的视角又是相通的!软件更是一个无比复杂的系统,在二三十年的高速发展之后,自然有不同的"流派"。如果我们在深入某项技术后,更能够多学习和融合各项技术、打破门户之见,那就能使自己的思想解放和升华。
从面向对象技术到构件、服务、模型、以至面向构件,每项技术都有互相借鉴,又有独到之处。本文从"大面向构件"的角度出发,讲解如何以构件为架构、以服务为构件的接口、以模型为构件接口的逻辑实现,从而使面向构件融合服务和模型的内容,形成可以充分从模型驱动开发(MDD)和面向服务架构(SOA)充分获益的"大面向构件"理念。图1简单表达了我们的核心理念,采用UML 2语法。


图1 构件、服务、模型的融合

构件
构件和对象的一大区别在于逻辑封装边界。对象调用往往在同一内存空间,所以有数值,指针等参数方式。构件往往在不同的内存空间以至不同的硬件设备上运行,只有数值参数。构件如何划分呢?分而治之在软件圈子里讨论的够多了,我倒是有意总结一下分而治之的两种方式(参见图2),从而找到架构--乃至面向构件架构--的位置。


图2 分而治之的两种方式

软件开发过程如此复杂,应当充分从两种分而治之的方式获益。一方面,应该从问题深度角度进行分而治之,先在比较高的抽象层次上构建虚拟解决方案--即软件架构。另一方面,全面进入诸多细节进行详细设计和编码实现时,应当在相对稳定的软件架构的基础之上,从问题广度角度进行分而治之(当然会依赖架构设计的合理性),比如按用户界面、业务逻辑、数据管理、系统交互等子系统进行分工,进行团队开发。
而面向构件的架构就是这样一种架构,它可以基于业务将整个系统化大为小,从合适的高度构建起一个抽象的系统,于是,其后的事情就解难为易了--每个业务构件有明确的业务责任,对外有明确的服务契约,成为一个可独立进行详细设计和实现的粒度适中的个体。

服务
服务与函数的关系,有如构件与对象的关系。服务以进出口数值的逻辑协议为边界,完全封装了实现的技术和内存模型。
协作和服务的关系,就如一个硬币的两面。协作被定义为"多个构件为了完成某种目标而进行的交互"。其实,构件之所以能发挥作用,就在于它参与为用户提供价值的各种协作。
在本专栏前面的文章中曾多次提到,构件是分层次的,我们称为离散的递归式分解(参见图3)。从我们的实践和业界的趋势来看,服务本身应当以粒度极大的构件--比如构件子系统或构件系统的接口的形式存在。

图3 多视角看待面向构件

采用多层次的构件体系,其意义在于:这种设计带来了良好的可重用性,节省了开发资源;通过已有构件的组合,就可以构造新的协作形成完成新功能的粒度更大的构件;这种方式非常自然和容易理解;至于设计的质量属性,这种设计还具有松耦合的优点。
由上述分析可见,可以将服务理解为一种协议、一种契约式的接口,它屏蔽了实现方法, 表达与外界的协作关系。

模型
我们听惯了软件专家谈模型,有时倒是觉得数学家说得更切中肯綮--这倒不奇怪,数学是计算机科学的母学科--模型的本质是抽象,它能通过强调激活你的思维和经验。
模型从某一个建模观点出发,抓住事物最重要的方面而简化或忽略其他方面。模型包含两个主要方面:语义方面的信息和可视化的表示法。语义方面,模型表达一种逻辑,一种业务描述。可视化的表达方式可以使人观察、浏览和编辑的形式展示语义信息。
一个模型是一个系统潜在配置的发生器;模型规定了系统可以变化的范围。按照模型来进行系统配置是一种很理想的情况。(A model is a generator of potential configurations of systems; the possible systems are its extent, or values. Ideally, all configurations consistent with the model should be possible.)由此可见,建立灵活的模型是一个平台级软件的关键所在。
听起来比较复杂,其实广义上讲任何编程语言都是一种模型语言,一段代码就是一节模型。只不过大家现在讲的模型,又更加抽象一步,通过图形、表格、XML,而不是代码来描述。

模型驱动
从现在的情况看,MDD的发展已日臻成熟,不仅Together、Rose等工具在不断完善,普元等国内致力于国产中间件的厂商推出的EOS Studio等产品也相当成熟了。《大规模基于构件的软件开发》的作者Alan Brown总结了MDD的发展历程(参见图4)。

图4 模型驱动的发展历程

从图4可以看出,MDA是MDD发展的高级阶段,当前还处在方兴未艾的阶段。采用MDA方式的软件开发,其过程有了根本的变化(参见图5)。其关键在PIM(平台独立模型),它是一个屏蔽了"平台相关技术"诸多细节的模型,但其语义必须完备,否则无法自动生成PSM(平台相关模型)。


图5 采用MDA方式的开发过程

我们关于模型方面趋势的看法,基本可以总结为三句话:模型在开发中的作用会继续增大,其应用范围会更加广泛、更加深入;模型的分工会产生分化,"隐藏细节"的理念会发展到"隐藏不应暴露的模型";暴露给用户使用的是符合用户视图的模型,比如,我们认为"面向服务"并不是要革"面向对象"乃至"面向构件"的命,它只是较多地暴露给业务用户的那部分模型而已。

SOA
SOA在业务子系统的层次上对业务进行封装,成为符合标准协议的服务,也可以认为是业务子系统层次的构件。
目前的SOA往往用于大型企业信息系统的架构,是对EAI技术的发展和替代。我们可以对legacy系统进行SOA的封装,也可以在新的系统中以SOA为架构模型来设计和规划各个子系统,以及子系统之间的关联。
随着SOA系统的成熟和普及,以及在安全性、可靠性、目录服务、领域业务标准方面的成熟,SOA 在未来会成为企业之间在广域网上自由组合和交互的标准。作为EAI的替代品,服务是经过内部设计和内部整合的。而在广域网的SOA架构之下,银行、商家、厂家之间能够更加快速的整合。也许,未来最大的互联网使用者,不是网络端的个人,而是基于服务的自动化软件。

面向构件

为什么称为面向构件?大家熟悉的"构件技术"一词(CORBA、COM、EJB)关注的是构件的描述方法、调用方法和运行体系,是一种分布计算的技术。用得比较多的"基于构件的开发(CBSD)"一词,从语义理解,是在大量构件库的基础上的组装和开发,怎么讲都是太长了点。"构件化"一词有点意思,但"化"字主要是强调最终应用软件的结果形态。而"面向"两个字,能够把设计、开发、复用、上线、管理,把构件、服务、模型,把软件生命周期的各个阶段,都以构件为中心重新定位。面向构件真是软件构件世界的最佳描述。
"大面向构件"的理念以构件为架构,以服务为构件的接口,以模型为构件接口的逻辑实现,融合了服务和模型的内容,与模型驱动和SOA有差别,又有联系。
感谢《程序员》杂志的信任,我们能够在这里一起讨论多年来从事大型企业软件的经历和思考。一些思想是大家的共鸣;一些思想由于个人局限可能错误;一些思想一时还不很彻底。感谢温昱先生的协助。谢谢大家!

相关阅读: