第二代Web服务展望 [转]
2024-07-21 02:25:26
供稿：网友
在互联网发展的早期，企业都使用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注册表中的元素只可以在它们相互之间进行查阅（也有极少数的例外），它们不能查阅到在web上其他地方的对象（例如其他uddi注册表中的元素）。以uri为中心的解决方案则以与电话号码系统组织电话那样的方式对数据域进行统一的组织。
由于businessentity文档都是xml文档，因此能够相对比较方便地添加元素、属性或其他名字空间。xml是一种可扩展的数据表达方式，通过添加特定的http头部甚至新的http方法（在极少数的情况下）很方便地扩展该协议。
性能
web服务的性能是一个十分重要的问题，任何从基于get的uri中获取的资源都会被牵涉到，在服务器之前的缓冲服务器、企业防火墙或客户端计算机都存在性能问题。缓冲是内置在http中的，soap get_businessdetail信息不能被现有的技术进行缓冲，对rest架构还可以进行其他方面的性能强化。
其他方法
uddi中还有其他与businessentities有关的方法，其中的一个是delete_business。http已经有了delete方法，因此delete_business在rest模式中已经是多余的了，我们可以不使用uddi soap-rpc的删除方法，而使用http中的删除方法，这样有利于与“知道”http中删除方法的windows 2000中的资源管理器等工具兼容。从理论上说，企业可以通过点击“删除”按钮删除一部分的记录。
很明显的是，授权和访问控制是关健。微软不可能抹杀它的竞争对手在这方面的进步。htttp中已经有了授权、认证和加密的特性，uddi的soap rpc协议不支持这些特性。
uddi中还有一个save_business方法，这是为了上载新的业务，在http中与之相对应的是put或post。使用http方法而不使用soap方法的一个好处是可以在html表格中执行post方法。
uddi中还包括有一个名字为find_business的方法，该方法在原理上与每个网站上的搜索功能或特定的搜索引擎并没有什么区别。在uri模式中，服务能够获取一系列的搜索参数，返回代表与搜索参数匹配的businessentities。
使用get、put、delete、post这四个基本的方法，我们可以做到使用几十个uddi方法才能实现的功能。rest于web服务的关系就象risc技术与cpu的关系，但二者之间的关系还是有相当大的区别的，其代价和带来的好处是不同的。
http的角色
我们通过web服务得到的好处利用http也可以得到，我们需要的仅仅是xml符号集，这也是xml的意义所在：更注重数据的交换而不是软件组件。
uddi中的所有东西都可以用http对xml资源的操作表示，因此，http与uri成为web中最核心的技术之一并不是偶然的，它的设计目标是作为以特性为中心的rest架构的主要部分。
下面是一个很激进的观点：无论什么样的问题，我们都可以，也应该将它作为一个数据资源处理问题而不是一个api设计问题来考虑，将web服务器考虑为一个巨大的信息仓库，我们在其中进行数据处理工作。
在讨论uddi时，我选择了一个能够被很简单地转换为rest架构的web服务，但我们可以将这一原理应用在所有的web服务中。那么在订单提交中如何呢？这更象是事务，订单也需要被命名。如果我们使用post或put将订单提交给新的uri，然后整个公司的内部系统都可以查阅该订单，而无论系统是在什么地方。使用http，北京分公司雇员使用的台式机上的xslt样式表和perl脚本代码能够处理在位于洛杉矶的大型主机上运行的财务系统上的订单。访问http编址的资源不比访问本地系统上的文件更困难。
即使是带有复杂的工作流的web服务也可以以uri为中心的方式进行组织。现在我们来看一个飞机票预订系统。在传统的html系统中，有各种不同的代表逻辑交易的网页存在。首先，我们需要捍拒合适的航班，得到一个表示许多合适航班的uri。然后从中选择一个航班，得到一个表示我们选择的uri。然后再决定是否提交订单，提交后会得到返回预订号的网页。一般情况下，该网页的uri会保留一段合理的时间，以便我们记下预订的号码。我们可以以这种方式来考虑所有的业务。
http甚至可以应用在p2p、异步、可靠的分布式计算中，如果读者对这些问题有兴趣，可以进一步地参阅其他的资料。
基于xml的web服务能够通过相同的步骤完成。不会在每个步骤中返回html表格，该web服务将返回符合航空业标准的xml文档，这些文档可以用在完全不同的飞机票预订系统中，运行完全相同的过程。
总结：任何商业问题都可以被看作是资源处理问题，http是一种数据资源处理协议。
安全
对数据进行全球统一的编址并不意味着让所有人都可以访问你的数据。我们可以通过不公布其uri而很方便地隐藏对象，也可以很方便地对对象使用安全策略。事实上，rest在很大程度上简化了安全问题。
在soap rpc模式中，我们使用的对象是不明显的，它们的名字也隐藏在方法的参数中，因此我们需要为每个web服务使用一种全新的安全策略。在rest模式中，我们可以对每个数据对象使用4种基本的权限：get权限、put权限、delete权限和post权限。我们可以使一部分资源具有或不具有get、put、delete和post四种权限，这与当前广泛使用的文件系统的权限有点类似，它是有效和成熟的。
以资源为中心的web服务可以很好地与防火墙进行合作。防火墙管理员能够很容易地通过阻止不使用get方法的http请求而使一种web服务只能被读取。
维护
事实上，安全只是可维护性的一种形式。所有网管都会说，任何规模的网络都会发生问题，有时ip没有问题但dns就会出问题（dns服务器关闭或dns配置不正确），有时ip和dns正常但http出了问题（防火墙或代理服务器配置不正确）。如果在http之上运行web服务，那系统出问题的可能性就是二者之和，可能会有多个部分出问题和安全漏洞。
一旦web服务能够正常地工作了，则可以通过在浏览器中使用服务对它进行测试，甚至是复杂的需要多个步骤才能完成的web服务都能够通过html表格进行测试。从本质上说，对rest web服务的测试与web网站差不多。另一方面，每个soap rpc服务都有自己的安全模式、地址模型、数据模型、状态转换表和方法集，对这样的系统进行测试要困难得多。
