在互联网发展的早期，企业都使用SMTP、NTTP和FTP客户端和服务器与互联网进行连接，传输消息、文本文件、可执行文件和源代码，当企业开始将企业信息集成到互联网架构中时，互联网就成了一种基本的工具。当互联网重心由交换信息的协议转向数据对象以及它们之间的链接时，互联网的普及程度就大大提高了。
早期Web架构的特征是HTML-GIF/JPEG、HTTP和URI，它们组合在一起时，其功能是异常强大的，使用这些技术，企业将多种多样的网上发布系统进行集成，使之成为比任何一种单一的技术更有吸引力的系统。

　　一旦各种机构都使用公共的数据格式、HTTP协议和一个单一的地址系统时，Web就不再是许多网站的集合了，而成为了最多样化和功能强大的信息系统，各机构团体建立起它们的信息和其他机构团体信息之间的链接。

　　第一代Web服务与第一代连接非常相似，各种Web服务之间并不是互相集成的，而且其设计目标也不是使第三方能够方便地以一种统一的方式对它们进行集成。我认为，新一代Web服务将是起源于网上出版和人机交互的更加集成化的Web服务，它将是建立在使Web更能发挥作用的架构的基础上的，该架构是三位一体的：标准的格式（XML）、标准的应用协议和单一的URI名字空间。

　　新一代的Web服务将与REST这种当前Web的架构模式息息相关，它的意思是“表示状态转移”。它说明了Web能够拥有URI、HTTP、HTML、JavaScript和其他许多特性的原因，它包含有多个方面的内容，我不敢说自己已经完全掌握了它，在本篇文章中，我们将着重讨论XML用户和开发人员最感兴趣的部分：

　　当前的Web服务

　　SOAP最初是作为DCOM或CORBA的跨互联网形式出现的，早期的与SOAP类似的一种技术的名称为“Web代理”━━基于Web的对象代理，它准确地表达了这种技术在DCOM、CORBA、RMI等标准上建立跨应用协议的含义，它也是解决应用之间互操作性问题的现有的模型。

　　在没有应用到Web上时，这些技术只取得了有限的成功。有分析家认为问题是微软和OMG的支持者不合作引起的，但我并不这样认为，其中有更深层次的问题。对于封闭世界问题而言，RPC确实不错。在封闭世界中，你知道所有的用户，可以与它们共享数据模型，可以根据自己的需求与它们进行沟通。在这样的环境中进行发展是相当容易的：你只需告诉所有的用户，RPC API将要在某个时间内发生变化，可能中间会有个过渡期，以避免出现问题。通过点到点的集成，就可以集成新的系统。

　　另一方面，当用户群非常庞大时，进行点对点的沟通就不可能了，我们就需要一个不同的策略。我们需要一个预先安排的框架，以在服务器端和客户端同时发生变化，还需要有一套明确的机制，与没有相同API的系统实现互操作。RPC协议在这方面有所欠缺，改变其中的界面异常困难，集成新的服务通常需要进行复杂的软件粘合。

　　我认为这是没有企业成功地将它们的系统统一在DCOM、CORBA或RMI上的真正原因。现在我们才触及到问题的症结所在：SOAP RPC是互联网的DCOM。

　　RPC中还存在许多能够解决的问题。但我认为其中最大也是最难解决的问题是需要有一个使客户端、服务器端和中间件端能够独立地进行升级的模型。

　　原型可升级应用

　　当今二种最具可伸缩性、最具有互操作性的分布式应用是Web和电子邮件，是什么使这二种应用具有如此大的可伸缩性和互操作性呢？它们依赖于标准化的、可扩展的消息格式（HTML和MIME）、应用协议（HTTP和SMTP），但我认为最重要的是每一种应用都有一个标准化的、可扩展的全球性地址系统。

　　在房地产界有一句笑话，形成房地产价值的三个要素是位置，位置和位置，在XML web服务中也是如此。如果实现得恰当，XML web服务使我们能够给数据对象指定地址，使它们能够被共享或修改。

　　特别地，WEB的中心概念是URI的单一的统一名字空间，URI能够允许使Web具有利用价值的大量的Web链接，它们将Web捆绑为一个单一的大规模的应用。

