专栏-创建面向构件的工作流、报表、内容管理


 2005-07-04 00:00:00       753

孤岛、梅花桩,恰如其分地形容了美国经典的垂直式应用系统,如人事、财务、交易平台等等。垂直系统的横向整合正是目前国外主流厂商的最主流的业务组成部分。其实,在经典的大型企业系统中,还有一批更加怪异的垂直系统,比如工作流、报表和内容管理系统。最典型的是报表系统:一方面,它同企业系统的每个子系统都息息相关;另一方面,它在操作上却与平时运行的系统完全独立存在,而且在数据定义上也往往全部打破运行系统的对象数据模型。

在面向构件的体系中,工作流、报表、内容管理等等都得到了构件化的体现和表达。它们不再是一个个独立的垂直系统,而是一组组灵活可组合的构件包。直接呈现在用户面前的报表展现构件,它的背后其实有丰富的业务逻辑构件的支撑,还可以与工作流管理构件、内容管理构件、以及企业的日常业务逻辑有机地结合在一起,真正成为一体化、人性化、随需应变的企业管理和运营系统。



业务系统平台化
互联网实验室早在2002年就发布过题为《业务基础架构平台研究报告》的报告。的确,对于应用系统而言,如果没有一种通用的平台,企业级应用的构建势必非常缓慢和昂贵,并难以扩展。众多垂直的应用系统如同林立的梅花桩,无法快速地、以低廉的成本集成在一起,更不要说与合作伙伴的整合了。业务系统平台化是软件开发发展演变的必然结果。它基于技术平台之上,融合各种业务应用,适合不同行业,具有协同性、集成性并面向用户需求。

趋势

从大处着眼,业务系统平台化日益显现出如下两个趋势。

抽象等级越来越高。Booch说过,软件工程的历史就是抽象的历史。业务平台的抽象等级之所以不断提升,是为了将复杂性和技术细节隐藏起来,提高开发和维护的工作效率。这种抽象等级,不仅涵盖了“实体”的抽象,也涵盖了“实体之间复杂关系”的抽象,而且这种趋势还在加强。我们非常赞同“生产力的提高是分工的结果”这一观点;业务平台的开发人员致力于将抽象等级提高,并屏蔽技术细节,这就使应用系统的功能开发人员能够专心于业务领域,也正体现了“专攻”对生产力的提高。

涵盖的范围越来越大。绝大多数成熟的生产行业,都必将是基于大规模重用的。业务平台之中包含的众多构件是可以重用的、模块化的软件资产,基于业务平台之上进行应用系统的开发,简化了应用,提高了开发效率。

优势 业务平台应该具有融合性、集成性、面向业务、可扩展性、客户需求个性化、跨平台性和技术平台无关性等诸多优势。

例如,融合性体现在三个方面,即技术上的融合、应用上的融合和管理上的融合。它改变了传统应用软件的孤立性,真正统一了各类应用要素和业务管理,使这些应用信息资源的构建、修改、共享和管理得到融合,从而大幅简化了信息系统的构件,强化业务基础、规范信息资源。通过一个统一的纽带形成一套开放式的运转思路,为用户搭建一个信息共享的,各环节内部融合的,同质化的应用平台。

再例如,业务平台可以支持不同的操作系统、应用服务器、数据库等,从而具有良好的可移植性。

而面向业务,对生产力的提高是根本性的,因为软件生产的所有问题,最终都将归结到人。

业务系统构件化
面向构件的业务平台的目标是“外秀而慧中”。我们认为,仅仅平台化是不够的--平台化仅解决了“外秀”的问题,构件化就是我们的“慧中”之道。

将关注点构件化

如Brooks所言,概念的完整性是软件质量的核心。面向构件的业务平台作为生命周期较长的系统软件,显然更应该注重概念的完整性,它是如何做到这一点的呢?

