注：Atlas中的Mashup极其复杂，其中涉及众多的对象与架构，为了写这篇文章，我花了不少时间学习研究。同时，关于这方面资源的匮乏简直到了令人发指的地步。往往Google一下居然一条记录都没有……但Mashup在现今的AJAX程序中又是如此重要，近一段时间内，我也收到了好多朋友的消息，希望我能介绍一下Mashup的心得，这里我就斗胆献丑了。但目前为止，我对Atlas中的Mashup也只是粗通皮毛，所以这个系列中将仅仅通过一些实例应用来顺便说出我的理解，其中一定有很多错误疏漏之处，还请各位不吝斧正！也欢迎大家探讨实际项目中遇到的问题。
对于传统的Web程序，浏览器只与一台服务器进行通信，并从这台服务器上得到所有信息。同时出于安全考虑，页面上的JavaScript也只允许和同一台服务器通信。而随着目前Internet的发展，越来越多的Web Service分散在互联网的各处，作为开发人员的我们自然希望能够充分利用这些已经存在的Service，这时，我们就需要对远端的Web Service做以Mashup。这是一项常见的需求，也是一项重复性很高的劳动，幸运的是，ASP.NET Atlas充分认识到了这一点，并对此有着强大的内建支持。
Atlas通过引入一种新的HTTP模块——asbx文件（其中b代表Bridge），来实现对远端Web Service请求的Mashup。asbx文件其实是一个结构化的XML文档，里面包含了对远端Web Service方法的封装，当然，您也可以同时指定一个CodeBehind CS文件用来对其进行一些复杂的控制。asbx文件和aspx文件位于同一台主机上。Atlas网站在编译的时候会根据asbx中的声明以及相应的CodeBehind文件（如果存在）将其编译并注册。这样当客户端JavaScript调用该asbx中定义的方法时，asbx会将其转发给实际的Web Service并将返回结果会送给客户端，起到一个Bridge的作用。而对于客户端，就和直接调用 同一主机上的Web Service没什么不一样。
如果您安装过Atlas的msi文件，并建立了一个Atlas Web Site，那么下面的配置已经为您做好了。否则，启用asbx的支持，您需要如下的操作：
- 在IIS的虚拟目录下按照下图所示，添加.asbx文件的映射。
- 在web.config的sectionGroup段添加：
<section name="webServices" type="Microsoft.Web.Configuration.WebServicesSection" />- 在web.config的compilation段添加：
<buildProviders> <add extension=".asbx" type="Microsoft.Web.Services.BridgeBuildProvider"/></buildProviders>- 在web.config的httphandlers段添加：
<add verb="*" path="*.asbx" type="Microsoft.Web.Services.ScriptHandlerFactory" validate="false"/>- 在web.config的httpmodules段添加：
<add name="BridgeModule" type="Microsoft.Web.Services.BridgeModule"/>下面让我们通过一个最简单的示例学习Atlas中Mashup的基本概念和asbx文件的基本结构。
首先，编写一个Web Service用来模拟在Internet上存在的一个服务。当然，这个服务没什么实际用处，仅仅是求两个integer的和：
using System;using System.Web;using System.Web.Services;using System.Web.Services.Protocols;[WebService(Namespace = "http://www.dflying.net/")][WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]public class SimpleWebService : System.Web.Services.WebService
{
[WebMethod] public int Add(int value1, int value2)
{ return value1 + value2;
}
}我将这个Web Service置于另外一台主机的IIS上，注意：我们应该更改web.config文件以允许通过HTTP GET对Web Service的访问，而不仅仅是默认的POST：
<webServices> <protocols> <add name="HttpGet"/> </protocols ></webServices>
下面就是最有“技术含量”的asbx文件了：
<?xml version="1.0" encoding="utf-8" ?><bridge namespace="Test" className="SimpleWebService"> <proxy type="Microsoft.Web.Services.BridgeRestProxy" serviceUrl="http://dflyingchen/MyServices/SimpleWebService.asmx/Add" /> <method name="Add"> <input> <parameter name="value1" /> <parameter name="value2" /> </input> </method></bridge>注意到作为一个合法的XML文件，asbx文件第一行是XML的声明。然后，对于本asbx文件，有如下部分：
- bridge段，声明该mashup的namespace和class name。注意这两个属性代表的是客户端调用时所见的被mashup过的namespace和class name，并不是远端Web Service的namespace和class name。
- proxy段，声明该mashup的类型，这里我们指定为Microsoft.Web.Services.BridgeRestProxy，相应的，指定一个代表服务URL的string：http://dflyingchen/MyServices/SimpleWebService.asmx/Add 。
- method段，您可以添加多个method段，每一个代表一个定义在上述URL中的服务。这里我们指定了Method的名称，同样的，它代表的仅是客户端调用的名称（这样客户端将以namespace.classname.methodname()的方式调用该mashup）。
- input段，其中通过parameter标记声明了该方法的参数。parameter标记中的name属性代表参数名，注意这里声明的参数名要和远端Web Method的参数名保持一致。这里我们声明了两个参数，与上面定义的Web Method的两个参数对应。
到此为止，一个最简单的asbx文件就完成了。当然，上述介绍与完备相距甚远。关于asbx文件中的其它可选声明，目前并没有官方文档，我只能在接下来的几个例子中根据使用情况适当介绍。
我们再来建立一个Atlas Page测试一下该mashup，首先添加一个ScriptManager，并添加对上述mashup的引用，注意扩展名为asbx，不要写习惯了就直接写成了asmx：
<atlas:ScriptManager ID="sm" runat="server"> <Services> <atlas:ServiceReference Path="SimpleBridge.asbx" /> </Services></atlas:ScriptManager>然后添加一段HTML，用来提供用户输入，引发调用并显示结果；
<input id="input1" type="text" value="1" size="3" /><input id="input2" type="text" value="2" size="3" /><input id="doAdd" type="button" value="Add" onclick="return doAdd_onclick()" /><div id="result" />function doAdd_onclick() { var int1 = $('input1').value; var int2 = $('input2').value; Test.SimpleWebService.Add({'value1': int1,'value2': int2}, onAddComplete);}function onAddComplete(result) { $('result').innerHTML = "Result is: " + result;}浏览器中如下：
示例程序源代码可以在此下载：http://files.cnblogs.com/dflying/SimpleBridgeDemo.rar
在接下来的几个实例中，我将对一些“真实有用”的Web Service进行mashup并应用到我们的程序中。
