delphi , webservice 与三层

[qufo]

三层程序一直在讨论，但无论我看哪个三层，都觉得不对劲，唯一对劲的就是 WebService实现的三层。

三层程序中，我们有一个数据管理层，这一层大家都交给DBMS了，如Sqlserver,Oracle.

一层是业务逻辑，这一层我们要考虑，要编码的。

还有一层是表现层。

三层应是相互独立的。

也就是说，逻辑层不知道下面的表现层是用delphi的win32表现还是Web形式的表现，反正只要符合一定的规则，就可以交流。

逻辑层负责逻辑完了，与数据库交流，不管数据是什么系统，他都要能交流得上（比如用标准sql与数据库系统连接）

这样一来，逻辑层只好用WebService了。


各位，我理解的三层与大众的理解不一定是一致的，这只是我的想法，欢迎拍砖。

Ps，拍完砖顺便告诉我一下一直困扰我的 WebService 执行验证，大家是怎么解决的。。

[hqhqhw]

谢谢sz_haitao用非常专业词语补充。
当时我用了口令，而没有用帐号密码之类的的词汇，想它包括SessionID或者其他各种形式的key，或者是一句“芝麻开门”，我以为做过的人都能想到呢。

[aipeli]

看了sz_haitao的这篇贴子受益非浅，学习到了另一种架构方式，但我比较关心的是数据转输速度，同在互联网的环境下可能速度相当，但如果在局域网内的INI@HTTP与DCOM的方式哪个速度快些，如果传输数据量在10W级，客户端等待数据转输会不会引起超时，有没有好的解决办法，如：分页传输数据等。

谢谢！

[hqhqhw]

re tjianliang

ActiveX也算？
MIDAS/DataSnap算不？虽然性能和稳定性上总是被指责

对于分层设计，我想有架构设计和部署实现两个层面，两个层面有关联，但关注点不完全一致。
总得说没有最好的设计或实现，只有最适合的。

WebService作为一种实现方式最大的优势我想就是标准化
-------------------------------------------------
不好意思，我01年开始delphi编程两年半就转了dotnet&java了，所以现在只记得大概做法。
ActiveX属于Internet编程，web上最直接的感受是flash player。我们当然可以用它来实现很多功能，因为能嵌入网页，所以偶尔也归于web。
最早称为MIDAS（Multi-tier Distributed Application Services Suite），后来称为DataSnap，那只是一个架构的大概念，具体在delphi开发环境里也就是控件组的名字而已。使用DataSnap组里面的WebConnection控件,其过程就如上我说的第一种，只是我用的话糙点。
不是信息本身累，而是交流方式累。看来我还要坚持“只看不说”的上网风格了，破例是想要点分还怀怀旧。我声明我什么都没说，也不要再有人就我的话回复，因为你一回我又得打字。

[亮剑_]

[Quote=引用 55 楼 hqhqhw 的回复:]
愿意交流下,delphi中三层的实现有四种方式,其中的一种走HTTP，也就是web了。前人具体做法又有：
1、自己写一个类似tomcat.exe/php.exe的文件来，自己玩一套。
2、webservice，这个是大家现在一直挂嘴边的。因为它是状态无关的，所以为了通过验证，到哪里都得把口令贴在脑门上。
3、再不济的，就用ActiveX了。
[/Quote]
ActiveX也算？
MIDAS/DataSnap算不？虽然性能和稳定性上总是被指责

对于分层设计，我想有架构设计和部署实现两个层面，两个层面有关联，但关注点不完全一致。
总得说没有最好的设计或实现，只有最适合的。

WebService作为一种实现方式最大的优势我想就是标准化。

[haitao]

[Quote=引用 68 楼 aipeli 的回复:]
看了sz_haitao的这篇贴子受益非浅，学习到了另一种架构方式，但我比较关心的是数据转输速度，同在互联网的环境下可能速度相当，但如果在局域网内的INI@HTTP与DCOM的方式哪个速度快些，如果传输数据量在10W级，客户端等待数据转输会不会引起超时，有没有好的解决办法，如：分页传输数据等。

谢谢！
[/Quote]

我的实际应用遇到过最大：3万条记录，7M字节的ini数据，压缩后为2M，异地（同省）接收，客户端等待大约5-15秒，服务器为5M的adsl，客户端是4M的adsl

[aipeli]

[Quote=引用 70 楼 sz_haitao 的回复:]
引用 68 楼 aipeli 的回复:
看了sz_haitao的这篇贴子受益非浅，学习到了另一种架构方式，但我比较关心的是数据转输速度，同在互联网的环境下可能速度相当，但如果在局域网内的INI@HTTP与DCOM的方式哪个速度快些，如果传输数据量在10W级，客户端等待数据转输会不会引起超时，有没有好的解决办法，如：分页传输数据等。

谢谢！


我的实际应用遇到过最大：3万条记录，7M字节的ini数据，压缩后为2M，异地（同省）接收，客户端等待大约5-15秒，服务器为5M的adsl，客户端是4M的adsl
[/Quote]

哪局域网内呢？同样的是3万记录，大概耗时多少呢？

[大肚肥肥]

这个帖子好。。

[haitao]

