|
|
|
|
EOS构件简析 发布时间:2005-08-26 00:00:00 作者:cservice 出处:goComDevCenter 语言:中文 阅读次数:2376次 |
| 1 概述
EOS™产品系列是普元的核心产品线,从2002年正式形成产品到现在,经过差不多
4年的不断完善,现已具备工业化应用强度与高可应用性;特别是在电信、金融等功能需
求复杂、性能要求极高的行业成功实践中充分证明了构件化软件技术的可行性与可发展
性。
使用过EOS或使用构件化理论进行软件设计的客户们正在深刻的感受到软件开发与应用需
求的完美结合,多快好省、随需应变已不再是某些IT厂商的希望或广告词。
本文不讨论构件理论及构件化开发过程,只是解析EOS™中6类构件的基本原理及应
用场景,以帮助那些正试图使用EOS™的人们在脑海中形成一个基于EOS™的
软件模型。
EOS™的设计者将软件(特别是大型企业级应用软件)中各种组件进行了有效分类
,形成了EOS™的6类构件:数据构件、运算构件、流程构件、业务构件、展现构件
、页面构件;通过各类构件在其设定的作用域的高效运行及利用XML数据总线实现各构件
间的松散耦合较合理的实现了计算能力---计算成本---开发成本---维护成本4元关系定
义。
下面我们就开始解析6类构件。
2 构件简析
2.1 数据构件
数据构件,一种用于完成从原生数据实体到语言级对象实体映像的组件;在EOS中简单的
讲就是一个XML文件(静态存在,存放在磁盘中)或一个DOM节点(动态存在,活动于内
存中);我们现在一谈到数据持久化、格式化就一定会想到DBMS,RDBMS确实提供许多其
他存储系统(软件存储系统)无法比拟的优势,所以现实世界中的90%以上的数据都是存
储于DBMS中的。数据库领域在全球范围内的供应商也不下10个,作为ISV特别是产品通用
型的ISV就会面临一个巨大的挑战---数据库兼容问题;为了实现多个数据库平台兼容IS
V们必须在同一套应用系统内提供多套数据处理方案,而且这一制约也给第二个制约雪上
加霜。
在SQL应用的程序里,我们对嵌入SQL语句部分的代码维护总是感到有点深恶痛疾,特别
是在OO理论高度成熟的今天,我们确实很难接受采用SQL集合式的数据处理方式,在原本
优雅的OO设计中因为加入了SQL嵌入处理而显得特别生涩或不爽;这就是我们在数据库应
用开发设计中的第二个制约。
Java技术的发展,特别是Java中Reflect机制的应用使得这些制约冲突得到缓和,出现一
系列跟数据持久及O/R Mapping相关的产品,例如:Entity
Bean、JDO、Hibernate等;都感觉不错,至少在我们的核心业务代码中SQL语句是越来越
少了。
EOS™作为一种构件化软件建设平台理所当然要去除这种因SQL带来的制约,它采用
的处理方法跟流行的持久化及ORM技术类似,采用XML文件来封装数据库物件,形成的文
件名以.ent结尾,文件存放在EOS_HOME/datadict目录下;用文本工具打开一看,它是一
个典型的XML文件,完成了从表、视图等到程序运行中所需的对象实体(在EOS中以DOM表
示)的映像。
在EOS™中可以有3种方式生成数据实体:
数据树 是用手动的方式进行数据结构定义,它并不进行数据库物件映像,相
当于C语言中结构,只定为了规范某些重要的运行期数据实体而定义的。
查询类数据实体 在编辑器中输入查询SQL语句,EOS
Studio会根据你定义的查询语句生成数据实体,相当于根据View来映像实体。
导入数据实体 根据数据库中表或视图的结构进行数据实体直接生成,而完成
映像。
以上三种数据实体生成方式基本能满足需求,用户可以有选择性的使用。
2.2 运算构件
运算构件,用于完成某一基本运算的原子组件。在EOS™中具体表现就是类中的一
个方法,不过EOS™进行方法接口定义,其方法接口为public static int BL_canbeDispatched(Document doc, BizContext param) throws
Exception,有一个缺省的前缀BL_,当然开发者也可以改变这一约定;之所以称为原子
构件,从方法接口上来看就能看出端倪,它的返回类型始终为int,而参数只有两个,由
此可见它的调用是非常简单的,调用者基本上不需要考虑其返回值,而且也限定了方法
内要实现功能的原子性,保证了运算的完整性。想想看,如果你的代码是如下情况你会
怎样:
void process() {
BL_process1();
BL_process2();
BL_process3();
…
BL_process3();
}
我们会感觉很爽,对不对?因为process中没有逻辑表示;EOS正是采用类似的方法,这
也是我们在传统面向过程或面对对象编程中一直追求的境界,这样的话对于每一个被调
用方法的改变都不会影响到程序的主体框架,我们称之为优雅,而且有效。那么程序中
的逻辑到哪里去了呢?有两点来进行阐明:
1、 在每一个运算构件中并不是没有if语句的存在,而是这些if语句应该是业务无关的
,即粒度控制得当。
2、 对于业务逻辑的控制EOS将其放在了业务构件中,使逻辑与运算分离;实现业务层的
MPC(Model、Process、Controller),大家对MVC结构的惊叹应该也发生在EOS实现了M
PC上(个人认为这是一经典实现)。
顺便也提一下运算构件的生成与运算原理,一个运算构件是为一个BL方法和一段XML配置
文件构成的;BL方法(即Java代码)完成实际运算,XML配置文件完成接口参数说明,有
兴趣的朋友可以在BL方法源文件同级目录中发现一个同类文件同名的XML文件,这就是它
的配置文件。
2.3 流程构件
流程构件,工作流物件构成的完整业务流程组件。EOS™中有一个非常优秀的工作
流引擎,完全符合wFMC标准定义,而且具有开放性。在这里不多介绍流程构件的设计与
运行原理,而介绍一下为什么在EOS™中会引入工作流。
在一些大型的系统中,特别是在大型的应用系统中,对现实业务的模拟往往显得很生涩
,而导致开发过程的不畅甚至失败,也导致终端使用者始终觉得不对劲。原因在于现实
业务大都是以流程形式存在的,而开发者却因为长期受事务观念的影响,将原本是非常
流程化的业务用基于事务和数据块增补的方式来进行模拟,首先输在设计。而后因为基
于事务和数据块增补方式对角色或组织机构是很不友好的,所以导改类似于权限控制、
数据隐藏等难题随及而来,开发者终于过上了东折西补的日子,冬天开始了。试想一下
,基于流程的业务实现会存在权限问题吗(大规模权限问题)?不会的,我们在设计流
程的时候就是按照不同的角色、机构或人来设计每一个工作项的,甚至每个工作项的可
访问数据都可以在设计期确定,怎么会存在这些问题呢?而最复杂的工作却由EOS的工作
流引擎替你完成了。
在EOS中是非常方便实现流程的定义、升级、废除的。
2.4 业务构件
业务构件,或许我们可以称之为业务逻辑控制器(或业务逻辑控制视图)。一直以来,
我们一直受制于语言本身,在所有的4GL中都没有将业务与逻辑两个词分开,业务与逻辑
总是成对出现。大师级的OO开发者也许在思考这些与控制相关的问题,他们开始做模式
相关的事,但是这是另一个方面,模式只是逻辑中一些具体体现,而我们需要的是随需
应变,我们首先关注的是我们是否具有逻辑控制的能力,而后才是考虑这种逻辑控制的
优良性(这里跟重构相关)。
大家会发现在EOS
Studio业务构件开发视图中,可用的的工具只有两个:一为运算构件,另一为连线;其
实业务构件图就是整个业务系统的逻辑视图。我们可以在此视图中任意改变我们的业务
流向,之所以能这样做,原因有三:
1、 运算构件充分保证了计算能力的原子性(这是构件自治的基础)。
2、 运算构件的接口一致且简单(具体请参考运算构件)。
3、 数据交换不采用方法间的P2P式耦合,而采用XML数据总线进行交换(请参考其他EO
S XML数据总线资料)。
但是这一优势也是一把又刃剑,有些人会说它灵活,而有些人会说它麻烦,依我看关键
问题还是粒度问题。什么的粒度呢?运算构件的粒度及业务构件本身的粒度,这是神也
不能帮助我们解决的问题,让我们去做更多的思考与实践吧。
2.5 展现构件
展现构件,简单的说是控制页面流转的组件(当然它也可以控制业务构件的流转,因为
它可以调用业务构件)。按照J2EE核心组件图来对照,我们很容易给它找出Servlet来对
映,它也和Struts中的Action非常相似,主要完成对于用户接口层的流转控制。它是前
台与后台的粘贴带,在EOS中展现构件定义得比Servlet或Action更严格,它只做流转;
从而避免了开发者的一些不良习气:在控制里无意识加入了业务处理代码而导致程序的
可维护性和可扩展性下降。
如果你还不了解展现构件,那么请再次到www.java.sun.com上将J2EE规范下载下来仔细
阅读Servlet部分。
2.6 页面构件
页面构件,因为页面也具备了输入、输出、服务等构件特征,故也称其为构件。对于基
于Request技术的页面技术,目前好像没有必要继续讨论下去。
EOS对页面构件的开发支持是目前所有WEB层框架中最大的,它有庞大的标签库来支持。
希望大家好好学学。
3 总结
以下只是简单的对EOS中的6类构件进行分析,点到为止,不涉及开发指南部分,若要进
行实践,请登录www.primeton.com下载必要开发手册。祝大家在构件化的道路上一路走
好:)。
作者:王安全,普元公司长沙PSO工程师
|
|
| 声明:本栏目转载文字、造型、样式、图形及程序如有来自网络,版权归原作者或首发媒体所有,欢迎任何个人访问或者转载,若有作者及出处有误,请来信说明,我们将及时更正。 |
|