InfoQ：你能告诉我们一些关于你自己的事吗？ Arjen Poutsma（AP）：我是Interface21的高级顾问。 我从事企业应用程序开发已有13年了，首先是C ++，然后是Java，两年的时间里我进行了.NET开发。 大约四年前，我开始对Web服务感兴趣，并为一些大型公司提供了有关如何实现它们的建议。
在过去的一年半中，我一直在从事Spring Web Services项目，该项目来自Spring产品组合，专注于创建合同优先，文档驱动的Web服务。 最近，我们发布了Spring Web Services的Milestone 3，我们计划在2007年第二季度发布1.0。
InfoQ：构建Spring Web Services的主要动机是什么？ Java的Web服务框架还不够吗？
AP：在担任顾问的过程中，我遇到了Web服务存在重大问题的客户。 例如，他们希望维护服务合同的多个版本，或者直接处理传入的XML，而无需先将其转换为对象。 当时，现有的SOAP堆栈侧重于使其更容易“ SOAPify”现有的Java类，而不是正确的方式：首先编写服务协定，然后编写可处理传入XML的类。 尽管可以进行合同优先的Web服务设计，但这并不容易。 就像整个Spring产品组合一样，Spring Web Services使正确的方法变得更容易，并向人们展示了如何在其现有架构中适应Web服务。
InfoQ：许多人会争辩说，将XML转换为对象并反向转换正是他们在Web服务堆栈中寻找的功能。 您似乎不同意-您能详细说明吗？
AP：我认为开发人员应该可以选择以他们想要的任何方式处理传入的XML，XML编组是一种（便捷的）方式。
但是，XML编组存在几个问题。 其中之一是，某些编组引擎非常脆弱，即当遇到不知道的XML时它们会爆炸，这与Postel定律并不十分吻合（对您发送的内容保持保守，对所发送的内容保持保守你收到）。
另一件事是，面向对象的语言（例如Java或C＃）与基于树的语言（例如XML）之间存在很大的结构差异。 以对象图为例。 假设我有一个Person类，该类具有配偶属性，因此，配偶的配偶指向同一对象。 没有标准的方法可以用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服务只是进行远程过程调用的另一种方式。 规范的名称清楚地表明了这一点。 这些年来，我们已经发现，行为驱动，类似于RPC的Web服务方式并不是前进的最佳方法。 它导致客户端和服务器之间的紧密耦合，并且完全忽略了诸如延迟，故障，缺少共享内存访问等问题。相反，数据驱动的，类似消息的方法更合适。
JAX-WS是对JAX-RPC的改进。 我特别喜欢的是提供程序API，它提供了一种以消息为中心的方式来处理传入的SOAP请求。 我不喜欢的事实是，该规范的其余部分仍主要集中在RPC上，并且即使有非常好的Java 1.4替代品，也强烈依赖Java 5功能。 看起来如今出现的每个JSR都必须定义几个注释。 仍然有很多Java 1.4甚至1.3用户，并且他们不能使用泛型，枚举和注释，当您使用上述Provider API时，这三个都是必需的。
InfoQ：是什么使Spring Web Services独树一帜，为什么我用它代替Axis，XFire或ActiveSOAP？
记者： Spring Web Services具有几个独特的功能。 首先，它完全专注于合同优先的Web服务设计。 基本上，这意味着您必须编写自己的XSD架构来定义XML消息。 您可以在WSDL中引用该模式（尽管Spring Web Services也可以从XSD生成WSDL），并且可以将其用于验证目的。 有趣的是，当人们使用契约优先的开发风格时，Web服务所具有的许多互操作性问题就消失了。 这就是为什么首先考虑合同优先是最佳实践的原因。 您基本上是在设计XML API：您使用Java实现该API的事实仅仅是一个实现细节，任何客户端都不必关心。
其次，Spring Web Services在契约和实现之间提供了松散的耦合：没有wsdl2java工具将契约直接与类联系在一起； 相反，您可以实现终结点，该终结点可以以您想要的任何方式（DOM，SAX，StAX甚至是XML编组技术（例如JAXB，Castor，JIBX或XMLBeans））处理传入的XML。 将传入请求映射到端点的方式完全取决于您：默认情况下，我们提供基于消息内容或SOAPAction标头的映射。 主要思想是您不是在处理方法调用，而是在处理XML消息。
最后，Spring项目可以提供一些功能：
- WS-Security实现与Acegi Security集成在一起，
- JMS支持使用Spring 2的消息驱动POJO，
- 客户端主类（WebServiceTemplate）提供了类似于JdbcTemplate的API，
- XML编组支持完全独立于Web服务（以便可以在其他设置中使用），
- 它适用于JDK 1.4及更高版本（尽管也有Java 5特定的功能）。
InfoQ：所以默认情况下，我的应用程序从消息中传递了XML？ 以什么形式-作为DOM树，流，阅读器或其他内容？
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架构生成1.1 WSDL。 WS-Addressing计划在1.0版后的时间范围内进行。 基本上，我倾向于等待标准的实施，直到有足够的用户需求为止。 到目前为止，人们似乎对我们拥有的产品感到非常满意。
InfoQ：您对WS- *的总体看法如何？
AP：嗯，有一些我喜欢的部分和我不喜欢的部分。 我喜欢SOAP，我认为这是跨传输发送XML消息的好方法。 我不太喜欢WSDL，因为它提供了具有操作，接口等功能的几乎面向对象的Web服务模型，这与SOAP不太适合。 SOAP没有操作，它只是XML消息。 在这方面，我更喜欢SSDL（SOAP服务描述语言）。
我喜欢WS-Addressing的概念：将寻址信息放在SOAP Header中，但是我不喜欢使用五个不同且不兼容的版本这一事实。 基本上，如果有人告诉您他们的服务支持WS-Addressing，则需要询问：“您是否支持2004年3月版本，2004年8月版本或任何其他版本？”
最后，我认为WS-Security非常有用。 它并没有尝试重新发明轮子，而是在有意义的地方使用了XML-DSig和XML-Enc。
InfoQ：您对REST有什么看法，您认为Spring Web Services有一天会支持它吗？
AP：我喜欢REST，我喜欢REST通过基于HTTP（一种成熟的技术）解决我们在WS- *空间中面临的许多问题的方式。 也就是说，我认为REST与SOAP一样，甚至比SOAP更严格。 在编写REST服务时，您必须清楚地知道资源是什么，对它们支持的数据格式（REST不仅与XML有关！），对它们支持的HTTP方法以及它们的含义。 所有这些也必须清楚地记录在案； HTTP规范不足以实现此目的。
许多人说他们在做REST，但实际上是Don Box命名为POX（普通的旧XML）。 POX是一种XML消息传递协议，您可以在其中简单地发送XML消息，而无需在其周围包裹SOAP信封。 Spring Web Services已经支持此功能。
关于“真正的” REST支持，我认为我们会在将来支持它，但在Spring Web Services的1.0版本中不会。 它与SOAP和POX有很大的不同，例如，没有XML消息始终存在。 我们不想通过从HTTP请求创建XML消息，然后将其发送到管道中（在三毫秒后再次对其进行解析）来支持REST：这太昂贵了。 相反，我们将基于Spring的Web框架Spring-MVC提供REST支持。
InfoQ：谢谢您的时间！
可以从Spring网站下载Spring Web Services产品。 Arjen还维护一个有关Web服务的博客 。
245
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
