一个三层midas（RDM）的调查，多人共同开发. 1.服务器的接口如何维护,如果项目比较大，又不想拆分为多个应服务器，这样服务器的RDM可能就会要定义很多接口供客户端调用，这样问题就出来，不同的开发人员的不同模块会需要不同的接口，这样最后如何合在一起。 2.如何注意安全性?
我们知道，RDM的安全性很差，其他人可能很容易恶意攻击你的系统，因为你可能会定义很多接口函数和输出很多TProvider。 希望大家畅所欲言，谈谈你的看法！
我们知道，RDM的安全性很差，其他人可能很容易恶意攻击你的系统，因为你可能会定义很多接口函数和输出很多TProvider。 希望大家畅所欲言，谈谈你的看法！
安全专门做个安全服务器用来验证身份的 内似内部网的那种 客户需要装客户端 可以吗
2:没做过,没经验~听课!
问题一：
1、尽量减少接口数量，把普通接口尽量做成通用性较好通用接口
2、多人公用主unit，各自建立自己的unit，主unit只放声明和调用接口，自己的unit里实现接口的功能，这样也许可以减少冲突的机会。
问题二：
可以在每个接口处加一个用于校验的参数，符合条件的才通过。不知这样处理是否可行？多多交流！
***建议由开发小组中的某一个人来统一管理所有的接口定义，并要求各模块的人
提交接口，然后接口管理者对申请的接口进行分类整合再定义接口，
然后分发所发接口定义和参数含义；
这个我倒是没有克意去解决，因为我的客户里面没有去攻击的，没有在意，
以前用过两种方式吧，一种就是用DELPHI内置的COM方式去联接，我不管了。
另外一种用SOCKET与接口函数的调用的方式组合起来调用，
不过太麻烦了，而自己做也很难把数据分块来传送，只能把所有数据全部传下来，
这样又影响效率了。
主unit只放两个：一个是函数，一个是过程，都只有一个类型为olevariant的参数客户端用一个函数来组合出这个参数，服务器端主unit解析该参数，分析出该调用那个分unit里的函数，每个f分unit也有一个自己的函数负责调用自己unit里的函数，这样调用的过程就比较清晰了
客户端：socketconnection1.appserver.execproc(olevariant);//olevariant为一个参数数组服务器端：
procedure execproc(olevariant);
var
UnitTag:integer;
begin
unittag:=从数组里的一个里取出
case unittag of
0:execprocex(olevariant);//分unit负责调用各自unit里的函数的分函数，也是负责解析的
.
.
.
end;
end;procedure exexprocex(olevariant);
var
tag:integer;
begin
tag:=从数组的第二个里取出
case tag of
0:具体的函数;
.
.
.
end;
end;你看这样处理行不？就是客户端组合成olevariant的实现比较复杂呵呵，也是一个想法，不知是否可行？
对每个 RemoteDataModule 中的数据库连接组件如 ADOConnection，都要在合法的客户端登录后才进行 ConnectionString 的配置。
这样，即使恶意的客户端连上了 RemoteDataModule，仍然不能取得数据库的数据。
IAppServer 接口中的 ProviderName 参数只是一个 WideString，没必要非要认为它是 DataSetProvider 的 Name 值。 正因为 ProviderName 参数只是一个 WideString，所以可以通过它传递很多信息——用户登陆获得的 Cookie、DataSetProvider 的 Name 值、复杂的查询条件等等。
理论上说可以不依赖 IAppServer 和 RDM，但对于当前的应用需要快速开发，如果全部自己来做，恐怕也是不太合适吧？见笑了^_^
非常不错，我觉的值 的大家一看：
http://developer.ccidnet.com/pub/article/c1079_a34765_p1.html
Delphi中编制分布式多层应用系统服务资源浏览器
作者：陈立平 发文时间：2002.12.25 09:28:38
本文详细介绍了在Delphi7中如何利用TSocketConnection控件设计开发一个通用的分布式多层应用系统客户端辅助开发工具——分布式多层应用系统服务资源浏览器。 在用Delphi开发分布式多层应用系统过程中，对于开发客户端程序的人员来说，了解分布式多层架构应用服务器所提供的资源（如：服务名称、提供者名称等）是一项经常遇到的工作。利用这些参数，客户端才能够正确地与服务器端程序连接并工作。 然而，在实际工作过程中，这些资源名称大都是以口头或E-Mail的方式，告知客户端开发人员；而一旦这些资源名称被改或者此类名称在一个开发服务器上较多时，就会发生程序不能与服务器正确连接的情况，或者造成服务名资源管理上的混乱。 另外，客户端开发人员只有在开发出客户端程序之后，才能够与服务器端程序进行连接并进行测试，没有前期通用的辅助工具与服务器进行交互，无形中增加了通信的开销，降低了开发工作的效率。 那么，有没有好的实现方法能够做到自动列出指定服务器上的开发资源名称，并能够与之进行动态地连接和交互呢？这就是笔者开发多层应用系统服务资源浏览器的原始初衷。
不知道用多个RDM会不会好点？
还有，如果强调安全性，那就不要用控件。
我还是比较喜欢用VC的ATL模板开发COM+的方式。
接口维护使用有意义的标识，做好文档，共同协商好，这样问题不大
添加自己的Socket Intercepter，并使用OpenSSL技术来解决安全问题
但这样对客户软件有所要求
com+和.net也是这个方法, 不过是利用mts和ASDI.
在midas中, 不同的模快应用不同的RDM. 再把这些RDM集合到一个app server中.
如：把算产品成本的一个COM（或者是一个类），
数据库操作也做成一个，
合法性验证也做成一个。安全的话我用的是TDCOMConnection(因为是局域网，客户还有放火墙，
所以没考虑太多)。说错了的话，不要笑呵，^_^
2、安全性问题，使用DCOM本身的安全性。另外还可以附加一种机制，每次客户端登录到服务器使用一次用户名、口令的验证，之后本次验证生成一个GUID给客户端，下次客户端使用该GUID进行验证即可。
我说的那个想法，你怎么不给点建议呢？
提一个 我做过得建议 中庸一点 尽量减少接口数量把一些做成同用 这样在RemoteDataModule
不同客户端就提供尽量清晰的 接口规范 专门让一个人 维护这些如何注意安全性这一点我同意流铭兄的观点：）
谢谢你的关注，同时也谢谢大家的关注，我在前面做过简单的回答了，我到最后会对这个贴子作个总结，同时也会提出自己的观点！希望大家各抒己见，没谁对也没谁错，有任何想法都可以说出来，大家共同探讨！ 兄弟姐妹们请继续！
兄弟姐妹们请继续！
兄弟姐妹们请继续！
谢谢你的关注，同时也谢谢大家的关注，我在前面做过简单的回答了，我到最后会对这个贴子作个总结，同时也会提出自己的观点！希望大家各抒己见，没谁对也没谁错，有任何想法都可以说出来，大家共同探讨！ 兄弟姐妹们请继续！
兄弟姐妹们请继续！
兄弟姐妹们请继续！
--------------
welcome to my homepage: www.ezService.org
1)：接口的集成度尽量高些，支持继承性的接口定义（就是定义地时候尽量的留出扩展）
2)：开发人员进行分离，业务层 + 表示层 //最好不进行跨界开发
3):接口少 + 精，开发模式 设计 -〉 模型 -〉 在设计 -〉 模型 2.如何注意安全性?
我们知道，RDM的安全性很差，其他人可能很容易恶意攻击你的系统，因为你可能会定义很多接口函数和输出很多TProvider。
安全性可能是一个不变的话题，软件做不到的事情，硬件可以做到。
DCOM已经提供了很好的安全处理机制，其实，在这儿，可以部队用户登陆信息进行什么安全性的验证，如果以RDM的登陆以安全性验证的话，你可以预留一个接口，进行用户身份认证，具体的做法相当多，其中，用户可能需要一个证书来反馈登陆信息反馈给用户的信息，这样可以在证书上做文章。这是一种，还有就是对接口之间调用的约定，等等，感觉方法太多了。
然而，安全商业只不过放君子罢了！
还有，你说的安全机制 是否要印出来事务机制？
2)：开发人员进行分离，业务层 + 表示层 //最好不进行跨界开发
这里开发人员进行分离，如果业务层没有开发完成的话，表示层的开发人员如何进行调试呢？
呵呵，没有这方面的经验，请指点一下，谢谢！
没有这方面的经验，请指点一下//设计 -〉 模型 -〉 在设计 -〉 模型
服务器和客户端都使用一个接口方法，然后通过命名管道的方式来调用。传入和传出的参数都通过Olevariant达包来传递。这样就就简化了接口的调用，
//Servicecode需要处理该调用的服务对象代码
//FuntionName 函数名，
//InParam 输入参数
//OutParam输出参数
。函数定义如下
function CallServiceFuncion(ServiceCode : string ;AFunctionName :string ;InParam :Olevariant ;out OutParam:Olevarint):integer;这里需要注意的是。应用服务器中对每个功能实体都定义了一个datamodule作为服务对象，它实现具体的功能。远程数据模块只是做一个分发中心，接受客户端请求，根据servicecode创建服务对象，转发请求给该服务对象。服务对象接收到命令请求后再根据具体的FunctionName再去实现具体的功能，返回值。通过这样的设计，客户端和服务器端的调用简单，对象颗粒化，职责清晰，缺点是：函数调用无法做到编译期检查，性能也不是很好你可以考虑这样的设计。
2)我想先认真，然后返回一串古怪的数字（当然每个用户认证的数字都不能一样），然后函数都要有这串数字，数字不对是不能调用函数的功能的。另外，值得注意的是效率问题，最好使用pool，另外MIDAS使用DCOM对服务器的性能要求比较高。
楼上各位说的都很有道理，让我受益非浅，毕竟欧没有参与过3层开发，见笑了。