关于Delphi开发分布式多层应用统核心技术.doc

关于Delphi开发多层应用系统核心技术

关于Delphi开发分布式
多层应用系统核心技术

陈胜 邓煜

南京科融数据系统有限公司
二〇二四年九月

目 录

第一章 应用背景 3
§1.1 应用需求发展 3
§1.2 系统架构变迁 3
§1.3 Delphi技术背景 4
第二章 MIDAS中间件技术 6
§2.1 透时中介引擎MIDAS 6
§2.2 MIDAS核心技术 8
第三章 高级分布式多层应用系统 12
§3.1 高效率应用服务器 12
§3.2理想的负载均衡系统 14
§3.3 完善的容错系统 14
§3.4 先进的插件系统 16
第四章 IE为用户界面应用系统 17
§4.1 ActiveForm技术 17
§4.2 InternetExpress技术 18

第一章 应用背景
§1.1 应用需求发展
科学整合、配置企业资源，快速扩大、响应市场，进一步降低生产成本、提高效率，实现管理的现代化、利润的最大化，是每个现代化企业管理的目标。在日常工作和管理中，传统手工方式无法满足这种现代发展的需要，这时，企业信息化却为企业目标的实现提供了一条解决思路。企业信息化从管理信息系统、物料需求计划进一步发展到企业资源计划，为企业目标的实现提供了巨大的支持力度。
每个企业都有自己的客户、供应商、业务合作伙伴，这样将各企业的信息系统是内部信息集成的外部环境，从方方面面影响内部系统资源集成的效果，将外部信息与系统内部信息进行整合将有利于构建真正面向市场的信息系统，从面为企业的发展提供新动力。图1为处在供应链上的用户。
用户
企业
用户
客户
用户
供应商
用户业务合作伙伴
图1 处在供应链上用户

§1.2 系统架构变迁
科学技术的发展总是日新月异，信息化系统实现技术更是这样。在LAN内C/S模式的发展经历了从两层到三层及多层的过程；在Internet/Intranet上B/S模式的发展同样也经历了这个过程。图2及图3分别为C/S典型的两层和三层的结构：
业务数据库
LAN客户端
图2 C/S下两层结构

业务数据库
LAN客户端
应用服务器
图3 C/S下三层结构

两层与三层从结构的角度上讲只是多了个应用服务器，但从软件实现的框架上，却实现了根本性的变化。两层结构主要存在以下几个弱点：
（1）胖客户，两层结构客户端普遍出现臃肿的现状，主要是因为客户端不仅有用户图形化界面、业务模型、控制，而且还包括业务规则等。
（2）业务规则不一致，所有的业务规则都分居在各个业务模块之上，对于在不同业务模块中同一个业务对象，在对实现业务规则时可能出现不一致。
（3）软件重用性差，对同一业务规则在不同的业务模块中，若能将同一业务规则提取出来形成业务规则层，不仅可为一个软件各个业务模块来调用，而且可为其他软件来使用。
（4）维护性差，系统可维护性作为系统一个重要性能指标在系统开发中占重要地位。
三层应用系统将业务规则层抽取出来，结合部分的系统控制功能形成应用服务层，有效地解决了两层的缺陷，并且在基础之上还提供负载均衡机制和强大的容错机制，从整体上提高了系统各个方面的性能。
B/S模式的情况也与此类似。
业务数据库
LAN客户端
应用服务器

HTML/XML
Internet
图4 集成商务结构
业务合作伙伴
WAN客户端
WEB服务器
HTML
XML
协同商务的发展给系统的架构提出新的需求，图4为集成商务的一个系统框架。

§1.3 Delphi技术背景
Delphi支持许多重要的分布式技术，针对Windows平台，Delphi结合了Microsoft的MTS以及Web服务器建构出分布式，Internet/Intranet的应用系统。在图5中，软件开发人员可以先在MTS/MIDAS服务器中开发各种企业对象，然后再使用Delphi开发客户端的图形用户接口并且使用中价的企业对象。稍后，当企业决定走向Internet/Intranet提供电子商务系统时，便可以加入Web服务器，然后再串连原先的MTS/MIDAS应用程序服务器让Web服务器能够继续使用在应用程序服务器中的企业对象。
图5中有许多的关键技术是这种分布式关键应用系统必须具备的，例如，Delphi的InternetExpress组件允许软件开发人员以X ML标准语言建制分布式电子商业，并且使用ADO组件配合MTS/MIDAS中介技术可做出安全强固的分布式应用系统。
DCOM/COM+
MIDAS
Internet
图5 Delphi在分布式系统开发主要技术
应用程序客户端
IE客户端
NetScape客户端
业务数据库
ADO OLEDB
BDE/IDAPI ODBC
MTS/MIDAS服务器
WEB服务器IIS
CGI
ISAPI/NSAPI
ASP

Delphi

XML/HTML
XML/HTML
InternetExpress
技术
WebBroker
技术
XML/HTML
ADO元件
DCOM/COM+
ObjectPascal
元件

Delphi不仅能够开发出执行在Windows平台的关键性应用系统，而且使用最新的软件技术，可以和Unix/Linux整合在一起以提供分布式服务。

第二章 MIDAS中间件技术
§2.1 透时中介引擎MIDAS
MIDAS是Delphi使用来开发多层应用系统使用的中介透明引擎。通过MIDAS，程序员可以使用相同组件存取不同的后端应用程序服务器。这此后端应用程序服务器可以是COM/DCOM应用程序服务器，MTS中介软件，或是CORBA应用程序服务器。此外MIDAS也提供了容错能力和负载均衡以及高执行效率等能力。
一、MIDAS结构
MIDAS是由数种不同功能的模型组成的。其中有三个主要的中介者（Broker）：
（1）远程数据中介者（Remote Data Broker）：提供客户端存取远程数据的能力。
（2）Constraint中介者：允许客户端应用程序下载远程数据为对于数据设定的Constraint。让数据在客户端就被数据库的Constraint检查，无需把数据传递到远程数据库，而增加网络负荷。
（3）企业对象中介者（Business Object Broker）：允许应用系统开发招待企业逻辑的企业对象，并且提供容错能力和负载均衡能力。
二、MIDAS通讯协议
MIDAS可以使用的通讯协议也包括三种：分别是TCP/IP，DCOM和OLE Enterprise。这三种不同的通讯协议各有优缺点，使用的通讯协议结构也不一样。图6、图7、图8是MIDAS使用的三种通讯协议结构图。从图中可以看到不同的通讯协议使用的通讯层都是不一样的。但是所的有通讯协议都必须使用TCP/IP Socket和Microsoft RPC。
Client Process
Remote
Object Proxy
Client
App
Remote
ServerProcess

Remote Serv
Stub
Remote
Object
MIDAS
MS RPC
TCP/IP（必须存在)
图6 MIDAS使用TCP/IP结构图

DCOM
Client Process
Remote
Object Proxy
Client
App
Remote
ServerProcess

Remote Serv
Stub
Remote
Object
MIDAS
MS RPC
TCP/IP（必须存在)
图7 MIDAS使用DCOM结构图
DCOM

Remote
ServerProcess

Remote Serv
Stub
Remote
Object
Client Process
Remote
Object Proxy
Client
App

OLE
MIDAS
OLE

MS RPC
TCP/IP（必须存在)

图8 MIDAS使用OLE Enterprise结构图

一般来说DCOM应用程序服务器会比Socket应用程序服务器有5%到10%的运行速度差异，实际的差距会根据应用程序的类型和机器的组网结构而有所差异。虽然DCOM应用程序服务器在执行速度上享有优势，但是DCOM初次连接的速度却与Socket有大的差异，见下表1：

花费时间
使用DCOM初次连接
2到5 秒
使用Socket初次连接
小于1秒
表1 DCOMvs. Socket连接
造成DCOM连接速度较慢有两个原因：客户端机器中所使用的网络连接通讯协议；机器中DNS的设定大幅影响客户端应用程序服务器的速度。而DCOM运行时速度较快则是因为：DCOM通讯协议在传送数据时会对传递的数据进行压缩。
三、MIDAS功能

MIDAS 3.0
MTS
CORBA
负载均衡
●

●
容错能力
●

●
CallBacks
●
●
●
Database Pooling
●
●
●
Object Pooling
●
〇
〇
线程模型
●
●
●
交易控制
〇
●
●
说明
● 代表支持此项功能 〇代表需要程序员的协助
表2 MIDAS 3.0功能表
§2.2 MIDAS核心技术
一、Data与Delta数据封包
图8说明了作为包含MIDAS技术的TClientDataSet两个数据封包：Data数据封包和Delta数据封包；TClientDataSet不管是向应用服务器取得数据或是用户在客户端更新数据传递给应用程序服务器，都是以数据封包形式。

数据封包
ClientDataSet

Data数据封包
客户端

Delta数据封包
运程数据模块
Provider
Resolver

数据库服务器
图8 MIDAS应用程序运作的原理

下面采用类型库方法来举例具体说明Data和Delta数据封包的格式及关系：
步骤一、刚取数据到客户端时，Data和Delta数据封包内容如表3和表4：
State
ID
Name
OValue
dsBrowse
1
张三
23
dsBrowse
2
王五
45
表3 Data数据封包

UpdateStatus
ID
Name
OValue
Null
Null
Null
Null
表4 Delta数据封包
步骤二、编辑数据，修改第一条记录Value值为26，删除第二条记录，增加一条记录后Data数据封包与Delta数据封包内容如下表5和表6：
State
ID
Name
OValue
dsEdit
1
张三
26
dsInsert
3
赵二
33
表5 Data数据封包
UpdateStatus
ID
Name
OValue
usUnModified
1
张三
23
usModified
Null
Null
26
usDelete
2
王五
45
usInsert
3
赵二
33
表6 Delta数据封包
步骤三、用AppServer.UpdateXXX类型库方法将表6的Delta数据封包传递给应用服务器层UpdateXXX方法。
步骤四、用AppServer.UpdateXXX类型库方法负责将表6的Delta数据封包进行解析，生成三条SQL语言如表7：

SQL语言
1
Update XTable Set Name=’张三’,OValue=26 Where ID=1
2
Delete XTable Where ID=2
3
Insert XTable(ID,Name,OValue)Values(3,’赵二’,33)

步骤五、通过AdoConnection中ADO接口在一个事务中到数据库中执行。
步骤六、更新出错时，则返回一个信息给客户端报错，若用客户选择放弃，调用TClientDataSet.CancelUpdates则Data和Delta数据封包形式如表3和表4；更新成立时，则返回一个信息给客户端，客户端则采用TClientDataSet.MergeChangeLog方法来更新Data和Delta数据封包，更新后Data和Delta数据封包内容如表7和表8：
State
ID
Name
OValue
dsBrowse
1
张三
26
dsBrowse
3
赵二
33
表7 Data数据封包
UpdateStatus
ID
Name
OValue
Null
Null
Null
Null
表8 Delta数据封包

二、负载均衡机制
图9是两个应用程序服务器向Business Object Broker注册，图形10中有三个客户端应用程序向Business Object Broker要求可以使用的应用程序服务器，Business Object Broker把注册的两个而且执行正常的应用程序服务器返回给客户端应用程序。由于客户端应用程序有三个，比起应用程序服务器多了一个，所以MIDAS会分配其中两个客户端各使用一个独立的应用程序服务器，而另外两个客户端则共享一个应用程序服务器，见图11。由于没有空闲的应用程序服务器，而且也不会发生所有的客户端应用程序都使用一个应用程序服务器，因此此时系统的应用程序服务器是处于负载均衡的状态。
注册
客户端
应用程序
客户端
应用程序
客户端
应用程序
OLE Enterprise
应用程序
服务器1
应用程序
服务器2
Business Object Broker
图9 应用服务器注册

请求服务对象并得到应答
客户端
应用程序
客户端
应用程序
客户端
应用程序
OLE Enterprise
应用程序
服务器1
应用程序
服务器2
Business Object Broker
图10 客户端请求服务对象并得到应答

客户端
应用程序
客户端
应用程序
客户端
应用程序
OLE Enterprise
应用程序
服务器1
应用程序
服务器2
Business Object Broker
图11 客户端与服务器进行交互

三、容错机制
若图11中的第二个应用程序服务器不堪重负已瘫痪，则客户端应用程序会向Business Object Broker注销此应用服务器，并请求新的应用服务，如图12。

客户端
应用程序
客户端
应用程序
客户端
应用程序
OLE Enterprise
应用程序
服务器1
应用程序
服务器2
Business Object Broker
图12 注销并请求服务
注销应用服务器2，请求服务对象并得到应答

原系统中只注册了两个应用程序服务器，后应用程序服务器2被注销掉，系统只剩应用程序服务器1，故系统返回应用程序服务器，客户端应用程序得到服务器名后即与之进行交互，如图13。
客户端
应用程序
客户端
应用程序
客户端
应用程序
OLE Enterprise
应用程序
服务器1
应用程序
服务器2
Business Object Broker
图13 客户端与服务器正常交互

第三章 高级分布式多层应用系统
§3.1 高效率应用服务器
一、应用服务器类型
（1） Dll应用服务器，即应用服务器做成Dll文件，优缺点如下：
优点：
方便，不需要启动就可提供服务。
缺点：
难提供实现控制功能，如取消一个在线用户。
（2） NT服务应用服务器，采用Service Application进行开发，优缺点如下：
优点：
方便，随Windows启动而启动后即可提供服务，能提供实现控制功能。
缺点：
安装卸载比较麻烦。
（3） 应用程序服务器，采用Application进行开发，优缺点如下：
优点：
方便，一般可手工启动；安装卸裁较易，能提供实现控制功能。
缺点：
连接时启动连接速度较慢。
应用服务器类型一般选择应用程序服务器。
二、服务器中Automation对象实例
COM对象的Instance
说明
Single
只允许应用程序服务器中的Automation对象同时让一个客户端应用程序使用。也就是说这个Automation对象会让所有客户端共享使用。
Multiple
允许应用程序服务器中的Automation对象同时让多个客户端应用程序使用。也就是说每一个客户端都会激活一个新的Automation对象，每一个客户端都使用它自己的Automation对象。
Internal
使用nternal的Automation对象代表它只是在应用程序服务器执行时暂时存在的COM对象。也表示这个Automation对象不会在系统注册器中注册任何的数据。这种Automation对象通常是属于特定应用程序服务器的COM对象，只能由应用程序服务器本身建立，使用之。而不能，或是不愿意让外界程序建立，使用之。
表9 服务器中Automation对象实例
三、应用服务器线程模型
COM/DCOM使用的线程模型如表9：
COM线程模型
说明
Single Thread
单线程，只有一个线程服务任何客户端的要求。

Apartment Thread
这种线程模型允许COM服务器拥有多个相同的Apartment在不同的服务器线程中执行，如此一来就可以同时服务许多个客户端。但是在每一个Apartment中只有一个单一线程可能执行这个Apartment中任何的COM对象。由于在COM服务器中可能有数个线程同时在执行，所以每一个线程必须小心保护全域变量的存取。
Free Threading
这种线程模型允许客户端应用程序同时存取COM服务器之中的任何COM对象。
Both Threading
同时支持Apartment Model和Free Threading的线程模型。这意谓在这个COM服务器中可能有多个不同使用不同线程模型的COM对象。此外Both Threading也保证当它通过接口回叫客户端的应用程序时，所有的回叫是依序的，而且会回叫到正确的客户端线程。
Neutral Threading
（无相关资料，应该是更好的线程模型）
表10 COM/DCOM线程模型
四、小结
在假设客户端应用程序为单线程模型下，应用程序服务器应采用Multiple类型的COM对象，而线程模型则采用Apartment线程模型，在这样认定下来讨论以下事实：
每一个参加分布式多层的应用程序，不管是客户端应用程序或是服务端的应用程序服务器，在执行前，都必须向操作系统的COM函数仓库初始化并且进入特定的Apartment。有如下结论：
（1）应用程序的线程（不管是主线程或是其它的线程）都在一个特定的Apartment之中执行。
（2）COM对象是建立于特定的线程中。
（3）Apartment是存在于Process之中。
结合Delphi选项和语言，各种关系可以使用图14来说明。
Process
Apartment
线程
COM对象
（远程数
据模块）
Tthread对象
Instancing
选项
CreateRemoteObject
CoInitializeEX
图14 Delphi中COM的各种关系

§3.2理想的负载均衡系统
一、多应用程序服务器原因
（1） 系统容错的需要，不因一台应用服务器停止工作而系统瘫痪。
（2） 应用服务器连接数据原因，在Apartment线程模型下，一般一台应用服务器可以服务48台客户端，若再增加客户端，速度有一定的下降（具体根据系统资源）。
（3） 负载均衡的需要，一个应用服务器负载过大时，系统性能会有明显的下降
二、多应用程序服务器负载均衡实现
MIDAS能够把客户端应用程序的需求分配到不同的应用程序服务器之中执行，以提高客户端应用程序和应用程序服务器的执行效率。
业务数据库
LAN客户端
客户端
应用服务器1
应用服务器2
LAN客户端
客户端
WEB服务器
随机请求服务
降低单个服务器上负载
图15 负载均衡示意图

Delphi的TSimpleObjectBroker能提供负载均衡功能，将TSimpleObjectBroker与TADOConnection相连接，在TADOConnection中设置应用程序服务器程序名以及ObjectBroker选项，而以TSimpleObjectBroker中设置应用程序服务器的机器名，再将LoadBalanced置为True，即可提供负载均衡功能。
§3.3 完善的容错系统
在执行关键性业务时，系统的稳定性是非常重要的，MIDAS在多层应用系统中的提供了容错功能，关键是TSimpleObjectBroker组件，将TSimpleObjectBroker及TADOConnection组件按§3.2中设置，即可实现系统容错功能。容错系统功能流程图16-图18如下：
图16为为应用服务器1正在为客户端提供服务。

应用服务器2
业务数据库
应用服务器1
图16 正在服务图
客户端
正在服务
客户端

图17说明在应用服务器1发生故障时，系统主动请求服务，MIDAS给出其他应用服务器，若此时给出的为应用服务器2且应用服务器2运行正常，则应用服务器2为客户端提供服务。
应用服务器2
业务数据库
应用服务器1
图17 服务出错后请求其他服务图
客户端
请求服务
客户端

若此时应用服务器2也发生故障，且系统中无其他正常运行的应用服务器，则系统客户端自动将其保存为本地交易文件，等下次要一个应用服务器为其提供服务时提交系统处理。如图18。
应用服务器2
业务数据库
应用服务器1
图18 其他服务也出错后存为本地交易文件图
客户端
本地交易文件
保存
客户端

TSimpleObjectBroker提供了图16-图18的除本地交易文件之外的容错功能，而TClientDataSet则提供了本地交易文件的容错功能，这种本地交易文件是以Delta的形式保存在本地，TClientDataSet.SaveToFile方法，而TClientDataSet.LoadFromFile则提供了恢复数据为下一次服务器正常工作时提交应用服务器执行的功能。
§3.4 先进的插件系统
插件技术既有利于提供松散的框架系统，也有利于提高软件产品核心技术的保密性，系统插件的技术如下图19：
客户端应用程序
应用服务器程序
业务数据库
业务模块插件A
业务A数据库表
应用服务插件A
业务模块插件B
业务B数据库表
应用服务插件B
业务模块插件C
业务C数据库表
应用服务插件C
图19 系统插件技术示意图

在实现上主要是应用服务器程序与应用服务插件的集成和客户端应用程序与业务模块插件的集成，在应用服务程序中，主要提供主功为通讯和控制功能，即将客户端应用程序传递过来的数据封包Delta传递给相应的应用服务插件，并且实现对招待交易的控制、出错控制和系统线程模型等的控制；而应用服务插件的主要功能则是对Delta数据封包进行解析，产生相应的SQL语言，并能提供系统出错的必要信息，应用服务插件主要采用.dll或.ocx的文件形式。而客户端应用程序与业务模块插件的集成可以借鉴木马病毒的技术，将在不同进程中集成在一个进程之中，主要采用Application.Handle:=AHandle以及SetParent(XXDllForm.Handle,BHandle)的形式。客户端应用程序主要负责系统的控制，如负载均衡等，并且也负责业务模块的调用以及与业务模块的数据通讯和应用服务器程序的数据通讯，而业务模块主要本业务的控制以及对客户端应用程序接口的调用来传递数据封包。

第四章 IE为用户界面应用系统
§4.1 ActiveForm技术
一、Delphi对ActiveX的支持
中间件

Holygram

Text

Graphics

Delphi

Numerical
Data

Audio

Animation

Video

图20 Delphi对ActiveX的支持

中间件可以用来开发ActiveX组件。
二、ActiveXForm工作流程
浏览器
WWW
Server
业务
数据库
ActiveX组件
下载到客户端
图20 ActiveForm在Internet工作流程
应用
服务器

浏览器首先从WWW Server上下载ActiveX组件到客户端，后与应用服务器进行交互。
三、应用程序转变为ActiveXForm
新建ActiveForm的应用程序，并将已有的应用程序工程文件加入到ActiveForm的工程中来，在此基础之上，将原应用程序的MainForm.Parent:=ActiveXForm，并且大小设置为ActiveXForm的大小，最后编译后将其发布到WWW Server上即可。
§4.2 InternetExpress技术
一、Delphi的InternetExpress技术框架

HTTP请求
HTTP请求
DCOM/Socket
应用程序服务器
InternetExpress技术
WebBroker Action WebBroker事件处理
WebBroker技术
NetScape
IE

二、

18