BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Arjen Poutsma谈Spring Web Services

| 作者 Stefan Tilkov 关注 3 他的粉丝 ,译者 俞黎敏 关注 0 他的粉丝 发布于 2007年12月8日. 估计阅读时间: 14 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

Spring Framework作为一种更轻量化的“企业”框架选择,它在Java开发人员中非常流行。最新增加的其中一项是Spring Web Services子项目,根据网站上的说法,是“专注于创建文档驱动(document-driven)的Web Services,[并]帮助推动契约优先(contract-first)的SOAP服务开发,允许利用操作XML payloads的多种方法之一来创建灵活的Web Services。

InfoQ的Stefan Tilkov和Spring Web Services的创建者Arjen Poutsma进行了一次对话,谈到了整体的Web Services,并特别讨论了Spring的支持。

InfoQ:您能向我们介绍一下您自己吗?

Arjen Poutsma(以下简称AP):我是Interface21的高级顾问。我现在从事企业应用程序开发已经13年了,刚开始用C++,后来用Java,有两年我还从事过一些.NET的开发。我大约四年前开始对Web Services感兴趣,并且建议了一些大公司如何去实现它们。

在刚过去的一年半中,我一直在从事Spring Web Services项目,这是Spring Portfolio中的一个产品,专注于创建契约优先、文档驱动的Web Services。近来,我们已经发布了Spring Web Services的Milestone 3,我们还计划在2007年的第二季度发布1.0。

InfoQ:构建Spring Web Services的主要动机是什么?Java还没有足够的Web Services框架吗?

AP:在我作为顾问的工作中,我遇到过Web Services有严重问题的客户。例如,他们想要维护一个Service契约的多个版本,或者直接处理得到的XML,而不用先转化成对象。当时,现成的 SOAP堆栈专注于使“SOAP化”现有的Java类变得更容易,而不是正确地完成它:从编写一个Service契约开始,并编写可以处理得到的XML的类。虽然有可能进行契约优先的Web Service设计,但也不容易。就像整个Spring Portfolio所做得那样,Spring Web Services使得以正确方式进行变得更加容易,并向人们展示了如何使Web Services符合他们现有的架构。

InfoQ:许多人认为,将XML转化成对象再转化回来,这正是他们在Web Services堆栈中寻求的功能。您对此似乎并不认同——能解释一下吗?

AP:我认为开发人员应该要能选择以他们想要的方式来处理得到的XML,XML封送(marshalling)就是一种(方便的)方式。

然而,XML封送有几个问题。其中一个就是有些封送引擎十分脆弱,例如,当它们遇到它们不能识别的XML时就会爆炸,这真的不太符合Postel法则(发送时严谨,接收时宽松)。

另一个问题是,在面向对象的语言如Java或者C#,和基于树的语言如XML之间有许多结构上的差别。例如以对象图为例。我们假设有一个Person类,它有一个spouse(配偶)属性,以便spouse的spouse指向同一个对象。用XML表示这种关系并没有标准的方法;你只能求助于定制机制。另一个问题是数据类型的:在Java中我们有一个java.util.Map,它一般有两个实现(HashMap和TreeMap)。XML Schema(XSD)没有字典结构的数据类型,因此当我将一个HashMap封送给XML时会发生什么呢?

我希望从中得到某种XML,但是当我再次解封它时,我就可能得不到与当初相同的HashMap了。

因此没有透明封送这回事,就像没有透明的对象持久化一样。你必须指示封送引擎如何将你的对象转化成XML,就像你指示一个对象/关系映射工具在SQL和对象之间进行转化一样。这就是我更喜欢称它为对象/XML映射而不是封送的原因,因为这显然也要注意对象/XML阻抗不匹配的问题。

InfoQ:您对JAX-RPC/JAX-WS怎么看?

AP:JAX-RPC发布时,人们只是把Web Services当成远程过程调用(Remote Procedure Calls)的另一种方法。规范的名称明显说明了这一点。在那些年里,我们发现像RPC这样进行Web Services的行为驱动方式,并不是最佳的前进方式。它导致客户端和服务之间更加紧耦合,并且完全忽略了像延时、失败、缺乏共享的内存访问等东西。像消息这样的数据驱动法反而更适合。

JAX-WS是JAX-RPC的一种改进。我特别喜欢的东西是Provider API,它提供了一种处理得到的SOAP请求的消息关注方式。我不喜欢的是,规范的其余内容仍然十分关注RPC,并且强烈依赖Java 5特性,即使有很好的Java 1.4时也一样。好像目前出现的每一个JSR都必须定义一对注解。外面仍然有许多Java 1.4甚至1.3的用户,他们无法使用泛型(generic)、枚举(enum)和注解(annotation),当你使用上述的Provider API时这三种都需要。

InfoQ:是什么东西使Spring Web Services变得如此独树一帜,为什么我要用它而不用Axis、XFire或者ActiveSOAP?

AP:Spring Web Services有几个独特的特性。首先,它完全专注于契约优先的Web Service设计。这基本上意味着你必须编写自己定义XML消息的XSD Schema。你可以引用WSDL中的Schema(虽然Spring Web Services也可以从XSD中生成WSDL),并将它用于验证。值得关注的事情是,当人们使用契约优先的开发风格时,他们在Web Services方面的许多互通性问题就消失了。这就是契约优先之所以被普遍当作是一种最佳实践的原因。你基本上是在设计一个XML API:你用Java实现这个API的事实,只是没有客户会在意的一个实现细节而已。

其次,Spring Web Services提供了契约和实现之间的一种松耦合:没有wsdl2java工具将契约直接连接到一个类;而是用你喜欢的任何方式(DOM、SAX、 StAX,甚至XML封送技术如JAXB、Castor、JIBX或者XMLBeans),实现处理得到的XML的端点(endpoint)。你将得到的请求映射到端点的方式,完全由你自己决定;默认情况下,我们提供基于消息内容的映射,或者SOAPAction Header。主要的思想是,你不用处理方法调用,而是处理XML消息。

最后,你可以从Spring项目中期待这些特性:

  • WS-Sercurity实现与Acegi Security整合;
  • JMS支持使用Spring 2的Message Driven POJO;
  • 主客户端类(WebServiceTemplate)提供一种类似于JdbcTemplate的API;
  • XML封送支持完全独立于Web Services(以便它可以用在其他的设置中);
  • 它适用于JDK 1.4及以上版本(虽然也有特定于Java 5的特性)。

InfoQ:因此在默认情况下,我的应用程序是从消息传送XML的?以哪种形式——以DOM树、流、Reader还是其他形式?

AP:应用程序传送一个XML输入抽象进行读取,并且一个输出抽象写入(相应为javax.xml.transform.Source和 javax.xml.transform.Result)。这样你的代码就不依赖任何特殊的XML处理API了。这个机制的实际实现取决于你选择使用的消息工厂。我们给SOAP提供了两种工厂:默认的是基于SAAJ的(javax.xml.soap,J2EE 1.4的一部分),它在底层使用DOM。对于更大的消息,我们支持Axis2的AXIOM,它使用一种StAX流。

InfoQ:Spring Web Services如何处理WS-*标准——你能开箱即用地支持它们中的任何一种标准吗?

AP:Spring Web Services支持SOAP 1.1和1.2、WS-Security,并支持在XSD Schema里面生成1.1 WSDL,WS-Addressing计划在1.0中发布。我基本上趋向于等到有足够的用户请求它时才会实现一种标准。目前为止,人们似乎对现状十分满意。

InfoQ:你对WS-*的前景整体上怎么看?

AP:嗯,有一部分我喜欢,有一部分不喜欢。我喜欢SOAP,我认为它是跨传输器发送XML消息的一种很好的方式。我不太喜欢WSDL,因为它提供了一个几乎是面向对象的Web Service模型,包含操作、接口等等,它不太适合SOAP。因为SOAP没有操作,它只是一种XML消息。从这一点上来说,我更喜欢SSDL(SOAP Service Description Language)。

我喜欢WS-Addressing的理念:把地址信息放在SOAP Header里面,但我不喜欢它有五个不同的不可兼容的版本在使用。基本上,如果有人告诉你他们的服务支持WS-Addressing,你就需要问:“你是支持2004年3月的版本,还是2004年8月的版本,或者其他的版本呢?”

最后,我认为WS-Security十分有用。它没有试图去重新发明轮子,而是在必要的地方使用XML-DSig和XML-Enc。

InfoQ:你对REST有什么评价,以及你认为Spring Web Services将来总有一天会支持它吗?

AP:我喜欢REST,我喜欢它通过把自身基于HTTP上,来解决我们在WS-*中面临的许多问题的方式,这是一种公认的技术。也就是说,我认为REST就像SOAP一样受限制,或者更甚。在编写一个REST服务时,你对于你有什么资源、你的哪些数据格式支持它们(REST不仅仅是关于 XML的!),以及它们意味着什么等等,都必须了然于胸。所有这一切也都必须清楚地写成文档,HTTP规范不足以达到这个目的。

许多人说他们在做REST,但是他们实际上在做的只是被Don Box称之为POX(Plain Old XML)的事情。POX是一种XML消息协议,在这里,你只要发送XML消息,而不需要用SOAP包将它封装起来。Spring Web Services已经支持这一点了。

至于“真正”的REST支持,我认为我们未来将会支持它,但不是在Spring Web Services的1.0版本中。它与SOAP和POX非常不同,例如,并不总是有XML消息进来。我们不想通过从HTTP请求中创建一个XML消息,将它射入3毫秒后要在那里被再次解析的管道中,以此来支持REST:这成本简直太高了。我们而是将把REST支持放在Spring-MVC中,它是 Spring的Web框架。

InfoQ:非常感谢!

注:Spring Web Services产品可以从Spring网站上下载,Arjen还在维护一个关于Web Services的博客

查看英文原文:Arjen Poutsma on Spring Web Services
译者简介:俞黎敏(网名:阿敏总司令),技术顾问,自由撰稿人,开源爱好者,曾经参与Spring中文论坛组织Spring 2.0 Reference中文版的技术审校和满江红开源组织Seam 1.2.1 Reference的中文翻译工作;另外他还翻译了《CSS: The Missing Manual》、《Java Persistence with Hibernate》等书籍,并担任 CSDN、CJSDN、Dev2Dev、Matrix、JavaWorldTW等技术网站Java论坛版主。他的博客是:http://YuLimin.JavaEye.com

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

spring ws配起来挺麻烦的 by pei kuo

spring ws配起来挺麻烦的,但是很灵活。
xfire倒是真方便。我以前没碰过xfire,用spring+xfire搭,十分钟就搞定了,很有成就感,呵呵

"我们还计划在2007年的第二季度发布1.0"? by zhu pan

"我们还计划在2007年的第二季度发布1.0"?

Re: 旧文新译 by Guo Xiaogang

这篇是前半年InfoQ中文站成立之前的旧文章,我们最近在整理以前的一些文章,把有价值的挑出来翻译。
看来是应该说明一下的。

Re: spring ws配起来挺麻烦的 by Chen Nikos

Xfire 会更方便吗 ?
那spring出的这个有什么优势吗 ?还是说目前还不成熟,不值得用?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

4 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT