在asp.net ajax中updatepanel比较常用,原本需要刷新的操作套在updatepanel中就成了ajax操作了,挺帅!但ajax也是支持与Xml Web Service交互的,这种方法更像是传统的ajaxpro和其他ajax框架,如jquery,magicajax,extjs的风格,但MS总是独树一帜,谁让他的产品设计能力那么高呢!我辈恐怕望尘莫及亚.闲话少叙,下面简单讲述下asp.net ajax如何调用xml web service,熟悉的朋友就略过吧
1. 创建一个支持Asp.Net Ajax的网站或者网络应用程序,我使用的是vs2008,在vs2008中,如果建立的网站支持.net framework 3.5就有ajax的缺省支持,这陈芝麻,烂谷子的事情,也不多说。
2. 建立好项目之后,在网站根目录中添加一个Web服务UserService.asmx,在UserService.asmx中添加如下方法:
注意服务类上部要添加Attribute
[System.Web.Script.Services.ScriptService]
3. 然后把default.aspx中的ScriptManager修改成如下代码的德性:
下面我们就在页面中创建用Ajax消费这个UserService的代码:主要包括如下:
在<head></head>添加如下脚本
4. 好,现在一个简单的ajax调用web service的示例代码已经搞定,罗索了不少,其实简单的不能再简单,运行页面,点击提交按钮,效果如下:
表示成功。一般人这一步都会成功的。二般的除外亚,:)
一些正常,那是不是到这里就万事大吉,ajax万岁!web service真好!下面是略加思考之后的问题
问题一:
上面的Xml Web Service没有任何保护,如果UserAdd是一个数据库插入操作,那这个操作往往系统只被经过授权的人才能调用成功。以前看有朋友讨论ajax如何调用带有SoapHeader的xml web service,细细想想,其实没什么必要!js是客户端的东西,是放出去收不回来的玩意,天知道用户是哪路货色 ,如果将身份信息试图通过js传递给SoapHeader,那密码被截获的可能性就比较大。正确的做法其实是Session .我们知道Web Service方法中添加一个[WebMethod(EnableSession=true)]就能使用Session了,Session这家伙专门用于保持会话,有这样一个 认识之后,新增一个网络服务方法,这个方法实现功能和起初的UserAdd一致,只是添加上访问限制
在页面中将AjaxWs.UserService.UserAdd(name,pwd,userAddCallBack);更改为AjaxWs.UserService.UserAddSecurity(name,pwd,userAddCallBack);点击提交按钮,会发现弹出结果为false!
在页面中添加一个按钮,点击这个按钮模拟登陆,点击代码为:
点击登陆按钮后,再次点击提交,便可以返回true。 这样便限制了用户对xml web service的访问。达到了解决问题一的目的。
问题二:
这个问题涉及到xml web service架构的缺陷,这个缺陷在WCF中已经有所更正和弥补。我们知道web service是一种强度公开和共享的技术,之所以称之为服务,必然是提供给其他应用程序所使用。但事实上,有很多服务是服务于局部或者特殊个体的,而不是理想中的大众。而在原来老的xml web service中,wsdl的发布与网络服务的发布是绑在一起的,我将.asmx部署到iis中,那在这个.asmx后加上?wsdl就能访问服务的wsdl。wsdl是对服务的描述,知道它,便能开发客户代理,从而消费服务,但这样有问题:我的服务只想让局部或者特殊的几个人知道 ,其他人根本不想让其访问到。这就麻烦了。我发布.asmx,wsdl就发布。而wsdl的发现依靠的是UDDI,通过下面的一段描述:
UDDI 如何被使用
假如行业发布了一个用于航班比率检测和预订的 UDDI 标准,航空公司就可以把它们的服务注册到一个 UDDI 目录中。然后旅行社就能够搜索这个 UDDI 目录以找到航空公司预订界面。当此界面被找到后,旅行社就能够立即与此服务进行通信,这样由于它使用了一套定义良好的预订界面。
如果遍历UDDI目录,不难发现WSDL,发现WSDL后便可以开发客户端与服务交互。这可不是好事情,在问题一中,用授权的方法可以解决一种问题,但假如我的服务是这样的,它返回服务器当前时间,这个方法对于我网站的用户而言是公开的,如果生硬的加上Session,有些麻烦。但这个服务我只希望我自己的ajax能访问,不希望别人发现并调用,但原来的xml web service架构的确不能满足这个需求。如果被一个攻击者发现,他可能会根据公开的wsdl开发客户端,然后不停的DDOS攻击,灾难!
上面这个问题对于原来的web service,我还是没有好的解决方案,当然不代表没有解决方案。有朋友知道,劳烦指教。
但对于WCF架构,就充分考虑到上面这个问题了。看看下面老的Xml Web Service架构与WCF架构之间的对比:
1) 老架构
2) 新架构
区别很明显,老架构MEX与业务耦合度非常高,俨然一体,而新的架构却将两者份将开来,分而不僵,反而会增加灵活性。如果是WCF开发的服务,在发布网站的时候,完全可以通过配置,将MEX终结点去掉,这样就可以解决上面的问题。具体实例下文讨论,有点困了,睡!
附上示例项目:
/Files/jillzhang/AjaxWs.rar
如对本文有疑问,请提交到交流论坛,广大热心网友会为你解答!! 点击进入论坛