在DOT.NET之前,从Browser CLIENT直接CALL SERVEr COM很难(可能性存在,但效率,跨防火墙等障碍使得实用性很低)
通常做法是:
(1)SERVER端在运行ASP时候就CALL COM,(这一切是在SERVER端完成),把COM结果付给即将传给client browser的ASP客户代码的hidden control, 或者displayed control中,这样,当客户端拿到HTML时候,就已经拿到了COM的结果。
(2)当Client Browser决定Call Server 的COM时候,也不会直接就调用,而是用GET/POST的方式把调用COM的参数传给SERVER, Server根据上传来的参数调用SERver端的COM.
================
当我们详细讨论其它internet上调用Server端的COM时候,就超出了ASP的范畴。
比如说,有的人不喜欢Browser/Server的Thin Client架构,他们Prefer Rich Client,那他们可以考虑使用WinSocket client + DCOM/ISAPI Server架构。
================
这一切将在Dot.Net出台后有根本改变,因为连Server 端的运行中的Object都可以用XML描述,并且可以顺利通过Internet 传递。当然此时的性能Performance问题就更需要小心的TUNE Up 了。
通常做法是:
(1)SERVER端在运行ASP时候就CALL COM,(这一切是在SERVER端完成),把COM结果付给即将传给client browser的ASP客户代码的hidden control, 或者displayed control中,这样,当客户端拿到HTML时候,就已经拿到了COM的结果。
(2)当Client Browser决定Call Server 的COM时候,也不会直接就调用,而是用GET/POST的方式把调用COM的参数传给SERVER, Server根据上传来的参数调用SERver端的COM.
================
当我们详细讨论其它internet上调用Server端的COM时候,就超出了ASP的范畴。
比如说,有的人不喜欢Browser/Server的Thin Client架构,他们Prefer Rich Client,那他们可以考虑使用WinSocket client + DCOM/ISAPI Server架构。
================
这一切将在Dot.Net出台后有根本改变,因为连Server 端的运行中的Object都可以用XML描述,并且可以顺利通过Internet 传递。当然此时的性能Performance问题就更需要小心的TUNE Up 了。