将POCO发布成WebService
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
WebService自动封装
1.前言
最近在做WebService相关的任务,任务主要的内容是如何管理和发布WebService,过程中通过学习和借鉴中对WebService进行整合的处理,在ZLBH中实现将现有的资源和功能通过WebService服务接口的方式进行管理和发布,现将过程分享如下。
简介
是一个关注于.NET企业应用开发的应用程序框架。它能够提供宽广范围的功能,例如依赖注入(IOC)、面向方面编程(AOP)、数据访问抽象, 以及、WebService、Windows Services、Remoting、COM+集成等,主要的模块如下图:
中的WebService
在.NET中对WebService的支持非常好,在VS中内置了WebService的构建和使用,不需要其他工具或SDK就可以完成WebService的开发,而且.NET Framework本身就全面支持WebService,包括服务器端的请求处理和客户端发送和接收SOAP消息的支持。
在VS中,通过内置的“Web服务”模板生成WebService服务端代码框架,类似于页面,包括一个*.Asmx标记文件和一个后台代码文件,如新建一个WebService1的Web服务,包括WebService1.asmx的标记文件和WebService1.asmx.cs的后台代码文件。
asmx标记文件内容类似于:
<%@WebService Language="C#"CodeBehind="WebService1.asmx.cs"Class="WebApp
lication2.WebService1"%>
指定了后台代码和具体调用的类名称,注:CodeBehind不是必须的,并可以修改。
代码文件内容类似于:
[WebService(Namespace = "/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
publicclass WebService1: System.Web.Services.WebService
{
[WebMethod]
publicstring HelloWorld()
{
return"Hello World";
}
}
其中对WebService、WebServiceBinding标签属性和对
System.Web.Services.WebService的继承都是可选的;
最后可以简略成如下结构:
publicclass WebService1
{
[WebMethod]
publicstring HelloWorld()
{
return"Hello World";
}
}
通过[WebService]向XML Web services 添加附加信息,如描述其功能字
符串,获取或设置XML Web services 的名称,获取或设置用于XML Web services 的默认XML 命名空间。
WebService的命名空间主要是控制SOAP的Action消息头以及返回结果XML的命名空间。
通过[WebService]标签,标明这是一个Web服务,通过WebMethod标明
这是一个Web方法,允许Web使用SOAP调用该方法。
从System.Web.Services.WebService是一个可选项,如果继承于这个类可获得对几个常见对象的访问权:
●Application对象和Session对象(状态管理)
●User对象(验证Web服务器调用者的身份)
Context对象(可以访问HttpContext类中调用者请求的所有特定HTTP信息)WebService就可以通过HttpContext控制这些对象了。
这样就在.NET的创建了一个可以被外部引用的WebService服务,外部程序(如:JAVA、JavaScript..)通过SOAP消息进行Web服务调用。
中管理WebService
先引用一段 framework帮助文档里的话:
“虽然目前.NET对web服务支持的非常好,认为还是有几个方面
可以改进。
●服务端
首先,.NET在.asmx文件中保存Web服务请求和服务对象的关联关系,这些.asmx文件不管有用没用都得放在那儿。
第二,希望能通过IoC容器对web服务进行依赖注入。一般说
来web服务总会依赖其它服务对象,所以,如果能用配置方式来选择服务对象,这个功能就相当强大了。
最后,目前在.NET中Web服务的创建完全是一个实现(特定类型)的过程。多数服务(虽不能说是全部)都应实现为使用粗粒度服务接口的普通类型,并且,某个对象能否发布为远程对象、web服务还是企业(COM+)组件应该只与配
置有关,而不应该取决于它的实现方式。
●消除对.asmx文件的依赖
用.aspx文件来保存表示层代码,用code-behind文件中的类保
存应用逻辑,.aspx与类代码文件各有分工;但web服务却不同,Web服务的逻辑完全是在code-behind的类中实现的。.asmx文件并没有什么真正的用途,
实际上,这个文件既没有必要存在、也不应该存在。
在将WebServiceFactoryHandler类注册为响应*.asmx请求的HTTP Handler之后,开发人员就可以在IoC容器中用标准的对象定义来
发布Web服务。
通过Http Handler拦截对Asmx文件的请求,在没有实际的asmx文件的情况下,通过动态代理来模拟一个.asmx页,Spring的动态代理由Spring.Web.Services.WebServiceExporter类来完成,它通过反射发出(Reflection Emit)动态创建一个内存驻留的名为Spring.Proxy的程序集,统一的类型为WebServiceExporter(继承于
System.Web.Services.WebService),WebServiceExporter为目标接口生成对应的代理,并添加对应的属性,当请求调用某个Web方法时,通过调用GetTarget方法取得对应接口的对象实例,调用实例的对应接口方法,返回结果。
对WebService处理的优点在于当生成服务端得Web服务代理时,不需要设置任何WebService的标签属性,比如[WebMethod]和[WebService],从文档中的一段话“Because .NET infrastructure code never really sees the "real" service, those attributes are redundant as the proxy needs to have them on its methods, because that's what .NET deals with, but they are not necessary on the target service's methods.”,可以得知,.NET架构代码从来不知道真正的服务实现在哪里,作为代理方法来说这些标签属性又都是多余的,因为.NET所处理的,但是对目标服务方法来说是不必要的。
这就意味着,我们可以放心的去掉原来Web服务上的[WebMethod]和[WebService],也就意味着我们可以通过代理自动为所有的接口方法添加[WebMethod]属性将POCO(Plain OLD CLR Object)发布成WebService。这样就可以在不改变原有代码的前提下,将现有的接口实现发布成WebService。
5.实验