级别： 初级 柴晓路 (fennivel@uddi-china.org)Chief System Architect
2001 年 12 月 01 日 本文对Web服务的工作模式、Web服务所必须面对的问题以及他们是如何克服这些问题进行了探讨，所有的细节都围绕着Web服务技术是否可信任展开。在了解了Web服务的发展现状之后，我们基本上可以认为，Web服务看上去应该能不断地"固执地"坚持发展下去，随着它们的不断发展和存在，他们将变得越来越适应我们的商务应用。当前，Web服务被限制于非事务型的数据处理和数据交换，那是因为目前我们有能力应用Web服务的模式来解决这一领域的问题，然而我们坚信，我们将会看到越来越多激动人心的Web服务。
随着围绕Web服务的讨论愈演愈烈，人们对Web服务的问题也越来越多。在这个Internet的时代，在Internet上一些技术讨论的站点和一些通过Internet为媒介进行传播的文章中，对于Web服务的许多方面还存在着很多的疑问。
- Web服务可以为我们做什么？
-
Web服务真的能够在Microsoft和SUN的不同解决方案中建立连接的桥梁？
-
无论是公司内部还是公司之间，Web服务能为我们的集成项目节省多少开支？
这里还有很多其他的问题，其中有一个关键问题是：
"我们是否真的能信任被交付中的Web服务？"
迄今为止，对于这个问题主要有两种类型的答案，"激进分子"阵营给出的答案和"怀疑分子"阵营给出的答案。前一个阵营试图掩盖Web服务的局限性，而后一个阵营除了说Web服务在18到24个月以后才将会变得成熟之外就什么也不做，让一切就如其自然发展而发展。
在这篇文章中，我希望能够一个相对中间的角度用一个相对均衡的态度来论述这个问题。
为了能回答这个非常关键的问题，我们首先需要了解我们的问题到底意味着什么？
"我们是否真的能信任被交付中的Web服务?"
当我们整理一下思路，我们可以看到实际上我们面对着两个问题，而且两者有紧密的联系。第一个是"Web服务是否将会被交付使用？"和另外一个"我们能否信任Web服务？"。像很多问题一样，回答这些混杂的问题需要做一些研究，所以让我们先从Web服务是否会被交付使用开始。
"Web服务是否将会被交付使用?"
这一点应当务须多虑，Web服务将会交付，实际上Web服务已经正在被交付到开发人员的手上，这一点无论从Microsoft的Visual
Studio .NET，还是IBM的Web Service Technology或是SUN的SUN
One都说明了这一点。尽管我们需要清楚的知道什么是正在被交付中的，然而和其他新的技术一样，为了评估它可能的成功，我们需要看看它能如何帮助我们以及它是如何工作的。那么，什么是Web服务?
在我的前一个关于Web服务的技术文章系列"架构Web服务"中，已经从技术的角度概览地介绍了"什么是Web服务"。
基本上来说，Web服务通过从一个应用程序发送消息给另外一个应用程序来实施基本的处理。这些消息使用SOAP(简单对象访问协议)和XML来格式化，在这些消息中将包含简单的处理信息，如程序运行的任何参数等等。一旦被调用的应用程序受到请求消息并实施运行，那么它将会使用另一个SOAP消息来返回结果信息。调用程序将会解码这个消息，以获得调用结果。这个过程有点像提问回答的过程，一个人提出问题，然后另一个人将结果告诉提问者。
当然，在具体使用Web服务的时候，还有一些其他的方面的步骤需要考虑，如同你在计算机中使用一个新的软件一样，并非只要考虑如何操作软件，也要考虑下载、安装、备份等等其他环节一样，使用Web服务同样要有一些相应的步骤：
-
首先你要寻找你需要的应用程序(Web服务)。现在一般使用诸如e-marketplace之类的中介平台来寻找。但是将来这个过程将通过UDDI（统一描述、发现和集成）注册中心来实现，UDDI就像一个Web服务提供者的目录列表或服务黄页(类似电话黄页)。
-
下一步你要阅读指南来知道如何使用这个Web服务。因为在Web服务领域，并没有一个友好的用户界面来为用户服务，Web服务是面向程序的不是面向人的。此时，当要使用Web服务时，就必须通过阅读和理解Web服务的WSDL（Web服务描述语言）文档可以做到这一步，该文档中包含了如请求格式、参数范围、和方法名称等调用Web服务需要的信息以及预期的服务返回信息。
-
最后，你可以在你的应用程序中去调用这个被发现的应用程序(Web服务)，在程序中调用Web服务和在程序中调用你自己的应用程序代码的方法是基本相同的，这一相同性是由Web服务开发环境(比如IBM的Web
Service Application Developer或是Microsoft Visual Studio
.NET)来保证的。
因此，我们能够把现存的应用程序发布为Web服务，或者，也许会更好，对于应用程序以明确作为Web服务运行的目的来设计和生成服务的接口函数。在先前的状况下，我们需要使用一个软件包以从调用SOAP消息中解码出调用信息，同时把输出信息转换成响应SOAP消息。而在以后，随着开发工具的集成度的不断提高，我们就能够直接使用开发工具中的函数调用来处理消息，对于开发人员来说，SOAP消息也许对他而言将是透明的。
对于你的Web服务的使用者(用户)而言，他们仅能够看到你发布的Web服务的使用界面，他们对你的Web服务的知识将被限制于用于提供接口描述的WSDL文件的内容。除非你的Web服务的实现中出了一些纰漏或者是暴露了你的Web服务的异常错误，一般你不需要担心你会暴露你的Web服务的内部系统的操作。然而，Web服务的客户端是从那里来的以及与这个客户端进行消息交互的安全性则是另外一个问题，我们不久就会讨论这个问题。
考察Web服务是如何工作的同时，我们必须确定Web服务的一些基本限制�D�DWeb服务是通过消息来调用的，消息需要花费一定的时间从发送者传输到接受者。因此，Web服务对于那些仅需要依靠通信交互来实施任务请求的场合非常合适，而并不适用于那些依赖于快速响应的应用场合。你不能够Web服务来驾驶一辆高速行驶的汽车(路上的情况千变万化，需要实时作出响应)，但你也许可以用它来向太空发射火箭(按下按钮，火箭就发射了)。
"我们能否信任Web服务?"
在讨论了这么多关于实际的Web服务本身的话题之后，那么使用Web服务所需要遵循的步骤又是怎样的呢？就如我们先前所说的，我们第一需要找到我们需要的Web服务，然后获得如何使用这个Web服务的技术信息(通过WSDL文档)。如果此时，信任成为一个必须要解决的特别重要的问题的时候，这个过程可能是非常棘手的。
一般的，我能找到一家公司，这家公司提供某个Web服务形式的在线服务，这个在线服务能够处理我的银行帐号。我能够知道如何来调用这个服务，因为可以获得调用的技术信息。然而，我不能从UDDI注册中心和WSDL文件中得出我接触的公司或人究竟是谁。我得到的一切仅是技术描述和联系细节，Web服务本身并没有告诉我更多的。
另外一边的情况也一样，公司决定把它们的一些内部应用以Web服务的形式发布。他们在UDDI注册中心中自身的Web服务建立了必要的注册信息，构筑了WSDL文档来描述他们的Web服务是如何工作的，然后等待潜在的用户的接入。但是潜在的用户中谁是公司可以信任的？比方说，如何来防止一个国际贩毒组织通过使用一个合法银行的Web服务来洗钱？如果我开发了一个小程序，提供了一些许多人将会需要的处理服务，其他人需要提供什么来使用我的Web服务？我想让他们使用吗？我可以知道谁在使用它吗？我想发布一个Web服务，提供了一些在线事务处理，在我所居住的地区是合法的，但在其他国家可能不合法，我如何知道谁在使用它，并且我如何能够相信他们在他们居住的地区没有违反法律呢？
信任和安全问题在消费者心中是紧紧联系在一起的，让我们看看一个在线银行的例子吧。比方说，我可以相信HSBC能够以一个安全和可靠的方式来管理我的在线银行业务，因为他们有各大银行间的大规模的物理网络，并且自从1865年以来他们就一直在金融市场中生存着。另外一方面，我可能不会将我的经常使用的银行帐户或者储蓄帐户委托给"Escobar
and Noriega Online
Accounts"，这是一家新建立的，并且没有任何明显的合法业务联系的业务机构。这里，我们期望描述的观点是：当Web服务开始在电子商务应用中立足的时候，获得认证的(这通常是一个昂贵的的过程)服务可能会被限制在那些现存的，并且之间的关系已经足以满足信任这个条件的公司之间。而把那些没有经过认证的(廉价的)Web服务留在临时或未知发布者的领域中。
两个公司之间如何建立一个信任的关系以共享Web服务？他们必须在不同类型的关联关系上达成一致，并且对于一个Web服务的连接，他们当然也必须就Web服务的连接达成一致。UDDI、WSDL和SOAP并不会描述这个商务上的一致化。因此，尽管仅仅是通过一个UDDI注册中心就可能找到一个合适的Web服务，但立即使用它的机会是非常小的。我们回到刚才所说的那点，在一开始，经过认证的Web服务将会在现存的商务联系中被使用。
安全: 在Web服务中建立信任机制
所以，我们需要在我们的Web服务提供者或Web服务的用户之间建立一个信任联系。但他们不是我们需要信任的唯一的对象团体。我们也需要大量的其他的人，其他的公司，其中大多数是我们从来没有见过的或了解的，获得我们的"信任"，或信任我们。简而言之，我们需要能够信任任何对于我们用来发送SOAP消息的通讯网络是可靠的人以及其他任何使用同一网络的人。这就是需要安全性的地方。我们必须考虑如何防止恶意的或者未授权的使用，如何提供可见性和监视机能，以及如何随着合作伙伴而调整安全方针。起码，在目前，只有少数的一些解决方案。
XKMS（XML Key Management Specification），该方案现在正在被World
Wide
Web联盟(W3C)考虑，用于探讨并试图提供一些基于键的安全性机制。XML签名(XML
Signature)，在W3C中也处于一个类似的位置，XML
Signature则是打算提供一个方法以在XML中建立一个安全签名的表示机制，一个安全签名用于表示一个指定的公司。SAML(Security
Assertion Markup
Language)则是另一个已存的基于XML的安全标准，用来交换认证和授权信息。
如果你不想在应用中去实现这么多的安全标准(大多数还不成熟，还不能称为标准)，另一个选择是，你能够去依靠专门的Web服务网络，由它们来提供你安全性。Grand
Central提供了一个Web服务网络的承诺，在这个Web服务网络中，包含了前面提到的关于Web服务安全性的三个方面的特性。Flamenco
Network也有一个Web安全网络，允许你保护你用于和合作伙伴交互的Web服务。无论是使用基于XML的安全方法或者利用Web服务网络的安全特性，你还是需要和你在Web服务世界的潜在业务伙伴使用同一种语言，Web服务网络也许会成为这样的媒介角色。如果使用这样的方式，那么你必须期望你的接入伙伴也是使用这样的方式来实施安全性，否则它的应用是非常有限的。
对于安全问题，一个第三方的解决方案是使用微软的Passport.NET。Passport.NET是作为My
Service.NET的早期版本HailStorm的一个组成部分存在的，它支持Kerberos
5.0标准。它使用了一个非标准的方法，通过在返回的证书中嵌入用户名来实施安全性的承诺。Passport.NET使用微软自己的统一数字验证文档，这个服务仅仅提供了用户信任状的验证，如果你想使用不同的验证级别来支持不同的用户，你将不得不寻找其他的解决方案。
最新出现的是The Liberty项目(
http://www.projectliberty.org/)，是一个由Sun、NTT
DoCoMo、Nokia和Apache Software
Foundation组成的联盟。这个好像是对Passport.NET和My
Services.NET的一个直接竞争，并且是基于公开的标准的，同时由许多公司参与的一个计划。
为什么使用Web服务
在了解了Web服务是如何工作的之后，我们得以使用这一信息来提供一个由消费者角度来观察的Web服务的功能列表：
- 无缝的嵌入函数；
- 从其他分布式的应用程序中消除功能函数的副本；
-
为用户团体和特定领域集中提供功能函数，以获得在竞争和开支上的优势；
- 完成对我们需要的但无法实现的功能函数或者服务的访问；
- 放宽我们对功能函数发布者的选择；
- 兼顾了对外包的功能函数开发的需要。
这些观点中的一部分也许不能马上从Web服务是如果工作的描述中推导出来，因此在这里，在讨论Web服务的缺点前，我们将做一些解释：
功能函数的无缝嵌入是指通过Web服务，我们能够穿越Internet/intranet将功能或信息拖入到我们本地的程序中而不需要知道数据或函数是从哪里来的。举个例子，在银行的应用中我们需要处理一个电子数据表格，在其中的几个单元格中为外币汇率。这些汇率每10分钟更新一次，对于用户而言，他们不知道也不需要知道这几个汇率是通过路透社的Web服务得来的。
而其他的观点，则都是从一个基本的事实得出的：Web服务可以用来提供非常特殊的功能函数。在考虑一个公司的IT设备基础结构的场合中，在线服务能够被放置在一个中央的位置并且被全国各地的办公室来使用。这意味着一个软件包只需要为公司开发并部署一次，也许这个开方的最终承担者是从可供选择的很多外来承包者中挑选出来的，这样就节省了开发的时间和金钱。这也减少了支持和管理该软件的支出，因为它只运行在一个地点。
在考虑Web服务的技术性能的同时，从商务的角度来看，这也有一些要使用Web服务的原因：
-
成本：通过基于公开的技术标准的实施，我们能够明确的保护我们在Web服务方面的软件的投资。这意味着转变为节省了巨额的开销，这对于现存的应用程序还是未来的项目都是等同的。
-
强大的来自技术提供者的支持：Web服务，绝对是第一次这样的情形，以前从来没有一个技术是所有技术提供者同时这样热心地认同的。
-
和其他电子商务协议的集成：随着ebXML和RosettaNet标准被接受和使用，不久以后Web服务可以能够用其他协议来实施电子商务。
-
使用方便：随着Web服务领域的多样化的工具不断出现，商业实体可以在一个商务处理中集成几个不同的Web服务。
-
开发者的生产力：既然它是基于公开的标准的以及完善的开发工具的，今天的开发者开发和使用Web服务将会更便捷。
Web服务的局限性
如同我在这篇文章开头所陈述的那样，我们打算对Web服务提供一个平衡的评论性看法。基于这样的考虑，让我们来检视一下Web服务现在所面对的主要的局限性:
- 内部功能实现的限制
- 匹配合适的Web服务
- 通用的实现 vs. 定制的实现
- 服务发布的粒度
- Web服务持续支持的保证
如果开发者能够开发出必要的代码，那么Web服务将会成为商业上的一个可行的选择。这也许意味着对于开发者、设计者和部署者的高要求。由于目前，Web服务是一门新技术，开发人员、设计人员、部署人员都没有被完善地培训和培养，开发Web服务毕竟承担着高额的风险。同时，也许公司的Web服务需求太复杂了，无法用一般提供的服务解决。并且他们也不能找到能够提供需求定制的公司。如果公司在这样的情况下，Web服务也许不再是答案了。
而对于第2和第3个问题，"我们提供或匹配什么类型的Web服务�D�D一般的还是定制的？"，这个问题应该说并没有一个比较完善的答案。它依赖域你将发布和使用的Web服务的种类。一些服务是为了通用性的目的，如清算帐目服务，而其他的一些服务则可能面对更加细分的的市场。同样，如果你有一个服务程序，并且你想作为Web服务发布，你准备发布多少？你的新的应用程序准备多大程度上依赖于Web服务?
Web服务的粒度依赖于应用设计的程度。
另外一个可能是更严重的局限是：Web服务能否是连续的工作，它的可靠性如何保证。你如何保证你的Web服务将一直可用？什么程度的"停工"是可以接受的？一个响应要花费多长时间？一定程度上来说，这些问题可以被严格的服务管理模块来处理，以实时地核查Web服务的质量。也许会出现一些提供Web服务可靠性管理的中介服务，以通过Web服务连接的方式来测试Web服务的可靠性。
结论
我们在了解了基于XML网络的Web服务的工作模式之后，在了解了一些Web服务所必须面对的问题以及他们是如何克服这些问题之后，我们基本上可以认为，
Web服务看上去应该能不断地"固执地"坚持发展下去，随着它们的不断发展和存在，他们将变得越来越适应我们的商务应用。当前，Web服务被限制于非事务型的数据处理和数据交换，那是因为目前我们有能力应用Web服务的模式来解决这一领域的问题，然而我们坚信，我们将会看到越来越多激动人心的Web服务。
参考资料
- Web Service 技术/评论网站
- 解决B2B电子商务应用交互和集成的InterOP
Stack系列技术标准规范
-
UDDI执行白皮书, UDDI-China.org, UDDI.org
-
UDDI技术白皮书, UDDI-China.org, UDDI.org
-
UDDI程序员API规范, UDDI-China.org, UDDI.org
-
UDDI数据结构参考, UDDI-China.org, UDDI.org
-
Web Service Description Language (WSDL) 1.0, IBM, 25 Sep
2000
-
SOAP:
Simple Object Access Protocol Specification 1.1, IBM,
Microsoft, DevelopMentor, 2000
-
XML Schema Part 0:
Primer, W3C, 2 May 2001
-
Extensible Markup
Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000
关于作者  | 
| |
柴晓路: 系统架构师, Web Service技术顾问,
UDDI Advisory
Group成员, UDDI规范中文版编辑。专长于Web Service架构、Web
Service系列技术以及基于XML的系统集成和数据交换技术，同时对数据库、面向对象技术及CSCW等技术比较擅长。2001年加入
UDDI Advisory
Group，参与了UDDI Specification V2的开发。目前作为
UDDI-China.org的主要核心成员参与UDDI-China.org的核心技术工作。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML
Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。
|
对本文的评价
| 
