跨越防火墙的通信
如果你的应用E序有成千上万的用户Q而且他们都分布在世界各地Q那么客L和服务器之间的通信是一个棘手的问题。那是因为客L和服务器之间通常都会有防火墙或者代理服务器。在q种情况下，你想使用DCOM׃是那么简单了Q而且Q通常你也不愿意把你的客户端程序发布到如此庞大数量的每一个用h中。于是，你最l选择了用览器作为客LQ写下一堆ASP面Q把应用E序的中间层暴露l最l用戗结果呢Q运气好的话Q只是开发难度大了一些，q气不好的话Q就会得C个根本无法维护的应用E序?/p>
惌一下你应该怎么在你的应用程序里面加入一个新的页面：你必d建立好用L?Web面)Q以及在q个面后面Q包含相应商业逻辑的中间层lg。这q不够，你还要再建立臛_一个ASP面Q用来接受用戯入的信息Q调用中间层lgQ把l果格式化ؓHTML形式Q最后还要把"l果?送回览器。要是客L代码不再如此依赖于HTML表单Q客L的编E不q单多了吗Q还有，建立ASP面的那一步可以省略掉吗？
当然。如果你的中间层lg是Web service的话Q你完全可以从用L面直接调用中间层lgQ从而省掉徏立ASP面的那一步。要调用Web serviceQ你可以直接使用Microsoft SOAP Toolkit?NETq样的SOAP客户端，也可以用你自己开发的SOAP客户端，然后把它和你的应用程序连接v来。这样做Q不仅可以羃短开发周期，q可以减代码的复杂度，q增强整个应用程序的可维护性。同Ӟ你的应用E序也不再需要在每次调用中间层组件时Q都跌{到相应的"l果?了?
以我的经验来看，在一个用L面和中间层有较多交互的应用程序中Q用Web serviceq种l构Q可以轻杄节省花在用户界面~程上的20%的开发时间。这样做q有另一个好处，是你将得到一个由Web servicel成的中间层Q这一层是完全可以在应用程序集成或其他场合下被重用的。最后，通过Web service把你的应用程序的逻辑和数据暴露出来，q可以让其它q_上的客户重用你的应用E序?/p>
应用E序集成
企业U的应用E序开发者都知道Q企业里l常都要把用不同语言写成的在不同q_上运行的各种E序集成hQ而这U集成将p很大的开发的力量。你的应用程序经帔R需要从q行在古老的IBML上的E序中获取数据；或者再把数据发送到L或UNIX应用E序中去。即使是在同一个^CQ不同的软g厂商生的各UY件也常常需要集成v来。通过Web serviceQ应用程序可以用标准的方法把功能和数据暴露出来，供其它的应用E序使用?/p>
例如Q你有一个订单登录程序，用于d从客h的新订单Q包括客户信息、发货地址、数量、h格和付款方式{信息。同Ӟ你还有一个订单执行程序，用于实际货物发送的理。这两个E序是来自不同Y件厂商的。一份新订单q来之后Q订单登录程序需要通知订单执行E序发送货物。通过在订单执行程序上面增加一层Web serviceQ订单执行程序可以把"AddOrder"函数暴露出来。这P每当有新订单到来Ӟ订单dE序可以调用这个函数来发送货物了。进而通过Web service集成应用E序
B2B的集?/p>
用Web service集成应用E序Q可以你公司内部的商务处理更加自动化。但当交易跨了你的供应商和客户Q突破了公司的界U时又会怎么样呢Q跨公司的商务交易集成通常叫做B2B集成?/p>
Web service是B2B集成成功的关键。通过Web serviceQ你的公司可以把关键的商务应用暴露给指定的供应商和客戗例如，把你的电子下单系l和电子发票pȝ暴露出来Q你的客户就可以以电子的方式向你发送购货订单，而你的供应商则可以以电子的方式把原料采购的发发送给你。当Ӟqƈ不是一个新的概念：电子文档交换(EDI)早就是这样了。Web service和EDI之间的主要区别在于，Web service的实现要比EDI单得多，而且Web service是运行在Internet上的Q在世界M地方都可L实现Q这样其q行成本q对较低。不q，Web serviceq不像EDI那样Q是文交换或B2B集成的一套完整的解决Ҏ。Web service只是B2B集成的一个关键部分，q需要许多其它的部分才能完成q个集成?/p>
用Web service来实现B2B集成的最大好处在于可以轻易实C操作性。只要把你的商务逻辑暴露出来Q成为Web serviceQ你可以让M指定的合作伙伴轻杄调用你的商务逻辑Q而不他们的pȝ在什么^Cq行Q用的是什么开发语a。这样就大大减少了花在B2B集成的上的时间和成本。这L低成本让许多原本无法承受EDI的投资成本的中小企业也能实现B2B集成?/p>
软g重用
软g重用是一个很大的主题Q它有很多的形式和程度。最基本的Ş式是源代码模块或者类一U的重用。另一UŞ式是二进制Ş式的lg重用。当前，像表格控件或用户界面控gq样的可重用软glg在市Z都占有很大的份额。但q类软g的重用都有一个很严重的限Ӟ重用仅限于代码，而数据不能被重用。原因在于你可以很轻易的发布lg甚至源代码，但要发布数据没那么Ҏ了，除非那些数据都是不会l常变化的静态数据?
而Web service允许你在重用代码的同Ӟ重用代码后面的数据。用Web serviceQ你不再像以前那P要先从第三方购买、安装Y件组Ӟ再从你的应用E序中调用这些组件。你只需要直接调用远端的Web service可以了。D个例子，你想在你的应用程序中认用户输入的邮件地址Q那么，你只需把这个地址直接发送给相应的Web serviceQ这个Web service ׃帮你查阅街道地址、城市、省区和邮政~码{信息，认q个地址的确在相应的邮政~码区域。Web service 的提供商可以按时间或使用ơ数来对q项服务q行收费。这L服务要通过lg重用来实现是不现实的Q因为那L话你必须下蝲q安装好包含街道地址、城市、省区和邮政~码{信息的数据库，而且q个数据库还是不能实时更新的?/p>
另一UY仉用的情况是把好几个应用程序的功能集成h。例如，你想要徏立一个局域网上的门户站点应用Q让用户既可以查询他们的联邦快递包裹，察看股市行情Q又可以理他们的日E安排，q可以在U购买电q。现在Web上有很多应用E序供应商，都在其应用中实现了上面的q些功能。一旦他们把q些功能都通过Web service 暴露出来Q你可以非常轻易地把所有这些功能都集成C的门L点中Qؓ用户提供一个统一的、友好的界面?br>用Web service来集成各U应用中的功能，为用h供一个统一的界?br>许多应用E序都会利用Web serviceQ把当前Zlg的应用程序结构扩展ؓlg和Web service 的合结构。你也可以在应用E序中用第三方的Web service 提供的功能。你q可以把你自q应用E序的功能通过Web service 提供l别人。所有这些情况下Q你都可以重用代码和代码后面的数据。MQWeb service 是软g重用的一U非常有力的形式?/p>
什么时候不应该使用Web Service
一个对Web service的完整介l还应该包括什么时候不该用Web service。经q前面的介绍Q我们知道了Web service 在通过Webq行互操作或q程调用的时候是最有用的。不q，q有许多情况QWeb serviceҎ不能l你带来M好处?/p>
单机应用E序
目前Q我们还有很多桌面应用程序是供商用和个h使用的。其中一些只需要与q行在本Z的其他程序通信。在q种情况下，我们最好就不要再用Web service Q只要用本地的API可以了。COM非常适合于在q种情况下工作，因ؓ它既又快。运行在一台服务器上的服务器Y件也是这P最好直接用COM或其他本地的API来进行应用程序间的调用。当然Web service 也能用在q些情况下，但那样不仅消耗太大，而且不会l你带来M好处?/p>
局域网上的同构应用E序
在许多应用中Q你所有的E序都是用VB或VC开发的Q都在Windowsq_下用COMQ都q行在同一个局域网上。例如，你有两个服务器应用程序需要相互通信Q或者你有一个Win32或WinForm的客L序要q接到局域网上的另一个服务器E序。在q些E序里用DCOM会比SOAP/HTTP有效的多。类似的Q如果你的一?NETE序要连接到LAN上的另一?NETE序Q那么你应该使用.NET remoting。有的是，?NET remoting中，你也可以指定使用SOAP/HTTP来进行Web service 调用。不q最好还是直接通过TCPq行RPC调用Q那样会有效得多。MQ只要你从应用程序结构的角度看来Q有别的Ҏ比Web service 更有效，更可行，那就不要再用Web service?/p>
ȝ
Web service是创建可互操作的分布式应用程序的新^台。Web service 的主要目标是跨^台的可互操作性。ؓ了达到这一目标QWeb service 是完全基于XML、XSD{独立于q_、独立于软g供应商的标准的?
Web service在应用程序跨q_和跨|络q行通信的时候是非常有用的。Web service适用于应用程序集成、B2B集成、代码和数据重用Q以及通过Webq行客户端和服务器的通信的场合?
当然QWeb service也不是万能的Q你不能到处滥用Web service。在有些情况下，Web service 会降低应用程序的性能Q而不会带来Q何好处。例如，一台机器或一个局域网里面q行的同构应用程序就不应该用Web service q行通信?/p>
]]>