Airstrip中间件简介
概述：
描述中间件的功能，地位，开发背景以及意义。
一、背景：
在MIS类型的企业应用软件开发过程中，由于企业应用的复杂性，大多数情况下都必须针对每个客户独有的业务，分别设计软件架
构。即使是同一领域的软件也是如此，比如人力资源软件，每个企业都有自己的人力资源管理思维以及业务方式，虽然它们都是大同小
异，但软件开发人员却必须为这些差异改动大量代码或重写新的版本。
在为每个客户量身度作的前提下，如何最大限度的提高软件的可复用性，从而降低开发成本？这个问题自软件进入企业应用以来，
业界一直都在探讨，各种角度和层次的观点很多，常见的有：
1、 使用面向对象（OOP ：Object Oriented Programming）：
封装一定功能的代码，相对面向过程的函数来讲，更能模拟现实世界的业务逻辑，很大程度上降低了设计复杂性企业应用架构的
困难度，同时也大大提高了代码的可复用性。
2、 基于组件开发（Component Based Applications）：
软件开发人员常常都会在不同的项目中使用一些共同"通用组件"来加快开发速度，比如解决跨数据库的数据访问层组件。
这一次层次的代码复用是最普遍的方法。
可以类比的是开发工具附带的Framework，比如.Net FrameWork或者vcl类库，MFC等，都是封装了和业务无关的底层操作，
从而复用了此类代码。再比如ADO， ODBC，同样也复用了访问数据库接口的底层代码。
3、 面向方面开发（AOP：Aspect-Oriented Programming）：
面向方面的思想的提出，本质目的是解决面向对象无法畅顺解决的一些贯穿整个业务体系的业务，比如日志、权限等。它是面
向对象思想的延伸，不过它的作用与其说是提高了代码复用性，不如说是更利于代码复用。
4、 反转控制（IOC：Inversion of Control）：
反转控制的目的是使业务对象的职责明确，降低类之间的耦合度，从而提高类的可复用性。
假设类Managers的功能是从所有员工里查找出职务是经理的员工，类FindAllEmployesFromExcel是负责从Excel读出所有员
工数据。类Managers就必须引用FindAllEmployesFromExcel来完成工作。如果不使用反转控制机制的话，那么类Managers必
须显示引用类FindAllEmployesFromExcel，也就是说类Managers和FindAllEmployesFromExcel是强耦合的。
在另一个项目中也有此业务，不过它的员工数据放在一个xml文件里，开发人员想复用Managers的查找功能，就必须另外写
一个FindAllEmployesFromXML类代码，同时改动类Managers，让它引用FindAllEmployesFromXML。
开发人员很容易想到，写一个工厂类FindEmployesFactory去负责生成具体从数据源查找员工，这样也能实现动态切换，
FindAllEmployesFromXML和FindAllEmployesFromExcel实现同一个接口IFindEmployes（也可以用同一个基类）
如果类工厂FindEmployesFactory是通过配置文件创建IFindEmployes实例，那么代码的偶合度进一步降低，应该说是一个比
较良好的架构，不辛的是，这仅仅是一个业务情况，就需要如此复杂的结构才能实现代码灵活和可复用性，企业应用中业务繁杂，
都如此实现，将导致业务类的关系非常庞杂，并且涉嫌过渡设计。
如果当初开发Managers时就使用反转控制机制，声明一个IFindEmployes接口，Managers引用IFindEmployes接口，而
FindAllEmployesFromExcel是IFindEmployes接口的一个实现，那么两个类之间的纽带就是接口，没有直接依赖关系，在程序运
行时再由反转控制机制根据配置自动创建FindAllEmployesFromExcel实例并付值给Managers。注意此时Managers内除了对接口
的引用，并没有创建该引用的任何代码。
此时复用Managers时，写一个实现IFindEmployes接口的类FindAllEmployesFromXML，再改动配置，就完成了工作。
从上述例子可以看出反转控制能大幅提高代码的可以复用性，并且使代码架构简洁明确。
5、 工作流引擎（Workflow）：
企业应用是复杂而又多变的，不同企业间的业务各不相同，即使一个企业内，它的业务也会随时变化，甚至在开发人员开发过程
中，其业务也可能变化，导致开发周期延长，项目的风险加大。
工作流引擎就是为了实现业务流程可配置化，当业务流程变化时，只需更改流程配置，改动少许代码乃至不需改动代码就可以完
成工作。
上述的软件开发思想在不同层次和角度上提高了代码复用，1-4相对是从代码级别提高复用性，而5 层次更高一点，是从通用业务流程
出发提高了软件复用。
但仅利用上述思想，对企业应用开发来说，仅仅是提供了代码可复用机制，对绝大多数企业应用开发来说，仍然是偏"底层"。因此还必
须总结提炼出更高层的业务通用机制，比如权限控制，事务控制，异常处理，日志记录，资源统一配置，数据访问机制等等，这些机制几
乎是每个企业应用都必须涉及的业务内容。
二、通用业务开发平台：
Airstrip中间件就是针对上述问题设计，为企业应用开发提供一个通用业务二次开发平台，它整合了多种前沿开发思想，从底层类
的复用到高层的业务复用都提供了完整的支持机制，并集成多个通用业务模块。
（注：Airstrip原意为"飞机跑道"。）
三、意义：
Airstrip中间件作为企业应用通用业务平台，可以构建大多数各类企业应用，比如人力资源、OA、ERP、CRM等等。
基于Airstrip架构开发企业应用，业务开发人员更关注于某个具体业务，而不必过多考虑数据如何存储，业务在整个业务流程中的
位置带来的影响等等，极大提高开发效率，节省开发成本，降低项目风险。对产品或项目的维护成本也大大降低。
Airstrip结构：
中间件的内部结构和外界交换接口，以及使用Airstrip时整个产品的结构。
Airstrip的组成结构 ：
1、 Airstrip Core Runtime：
Airstrip底层运行的核心Framework，包括IOC Container，AOP Framework，O/R Mapping Framework.。
2、 Airstrip Application Service：
包括AirstripWorkflow Service，Business Object Container、Airstrip EAI Service、Airstrip Load Balance Service、
PassportService、ReportService、 Airstrip Analysis Service、AirstripCache Service、MessageService。
3、 Business Support Component：:
为业务类库提供Transiation Manager，Resource Manager，Access Controller，Business Config Manager，
Log Manager， Exception Manager，DBConnecterManager、SMS Message Component 、
Mail Message Component 等企业通用业务模块。
4、 AirstripSDK：
为基于Airstrip的企业应用开发提供接口。包括BusinessSDK、 BsinessDataSDK、UISDK、ReportSDK。
5、 AirstripClient：
中间件企业应用程序界面访问接口 。
6、 AirstripAdmin：
中间件管理接口。包括引擎管理接口，应用集成服务，权限管理 器、持久对象设计器、数据代码管理器等。
7、 Airstrip Developer IDE ：
提供快速/二次开发的集成环境。
详细描述：
中间件组成模块的各自职责的详细描述以及意义。包括实现技术的简介。
1、 Airstrip Core Runtime：
Airstrip底层运行的核心Framework。
i. IOC Container：
IOC（Inversion of Control即反转控制）通过自动装配组件（服务）的方式，实现组件的配置与使用分离。从而实现类的
低耦合。所有的组件（或者构成组件的类）之间的关系都是运行期根据配置生成，看起来像从一个盒子中取出几个零件，再
依据安装图纸（配置文件）组装使用，因此我们称之为IOC Container。
IOC的.Net下基本技术实现是通过.Net 的反射技术，根据类信息创建对象，再根据配置信息配置对象。因此要使两个类在
运行期组合，至少需要一个读取配置文件模块，一个配置文件的解析模块，一个根据解析结果创建对象的模块，以及一个对
象组装模块。
这些都由IOC Container集成提供。
作为功能扩展，IOC Container还提供对象实例缓存，单一模式创建还是多实例创建等扩展或优化功能。
作为Airstrip中间件的核心基础，几乎所有的基础服务以及依赖于Airstrip中间的件的二次开发，都将直接或间接使用到IOC。
ii. AOP Framework：
AOP（Aspect Object Program）面向方面编程，提供对"横切面"类型业务的便捷编程方法。像权限管理、日志管理等等，
都是贯穿在整个系统 架构中，如果采用纯OOP方式或面向过程开发，那么处理此类的业务代 码几乎会分散在每个类中，对
该业务的功能变更可能会导致每个类的改动，即使设计良好，也很难使某一个业务类和一个"贯穿类"（比如日志类）的代码完
全分离。 Aop通过拦截机制分离此类代码，比如对象A调用其b方法，Aop Framework拦截到该方法，调用权限对象，判断是
否有权限调用该方法。这样b方法里就不需有相关权限判断的代码，它对是否需要权限判断以及如何判断一无所知，充分体现
了职责分离的设计原则。
AOP的拦截机制目前有两种技术实现，一是利用.Net Remoting的"透明代理"机制；二是在.Net 代码实时编译时，通过Emit
方法改变中间语言 (MSIL) 指令流，重新指定调用方法的地址，类似一个代理机制。两种技术都互有优缺点，但相对来说，前
者的技术实现难度小，但限制范围大（因为必需从指定基类继承），Airstrip当前的Aop Framework就采用该技术，但后期将会
重构成后者实现。
Airstrip中基于AOP的有权限管理，事务管理等。
（注：AOP思想体现不仅仅包括调用拦截，还有接口混合等。）
iii. O/R Mapping Framework.：
O/R Mapping 即对象和关系数据的映射。
在面向对象体系中，所有事物以对象方式表示，而数据的存 储是以二维关系（表）型方式。比如一个人，在关系数据库
中存储在人员表的一条记录中，而在OO体系中，他应该是一个对象。 没有O/R Mapping 框架下，开发人员必须编写sql 从
数据库中查询出该人员，并把人员数据转换成对象形式。（注：.Net 里的DataTable，DataRow类并非模拟现实的对象，只
能算数据表对象化表示，因此这些类并不能和业务类完美协调工作。）
O/R Mapping Framework就是自动完成从关系数据库数据到对象的双向转换，这样可以完全根据实际业务情况设计类，
开发人员不需再考虑数据保存到何种数据库（Sql server、Oracle…..）；如何存储（表结构、表关系）；不需要"拼SQL"，
就完成组合数据的存取。无论从系统架构上，还是开发效率讲，O/R Mapping 都将带来很大的提升。
上图所示，类Person，类Employe，类 Managers分别是基 本人员类，员工类，管理人员类，它们之间是继承关系。而
它们映射到数据库时，用一张表person.(也可以指定其他映射方式， 比如分别对应三张表，再加上外键关联)。
O/R Mapping 的实现技术多种多样，不过都利用反射技术，获知定义的数据实体类的类信息，类的创建和使用都自动转
换为sql 和数据库交互，针对不同的数据库，sql 的生成也有所不同。
2、 Airstrip Application Service：
i. AirstripWorkflow Service：
工作流引擎，为流程化的业务实现配置和使用分离。
在企业应用中，许多业务都需要多人参与才能完成，典型的比如公文流转，再比如请假，需要请假人填写假单，部门经理
审核，送交人事部门和考勤、薪资挂钩，这就组成了一个完整的请假流程。
如果没有工作流引擎，同样也可以订制开发此类应用。但企业应用是复杂多变的，即使是同一个企业，他的请假流程或公
文流转的顺序或业务点会随时改变，开发人员就必须为业务的小小改动付出很大的维护代价。同样，为不同的企业也必须开
发多个差异很大的版本分支，后期的维护工作将不堪重负。
利用工作流引擎，自由配置流程内业务的组合，可以由售后服务人员，而不是开发人员去订制客户需求，从而紧密跟随客
户业务变化。同时，为不同企业提供类似解决方案时，只需同一版本，不同配置，就可以完成大部分工作，为开发人员节省
很大的工作量。
下图是工作流引擎应用的体系结构图：
Airstrip工作流引擎是依据WFMC提出的工作流管理规范开发，其流程定义文件基本符合XPDL1.0标准，能完成工作流标准
流程模式中的绝大多数模式。
在工作流管理联盟所提出的工作流系统参考模型中，以工作流服务为核心共定义了五类接口：
当前，Airstrip工作流引擎只是实现了接口一"过程定义"和接口二"客户应用"，其中接口一"过程定义工具"尚未完成。
ii. Business Object Container：
业务对象容器，实现业务对象的反转控制，直接依赖于Airstrip Core Runtime的IOC Container。
所有对业务对象的访问都是通过它进行。其机制不再复述。
iii. Airstrip EAI Service：
企业应用集成服务。尚未完成。
Airstrip中间件不仅能为多个企业应用提供运作平台，而且将能集成第三方企业应用，无论该企业应用是否以Airstrip平台开发，
为企业提供完整、无缝的整体解决方案。
iv. Airstrip Load Balance Service：
负载均衡服务。尚未完成。
在大型企业应用或多企业应用集成情况下，Airstrp中间件将采取 群集部署，自动分配队列请求，以实现最大吞吐量。
单机部署下，使用队列请求，多线程处理技术。
v. PassportService：
登陆认证服务。
为每客户端提供请求认证，其认证凭据为客户端的每次业务请求提供依据，Business Support Component中的多个模块
都需要访问该服务，比如权限、事务等。
登陆服务具有和Asp.Net的Session 类似功能，提供完整的会话状态服务，依赖于AirstripCache Service。
vi. ReportService：
报表服务。尚未完成。
为企业各种报表提供设计，部署，浏览等完整功能。
vii. Airstrip Analysis Service：
企业数据分析服务。尚未完成。
对企业数据构建不依赖于数据库平台的数据分析服务。
viii. AirstripCache Service：
缓存服务。基本完成。
提供中间件内部和外部都能使用的缓存服务，该缓存可以通过配 置方式指定缓存的存储方式，比如是进程中，或保存到
数据库中。
提供缓存的时效管理、缓存对磁盘配置文件的依赖管理以及缓存间的相互依赖管理。
ix. MessageService：
消息服务。尚未完成。
实现消息队列、消息派发和消息广播机制。
3、 Business Support Component：:
为业务类库提供多个企业通用业务模块。
i. Transiation Manager：
事务管理器。
在OOP开发中，细粒度业务对象为代码复用带来很大的空间，同时也 带来一些问题，比如数据库事务。
为了避免数据库事务的长时间挂起，事务的相关操作代码，是要求在一个代码段中完成，也就是在一个封闭过程内完成事
务的起始，提交或回滚。在细粒度的对象体系中，这个过程常常是由几个类协同完成的。这就带来类设计上的粒度矛盾和职责
矛盾。
另外一个场景是必须同时对多种事务进行处理，比如多数据库事务或者Com+分布式事务必须同时进行，此时将很难保证
类的良好架构。
解决办法是用一个事务管理器去统一管理和协调事务，可以认为，事务和权限一样，也"贯穿"在业务体系中。事实上，事
务管理也是基于AOP Framework，通过拦截调用方法，决定事务起始和结束。
需要启动或关闭事务的业务类方法，只需指定相关的Attribute，并附加参数告知事务管理器即可。
ii. Resource Manager：
资源管理器。
提供统一的资源分配，以利于国际化支持。
实际也是利用Container的配置机制。
iii. Access Controller：
权限控制器。
其机制在前面已有描述。
使用上和事务管理相似，对需要权限控制的类的方法上加上Attribute指明需要权限配置。
iv. Business Config Manager：
配置管理器。
作为企业应用的配置管理中心。
v. Log Manager：
日志管理：
日志管理实质和权限管理类似，但日志还需要一些其他内容，比如日志的输出和通知方式，对不同条件下的日志输出。
Airstrip中间件当前使用了第三方的日志组件log4net。后期将自己实现。
vi. Exception Manager：
异常管理器。
对异常统一处理。异常有几种类型，有的只必须中断当前操作，有的是导致系统不能持续运行，对这几种异常的处理方式是
不同的。还有异常的输出方式。
vii. DBConnecterManager:：
连接管理器、连接池。
对每个用户来说，它对数据库操作时，是拥有自己的连接的，而数据库的连接资源是有限的，同时事务的分散也要求用户
在整个事务范围内，对连接是不变的。连接管理器即同时解决上述问题。
它依赖于AirstripCache。
viii. SMS Message Component ：
短信服务模块。尚未完成。
发送和接收短信管理。
ix. Mail Message Component：
邮件管理。尚未完成。
4、 AirstripSDK：
为基于Airstrip的企业应用开发提供开发包。
i. BusinessSDK：
业务类开发包，提供业务基类，相关和中间件协作的接口和其他一些类，比如权限或事务的Attribute标志类。
ii. BsinessDataSDK：
数据实体类开发包，提供数据基类以及其他一些规范。
iii. UISDK：
界面开发包，界面基类，一些协作的界面数据感知组件 ，
比如支持数据代码翻译的DataGrid。
iv. ReportSDK。
尚未完成。
5、 AirstripClient：
中间件企业应用程序界面访问接口 。
企业应用的UI层，取业务对象必须通过中间件，而访问中间件的接口就是AirstripClient。
第一次访问需要登陆，成功后获得凭据，以后每次访问都必须传入凭据。
6、 AirstripAdmin：
中间件管理接口。
i. 工作流引擎管理接口：
配置流程定义、终止流程、唤醒流程、暂停流程等流程管理操作。
ii. 应用集成服务管理接口：
尚未完成。
iii. 权限管理器：
配置角色和用户的业务权限和数据访问权限。尚未完成。
iv. 持久对象设计器：
配置数据实体类。尚未完成。
O/R Mapping 机制下的数据实体类，"字段"信息是作为类的属性或字段存在，在带来紧密联系业务体系结构和编译时能够
检查数据访问的好处时，也带来一个缺点：数据构成不灵活。数据结构的改动必须改动相应数据实体类的代码。这给产品实施
和产品维护带来很大问题。
解决办法就是动态编译数据实体类，并且提供一个简单易用的界面完成此功能。
v. 数据代码管理器等。
配置数据代码。尚未完成。
在业务数据中，有很多业务数据是通用的，比如性别，省市地址等。出于数据标准化和性能的考虑，对这类数据编码，比
如"男性"编码成"代码"1，而"女性"编码为"代码"2。人员信息的性别在数据库中就以"代码"保存，在界面显示的时候作一次转换
工作，显示成"男性"或"女性"。在录入和查询统计时就有标准规范可循。
同样的出发点，对不同企业的一些个性数据也可以采用编码形式，比如部门、职务等信息。
数据代码管理器就是对上述需编码的数据统一管理维护。
7、 Airstrip Developer IDE ：
提供快速/二次开发的集成环境。 尚未完成。
提供一个独立或者Add-in形式的开发环境，通过图形向导、相关代码自动生成等方式，加快基于Airstrip中间件的开发、部署。
开发路线和未来展望：
说明当前中间件的开发进度，阶段小结 ，以及后期的工作计划以及远期规划。
Airstrip当前版本号是0.1 内部测试版，完成最基本功能的大部分开发工作 ，已基本可用，但距离可发布的版本还有一段距离。
有些功能尚未开发，有的功能需要进一步完善。
Airstrip中间件开发的路线图：
0.1 RC1 ：
AOP、IOC、O/R Mapping、Workflow Engine、Cache Service、 PassportService、
Business Support Component 的大部分、AirstripClient、 AirstripSDK的一部分。
----------------------------当前点------------------------------------
0.2 RC1：
AirstripAdmin接口。编写Sample。整合开发文档和SDK文档。
根据人力资源软件开发修订测试和第一次重构。
0.3 RC1：
SMS Message Component 、Mail Message Component。
修订测试和第二次重构。
0.4 RC1：
整合Aop和IOC。第三次重构。
0.5 RC1：
ReportService。
0.6 RC1：
O/R Mapping 的重构，实现无需继承指定基类，并和IOC整合， 直接支持统计。
----------------------------------重要里程碑----------------------------------
0.7 RC1：
MessageService。
支持.Net Remoting访问。
0.8 RC1：
支持WebService访问。
内建自己的web 服务器。可以脱离其他的.Net宿主。
0.9 RC1：
Airstrip Load Balance Service、Airstrip EAI Service，相应的AirstripAdmin接口的完善。
1.0 RC1：可作为独立中间件产品推出。
编写Sample、开发文档、SDK文档。测试重构。
