Web Services 架构和应用的介绍

另一种形式是从应用程序开发的时候就把它开发成Web Services，而不提供传统的组件调用接口，这种形式比较适合将来新开发的项目。而且Web Services实现的效率也比上面的方法要高，Microsoft的.Net就是这样做的，.Net平台全面支持Web Services，也可以说是将命运完全押宝在Web Services上面了。使用C#开发Web Services是异常的简单，将程序保存为扩展名apmx，然后发布到IIS上面，当第一次请求服务的时候，就会自动编译，发布和运行。

我们再进一步分析HTTP Post的数据内容。HTTP Post的数据，可能包含三种类型：
(1) 需要存档在服务器的数据
比如，用户注册时候，输入的基本信息，用户名、密码、电子邮件等。这些信息要存放到服务器的数据库。
对于这种基本信息，HTTP Post，XMLHttp，SOAP处理起来，难度都不大，没有很大区别。
B2B的数据交换，也属于这个类别。用何种技术区别不大。一般采用SOAP，因为SOAP是一种流行的标准协议。
(2) 服务调用参数
比如，用户进行复合条件查询的时候，输入的查询条件。这个时候，HTTP Post处理起来就非常蹩脚。而XMLHttp，SOAP则具有很大的优势。可以把复杂的查询条件很好组织成XML数据，发送到服务器端统一处理。SOAP里面甚至可以定义对象名、方法名等详细的调用信息。
(3) 指令
这种情况比较少见。上面的参数类别中提到的“对象名、方法名等详细的调用信息”，和这个指令类别有些交叉。
假如一个SOAP调用方法里面的参数也是一个自定义的对象，这个自定义对象的属性数据在SOAP信息中进行了定义。到了服务器端之后，服务端程序首先调用这个自定义参数的构造函数，生成这个参数对象，然后调用对应的服务对象，把这个参数传给服务。这个过程可以看作是一个顺序指令：[1]构造参数[2]调用服务。
这只是最简单的情况。而目前的Web Service一般也就支持到这个程度。
我的看法是，一不做，而不休。既然都把调用信息定义到这个程度了，不如做的更彻底一些，全面完善的支持指令。这个指令则意味着逻辑。前面讲过了，我不赞成用XML Tag表示逻辑，而赞成脚本。这里比较适合的脚本是JavaScript，因为JavaScript比较通用，客户端、服务器端都可以解释执行。注意，这里和一般的做法正好相反：一般的Web应用总是把JavaScript从服务器传到浏览器里面执行，而这里是把JavaScript在浏览器里组织好，发给服务器端处理；这个JavaScript将会在服务器端执行，调用服务器端的对象。举个SOAP含有JavaScript指令的例子 (只是示意，非标准格式) ：
<soap envelope>
<XML Data>
<a>
<b>12</b>
</a>
<c>
<d>21</d>
</c>
<e>
<e>16</e>
</e>
</XML Data>

<script>
final_result = default;
result1 = service1.service(a.b);
if(result1.ok){
result2 = service2.service(c.d);
if(result2.ok)
final_result = service3.service(e.f);
}
</script>
< /soap envelope >

这个好处是：
[1] 发布了更多的基本Service。给客户提供了更大的灵活度。
比如，这里就发布了3个Service。由用户自己组织逻辑。
按照传统的做法，上述流程将整个包装在服务器端执行。发布给用户的Service只有最外面的一个Service，而且高度耦合（if, else, if, else流程hard code在服务器端），不灵活，不通用。
这里的方法，就可以让客户端随意组织service1, service2, service3的调用顺序和方式。
[2] 减少了通信次数。
假如这段Script在客户端执行，那么和服务器要进行3次通信。

传统Web的权限控制一般在URL级别，这种script -> server方式的权限控制则要在对象级别、方法级别、Code片断级别了，复杂很多，也许要大量应用Java的Code权限认证机制。