　　URI等同于资源。资源是一个概念性的对象，它们的表达被以HTTP消息的格式在web上发布。这些理念相当简单，但其功能却非常强大，而且取得了不俗的成功。URI之间的联系非常松散，我们甚至能够利用一张纸或OCR将一个URI从一个系统传递给另一个系统。URI是后期绑定的，它们不定义能够对所指的信息进行哪些处理。正是其具有的“松散”和“后期”特性，使得它们能够适用于Web这样规模的网络。

　　不幸的是，我们中的大多数都不这样考虑web服务，我们都将web服务看作是代表软件组件的端点间的远程过程调用，也就是CORBA、DCOM的思想，Web的思想是根据资源组织URI。

　　新一代web服务将使用单独的数据对象作为端点，软件组件间的界线也将是非常小的。

　　一个示范性的例子

　　UDDI是能够被作为以资源为中心的功能更强大的WEB服务的一个例子，在这里我们不讨论UDDI在WEB服务中哲学意义上的角色，只讨论如何从中获取信息或向其中输入信息的具体问题，这些观点适用于已经存在的大部分的WEB服务，例如股票行情、飞机票预订等。

　　UDDI中有一个代表一个企业的businessEntity概念，企业是由UUID确定的，在以Web为中心的模式中，企业是由URI确定的，最简单的方式是把businessEntity作为一个可以设定地址的XML文档，例如，http://www.uddi.org/businessEntity/ibm.com或http://www.uddi.org/getbusinessEntity?ibm.com。这二种方式之间的差别相当小，而且与技术的关系不大，因此我们无需为此担心。

　　我们可以把http://www.uddi.org/businessEntity看作是一个包含文件的目录，或者一个从数据库中读取数据的WEB服务。WEB最奇妙的特性之一就是仅仅通过URI，不能分辩出它到底是什么，这也是“松散组合”的作用。

　　我们来考虑使用基于HTTP的URI而不使用UUID表示企业实体的意义：

　　·想检查企业实体的人只能将浏览器指向该URI，并查看businessEntity记录，HTML版的企业实体只适用于以前的浏览器，而XML版的企业实体适用于较新的浏览器。

　　·要在另一种WEB服务或文档中引用一个businessEntity，则只能使用它的URI。

　　·要将被引用的信息集成在其他的XML文档中，可以使用XLink、XPointer或XInclude。

　　·要保存一个记录的永久拷贝需要使用wget这样的命令行工具或在浏览器中选择“保存为”菜单项。

　　·XSLT样式表能够动态地获取资源，并在转换中与其他资源进行组合。

　　·可以使用标准的HTTP授权和访问控制机制控制对businessEntity的访问。

　　·元数据可以通过使用RDF与businessEntity发生关联。

　　·任何客户端应用（无论是否是基于浏览器的）可以在没有特别的SOAP库的情况下获取数据。

　　·二个企业褓可以使用从一个企业实体到另一个企业实体的重定向表示二者的合并。

　　·象Excel、XMetaL、Word和Emacs这样的编辑和分析工具能够利用HTTP直接从URI中导入XML文档，并利用WebDAV进行回写。

　　·UUID或其他形式的与位置无关的地址仍然可以被指定为附加的抽象层。

　　目前的UDDI API有一个被称作get_businessDetail的方法，在以地址为中心的模式下，该方法就完全成为多余的了，可以从API中把它删除了。UDDI有几种对tModels、商业服务等数据对象进行操作的get_方法，这些数据对象可以被表示为逻辑XML文档，这些方法也可以被删除。需要注意的是，我们大大简化了用户对UDDI信息的访问，同时提高了XML和XML模式在UDDI系统中的重要性。

　　企业实体并不是UDDI中唯一的应该根据以URI编址的XML资源而不是SOAP API确定的东西，事实上，所有UDDI数据库中的数据都可以以这种方式确定。

　　总结：资源（数据对象）就象孩子，如果要融入到社会这个大家庭中去，他们每个人就需要有一个名字。

　　可扩展性

　　如果围绕URI组织WEB服务，该服务就可以通过链接自动地与其他WEB服务进行集成，一个注册表中的一个UDDI条目能够很方便地指向另一个注册表系统中的UDDI条目。事实上，企业可以在自己的站点上维护企业信息，在信息有变化时向UDDI“注册”这些变化即可。以资源为中心的web服务从本质上说是很容易进行集成的。

　　在一个UDDI注册表中的元素只可以在它们相互之间进行查阅（也有极少数