[Quote=引用 71 楼 aipeli 的回复:]
引用 70 楼 sz_haitao 的回复:
引用 68 楼 aipeli 的回复:
看了sz_haitao的这篇贴子受益非浅，学习到了另一种架构方式，但我比较关心的是数据转输速度，同在互联网的环境下可能速度相当，但如果在局域网内的INI@HTTP与DCOM的方式哪个速度快些，如果传输数据量在10W级，客户端等待数据转输会不会引起超时，有没有好的解决办法，如：分页传输数据等。

谢谢！


我的实际应用遇到过最大：3万条记录，7M字节的ini数据，压缩后为2M，异地（同省）接收，客户端等待大约5-15秒，服务器为5M的adsl，客户端是4M的adsl


哪局域网内呢？同样的是3万记录，大概耗时多少呢？
[/Quote]

局域网只会更快，因为一般都是100M的连接。比上面的实例快了10倍。当然仅仅是传输快10倍，数据库的io、组包、压缩的速度是一样的

[aipeli]

谢谢，下次在做项目选择架构方式时，又多了种可选的方案。你哪里有没有相关的DEMO呢?可不可以发份给我学习下呢？ 邮箱:aipeli at 163 dot com 。

[nanchangfantasy]

顶,学了不少东西

[lyhoo163]

up

[tristan1212]

嗯,写的不错,学到不少东西,我现在需要做个Web应用程序,可是不会

[lyguo]

socket 技术比较成熟
另外也可以用Soap + WebService + COM+ 数据库

[fsse2000]

使用 Delphi + WebService + DBMS
這中模式比較好， 可以跨平臺服務， 中間層用java些，
利用XML 壓縮傳輸，速度嘛，還比較可以的，我從上海傳遞1萬條數據 到深圳，
1、20秒吧。具體沒有測試研究。

主要是 中間層的java強大 ，使用 java 比較靈活， 而客戶端使用Delphi 那是不爭的事實。

兩者優點相互結合，我趨向于這中模式，至于使用socket 或者 ini什么的，我沒有試驗過。
XML是通用網絡傳輸標準語言，還是跟標準走好。

[qufo]

[Quote=引用 56 楼 sz_haitao 的回复:]
2、状态无关的，也不用 为了通过验证，到哪里都得把口令贴在脑门上
【
安全性的实现：

由于HTTP协议的上下文无关特性，任何B/W或C/W模式的应用，都离不开如何“以上下文无关的协议实现上下文有关的逻辑”的问题。如：正常的应用流程是“先用户登录，合法用户才可以进行内容访问操作”，而HTTP协议的上下文无关，使得用户登录与内容访问操作不存在必然的关系，即非法用户只要知道了内容访问操作的URL，也可以绕开用户登录而直接进入内容访问操作，这显然是一个很严重的安全漏洞！

笨拙的解决办法是：要求内容访问操作也附加用户合法性验证的信息，但是每次操作都附加用户合法性验证的信息，一则数据冗余，二则增加了不安全因素。

幸亏B/W模式的应用有了一个巧妙的通用解决措施：通过一次有效的SessionID。服务器维护一个“合法登录用户信息—随机码”的对照表，对于经过用户登录被验证为合法的用户，服务器生成一个随机码（可以是纯数字，也可以是字符串，只要足够长度以致非法用户难以伪造冒认），并将此随机码与该用户信息一起存入“合法登录用户信息—随机码”的对照表，同时将此随机码发给前端（浏览器），以后前端（浏览器）的内容访问操作必须附加这个随机码（而不是原本的用户合法性验证的信息）以供服务器验证，没有随机码或随机码不存在于“合法登录用户信息—随机码”对照表的请求被视为无效请求。“合法登录用户信息—随机码”对照表的内容，在对应用户显式退出或超过指定时间没有操作请求后，自动被服务器删除。

这样，即使某个有效的随机码被非法用户截获，那么这个非法用户也只能盗用一段时间，下一次就仍然会拒之门外。
】
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sz_haitao/archive/2009/09/10/4539228.aspx
[/Quote]

扯鸡8蛋。 我一直占着 这个 SessionID,一直发心跳包，不就可以不拉屎啦，这个盗用“一段时间”，从历史的长河中看，还真是一段。

[haitao]

lz、楼上也不用这么激动吧

sessionid机制，是有这个被“暂时”盗用的可能，如果后台怕它一直刷新以便失效，可以把失效机制改为：登录n个小时，不管是不是还有请求，一律失效

我认为这个机制好，是因为：如果帐号、密码被截取，损失更大

另外，防止截取方面，还有一次性过程密钥、另外渠道获取附加校验码之类的做法（这个做法对于sessionid还是帐号密码都是适用的），就看是不是值得

[luoyanqing119]

如果中间层用webservice，客户端转输比较大数据时，可以压缩后，做BASE64运算，在封包，这样就不会存在安全问题了。-------如果服务器端的SOAP通过一定的运算转换，那么一般人也得不到实际的结口。（安不安全不是架构的问题，应该是人的问题）

[luoyanqing119]

中间层也用过JAVA+TOMCAT+Axis2，但是JAVA写的中间层有点变态，占用次源太高。

[山东蓝鸟贵薪]

看的头都大了,不过先谢谢了>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

[qufo]

不好意思,搞了个跨年贴.