ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Web Service开发中需要注意的问题

Web Service开发中需要注意的问题

原创 Linux操作系统 作者:wenjianan 时间:2009-06-24 10:06:47 0 删除 编辑

一只倒霉的狐狸被猎人用套子套住了一只爪子,它毫不迟疑地咬断了那只小腿,然后逃命。放弃一只腿而保全一条性命,这是孤独的哲学。

人生亦应如此,当生活强迫我们必须付出惨痛的代价时,主动放弃局部利益而保全整体利益才是最明智的选择。智者曰:“两弊相衡取其轻,两利相权取其重。”趋利避害,这也正是放弃的实质。

玫瑰花枯萎了,蜜蜂仍拼命吮吸,因为它以前从这朵花上吮吸过甜蜜。但是,现在在这朵花上,蜜蜂吮吸的是毒汁。蜜蜂知道这一点,因为毒汁苦涩,与以前的味道是天壤之别。于是,蜜蜂愤不过,它吸一口就抬起头来向整个世界抱怨,为什么味道变了?

终于有一天,不知道是什么原因,蜜蜂振动翅膀,飞高了一点。这时,它发现,枯萎的玫瑰花周围,处处是鲜花。

求职的路也并非一帆风顺,有时不好的境遇会不期而至,搞得我们狼狈不堪。这时我们应该学会放弃,放弃焦躁的心理,放弃过高的期望,放弃已经属于我们但我们并不擅长的职位或行业。放弃有时候是痛苦的,但学会放弃却是一种洒脱,一种智慧。

 

Web Service开发中需要注意的问题
1.接口是自说明的
接口的名字、参数和返回值应该一看就知道这接口大概是干什么用的。当然接口描述文档肯定是必需的,但这些描述文档的质量谁知道怎么样呢,谁有空天天翻着文档写东西呢,又有谁会背下来呢?所以让人眼前一亮的接口命名绝对值得,这也是所有代码书会告诉你应该遵守的一条规则。

2.服务接口粒度要合适
Web Service服务接口粒度太小了,那纯粹是不考虑XML解析性能了。一般新手容易犯这毛病,简单地把类的方法暴露出来做服务接口,这样其实是把原来在 local的调用放到了remote,除此之外几乎没有任何好处。粒度太大,会给使用者带来很多麻烦,因为在Web Service中,粒度很大的服务一般都需要很多参数来映射该服务各种各样的情况。

3.接口参数要尽量简单
只有一个参数的服务接口,往往不能满足业务需求。但过多的参数也提高了出错的几率,增加了测试的成本。所以,参数恰到好处为妙。

4.要提供对接口参数和返回值的校验
严格来说,对接口参数和返回值的验证也应该算是Web Service接口声明的一部分。增加对参数和返回值的校验,有利于减少调用者的疑惑,系统接受什么样的参数,返回值是什么格式都一目了然。但是这需要一个很好的权衡,否则调用者会觉得你暴露的方法很难用,因为限制太多了。比较理想的系统应该是宽进严出的,目标用户越多越应该注意这一点。要在宽进严出和全面校验之间做好平衡确实挺难的。简单的办法是,对要暴露的接口自己做测试,在测试的过程中体会这个度。一般来说如果自己感觉都不爽,那别人是绝对不会用的。

5.接口的返回值应该是简单的语言无关的
听见过很多人问如何返回DataSet之类的复杂类型,尤其是玩.NET的人,也许是VS.NET对封装DataSet提供了过于完美的支持吧。但对于XML来说,把任何复杂对象映射到XML文档都是困难的。就好比把三维向二维投影一样,复杂性增加了可不是一点半点。在XML中说到底所有的类型都是字符串,要想表达其他类型,就要添加额外的说明。可以看看rpc/encode方式WSDL文档的complexType部分,自行体会。

6.谨慎地抛出异常
对Web Service中的任何异常都应该进行相应的处理。可以简单地归纳为以下两种情况。

第1种情况是接口返回值是简单类型,比如bool型,就true和false两种情况,不抛出异常怎么办?选择有两种,一是抛出异常,二是改变接口,返回int用1和0对应true和false,用-1对应系统异常。

第2种情况是接口返回值是复杂对象,可以通过参数out string exceptionInfo来返回异常信息。

7.接口要尽量采用更新的标准
如何让一次定义的接口能服务得更好更久?从技术规范方面来说有两点:不超前,不落伍。超前,支持它的工具集不会太丰富,估计谁也不想弄出个看起来很美但是谁都用不了的东西;落伍,眼前所有的工具大概都支持,不过明天就不一定了,技术发展这么快,不能把自己累死吧。尽量采用更新的标准的意思是在不落伍的基础上要有前瞻性。举个简单的例子,今天再采用rpc/encode方式就显得不合时宜了,虽然它在前两年很流行,可今天都已经不提倡用了,明天说不定大家就都忘了。就算你及时更新了你的接口,客户也说不定已经换了供应商了。

8.要注意标准的通用性
虽然都是一样的标准,但标准有不同的版本,而且即使是同一个版本的标准,不同的工具实现起来也还是有细微差别的。如果用户是特定的还好说,采用些工具绑定的特性也没什么。但如果接口用户不是特定的人群,那就要注意了,在采用某一规范标准时不要用实现工具所特有的东西,否则很有可能造成客户的麻烦,导致只有很少一部分客户能使用你提供的接口。多一个客户就多一分钱啊,兄弟,干嘛跟钱过不去?

9.禁用HTTP POST/GET协议
除非另外指定,否则.NET将试图把Web服务绑定到3种协议:HTTP/POST、HTTP/GET和SOAP。之所以说“试图”,是因为依赖于服务的参数和返回类型,HTTP/GET协议可能不可用。.NET生成的WSDL文件将自动包含绑定这3种协议的指令,客户程序可以自由选择使用哪种协议与服务通信。

只要在Web.config文件中加入下列内容,就可以删除对HTTP/POST和HTTP/GET协议的绑定:

   

       

       

   

为什么要避免通过HTTP/POST和HTTP/GET协议引出Web服务呢?主要的2个因素是安全性和互操作性。HTTP/GET的安全性不如SOAP,而且由于HTTP/GET常见于Web链接,怀有恶意的人可能利用它实施欺骗,使别人在不知不觉中用自己的安全标识调用Web服务,却还以为自己在单击Web链接。

就互操作性而言,SOAP是广泛应用的Web服务通信标准,而HTTP/GET和HTTP/POST不是。因此,对于.NET生成的WSDL文档中默认包含的HTTP/GET和HTTP/POST绑定,许多自动生成代理服务器的工具不会理解。因此,如果你的Web服务不是非绑定到HTTP/GET和HTTP/POST协议不可,最好取消这两种绑定。

10.用TcpTrace查看SOAP请求/应答消息
对于开发Web服务应用的人来说,调试可能是件异乎寻常的难事,因为无论是.NET SDK还是VS.NET,都没有提供工具来查看客户端和服务器之间的SOAP消息。

如果.NET和非.NET的客户端、服务器端的交互过程出现了问题,要想找出问题的根源,拥有查看SOAP消息的能力就尤为重要,因为这类问题往往与SOAP消息的格式有关(例如“消息中包含了SOAPAction吗?”)。

tcpTrace(www.pocketsoap.com/tcptrace)是一个查看这类消息交换过程的优秀工具,它通过设置一个客户端和服务器端之间的隧道工作。启动tcpTrace时,它会要求输入目标URL和端口号,以及tcpTrace监听的本地端口号。这样,你就可以通过设置代理stub的URL属性,把stub指向这个本地端口(例如localhost:8080)。tcpTrace能够记录所有的请求和应答HTTP消息。

tcpTrace的一个局限是,它在消息流程中所处的位置决定了它不能用来查看通过SSL发送的消息。如果你要查看通过SSL发送的SOAP消息,只能编写一个定制的ISAPI过滤器。

11.简化接口设计
在众多有关N-层应用设计的论述中,简化接口设计这一设计要诀可以说是随处可见。但是,对于Web服务这样的分布式计算环境来说,简化接口设计的重要性更加突出。

在设计分布式应用时,出于性能和可伸缩性的考虑,应当保证客户端和服务器端之间的调用尽可能地少。减少网络调用不仅有利于减少通信开销(如果只用1个SOAP消息可以达到目标,就绝对不要发3个消息),降低网络流量,而且提高了应用的性能。显然,这一切都是开发者梦寐以求的目标。那么简化的接口到底有何特征呢?