整个面向构件方法体系的重点在于,通过恰当地分离关注点,保留并改善自治性;通过将业务空间构件化,能得到清晰完整的、面向构件的解空间。如图3所示,面向构件的报表系统不仅从页面、流程、业务、运算、数据这一维度进行了关注点分离,还从功能、配置、管理这一维度分别将构件打包。这样一来,一个个高聚合的构件,成就了整个报表系统的松耦合品质。例如,报表配置和报表功能可以方便地重用同一个报表数据构件,而工作流和报表系统都可以使用同一个权限和角色管理构件包,等等。

还有一个非常重要的好处,就是从用户角度,非常容易组合。我们认为,在企业级应用里边,单纯从角色角度定制用户视图是有悖于“以客户为中心”这一可用性(usability)原则的。因为角色只是责任的一种抽象,而一些员工可能同时担任多种角色,在传统的企业应用中,这些员工要登录多次才能完成日常工作,非常不方便。而将报表、工作流、内容管理等业务构件化之后,可以很方便地、随需应变地在不同用户的界面里边集成他当前负责的所有工作,例如报表的查看、工作流的管理、权限的配置等等。

优势

面向构件的业务平台,具有灵活性、集成性、一体性的优势。

灵活性。构件是高度自治的软件单元,面向构件的应用系统由不同构件相互协作、组装而成。整个开发流程组织在构件周围,开发、部署、维护、个性化定制,都变得非常灵活、敏捷。其实,任何软件开发问题的解决都暗含了一个先“分解”后“组合”的过程,从结构化方法、到面向对象、到面向构件,无不如此。但面向构件方法赋予这“一分一合”更深刻的意义,支撑起一种积木式的软件开发方式,有望将近二十年来日益增长的“软件开发复杂性”拉回到80年代的水平。

集成性。面向构件的业务平台应当注重多层次的封装。封装和抽象,是一个硬币的两面--封装可以屏蔽细节,只将用户感兴趣的抽象提供出来。封装的层次越高,重用该抽象的价值就越大;封装的层次越低,集成时的控制就越精细。因此,我们应当使“积木”拥有不同的粒度--构件逻辑、构件、构件子系统、构件系统、构件系统联邦,这样可以将面向构件的优势发挥到最大化,为不同级别的集成提供方便的支持。

一体性。构件的优势还在于它的一体性。从形态而言,构件是提供明确接口的完整的单元,它将所有相关工件紧紧围绕一个明确的功能周围,并将复杂性和技术细节隐藏起来。从部署而言,构件是自包含的、可独立部署和运行的。从功能而言,构件完成明确的功能,而不同粒度的构件(如构件逻辑、构件、构件系统、构件系统联邦)完整而优美地覆盖了需求的不同层次(系统需求项、系统需求、用户需求、业务需求)。

CIO故事
有件事情耐人寻味。一个人做到了IT企业的CIO或者CTO,当他跟同业的人接触时,就会发现,其实大家(这些CIO或者CTO们)都处在一种很焦虑的状态。一方面,现在中国的企业业务变化非常快,软件来不及生产或者软件本身的质量存在很大的问题,不能适应新变化的要求,所以他们的日子也很难过。另一方面,软件的应用日益深入地渗透到各行各业之中--这意味着企业级软件的“需求面”扩大了--于是,企业的业务流程会同时涉及到多个以前孤立的应用系统,这就是EAI(企业应用集成)产生的背景。

而现在有了构件之后,情况则大为不同。他们一下子就觉得软件成了他们可以控制的东西、他们可以随意组合的东西,当领导的需求来的时候,他们的要求就能够很快地被实现。当然对这些CIO来讲,系统的稳定性成了最关键的因素,而基于构件开发的系统,当一个系统由几百个构件组成的时候,你只有几百个地方可能出错;而当这个系统由几百万个代码组成的时候,它就有几百万个地方可能出错。所以,当你用构件来写软件的时候,这个系统就被定性了,下次(它的功能)就会提高很多。

其实,作为软件的供应商来讲,也很欢迎构件化的生成模式。公司的员工走掉不再那么可怕,构件积累下来了--公司的核心价值就体现在这些构件里面。

关注业务,将技术细节交给面向构件的业务平台,这就是“办得到”的秘密!

相关阅读: