Java Web服务,第1部份: Java Web服务在将来一年内的发展[Java编程]

2006 年将是 Web 服务（分外是 Java Web 服务）发展标志性的一年.新的第三代框架行将撩开面纱,这些框架将为 doc/lit SOAP 供应更好的支持,并能带来潜在的性能提高.同时,第四代 WS-* 尺度也终究开始形成一组可互操作的层,对 SOAP 和 WSDL 举行扩大,以支持核心企业需求.

这篇文章是我的 Java Web 系列的第 1 部份,我将谈论以下 Web 服务目前的状况和在 2006 年行将发生的主要改变,并将简单阐明新框架和技术若何相关和交互.后续文章将深化谈论此中的很多框架和技术,但愿能籍此让您理解在该范畴最新的发展,并关注其如作甚您的编程项目供应帮忙.

后台介绍

从 SOAP 1.0 标准公布到本日,已经六年多了.在 SOAP 标准公布之前,开辟人员早就在通过 Internet 协议交换 XML 消息了,但 SOAP 的推出答应对此技术举行标准化,并实现更好的互操作性.SOAP 还供应了各种挂钩 (hook) 机制,以便利扩大,从而可以增添高级底子构造功效,以加强将来的 XML 消息交换.WSDL 标准在 SOAP 推出后不久公布,增添了 Web 服务元数据的尺度表示办法.主要软件供应商很快看到了将 SOAP 和 WSDL 结合利用的潜力,在接下来的几年里,SOAP Web 服务仿佛成了不可拦阻的发展潮流.

SOAP 和 WSDL 挑衅

固然在整个行业中 SOAP+WSDL 快速兴起,但仍旧在很多方面存在问题,会阻碍 SOAP 到达很多人所盼望的完好成功.第一个方面就是互操作性.固然 SOAP 最诱人的一个重要方面就是它的互操作性答应,但实际进展却并不明显.这最初是由于对 rpc/encoded 款式的 Web 服务（也称为 rpc/enc）的夸大所造成的,在此情形下,对象模子将序列化为 XML 然后再在接纳端重新构造.此自动序列化/反序列化功效使得 rpc/enc 非常易用（只要利用其支持的相对简单的数据构造）,但却会招致生成无法用于任何目的的 XML.更糟糕的是,语言和平台支持的差别招致了实现之间大量的不兼容现象.

被遍及承受的 Web 服务最佳实践目前正偏向于利用 document/literal 款式 (doc/lit) 替换 rpc/enc 款式.在 doc/lit 中,XML 消息格局是由 W3C XML Schema 定义所定义的.就理论上来说,这该当能消除互操作性方面的任何问题,因为情势实例定义 XML 的实际构造,而每个平台负责恰本地处理该 XML.在实际中,对极其复杂的 W3C Schema 尺度的支持程度良莠不齐,且又带来别的一些互操作性问题.

较早的 rpc/enc 互操作性问题和近来的 doc/lit 互操作性问题城市因贫乏熟习而进一步加重.关于 doc/lit,各种框架支持差别的情势尺度子集,却没有列出贫乏的特点,从而使得这种情形尤为锋利.即便差别的框架声称支持特定的情势特点,实现也常常不完好,从而招致利用这些特点时呈现互操作性问题.转向 doc/lit 的部份缘由是但愿能操纵企业或行业尺度情势.此类尺度情势的计划普通没有考虑会在 Web 服务中利用,因此它们常常利用 SOAP 框架不能供应杰出支持的特点.

SOAP Web 服务的另一个问题是底子构造扩大和基本 SOAP 处理——增添的可在一系列 Web 服务上利用的处理层——之间不断的混合不清.SOAP 的计划运行便利地增添此类扩大,但这些扩大普通仅在其为受多个框架支持的尺度时才有效.这要求整个行业举行合作,但普通很难办到.即便最底子的扩大（如附件和安全性）,也需求若干年举行开辟,但仍旧不受全部框架支持.

SOAP 的阻力

前一部份中具体谈论的互操作性和尺度化问题限制了 SOAP Web 服务的实用性,同时,SOAP 框架本身也普通很复杂,难于利用.上风有限以及潜在的复杂性让很多开辟人员转而采取比 SOAP 更简单的替换办法.SOAP 的大部份阻力都来自与一项称为 REST 的技术相关的方面.严峻来说,REST 是可利用到 Web 服务的 HTTP 协议的基本法则的标准化技术.在实际中,REST 活动常常将标准化放置在一边,而在此中包含全部在不利用 SOAP 包装的情形下在 HTTP 上传输 XML 文档的全部东西,基本上与呈现 SOAP 之前举行的直接 XML 文档方法一样.

REST 远不如 SOAP 雄心勃勃.REST 自然被限制为利用 HTTP 作为传输层（固然可以利用近似的办法举行其他传输）,而 SOAP 从理论上来说是独立于传输层的（固然到目前为止只遍及利用 HTTP 传输举行布置）.REST 并不包含任何直接增添底子构造扩大的办法——但在 SOAP 真正开始供应此类扩大前,此限制都可以被视为无足轻重的方面.

由于 REST 的功效答应并比不上 SOAP,因此普通不需求利用任何框架代码来实现客户机或服务器,因此开辟人员无需处理框架的复杂性.不太便利的一面是,此技术的确 需求直接实现 HTTP 和 XML 处理,不过很多开辟人员都已经习惯处理这些技术了.直接处理 XML 乃至可以算得上是一个上风,因为与 SOAP 框架供应的挑选相比,开辟人员在这种情形下的挑选空间更大.

那么,是不是应当丢掉 SOAP 而开始采取更简单的 REST 呢?对很多 Web 服务利用程序的表单而言,这大概都是一个很实际的挑选,因此我并不反对这样的设法.不过,有很多其他利用程序（分外在企业级）需求 SOAP 所答应的底子构造扩大和传输独立性.转向 REST 则意味着这些利用程序将需求直接实现安全、事件处理和合作等功效,而不是通过框架供应这些功效.大大都企业利用程序将大概挑选完好避免利用 Web 服务,而不去花这份心机.

但就像片子中一样,即便 SOAP 的前途看起来真的很暗淡,但仍旧会有新的但愿.这个但愿来自行将推出的新一代框架.这些框架的目标是终究发掘 SOAP 的全部潜能,使实现全新的 SOAP Web 服务利用程序变成实际,同时大幅度提高 doc/lit Web 服务的互操作性.

　　以上是“Java Web服务,第1部份: Java Web服务在将来一年内的发展[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：