首先来看一个复杂接口的例子:

namespace ChattyService

{

    public class ChattyService : WebService

    {

        private string username;

        private string password;

        public string Username

        {

            [WebMethod]

            set

            {

                username = Username;

            }

        }

        public string Password

        {

            [WebMethod]

            set

            {

                password = Password;

            }

        }

        [WebMethod]

        public bool Logon()

        {

            //验证身份

            return true;

        }

    }

}

在这个例子中,username和password是两个属性,调用logon()方法之前首先必须设置这两个属性。有一个问题光看这段代码不太容易注意到,这就是username和password都作为Web方法引出。这就是说,每次对属性的get/set操作都会导致一个对服务的调用。

按照简化接口设计的要求,改进后的代码如下:

namespace ChattyService

{

    public class ChattyService : WebService

    {

        [WebMethod]

        public bool Logon(string Username, string Password)

        {

            //验证身份

            return true;

        }

    }

}

现在,username和password成了logon()方法的参数。修改之后的代码的优点在于,它把登录操作对服务器的3次调用降低到了1次。另一方面,如果参数的个数太多,这个方法可能看起来很不像样。这时,可能要把方法的参数整理成几个复杂类型,例如,把username和password 两个参数封装到一个credential(证书)对象中。

12.避免使用ASP.NET会话状态
.NET实现的会话状态管理功能解决了它的前辈ASP 3.0存在的许多问题,例如请求串行化等,但仍存在一些局限。应当认识到,.NET的会话状态管理功能不是专门为Web服务环境中的会话状态而设计的,而是为了在范围更广泛的ASP.NET应用中管理会话状态而设计的,它依赖于HTTP Cookie(有一种通过改写URL实现的不需要Cookie的模式,但不适用于Web服务)。

Cookie是HTTP独有的。在Web上,所有的浏览器都支持HTTP,所以Cookie非常适合在Web应用中使用。但是,在Web服务中应用Cookie却把服务限定到了HTTP协议上。另一方面,SOAP协议的运行是独立于传输协议的,因此如果把Web服务应用限制到HTTP协议上,那么应用的灵活性也将受到限制,一旦要通过非HTTP的传输协议(例如SMTP)提供服务,事情就会变得很麻烦。
常见技术面试题

 什么是Web Service?

Web Service有何优势?

如何在ASP.NET中创建Web Service?

保证WebService的安全有哪些措施?

常见面试技巧之经典问题巧回答
你对加班有什么看法?

“你能接受加班吗?”曾经一家台资企业以此为应聘者设了第一关。这让不少大学生都打了“退堂鼓”,直接拒绝:“太累了!”“连续加班啊,我不行!”

程序员由于其所处的行业特性,大部分属于项目制。如果项目延期或系统出了问题,的确需要临时加班。不过,一开始就问这个问题,主要是考察学生的心态,看学生有没有责任心,能不能吃苦。如果不具备责任心和吃苦精神,业务能力再突出也无济于事。

其实,用人单位非常注重应聘者是否具有责任感和吃苦精神。虽然不少人专业素质很不错,但真正到了实际工作中,经常牢骚漫天。

可以这样说,高效工作是人才的一个必备素质,也是为企业提高效率的一个途径。因此,能在工作时间内完成的就不要拖到休息时间。但如果确是工作需要,或者公司做了临时的安排,那加班完成工作当然义不容辞,“优先把事情做好”是我一贯的准则。另外,最好还能说明自己可以加班的条件,比如目前尚无家室,也可以抽出比较多的时间和精力。

你是否考虑过个人创业?

“你是否考虑过个人创业?如果希望个人创业,你准备什么时候创业? ”

在回答这个问题时要注意,千万不要逞一时英雄来表现自己的雄心壮志。既然面试,说明你选择打工,所以避免提及创业。因为打工和当老板差异太大,过多地在面试中表达想创业的想法会使面试官不舒服;很多公司还会害怕有朝一日你在他这带走核心技术资料、商业秘密。所以,可以说:“我目前不考虑创业;我的目标是安心工作,在这个行业、在这个岗位上有所作为。”

本文出自《亮剑.NET:.NET深入体验与实战精要》一书

本系列图书技术问题答疑平台: www.100tt.net


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9215421/viewspace-607366/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-06-09

  • 博文量
    111
  • 访问量
    107733