构件化应用开发平台设计说明书.docx
《构件化应用开发平台设计说明书.docx》由会员分享，可在线阅读，更多相关《构件化应用开发平台设计说明书.docx（41页珍藏版）》请在冰豆网上搜索。
构件化应用开发平台设计说明书
构件化应用开发平台
设计说明书
山东点服软件有限公司
2010年04月
请不要删除后面的分节符
变更记录
变更版本
日期
图表、表格、段落号
A/M/D
原因与修改情况描述
修订人
审核人
1.0
2010-4-20
ALL
A
首次创建
姜健
2.0
2010-5-28
ALL
A
调整结构，重新组织内容
姜健
2.1
2010-6-16
第5章构件实现
M
增加业务构件实现过程描述
冯强
2.2
2010-6-16
第8章工具
M
根据新的界面设计修改文档
王阁迎
2.3
2010-7-15
第7章构件复用方法
A
增加复用方法的描述
仝林智
注：
A–增加M–修改D–删节
请不要删除后面的分节符
请不要删除后面的分节符
第1章引言
1.1.编写目的
编写的目的主要是通过对业务构件设计相关内容具体描述，为公司开发人员指导性文件。
1.2.定义
（业务）构件：
封装了业务数据操作的程序包，对外提供明确的服务接口、依赖及运行参数配置。
UI构件：
在业务构件的基础上封装了人机交互界面的可重用的程序包。
程序包：
对软件可运行代码的打包，形式包括jar、集成存放的目录等等。
1.3.参考资料
1）国防科技大学《指挥信息系统工程》之构件化开发方法
2）《构件化软件体系结构研究》
3）《Introducing_SCA》
第2章概述
本设计文档从方法、架构、工具三个方面对构件化应用开发平台进行描述。
平台包括很多软件开发工具的开发。
这些工具可以帮助开发人员快速搭建起一个新的应用，并且使其天生具有良好的架构，规范了开发人员的开发行为；而所有的工具、架构，最终体现的是一整套的构件化的开发方法，这套方法定义和约束了如何定义构件、如何开发构件、如何封装构件、如何组装构件、如何重用构件、如何管理构件。
在当前所实现的版本中，主要解决如何定义构件、如何开发构件、如何封装构件的问题。
第3章主要描述本工具所体现的应用系统设计原则，这些原则也是构件化开发方法所要遵循的一些原则。
关于构件化开发方法更详细的描述，计划在单独的文档中进行描述，本文重点不在这里。
第4章主要描述本工具所体现的应用系统的架构，是对常用开发框架的总结和沉淀；
构件化的体系架构将应用从技术上简单的分成人机交互构件层和业务构件层，所以第5章和第6章从架构的角色进一步详述了两种构件实现方式。
第7章回答了如何复用构件的问题。
第8章则从开发工具的角度解释如何实现上述方法和架构。
第3章设计原则
通常认为，一个易于维护的系统（构件），就是复用率较高的系统（构件），而一个复用性较好的系统（构件），就是一个易于维护的系统。
对于面向对象的软件系统（构件）设计来说，在支持可维护性（Maintainability）的同时，提高系统的可复用性（Reuseability）就是一个非常重要的问题，为了避免软件系统（构件）过于僵硬（Rigidity）、过于脆弱（Fragility）、复用率低（Immobility）、黏度过高（Viscosity），我们通常采用以下的原则和思想来设计系统（构件）。
3.1.基本原则
业务构件在设计、开发的时候仍然符合软件开发的基本思想原则。
1.开闭原则
每个业务构件都符合对扩展点开放，对扩展点增加，对修改关闭的原则。
1）通过扩展已有的构件、可以提供新的行为，以满足对构件的新的需求。
2）已有的构件模块，特别构件中最重要的抽象层次，抽象代码不能再修改，这就使变化中的构件有一定的稳定性和延续性。
具有这两个优点的业务构件是一个在高层次上实现了复用的系统，以使一个易于维护的业务构件。
2.面向接口编程原则
接口是对可插入性的保证，接口使可插入性变得可能。
3.依赖倒转原则（DependenceInversionprinciple）
抽象不应当依赖于细节；细节依赖于抽象，针对接口编程，使用接口和抽象类进行变量的类型声明、参量的类型声明、方法的返回类型声明，以及数据类型的转换等。
坚持依赖倒转原则是实现可拆装、可扩展的业务框架的最重要的思想。
4.里氏代换原则（LiskovSubstitutionPrinciple）
凡是基类被使用的地方，子类型一定会适用，符合该原则可以使系统灵活性提高。
5.接口隔离原则（InterfaceSegrgationPrinciple）
3.2.其他原则
1）增强构件的可重用性需要提高抽象的级别，应有一套有关名字，异常操作，结构的标准。
2）可理解性，必须伴随有完整、正确、易读的文档，具有完整的说明，有利重用。
3）构件代表一个抽象，有很高的内聚力，提供一些所需的特定操作、属性、事件和方法接口。
4）提高构件的重用程度，分离功能构件，将可变部分数据化、参数化，以适合不同的应用需求。
5）构件的尺寸大小、复杂度适中。
6）构件要易于演化，数据与其结构是封装在一起的，数据存放在数据构件对象中，能主动解释其结构。
第4章面向构件的系统架构
4.1.技术架构
构件化应用开发框架总体技术架构图如下图所示：
系统总体由四部分组成：
构件（Component）：
提供应用开发常用的各种基本构件，也允许开发人员扩展自己的构件。
每个构件要明确发布自己对外公开的服务接口。
构件服务发布（SCA）：
构件服务发布层为构件提供了发布成远程访问组件的能力。
这个发布能力依赖于服务容器，本平台选择符合SCA规范的构件容器Tuscany来提供构件服务发布环境。
UI构件：
基于构件的API，封装构件的人机交互界面。
应用集成门户（Portal）：
提供基于ZK的构件集成框架，实现对UI层构件的集成。
4.2.构件模型
构件中包含了服务，服务是构件的一部分，构件是服务的载体，服务时构件的功能暴露，构件需要依赖于其他构件的服务，服务是构建功能被访问的接口。
4.2.1.基本构件模型（Component）
构件（Component）是SOA体系架构下的应用标准构造单元，用以构造更为高层和更粗粒度的应用软件模块，用以封装更为底层和更细粒度的逻辑实现。
从外层看，构件有4个要点：
1.Services：
服务是被使用的功能
2.References：
实现时所要依赖于其他构件的服务
3.Propertites：
实现时影响构件运作的可设置数值
4.Implementation：
支持各种实现技术（Java，c++，PHP，JavaScript，BPEL，SQL，XQuery，Composite…）
如下图所示：
构件时可独立配置的单元，他强调与环境和其他构件的分离，因此构件的实现时严格封装的，外界没有机会知道构件内部的实现细节，构件可以在适当的环境中被复用，因此构件需要提供清楚的接口规范，可以与环境交互。
构件沿袭了对象封装特性，但同时并不局限于一个对象，其内部可以封装一个或多个类、原型对象甚至过程，结构是灵活的。
构件的内部具体实现请参考第5章介绍。
4.2.2.SCA业务构件模型
构件在posite文件中作为组合构件的子元素来声明。
component元素代表构件，它是组合构件（composite）元素的子元素。
在composite中可以有零个或多个component元素。
以下片段展示了带有component子元素schema的compositeschema。
Component元素有如下属性：
•name（必须）–构件的名字。
在同一组合构件里的所有构件中名字必须唯一。
•autowire（可选）–指示包含的构件引用是否自动连线，默认是false，autowire在“自动连线”节介绍。
•requires（可选）–策略意图的列表。
查看策略框架规范对该属性的描述。
•policySet（可选）–策略集列表。
查看策略框架规范对该属性的描述。
•constrainingType（可选）–强制类型的名字。
当指定时，构件的服务、引用和属性的集合，加之相关的意图将被限定为强制类型定义的集合。
component元素有零个或一个implementation子元素，该子元素指定构件所使用的实现。
没有implementaion子元素的component是不能运行的,但这种构件也许在自顶向下的开发过程中，在实现被开发出来之前作为一种定义实现的特定需求的手段还是有用的。
Component元素有零个或多个service子元素，用于配置构件的服务。
可配置的服务是由实现定义的。
service元素有如下属性：
•name（必须）–服务名字。
必须匹配由实现定义的服务名。
•requires（可选）--策略意图的列表。
注意：
服务的有效的策略意图集包含由该requires属性中任意显式声明的意图，和由实现为服务所指定的任意意图。
•policySets（可选）--策略集列表。
查看策略框架规范[11]对该属性的描述。
service有零个或一个接口。
该接口描述了服务提供的操作。
接口是由作为service元素的子元素interface元素来描述的。
如果没有指定接口，那么实现为服务指定的接口有效。
如果指定了接口，就必须提供一个与实现提供的接口相兼容的子集。
比如，为服务提供一个由实现定义的操作的子集。
service元素有零个或多个binding子元素。
如没有指定binding，那么实现为服务指定的binding有效。
如果指定了，那些绑定会覆盖实现所指定的绑定。
Binding与任意有效的PolicySet结合，必须满足服务上的策略意图集。
component元素有一个或多个reference子元素，用于配置构件的引用。
可以配置的引用是由实现定义的。
reference元素有如下属性：
•name（必须）–引用名。
必须匹配实现中定义的引用名称。
•autowire（可选）–指示引用是否自动连线，默认是false，autowire在“自动连线”节会讲到。
•requires（可选）–策略意图的列表。
查看策略框架规范[10]对该属性的描述。
注意：
引用的有效的策略意图集由该requires属性中任意显式定义的意图，与任何由实现为引用所指定的意图组合而成。
•policySet（可选）–策略集列表。
查看策略框架规范[10]对该属性的描述。
•multiplicity（可选）–定义了能连接到目标服务的引用的连线数目。
覆盖实现上的引用指定的多重性。
其值只能遵循或更进一步的限制：
比如0..n则0..1或1..n则1..1。
multiplicity可以是如下取值：
1..1–作为源，只能有一个引用的连线
0..1–作为源，能有0个或1个引用的连线
1..n–作为源，能有1个或多个引用的连线
0..n-作为源，能有0个或多个引用的连线
•target（可选）–一个或多个目标服务URI的列表，依赖于multiplicty的设置。
每个值都将引用连线到解析该引用的构件服务。
具体细节查看“连线”节。
覆盖实现中为引用所指定的任意目标。
•wiredByImpl（可选）–一个boolean值。
默认”false”，指示实现动态地连线该引用。
如果设置为“true”，表示这个引用的目标由实现代码在运行时设置（比如，由代码用某种方式来得到端点引用，并通过使用相关的客户程序和实现规范中定义的编程接口作为引用的目标来设置）。
如果设置为”true”，那么组合构件中引用不应该被静态地连线，而是不要连线。
引用有零个或一个接口，描述引用必须的操作。
接口用作为reference元素的子元素interface元素来描述。
如果没有指定接口，那么实现为引用指定的接口有效。
如果指定了接口，实现就必须提供一个兼容接口的超集。
比如提供一个实现为引用定义的操作超集。
Interface元素的细节信息，请看“接口”节。
reference有0个或多个binding子元素。
如没有指定binding，那么实现为引用指定的binding有效。
如果指定了，那些绑定会覆盖所有由实现指定的绑定。
binding元素的细节信息，请查看“绑定”节。
binding与对于binding来说有效的任意PolicySet结合，必须满足引用的策略意图集，注意：
binding元素可以指定端点，该端点是绑定的目标。
引用必须不能混用通过binding元素指定的端点和通过target属性指定的目标端点。
如果设置了target属性，那么binding元素只能列出一个或多个绑定类型，该绑定类型用于由target属性所标识的连线。
这种情况下，所有被标识的绑定类型可用于每条连线上。
如果在binding元素中指定了端点，那么每个端点必须使用binding元素中定义的绑定类型。
除此之外，这种情况下，每个binding元素必须指定端点。
component元素有零个或多个property子元素。
该子元素用于配置实现的属性数据值。
每个property元素都为命名的属性提供了一个传递给实现的值。
可配置的属性及其类型在实现中定义。
实现可以声明某个属性为multi-valued（多值），在这种情况下，给定的属性会存在多个属性值。
属性值可以按以下三种方式之一来指定：
•其值由属性元素的内容
•通过引用包含构件的组合构件的属性值。
该引用通过property元素的source属性指定。
Source属性值可以是某个XPath表达式的形式。
该形式允许组合构件特定的属性可以通过name来定位。
在属性复杂的地方，能扩展XPath表达式来指定复杂值的子部分。
所以，比如，source=”$currency”用于引用称为“currency”的组合构件属性，而source=”$currency/a”用于引用称为currency的复杂组合构件属性的”a”子部分。
•通过使用file属性指定一个指向含有属性值的文件的浏览器可打开的URI。
引用文件的内容作为属性值使用。
（译者注：
原文为：
ByspecifyingadereferencableURItoafilecontainingthepropertyvaluethroughthefileattribute.Thecontentsofthereferencedfileareusedasthevalueoftheproperty.）如果存在多于一个的属性值，source属性优先，然后是file属性。
可选地，属性的类型可以按以下两种方式之一来指定。
•通过在XMLschema中定义的类型qualifiedname，使用type属性
•通过在XMLschema中的全局元素的qualifiedname，使用element属性，指定的属性类型必须兼容实现中声明的属性类型。
如果没有指定类型，则使用实现中声明的属性类型。
property元素有以下属性：
•name（必须）–property的名字，必须匹配实现中定义的属性名。
•type（可选）–属性的类型定义为XMLSchema类型的qualifiedname。
•element（可选）–属性的类型定义为XMLSchema全局元素的qualifiedname，type即是全局元素的类型（译者注：
原文为：
element（optional）–thetypeofthepropertydefinedasthequalifiednameofanXMLschemaglobalelement–thetypeisthetypeoftheglobalelement）
•source（可选）–一个XPath表达式，指向组合构件所包含的属性。
该构件的属性值源自包含该构件的组合构件的属性值。
•file（可选）–一个指向包含了属性值的文件的浏览器可打开的URI
•many（optional）–false指定属性为单值，true为多值。
可以覆盖实现中为属性所指定的many。
其值只能是等效于或更进一步的限定。
比如，如果实现指定many为true，那么构件可以配置为false。
在多值属性的情况下，则在实现中以属性值的集合形式存在。
（译者注：
原文为：
many（optional）–（optional）whetherthepropertyissingle-valued（false）ormulti-valued（true）.Overridesthemanyspecifiedforthispropertyontheimplementation.Thevaluecanonlybeequalorfurtherrestrict,i.e.iftheimplementationspecifiesmany1.3.1）
4.3.构件间关系
1.单个构件（Component）可以提供和消费服务。
多个构件可以使用和配置为同一个实现，而每个构件又可以对实现有不同的配置，多个构件可以组合成一个组合构件，一个组合构件是域中组合的基本单元。
组合构件是一个构件、服务、引用以及内连它们的连线的集合体。
使用组合构件向一个域contribute元素。
2.组合构件有如下特性：
1）可以用于构件实现。
当以这种方式使用时，其定义了构件可见性的边界。
其内部构件也许不能直接被组合构件
2）外界引用。
3）用于定义一个部署单元。
使用组合构件contribute业务逻辑构件到域中。
一个组合构件可以用来提供其它组合构件定义的一部分，通过使用包含处理。
这使得大型组合构件的团队开发更容易。
部署期间，被包含的组合构件被一起合并到容器组合构件（此容器组合构件指包含被包含组合构件的组合构件）中以形成一个单一逻辑组合构件。
通过在容器组合构件中的元素将组合构件包含进其它的组合构件中。
域以类似的方式使用组合构件，通过特定位置组合构件文件的部署。
3.域的概念
一个域描述了一系列提供业务功能领域的服务，其由一个单一组织控制。
比如，对于商务中的会计部门，
域也许会覆盖所有金融相关的功能，且其可能包含一系列处理帐务特定领域的组合构件，一个用于处理客户
帐户，另一个用于处理可支付帐户。
一个域指定一系列构件（通过一个或多个composite文件提供）的初始化、配置以及连接。
域，如同一个组合构件，也有服务和引用。
域也包括连接构件、服务以及引用的连线。
如下图：
其中ComponentA、ComponentB为单个构件，CompositeY为两者的组合构件，CompositeY、CompositeZ...组合成为一个SCADomain。
4.4.系统部署
构件可按传统的应用系统划分进行集中部署，也可进行分布式的构件化的部署。
构件分布式部署逻辑图如下：
每个Server就是一个独立的业务域，其中可以部署多个业务构件。
业务构件通过tucany发布服务。
如果企业内存在众多的业务域，则可增加服务总线。
服务总线作为企业统一的服务出入口对外提供服务。
Portal服务器部署应用集成框架，提供对UI层构件的集成能力。
第5章业务构件实现
5.1.业务构件环境
开发包：
Zk3.6、spring2.5、hibernate3.2
数据库服务器：
mysql5.0
web服务器：
tomcate6.0
构件服务器：
tuscany1.7
开发工具：
Powerdsiger15、uniwin构件向导、Eclipse3.5、SCAEclipseplugin
5.2.业务构件层结构
整体结构图：
<业务构件层结构图>
5.2.1.UI构件（ZK）层
UI构件（zk）层是开发者用zk开发的.zul文件，是用户和系统进行交互的界面。
UI构件（zk）包含了两部分zul页面和window类。
1）Zul页面
Zul页面有和html相似的标签形式，如图：
丰富的标签库，如图：
Zul页面支持多种语言，如图：
2）Window类
Window类是zul页面绑定类，window类可以直接控制页面标签元素的显示逻辑、数据、样式。
也可以响应页面的事件，控制页面的跳转和关闭、打开。
5.2.2.Bean层
Bean层是业务实体，对业务实体的描述类。
如描述一个用户基本信息的实体类User.java
5.2.3.IManager层
IManager层是系统各类业务逻辑实现。
与传统的MVC结构中的M对等，具体实例程序，包含接口如图：
实现实例描述如图：
5.2.4.IDAO层
IDAO层是对数据库的访问和操作。
针对数据库表的增加，删除，更新以及以及数据库端程序（存储过程，包程序，函数等）的调用。
5.2.5.TransactionManager层
TransactionManager层主要负责事务管理。
针对IManager层出现的异常实现数据库数据自动回滚，一定程度的保证了数据库数据完整性，业务操作的安全性。
5.2.6.Logger层
Logger层是提供日志添加服务。
可以通过两种方式实现，一种是通过”面向构件开发工具”自动生成（详见第8章），实现自动添加。
另一种是手动添加方式，通过Logger对象实例注入，手动调用完成。
5.3.业务构件层组装
业务构件组装由Spring通过配置文件的方式加载和组装。
1）Bean加载和组装。
如图：
Spring以对象池的方式管理每一个Bean实例的生命周期。
2）IDAO加载和组装。
如图：
IDAO接受到被注入两个对象，分别为hibernateTemplate, jdbcTemplate。
hibernateTemplate主要可以通过对象实例和HQL的方式，jdbcTemplate以sql方式。
3）IManagewr加载和组装。
如图：
IManager通过注入的DAO实现可以实现对数据库的访问以及多种业务逻辑复杂判断和操作。
4）TransactionManager加载和组装。
如图：
可以根据项目的需要自由的定制事务管理和拦截的方法，srping通过新添加的管理和拦截方法的描述，自动的管理IManager层的事务。
5）Logger加载和组装。
如图：
实现日志切面，日志自动记录功能。
记录数据项可以在log4j.properties文件中按照log4j帮助文档进行参数配置。
例如，配置日志文件保存的位置等等。
5.4.业务构件层包结构
基本包结构图
图A
图B
IManger接口所在位置com+单位名称+项目名称+模块名称，如图B
IDao接口所在位置com+单位名称+项目名称+模块名称，如图B
IManger接口实现所在位置com+单位名称+项目名称+模块名称+service，如图B
IDao接口实现所在位置com+单位名称+项目名称+模块名称+dao，如图B
Bean所在位置com+单位名称+项目名称+模块名称+model，如图B
第6章UI构件实现
6.1.UI构件介绍
UI构件是在
升级会员 