小小飞鹰

     中国人缺少的是步骤,太急。练太极!
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

WebService基本概念

Posted on 2008-11-26 12:44  小小飞鹰  阅读(1132)  评论(1编辑  收藏  举报

 //=========================================================================================================================================       
        //Web Service大体上分为5个层次:
        //1. Http传输信道
        //2. XML的数据格式
        //3. SOAP封装格式
        //4. WSDL的描述方式
        //5. UDDI

        //总体上来讲,.NET 下的 Web Service结构比较简单,也比较容易理解和应用:
        //一般来讲在.NET结构下的WebService应用都是基于.net framework以及IIS的架构之下,所以部署(Dispose)起来相对比较容易点.
        //从实现的角度来讲,

        //首先WebService必须把暴露给客户端的方法所在的类继承于:System.Web.Services.WebService这个基类
        //其次所暴露的方法前面必须有[WebMethod]或者[WebMethodAttribute]

        //WebService的运行机理
        //首先客户端从服务器的到WebService的WSDL,同时在客户端声称一个代理类(Proxy Class)
        //这个代理类负责与WebService服务器进行Request 和Response
        //当一个数据(XML格式的)被封装成SOAP格式的数据流发送到服务器端的时候,就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析,然后对事物进行处理,处理结束以后再对这个计算结果进行SOAP包装,然后把这个包作为一个Response发送给客户端的代理类(Proxy Class),同样地,0,继而进行后续操作。

        //这就是WebService的一个运行过程。

       //当涉及到实体类集合的时候,如果使用IList<Student>来表示,就会抱错,原因是IList是不可以序列化的,这种情况下,我们就可以使用System.Collections.ObjectModel.Collection<Student>来表示一个实体类集合

//=========================================================================================================================================

        //        (一).XML WebService作用
        //  XML WebService在应用程序中所起的作用与.Net远程调用处理组件相同.
        //  用户不能直接使用WebService,只能通过Asp.net Web应用程序或Windows桌面
        //  客户端来调用.

        //(二).XML WebService与.Net远程处理区别
        //  1. XML WebService比.Net远程处理对象所受的限制更多。它类似于.Net远程处理
        //     的单独调用对象的工作机制。 不能创建一个单独的或是由客户端激活的对象.
        //  2.XML WebService的创建和设计比远程组件更容易/简单.
        //  3.Net远程处理二进制通信要比XML WebService SOAP格式通信要快捷.
        //  4.XML WebService较.Net远程处理扩展性强。 它支持以跨平台使用为目的的开放标准.
        //  5.XML WebService不需要专门的宿主程序,而是由Asp.net承载。 可以访问一些重要的
        //    平台服务,如:数据缓存/网络会话状态管理/身份验证/全局共享应用程序集合等。而.Net
        //    远程处理则很难实现这些功能.
        //  6.XML WebService运行在IIS和ASP.NET之上,使用http信道(80端口)与客户通信。
        //    可以自由跨越防火墙.

        //(三).XML WebService创建与调用过程
        //  I.服务端创建
        //     1.使用IIS,在Web服务器上新建一个虚拟目录来存放XML Web服务.
        //     2.建立XML WebService类,使用[WebMethod]属性来标记方法可以被远程调用.
        //     3.在虚拟目录中部署XML Web服务的文件.
        //  II.客户端使用
        //     1.客户端通过URL或文件查询或UDDI注册,发现XML WebService
        //     2.客户端请求描述XML WebService的WSDL文档。
        //     3.客户端在WSDL文档的基础上生成一个代理类。
        //     4.客户端生成代理类的实例,并调用XML Webservice,发送消息并接受处理后结果.
        //       也就是说调用XML WebService是由客户端生成的代理类实例对象完成的.

        //(四).IIS作用
        //  1.IIS通过虚拟目录提供对Web服务器进行访问。简单的说: 就是将"c:"MyWeb"映射
        //    一个URL地址形式的虚拟目录:"http://192.168.83.66/MyWeb",供本机或Internet
        //    上计算机访问Webservice.
        //  2.虚拟目录的权限与普通目录不同。根据默认设置,不允许远程用户浏览虚拟目录,运行
        //    可执行文件,新建文件和下载某些文件类型文件。可以根据需要自定义IIS虚拟目录权限设置.
        //  3.IIS对Internet进行公开处理. IIS并不负责运行Asp或Asp.net布面 或XML Webservice,而是
        //    维护一个注册的文件扩展名列表。如果IIS收到对某一种文件类型的请求,就把工作提交给
        //    Asp.net工作进程,由Asp.net工作进程处理剩下的工作.

        //(五).XML WebService和SOAP标准支持的数据类型
        //  不知道读者有没有遇到这种情况,在调用WebService并给一个方法传递了一个DataRow参数时,运行
        //  时会抛出异常: "没法将参数序列化!",如果把DataRow加入到DataSet中,并将DataSet作为参数
        //  传递再运行就OK了。 这是因为:XML WebService只能对数据集DataSet对象类型进行XML序列化,
        //  不能对DataRow对象类型进行XML序列化造成的错误.  所以了解一下XML WebService支持序列化的基
        //  本数据类型是比较重要的.它支持的数据类型如下:
        //  1.基本数据类型.  
        //      标准类型,如:int float bool DateTime string等基本数据类型
        //  2.枚举.
        //      支持枚举Enum定义的类型
        //  3.自定义对象.
        //      可以传递任意基于自定义类或结构创建的对象。 但要注意一点: 它只能传输数据成员(变量和属性).
        //      如果定义了方法,则方法不能进行序列化传输,序列化后只剩下数据成员.
        //  4.DataSet对象
        //      支持DataSet,切记:不支持DataTable和DataRow,DataSet已经是XML Webservice能够支持的最小的可序列化对象.
        //  5.XmlNode对象
        //      基于XmlNode的对象可以表示XML文档的一部分.
        //  6.数组和集合
        //      可以使用任何被支持的类型的数组和简单集合,包括: DataSet对象/XmlNode对象和自定义对象.

 //=========================================================================================================================================
        //长项一: 跨防火墙的通信
        //如果应用程序有成千上万的用户,而且分布在世界各地,那么客户端和服务器之间的通信将是一个棘手的问题。
        //因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下,使用DCOM就不是那么简单,
        ///通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是,选择用浏览器作为客户端,
        /////写下一大堆ASP页面,把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大,程序很难维护。

        //        长项二: 应用程序集成
        //企业级的应用程序开发者都知道,企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来,
        //而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据;
        //或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上,不同软件厂商生产的各种软件也常常需要集成起来
        //。通过Web Service,应用程序可以用标准的方法把功能和数据“暴露”出来,供其它应用程序使用。

        //        长项三: B2B的集成
        //用Web Service集成应用程序,可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户
        //、突破公司的界限时会怎么样呢?跨公司的商务交易集成通常叫做B2B集成。

        //        长项四: 软件和数据重用
        //软件重用是一个很大的主题,重用的形式很多,重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用
        //,另一种形式是二进制形式的组件重用。

        //短处一: 单机应用程序
        //目前,企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。
        //在这种情况下,最好就不要用Web Service,只要用本地的API就可以了。COM非常适合于在这种情况下工作,
        //因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用
        //。当然Web Service 也能用在这些场合,但那样不仅消耗太大,而且不会带来任何好处。

        //        短处二: 局域网的同构应用程序
        //在许多应用中,所有的程序都是用VB或VC开发的,都在Windows平台下使用COM,都运行在同一个局域网上。
        //例如,有两个服务器应用程序需要相互通信,或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。
        //在这些程序里,使用DCOM会比SOAP/HTTP有效得多。与此相类似,如果一个.NET程序要连接到局域网上的另一个.NET程序,
        //应该使用.NET remoting。有趣的是,在.NET remoting中,也可以指定使用SOAP/HTTP来进行Web Service 调用。
        //不过最好还是直接通过TCP进行RPC调用,那样会有效得多。