与Midas 的区别
Borland 公司的Midas 技术在多层结构开发上是一个很好的平台，
在组件方面来说，它的TClientDataSet,TDataSetProvider 是一个完美之作品！
Midas标准接口：
IAppServer
UA SDK:
由 IDispatch 继承发布一个用户自定义接口，做为 应用层服务器的业务组件代理接口！
只需要发布一次，方便管理，发布，配置！
Midas 有7个接口方法：
function AS_ApplyUpdates(const ProviderName: WideString;
Delta: OleVariant;
MaxErrors: Integer;
out ErrorCount: Integer;
var OwnerData: OleVariant): OleVariant;
safecall;
function AS_GetRecords(const ProviderName: WideString;
Count: Integer;
out RecsOut: Integer;
Options: Integer;
const CommandText: WideString;
var Params: OleVariant;
var OwnerData: OleVariant): OleVariant;
safecall;
function AS_DataRequest(const ProviderName: WideString;
Data: OleVariant): OleVariant;
safecall;
function AS_GetProviderNames: OleVariant;
safecall;
function AS_GetParams(const ProviderName: WideString;
var OwnerData: OleVariant): OleVariant;
safecall;
function AS_RowRequest(const ProviderName: WideString;
Row: OleVariant;
RequestType: Integer;
var OwnerData: OleVariant): OleVariant;
safecall;
procedure AS_Execute(const ProviderName: WideString;
const CommandText: WideString;
var Params: OleVariant;
var OwnerData: OleVariant);
safecall;
UA SDK 接口方法：
procedure Request(SrvObjName:WideString;ServiceName:WideString;DataIn :OleVariant;var DataOut:OleVariant);safecall;
procedure Update(SrvObjName:WideString;ServiceName:WideString;DataIn :OleVariant;var DataOut:OleVariant);safecall;
procedure Execute(SrvObjName:WideString;ServiceName:WideString;DataIn :OleVariant;var DataOut:OleVariant);safecall;
Midas:
我们每设计一个应用层服务器组件的时候，都必须发布一个继承于 IAppServer 的接口，也就是说，如果我们这个
应用层服务器组件要进行接口方法修改的时候，就会面临一样事情，对以前所发布接口的兼容和保证以后的扩展性能！
再加上在接口发布，配置的繁重工作，这都会给我们的应用层服务器带来应用性能的降低。（譬如：好端端的，系统
报出一个接口错误信息，或者某种Exception)，如果要实现 无状态对象和对象缓冲机制，开发人员必须编写额外处理代码！
还有就是在RemoteDataMoudle 上的众多的TAdoDataSet,TDataSetProvider ... 组件的属性设置和管理！
UA SDK:
TComponent --> TuaSrvObj-->TxxxSrvObj;
应用层服务器组件都是继承于 TuaSrvObj 一个组件, 在新发布组件时，只需要向 UA SDK 的应用层服务器对象管理队列
中注册就可以，如果是标准的数据 增，删，改，查询，开发人员根本就不需要写任何代码！
使用命名约定机制，客户端通过参数约定，呼叫应用层服务器业务对象的某个特定处理过程！
优化的数据分段处理机制，不用一行代码，就可以实现真正的无状态对象，这对于实时的互联网应用非常有用，因为大
规模数据传输一直是我们进行多层应用开发的鸡肋！
优化的对象缓冲管理机制，开发人员不需要写额外处理代码，使用UA SDK内嵌的对象缓冲池管理组件，就可达到 Db Connection
Pooling , Object Pooling ...!
Miads:
在事务处理方面，要实现事务同步机制，没有一定的经验积累，是很难实现！譬如
代码：
if dbconnection in trasaction then
dbconnection rollback;
dbconnectoin begin
transaction
try
try
cdsxxx.applyupdates(-1);
//假如还有其他的业务逻辑要处理，麻烦来了！
cdsyyy.applyupdates(-1);
exception
on e:Exceptiondo
begin
dbconnection rollback;
end;
end;
finally
dbconnection commmit;
end;
UA SDK:
内嵌的事务同步处理机制，开发人员不需要写额外的处理代码就可实现标准事务同步处理，同时
可以实现对行数据的个性化处理！开发人员只需要代码设置两个参数就完成！
1:
参数数据包传输：在Midas ，我们经常遇到就是我的参数怎么传输给应用层服务器的问题。
在 UA SDK 中，使用自有的协议数据包技术。可以一次性传输任意数据到应用层服务器。
UA SDK 架构结构简单，容易管理，在对于开发工作来说，非常难得！支持异步开发，异步调试，使用命名约定，
方便开发工作的跟踪，开发文档管理！再者就是对C/S 到多层架构的迁移支持，有很多应用系统都
是使用Delphi 开发，而且基于C/S结构，多年的行业应用经验，使得这些应用系统在业务解决能力和
对现在互联网应用支持上面形成一种头重脚轻的状态，而采用Midas 上，毕竟从开发风险，周期，
成本，开发的可控性都是头疼的问题，但在UA SDK 架构中，不需要对原有应用系统逻辑进行大量的结构
修改，开发和在C/S下没多大区别，因为客户端只是告诉应用层服务器端我要什么，原先的存储过程
或者业务逻辑都直接在应用层服务器执行，一切工作开发人员都很清晰！
2:
许多开发人员都会对 在如何衡量一个系统是多层结构的标准中产生疑问，大量的存储过程，大量
的数据表，又或者的一个业务逻辑凌乱的服务器对象，
在 UA SDK 架构中，进行了大量优化处理， 对于标准的设计期间的数据表结构提取，数据下载，修改提交，
普通的数据查询，存储过程的执行，事务处理都进行了封装处理，
开发设计人员需要的就只是根据对系统的需求基础上进行服务器对象的分布设计工作！
客户端不需要多余代码， 只须设定好几个标准属性就行
3:
应用层开发工作也一样，继承TuaSrvObj 对象，按照规范代码进行对象属性进行设置，就完成一个具备标准数据处理的服务器对象！
而权衡标准是在于对于业务逻辑处理时对参考数据的采集的，系统的处理资源消耗，
系统资源的有效利用业务逻辑处理的完整和健壮由应用层进行事务控制，有效的提高数据库的并发处理能力！
4:
在UA SDK 架构中，客户端，应用层服务器端，业务调度服务器，后台数据库
都可以在参数约定的规范下进行开发调试工作， 发生在应用层服务器的处理错误都可以直接返回到客户端；
]