Web Service在.NET项目开发中的概念、实用性辩析
Web Service（WS）是VS.NET平台中的一个亮点，成为在J2EE架构与.NET企业架构中的唯一一个有“共同语言”的东西。
我们在项目的开发中，并没有太多的使用WS，我对WS的实战经验也不多。从众多的网站讨论中，我觉得有几个重要的东西，下面是积于我目前的理解所做的一个总结，大家评论一下，哪些是错的，哪些是对的：
一、WS相关一堆名词什么关系
XML：不说了
WSDL：用于描述WS，XML格式，指示客户端如何与该WS进行交互。
UDDI：WS如何发布，客户如何找到WS，用UDDI
与那个天才的名字DISCO有关！！？？ ：o
（以下摘自MSDN）
UDDI（通用说明、发现和集成）规范定义一个发布和发现有关 XML Web services 的信息的标准方式。与 UDDI 关联的 XML 架构定义四种使开发人员能够使用已发布的 XML Web services 的信息。它们是：业务信息、服务信息、绑定信息以及有关服务规范的信息。
作为 UDDI 项目的核心组件，UDDI 业务注册表使业务能够以编程方式定位有关其他单位公开的 XML Web services 的信息。开发人员可以使用 UDDI 业务注册表定位发现文档和服务说明。
SOAP：一个协议，内容为XML格式的、在WEB上交换数据的轻量协议。
它在WS中的作用是：服务器与客户端交换数据时使用的协议。
（以下摘自MSDN）
SOAP 协议规范包含四个主要组成部分。第一部分定义用于封装数据的必需的可扩展信封。该 SOAP 信封定义 SOAP 消息，并且是 SOAP 消息处理器之间的基本交换单位。这是该规范唯一必需的部分。
SOAP 协议规范的第二部分定义用来表示应用程序定义的数据类型和有向图形的可选数据编码规则，以及用于序列化非句法数据模型的统一模型。
第三部分定义 RPC 样式（请求/响应）的消息交换模式。每个 SOAP 消息都是单向传输。尽管 SOAP 的根位于 RPC 中，但它不仅仅只是请求/响应机制。XML Web services 经常组合 SOAP 消息以实现此类模式，但 SOAP 并不强制要求消息交换模式，这部分规范也是可选的。
规范的第四部分定义 SOAP 和 HTTP 之间的绑定。但该部分也是可选的。可以将 SOAP 与任何能够传输 SOAP 信封的传输协议或机制（包括 SMTP、FTP 甚至软盘）结合在一起使用。
二、请大家帮我纠正几个概念
首先需要纠正一些概念。
第一个要正名一下多层结构：
我们讲分层开发，注意，通常只是软件代码结构，并不是部署的结构。
我们开发软件时，分数据访问层，分业务逻辑层，分界面层，但实际上是编译完成后，在部署时这些层物理上是在同一台机器上的，数据库可能再放一台机器，如果说这是多层应用的话，显然是一个误区。
分层开发提供是良好代码组织管理、易维护，只是一种代码组织手段，越大的工程，这一点的优势越明显；越小的工程，优势越微弱，甚至为劣势。
可以简单的说，分层开发无非是指一个应用1.EXE或者1.ASPX，通过2.DLL找到3.DLL，2.DLL通过3.DLL找到4.DLL，3.DLL通过4.DLL找到5.DLL，4.DLL通过5.DLL找到6.DLL……最后，n.DLL去找存储过程，存储过程去找数据库中的数据。
发布时，存储过程和数据库表只能在一台机器上，其它代码编译后只能在一台机器上。两台机器。
所以多层结构是软件架构，是代码级的结构，与部署没有任何关系。
有人画一个图，一个服务器称为DB Server，一个服务器称为WEB Server，然后画一个笔记本，标上IE，说是客户端，并郑重指出这就是多层结构。！！！大错特错！！！
以上是我的理解，标注为问题1，大家评论对不对。
第二个要纠正一下B/S结构与C/S结构：
很多公司和程序员口口声声说“我们转向B/S结构了”，至今我不明白传统意义上的B/S结构与C/S结构的软件在开发上有什么区别？？？！！！
我觉得在开发上没有任何区别，都是写一堆代码，访问数据库服务器而已。
唯一的不同仅在部署方面。所谓B/S结构将代码装在一台机器上，用户从自己的机器上直接访问服务器就行了。C/S结构将代码装在每个用户的机器上而已，如此而已。一堆人跳出来说这样维护方便。我做了很多大大小小的项目，没觉得方便多少。如果能从服务器上拷贝个客户端软件我更喜欢。安全？我做的项目中没有用户想用好还要好好学习一下，想不出错来不及，会当黑客、搞坏你的数据？？？
因此我觉得所谓的B/S结构与C/S结构在软件开发方面没有任何区别。
以上是我的理解，标注为问题2，大家评论对不对。
第三个要说一下“业务逻辑层”
业务逻辑层是一个很操蛋的名词，不明不白。
如果说明数据层指数据库，界面层指应用程序界面或者IE里看到的东西，那么这两个名词就象说“帽子”、“鞋”一样，很明确。
而业务逻辑层像什么？？我觉得象“衣服”一样很不明确。
所以你可以说你穿了鞋和衣服，你也可以说你穿了鞋、帽子、袜子、裤衩和衣服。
所以，能解释的通的做法，只能将数据层、界面层之外的东西统统称为业务逻辑层。
以上是我的理解，标注为问题3，大家评论对不对。
至今我不能确定下面两个命题的真伪，大家写下答案：
1、 存储过程可以处理大量业务，包括访问数据、统计计算、查找数据等，但存储过程只能放在数据库里，而且，我几乎没有遇到过有足够理由将存储过程与数据库数据分别放在两个数据库实例中的要求（仅用过一些所谓的“远过程调用”，即ServerName.DBName.DBSchema.TableName的全格式调用）。
那么，存储过程是数据层还是业务逻辑层？
还是有的存储过程是数据层，有的存储过程是业务逻辑层？——如果是，这又是个操蛋的答案。我查找叫“GONGLV”的用户的SP（存储过程）是业务逻辑层、而得到所有用户的SP是数据层？？？
以上是我的理解，标注为问题4，大家评论一下或给出答案。
2、 什么是数据层？DBMS加上一堆表能不能叫数据层？还是直接访问数据库的C#/C++/VB/JAVA代码才叫数据层？还是两个加一起？？还是其它？？？
这个问题可能答案已经明确，我说了半天将自己说糊涂了，标注为问题5，大家给个答案，拯救一下我。
三、WS到底干了什么
我们开始说我们的WS。
如果我的理解不错的话，实际上，C/S结构与B/S结构的区别，多层结构等概念，实际上是程序员在写代码时的逻辑概念，仅用于开发过程，本质上都是写一个软件，访问一下服务器而已。
开发与部署是不同的。WS的唯一的作用是在软件部署上的作用。
我们可以写一个程序，作为服务器（A），访问数据库服务器（B），在5678端口listen。
我们再写一个程序，作为客户端（C），通过TCP/IP协议访问服务器（A），到5678端口找东西，不管你是异步的还是同步的。
这样，在部署时，第一次有可能使用两台以上的服务器，A、B和C，当然如果客户端C是一个WEB网站，那么还可以有一个“笔记本”IE（D）去访问它，但这个应用应该是三部分，D不应计算在内的。
于是可以用户访问我们的A1，A1通过A2找A3，再找A4，再找A5，再找……瞧，可以有无数台服务器（如果必要）。
我觉得这是另外一种“多层结构”，与前面讲的“多层结构”完全不同，因此只要存在多层，一次是合理的，不能象有些例子中，硬分成BusinessFacade、BusinessRules、DataAccess什么是，而每一层中都有一个参数和代码几近完全相同的函数，层层调用——这只会增加软件维护的复杂度，与软件开发的基本思想相去甚远。
或者权且叫做系统的“可多服务器部署多层结构”
当不再直接（DIRECT）用TCP/IP协议了，不再传递二进制格式的数据了，可以有新的概念，将数据格式、协议固化下来，推荐给大家用，看，这就是新的标准，或者是让无数的、大大小小的、新的老的程序员们心动的“新技术”。
比如DCOM，比如CORBA。
再比如…………………………………………Web Service。
不再是约定一个5678端口，而用UDDI去发现。
不再（直接）用TCP/IP协议，使用SOAP传递。
不再说好我给你什么，你再给我什么，而使用WDSL告诉你。
不再传递二进制格式的数据，而是XML格式，必须是二进制的（如图片）转换为BASE64格式，长35%也没关系。
以上是我的理解，标注为问题6，大家评论。
四、WS的优势评析
我一直困惑以致夜不能寐：在我们实际的软件产品中，WS到底有什么优势？
1、 实现起来简单
简单所以会滥用，何况咱们的程序就怕简单，越复杂越喜欢。
2、 可以提供一个WS计算A+B=？收钱
买个函数库一样实惠，还有张漂亮的光盘，不担心卖WS的厂家会倒闭，或者提供WS的服务器会DOWN机。
3、 发布一次，大家都可以用
写个类库一样完成该功能，且打包发布、后期更新更简单。
4、 XML是趋势，是标准，以后数据交换都靠它
看看有多少人在关心XML的安全传输？？！！
5、 WS的SESSION问题：
我有一个需求，要做一个简单的统一认证服务器，想用WS，支持用户的单次登录，全网通行，找到了WS的SESSION，差点欣喜若狂 —— 但该SESSION必须要客户程序有SESSION一一对应，客户程序能做可以满足需求的SESSION，我要WS的SESSION的干吗？？？自找苦吃还是有病？
WS的SESSION到底能解决什么问题。
（至今未解决该问题，单作为一个问题，标注为问题7，请大家帮忙）
6、 速度
狗屁，加大了传输量，多一层WEB交互，只会降低速度。
7、 安全
我不说了，你自己说XML传输是否安全
8、 容易找到成就感
这正是软件开发中将任务技术化的一个误区。
9、 体现概念
现在概念不值钱，决定能否赚钱是市场能力、品牌知名度、再加上产品的品质，品质中不包括概念，只包括易用的UI、功能和性能。
10、我试试还不行吗
你试试吧。
以上观点除标注为问题8，请大家评论。
五、给我个使用WS的理由
综上所述，我觉得在一个真正的软件产品中，使用WS的唯一理由是：
为实现“可多服务器部署的多层结构”提供了一种新手段。
而这种应用在我们的实际需求中并不多。可多服务器部署的多层应用，在每一层上必然都有自己的考虑，出于功能考虑，或者出于性能考虑。
以下是我绞尽脑汁想出的一些可能应用，未作必要性可行性分析：
1、 写一个WS，完成一组服务器负载均衡的处理
2、 写一个WS，针对某特殊应用，作为数据为服务器的前端高速缓冲
3、 写一个WS，处理某跨网段应用的协作。
4、 写一个WS，实现某特定应用的性能能够线性扩展（加一台服务器，性能线性提高。而集群的作用不能线性提高性能）
5、 作为一个问题，标注为问题9，请大家提提可能的新的应用。
六、最后一句话：
请大家回答问题1-问题9，指出我的错误，说些WS的有实用价值的优点，说服我，拯救我于水深火热之中。
我的邮件：lichunlei@clever.com.cn
