7.10 Web Service开发中需要注意的问题（2）

7.10  Web Service开发中需要注意的问题（2）

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）提供服务，事情就会变得很麻烦。