java jax-ws
介绍
除了商业供应商提供的选项之外，还有许多开源Java框架可供选择以实现Web服务。 在Java空间中用于实现基于SOAP / WS- *的解决方案的最受欢迎的开源堆栈包括Apache Axis2 ， Apache CXF ， Spring Web Services ， JBossWS和Sun的Metro 。 我向这些堆栈的主要开发人员提出了许多问题，这些问题涉及他们的设计目标，他们对Java和Web服务标准的处理方法，数据绑定，访问XML，互操作性，REST支持以及框架成熟度。 不出所料，结果显示出许多相似之处和一些值得注意的差异。
我将本文分为两个部分：首先，我概述了问题以及开发人员的回答中的重点内容。 尽管我已尽我所能使摘要保持公正，但在第二部分中提供了原始答案供参考（以及对所有详细信息感兴趣的人）。
采访的开发人员包括Paul Fremantle（Axis2），Dan Diephouse（CXF），Arjen Poutsma（Spring Web Services），Thomas Diesler（JBossWS）和Kohsuke Kawaguchi（Metro）：
Paul Fremantle是WSO2的联合创始人兼技术销售副总裁，该公司是许多Apache项目背后的推动力。 在IBM任职期间，Paul创建了Web服务网关，并领导了将其作为WebSphere Application Server的一部分进行开发和交付的团队。 Paul是将服务集成总线技术引入WebSphere Application Server 6的团队的成员。他还共同创建了Web服务调用框架（WSIF），并且是JSR 110和OASIS WS-RX TC共同主席的共同负责人。 。
Dan Diephouse是MuleSource（一家开源Mule ESB背后的公司）的软件架构师。 在这里，他专注于构建和帮助其他人构建开源Web服务/ SOA解决方案。 他是Web服务框架Apache CXF的共同创始人，是XFire，SXC和Jettison等其他几个项目的创始人，并在可能的情况下参与了其他几个项目。
Arjen Poutsma是高级企业应用程序架构师，是Spring Web Services的创始人和项目负责人。 这个Spring项目旨在促进文档驱动的Web服务的开发。 Arjen还为其他各种开源项目做出了贡献，包括XFire，NEO等。 自2005年初以来，Arjen一直是荷兰Interface21（Spring背后的公司）的顾问。
Thomas Diesler是JBoss的Web Service项目负责人，通常作为技术董事会成员帮助JBoss设置技术方向。 作为JCP的成员，他帮助定义了各种Web Service规范（例如JAX-WS）。
Kohsuke Kawaguchi是Sun Microsystems的一名高级工程师，自2001年以来一直致力于XML和XML模式语言，包括RELAX NG和W3C XML Schema的规范工作，以及许多相关Java工件（包括JAXB和JAXP）的实现工作。 他作为Java Web服务和XML社区的原始领导者之一，活跃于java.net。
第一部分：概述
设计目标
在所有堆栈中共有一些设计目标，例如可扩展性，模块化和性能。 Axis2是围绕一个称为AXIOM的XML对象模型而设计的，AXIOM是流和基于树的消息传递的混合，并提供可插拔数据绑定支持。 CXF支持可插拔传输，数据绑定，甚至可以支持JSON等替代格式。 Spring-WS也支持多种处理XML的方式-从基于XPath的访问到许多XML API（例如DOM，SAX和StAX），再到数据绑定方法（例如JAXB，Castor和XStream）。 Metro还具有可插拔的传输和编码功能。 假设所有这些方法都已付诸实践并按预期工作，那么在这方面很难看到任何重大差异。
保罗·弗里曼特尔（Paul Fremantle）指出，Axis2的体系结构被设计为可在C和Java中实现。 他还强调了Axis2的模块概念，该概念允许将处理程序的相关集合以及库和数据文件作为单个单元进行部署。 Dan Diephouse指出CXF的可嵌入性是其主要功能之一。 他指出的另一方面是开发人员注重易用性。 Arjen Poutsma非常强调Spring-WS对WS开发的“契约优先”风格的支持。 Thomas Diesler指出，JBossWS既可以支持自己的本机堆栈，也可以与其他组件（包括CXF和Metro）集成。 Sun的Kawasuke Kawaguchi将互操作性列为Metro的设计目标。
JCP标准
JCP中有许多用于XML和Web服务的标准，最著名的是JAX-RPC，JAXM及其后继者JAX-WS以及JAXB（用于XML数据绑定的JCP标准）。 关于在不同框架内支持这些标准的观点开始有所不同。
Axis2团队做出了明确的决定，将JAX-WS作为“最小，干净的API”之上的一层来支持，这遵循了自己对使框架“酷”的观点。 JAXB本身或与JAX-WS一起受支持。 Paul Fremantle分别认为JAX-RPC和JAXM已过时且从未使用过。 Dan Diephouse（和CXF框架）对JAX-RPC和JAXM持相同意见，CXF也支持JAXB和JAX-WS。 有趣的是，Diephouse认为JAXB是“快速，非常健壮的”，并且发现它“将与他遇到的99.999％的架构一起使用”。 他还指出了自己的SXC项目 ，以极大地提高JAXB的速度。 JBossWS支持JAX-RPC，JAX-WS和JAXB。
出于显而易见的原因，对JCP标准的支持是Sun Metro的最重要目标之一。 正如Kawasuke Kawaguchi指出的那样，Metro包括JAXB和JAX-WS JSR的参考实现。 Arjen Poutsma解释说，Spring-WS公开的编程模型与JAXM非常相似，因为它是基于消息的编程模型，而不是“类似于RPC的模型，例如JAX-RPC和JAX-WS”。 因此，尽管支持JAXB 1和2，但不支持JAX-WS（作为一个明确的设计决策，似乎如此）。 似乎Axis2和Spring-WS都没有表现出对JAX-WS的太多赞赏，而只有Spring-WS远远不包括对它的支持。
Web服务标准
所有框架都声称支持一套通用的Web服务标准，包括SOAP 1.1和1.2，WSDL 1.1，MTOM / XOP和WS-Security。 Axis 2是唯一支持WSDL 2.0的堆栈（这可能并不奇怪，因为WSO2联合创始人Sanjiva Weerawarana是WSDL 2.0编辑器之一）。 除Spring-WS和JBossWS之外的所有工具均实现WS-Addressing和WS-Reliable Messaging（计划在将来的版本中同时支持WSDL 2.0和WS-Addressing）。 Metro是唯一支持WS-AtomicTransaction和WS-Coordination的堆栈，它们已连接到J2EE / Java EE事务。
数据绑定
数据绑定的主题，即从XML到对象再到对象的映射，通常导致Web服务和XML从业人员之间的激烈争论。 Arjen Poutsma的观点（“数据绑定[…]可能很方便，但是为所有互操作性问题打开了大门”）被许多受访者所接受，但是由于以下原因，包括Arjen的Spring-WS在内的所有堆栈都支持它：简单的用户需求。 它们都还支持直接XML访问，通常通过SAX，StAX，DOM进行； 还有一些其他选项可用，例如，在Axis2中使用AXIOM，在CXF中使用Aegis，以及Spring-WS的XPath。
互操作性（尤其是.NET / WCF）
保罗·弗里曼特尔（Paul Fremantle）认为，由于团队参与了许多互操作性活动，因此Axis2是最可互操作的堆栈之一，并指出了针对单个标准和整个配置文件的互操作性测试。 Dan Diephouse将互操作性测试分为三个领域：数据绑定（CXF依赖于经过验证的JAXB和Aegis实现），WS-I基本概要文件支持和WS- *互操作性。 CXF依赖于WS-I BP的合规性，使用诸如WSS4J之类的框架来确保安全性（也被Axis2使用）以及互操作性测试以确保互操作性。 Arjen Poutsma认为Spring-WS的合同优先方法是尽早发现和解决互操作性问题的最佳保证。 据川口昌介说，与Microsoft产品的互操作性是Sun的Metro项目中引起管理界高度关注的主题之一。 根据Thomas Diesler的说法，JBossWS开发人员也参加了互操作性事件。
REST支持
关于堆栈对REST的支持的问题让开发人员都不感到意外，尽管答案差异很大。 根据Paul Fremantle的说法，Axis2支持基于HTTP的简单XML场景（通常不是RESTful）以及通过WSDL 2.0的HTTP绑定的“真实” REST。 超媒体是Axis2尚不支持的区域。 （我个人对此说法持怀疑态度，因为WSDL 2仍然围绕操作的概念，从我的角度来看，这似乎与REST类似。）Dan Diephouse将CXF对POX（基于HTTP的纯XML）的支持描述为以及REST：后者是通过注释完成的，类似于JSR 311所采用的方法。Arjen Poutsma承认REST是SOAP，WS- *和POX的有趣替代品，但Spring-WS尚不支持它。 将来某个时候这样做时，它将基于Spring Web框架提供支持。 川口浩介（Kohsuke Kawaguchi）宣布了对REST的热爱，但认为对它的支持超出了Metro的范围，并指向Sun的JSR 311实现方案Jersey。 有趣的是，当被问及JBossWS中的REST支持时，Thomas Diesler指向Metro。
框架成熟度
毫不奇怪，所有开发人员都声称他们各自的框架已经成熟并且可以投入生产。 Axis2和CXF用在许多其他开源项目中，而Axis2则更多使用（甚至在某些商业产品中，例如IBM WebSphere）。 根据Arjen Poutsma的说法，将Spring-WS升级到1.0版花了两年的时间是因为Interface 21的高质量标准。 Kawaguchi的Kohsuke Kawaguchi和CXF的Dan Diephouse都指出了其框架的历史，这些框架分别植根于JWSDP和XFire。 Thomas Diesler指出，根据调查，超过60％的JBoss客户群使用JBossWS。 Kawaguchi巧妙地指出，在Java 6 JDK中包含Metro的组件很容易使其成为安装最广泛的工具箱。
结论
仅查看不同堆栈的开发人员提供的答案就很难得出任何明显的建议。 至少从目标看，肯定有更多的共同点，而不是存在差异：关注效率和性能，可扩展性和可插入性以及开发人员的选择。 与CXF，Spring-WS和JBossWS相比，Axis2和Metro支持更多的WS- *标准。 尽管Axis2试图统一“经典” WS- *样式和REST样式，但其他人则认为它是通过不同的编程模型来支持或根本不支持它。 Metro显然是受JCP标准影响最大的一种。
有人认为这是幸运还是不幸–似乎Java WS社区将继续不得不选择相当长的一段时间。
第二部分：细节
以下是我提出的原始问题以及从框架开发人员那里获得的答案。
（1）您能否描述“您的”框架的主要设计目标？ 您认为它的主要优势和独特功能是什么？
保罗·弗里曼特尔（Axis2） ： Axis2的主要设计目标是建立一个围绕XML进行干净设计的框架，该框架具有很高的性能，并且易于扩展以添加对各种WS- *协议的支持。 一个目标是采取以XML为中心的设计重点。 也就是说，与其他WS堆栈不同，Axis2架构不会将XML视为要尽快转换为对象的热点。
相反，它将XML视为要执行的自然数据模型，并允许我们将数据绑定“外包”到同类最佳的开源项目中。 可插拔数据绑定意味着我们可以使用JAXB，XmlBeans，我们自己的简单模型（ADB）或任何第三方程序包。
AXIOM，我们的XML API，为我们提供了令人难以置信的快速和灵活（流和基于树的混合）消息处理。
我们的“模块”体系结构允许将相关的Handlers集合以及库和数据文件作为一个单元部署，从而大大改善了Axis1和其他系统的基于处理程序的模型。 模块约束系统消除了手动处理程序订购的需要。 通过用户配置或策略处理来使用模块，并且分发可以从“裸露”变为“完全启用WS- *”，其中包含一些文件。
服务和模块都可以轻松地作为存档文件或分解目录进行部署。 “作用域”上下文模型丰富了配置和控制-设置来自消息，操作，服务，会话或整个系统，并且非常易于使用。
我们的可插入后端意味着可以轻松实现JavaScript，EJB，数据库或其他实现的服务适配器。
另一个关键的设计要点是，我们将体系结构设计为可在Java和C中实现。就我们所知，我们在拥有完整的本机C实现方面是独一无二的。 我们已经完成了C堆栈PHP绑定，并且正在处理Perl和Ruby绑定，并且还将进行Python绑定。
Dan Diephouse（CXF） ：首先，作为一个Apache项目，我们基于社区模型。 这意味着我不能代表该项目涉及的所有开发人员或组织。 因此，以下仅是我的意见！
我们的框架的目标没有特别的顺序是：
支持Web服务标准，其中Web服务标准表示SOAP / WS- *。 我们支持用于开发服务的各种场景，从不需要注释的简单代码优先服务到WSDL优先服务，再到JAX-WS API Provider / Dispatch API。
人体工程学：当然，我们并不是十全十美，但我们确实在努力使CXF尽可能易于使用。 我们的API旨在使简单用例变得微不足道，而使硬用例成为可能。 我们还努力创建了很多工具-包括Maven / Ant插件。
可嵌入性：CXF被设计为嵌入在应用程序内部的组件。 该应用程序可以是您自己的业务应用程序，ESB或应用程序服务器。 例如：Mule，ServiceMix，Geronimo和JBossWS是一些很好的公共示例。
Spring集成：我们的Spring集成使在ApplicationContext内部配置客户端，服务器和传输变得容易。
性能：CXF的SOAP / XML部分基于流XML消息模型，该模型促进了非常快速的XML处理和低内存使用。
灵活性和可扩展性：CXF诞生的原因之一是我们需要一个非常灵活且可扩展的框架。 您可以轻松编写新的传输方式。 您可以添加对不同绑定的支持。 我们支持JSON和Corba等非XML格式。 都是非常可插拔和可扩展的。
Arjen Poutsma（Spring-WS） ：Spring Web Services的主要设计目标是“使最佳实践成为一种简单实践”。 传统上，合同优先服务开发（即从WSDL和XSD开始）一直很麻烦。 Spring Web Services旨在简化此过程，例如通过从XSD架构生成WSDL。
就像Spring产品组合中的所有产品一样，Spring-WS的另一个独特功能是选择。 您可以使用任何想要的方式处理传入的XML消息：通过使用DOM，JDOM，dom4j，XOM，SAX或StAX等低级API，通过使用XPath表达式，甚至使用受支持的XML编组之一机制：JAXB 1或2，Castor，XMLBeans，JiBX或XStream。
Thomas Diesler（JBossWS） ：JBossWS是jboss应用程序服务器中可插入Web服务堆栈的框架。 当前，我们支持本机堆栈，Sun Metro和Apache CXF。 看这里
川口浩辅（地铁） ： 地铁的主要设计目标之一就是性能。 我们已经完成了Web分布式技术（CORBA，JAX-RPC 1.0和JAXB 1.0等）的一次迭代，因此我们第一手知道减速的原因以及如何修复它们。 这些专业知识和经验被投入到Metro的设计中，我认为这正在显示 。 性能目标的另一部分是为确实需要从中获得最大收益的少数人（通常是框架开发人员）提供额外的专有API。 一个很好的例子就是我们的异步实现-对于典型的开发人员来说这还不容易，但是例如OpenESB的人就利用这一点来实现出色的可伸缩性。
Metro的另一个设计目标是可扩展性。 同样，我们在前几代技术上拥有丰富的经验，因此我们知道在哪些地方可以使用附加抽象。 这包括传输和编码抽象之类的东西。 我们使用它们来实现FastInfoset支持和JSON支持，从而扩展了Metro以及其他传输（如JMS，SMTP和in-JVM本地传输）的适用性。 在许多地方，我们也能够设计抽象以促进更好的性能。 这些可扩展性是我们以模块化方式实现大量WS- *规范的关键。
互操作性是另一个重要目标。 同样在实践中，这更多地与艰苦而艰苦的测试工作有关，而不是设计工作。 我们与不同的供应商进行了多次互操作性研讨会，我们与工程师和Microsoft工程师举行了例行会议以讨论问题，甚至邀请了Microsoft专家参加JavaOne主题演讲，以展示我们的互操作性。 我们每晚进行互操作测试并监控结果。 这就是我们对互操作性的重视程度。
最后但并非最不重要的一点是，易用性是我们的另一个重要目标。 同样，这与关注细节而不是设计息息相关。 我们认为生产力的损失通常伴随着解决一些问题的困难。 例如，您中有多少人有花费数小时来搜索特定问题的解决方案的经验？ 因此，我们付出了很多努力来进行良好的错误诊断和报告，使用调试和日志记录开关来让您和我们确定正在发生的事情，等等。易于使用的另一个重要Struts是良好的用户支持经验和文档。 我们还通过几种不同的渠道为Metro提供有偿支持。
我不知道它们是否唯一，但是我认为它们的组合使Metro成为非常可靠的Web服务堆栈。
（2）您对JCP标准（例如JAX-WS，JAX-RPC，JAXM，JAXB）的立场和框架的支持如何？ 为什么包含/不包含对此的支持？
Paul Fremantle（Axis2） ：从一开始就将Axis2设计为具有最小的，干净的API，它将真正利用使我们的框架更酷的特定功能-范围内的上下文，AXIOM流XML模型，基于模块的可扩展性，等等。我们还想确保Java 1.4的兼容性，并且已经对TCK认证的延缓和延迟有一定的经验。 因此，我们决定支持JAX-WS（需要1.5）-但作为基础之上的插件层。 我们还完全支持JAXB本身或与JAX-WS一起作为可插入数据绑定。 这使我们既可以支持标准，也可以独立开发自己的API。 由于JAX-WS取代了JAX-RPC，因此我们认为JAX-RPC不值得，而且JAXM从未使用过。 我们还意识到JVM不仅适用于Java。 我们在支持JavaScript服务方面已经做了大量工作，并且我们计划也要与其他JVM语言（例如JRuby和Groovy）进行绑定。
Dan Diephouse（CXF） ：JAX-WS：我们支持JAX-WS 2.0标准，并且现在也正忙于实现2.1标准。 我认为JAX-WS非常重要，原因有二。 首先，它使构建Web服务和客户端相对容易。 其次，因为它是一个标准，所以关于如何使用它的开发人员知识储备越来越大。 这意味着您作为开发人员不必花时间学习专有的API或新框架的内幕/外幕。
JAXB：JAXB也是重要的JCP标准。 出于同样的原因，JAX-WS也是如此：它使构建服务变得容易，并且关于如何使用它具有大量的知识。 另外，目前唯一的JAXB实现非常好。 它速度快，非常健壮，并且可以处理我遇到的99.999％的架构。 关于最后一点-您可以将其与任何其他框架进行比较，除了可能的XMLBeans，而且JAXB将会领先。
但是，它确实有一些烦恼：您经常需要创建jaxb.index文件，默认情况下会在默认名称空间中创建元素，并且它的速度不如预期的快。 关于最后一点，我们已经致力于通过SXC（http://sxc.codehaus.org）项目解决此问题，该项目为JAXB bean提供了已编译的读取器/写入器。 这使JAXB大大提高了性能。
JAX-RPC：我们不支持JAX-RPC。 如果您要开发新服务，这是一个很少使用的非常过时的标准。 尽管我们已经讨论了添加对JAX-RPC的支持以帮助人们从较旧的框架中迁移出来，但是这将为我们带来很少的边际价值，而我们的工作量很大。
JAXM：我们也不支持JAXM。 它是一个几乎没有人使用的旧标准。 此外，它似乎已被JAX-WS取代。
Arjen Poutsma（Spring-WS） ：Spring Web Services提供的编程模型与JAXM非常相似，即它是基于消息的编程模型，而不是像JAX-RPC和JAX-WS这样的类似RPC的模型。 此外，Spring-WS支持SAAJ，它是SOAP消息抽象，从1.4开始就已成为J2EE的一部分，但使它对开发人员更加友好。 例如，由SAAJ抛出的已检查SOAPException由运行时异常包装。
最后，对象/ XML映射抽象支持JAXB 1和2。
Thomas Diesler（JBossWS） ：我们支持JAX-WS，JAX-RPC，JAXB。 在我们看来，JAX-WS取代了JAXM。 因此，我们不支持JAXM。
川口浩辅（Metro） ：Metro的各个部分可以单独使用，因为它们比Web服务通常具有更广泛的适用性，并且这些部分包括JAXB RI，JAX-WS RI和SAAJ RI等。 对于不熟悉JCP术语的人来说，RI状态意味着它们被用作JCP规范的退出标准之一，除非它们通过所有兼容性测试（称为TCK），否则我们将不发货。 ）此过程通常使RI最符合规范的实现。 如您所见，Metro非常重视兼容性。 我们甚至至少每晚进行一次TCK测试，在某些情况下，我们会连续进行测试以检测任何兼容性下降。 因此，对于我们来说，这是开发过程的一部分，而不仅仅是我们在发布周期结束时运行的过程。
其他一些Web服务工具包并没有像我们这样强调JCP标准，但是我认为兼容性在许多方面对用户都是有益的。 例如，它为竞争创造了一个公平的竞争环境，它有助于避免供应商陷入困境（从而减少了选择一个工具箱并被其困住的风险），但对我而言更重要的是，因为它创建了一个更大的生态系统，谢谢扩大到更大的用户群。 更大的生态系统使许多事情在经济上可行，而这在其他方面是不可能的，这包括从书籍和文章到培训和工具的所有内容。
我们仍然在许多地方提供专有的API，但是由于这些原因，我们会继续在有意义的地方坚持使用标准。
（3）您支持哪些Web服务标准，以及为什么不支持那些您不支持的标准（即，您打算以后再将其包括在内，也不是完全不包括，…）
Paul Fremantle（Axis2） ：Axis2本身主要涉及XML和SOAP消息处理，并支持SOAP1.1和SOAP1.2，并包括多种传输方式（HTTP / S-包括非阻塞IO，JMS，TCP，SMTP / POP，XMPP）。 即时支持MTOM，以及WSDL 1.1和2.0，WS-Addressing和WS-Policy。 我们还支持可插入编码，包括FastInfoset和JSON。 更高级别的规格均通过可插入性支持，我们认为这对于不需要每个规格的嵌入式应用程序尤为重要。 我们提供了WS-Security（1.0 / 1.1），WS-SecureConversation and Trust，WS-ReliableMessaging（1.0 / 1.1），WS-Transactions，WS-MetaDataExchange，WS-Transfer，BPEL（Apache Ode），WS-Eventing，和WS-RF / Notification（Apache Muse）。 我们的团队或其他人可以根据需要轻松添加对其他规范的支持。
Dan Diephouse（CXF） ：我们支持：
- SOAP 1.1、1.2
- WSDL 1.1
- WS-I BasicProfile 1.1
- WS-Addressing 2004 / 08，1.0
- WS政策
- WS-ReliableMessaging 1.0
- WS-Security 1.0、1.1
我们希望也能尽快支持WS-SecureConversation和WS-Trust。
当然还有很多其他的。 许多都不重要或毫无价值（您可能会觉得它们都是，但这又是另一回事了！），因此我们专注于从用户那里听到的内容。 如果您觉得缺少对重要规范的支持，请给我们发送电子邮件（http://incubator.apache.org/cxf/mailing-lists.html），以便我们考虑将其包含在将来的版本中。
Arjen Poutsma（Spring-WS） ：显然，Web服务应该主要关注互操作性，但是令人惊讶的是，这些规范中有很多根本根本不能互操作。 这意味着存在Java或.NET的实现，但没有Ruby，Python或Perl等脚本语言的实现。 因此，在实现WS- *规范时，我们尝试采取一种非常务实的方法，并且仅实现那些能够增加价值或具有足够用户需求的方法。
也就是说，Spring-WS当前支持SOAP 1.1和1.2，WSDL 1.1，MTOM，并且具有与Spring Security集成的WS-Security实现。 对于即将发布的1.1版本，我们计划实现WS-Addressing和WSDL 2.0。
托马斯·迪斯勒（Thomas Diesler）（JBossWS） ：请参见此处 。 我们希望通过Metro / CXF集成支持更多WS- *标准。 当前，我们还在致力于本机WS-RM支持。
川口浩辅（地铁） ：
我讨厌Web服务的地方是涉及太多规范。 但是无论如何，从简单的基础开始，我们使用WS-I Basic Profile 1.1作为基线，因此我们发布和使用的WSDL符合WS-I BP。 为了处理大型二进制数据/附件，我们支持WS-I附件概要文件1.0和MTOM / XOP。 我们还支持整个WS-Addressing 1.0。 我们甚至提供了利用WS-Addressing优势的改进的编程模型。 Metro中也提供了WS-MetadataExchange支持和WS-Policy，它们或多或少是透明的，但仍然是使内容透明地工作的重要部分。
Metro包含WS-ReliableMessaging支持，用于在涉及中介时可靠地按顺序传递消息。 它支持WS-AtomicTransaction以及WS-Coordination。 这些已连接到JavaEE事务，因此您可以使用它在多个JavaEE系统和.NET系统之间进行声明性的分布式事务，而无需过多了解这些在线协议的细节。
在安全方面，Metro附带了WS-Security，WS-Trust和WS-SecureConversation。 这些规范满足了从简单的消息级安全性到跨不同组织的更复杂的联合身份验证的不同需求。 所有的安全性，事务和可靠性功能都是以WSIT（又名Tango项目）的名义完成的，我们在其中投入了大量资源。
即使我们实现了所有这些规范，而且它们确实是开箱即用的，但我们还是要特别注意几件事。 首先，我们与NetBeans团队紧密合作，以便始终有一个随附的NetBeans插件，该插件使您可以通过漂亮的GUI配置那些模块。 这可以保护您免受底层系统如何配置这些规范的繁琐细节的影响。 其次，从整体上讲，这就是按需付费的模型，即您无需为不使用的功能付出性能，复杂性和认知损失。
最后，如果用户需要付出合理的努力，则相同的模块性允许我们实施其他和将来的WS- *规范。 因此，如果您认为清单不足够，请告诉我们您希望我们提供的支持。
（4）您对数据绑定以及与之相关的许多问题持何立场？ 您是否支持对XML消息的本地访问，XML /对象映射或两者都支持？
Paul Fremantle（Axis2） ：Axis2的设计旨在支持灵活的数据绑定模型，包括对消息的本机XML访问。 Axis2支持各种数据绑定工具箱，包括JAXB，XMLBeans，JIBX，ADB（内置数据绑定），并且该方法可扩展到任何数据绑定工具箱-尤其是如果该工具箱支持StAX标准。 如果用户选择直接访问XML，则Axis2将提供树状模型（Axiom）以及StAX流，并且简单的实用程序类还将提供DOM和SAX接口。 我们认为数据绑定用例非常重要，并且Java编码人员应能够将Web服务与Java模型一起使用，而XML编码人员应能够对XML进行快速有效的访问。 我们认为我们找到了一个良好的中间立场，这使Axis2的Java头和XML头都能成功。 Dan Diephouse（CXF） ：那里的想法是，数据绑定只是获取XML并生成POJO，但我想将此定义扩大为“任何类型的可隐藏或删除原始XML信息集的处理”。 99.999％的应用程序将需要执行此操作-无论是使用JAXB，手动访问XML DOM还是使用诸如XPath之类的应用程序-他们都需要提取数据并对其进行一些业务逻辑。 唯一不需要执行此操作的应用程序是最终使用XML作为其唯一数据模型的应用程序。
以此方式来看，我们可以根据对以下问题的回答来选择数据绑定：在xml信息集的易用性和保留性之间最好的平衡是什么？ 答案是“取决于情况”。 我觉得对于大多数应用程序，JAXB达到了最佳效果。 它创建非常简单的POJO，因此非常易于使用。 它向用户隐藏了许多平凡/容易出错的XML处理任务。 它适用于大多数（如果不是全部）架构。 而且，如果您遵循正确的架构版本控制做法，那么最终将获得一个非常健壮的，长期存在的服务，该服务将遵守您的合同。
我们确实支持其他几种数据绑定方式。 您可以通过“ StAX数据绑定”访问原始XML流。 还有从XFire继承的Aegis数据绑定，这使得从几乎任何代码中构建模式/ WSDL变得容易。 它支持许多替代数据类型，例如Maps或java.sql.Date。 我们支持JAX-WS Provider，使您可以将XML消息作为Source对象使用。 我们也希望为我们的下一个版本提供XMLBeans和JiBX支持。
Arjen Poutsma（Spring-WS） ：数据绑定，或者我更喜欢称之为对象/ XML映射，可能非常方便，但是却为一系列互操作性问题打开了大门。 事实是Java语言和XML语言完全不同，并且只要两者之间发生转换，就会出问题。 以XSD日期和java.util.Calendar之间的差异为例。 通常，XSD日期“ 2007-09-14”将转换为表示当地时区午夜9月14日的日历。 如果将该Calendar转换回XML，则不会以开始时的XSD日期作为结束日期，而可能以dateTime结尾。
但是正如我之前所说，OXM可以非常方便。 因此，Spring-WS以JAXB 1和2，Castor，XMLBeans，JibX和XStream的形式支持它，但如果需要，还提供对原始XML消息的访问。
Thomas Diesler（JBossWS） ：我们有一个SOAP内容元素的概念，它是与数据绑定相关的消息部分的抽象视图。 客户端代码可以本地获取XML（DOM），Java（JAXB）或SAAJ的内容。
川口浩辅（Metro） ：我认为没有人不同意数据绑定在许多情况下都是有用的，因此我们当然会在Metro中提供数据绑定解决方案。 同样，我认为没有人不同意在许多其他情况下访问原始信息集很有用，因此显然我们在Metro中也提供了这一点。 好，所以首先要谈谈数据绑定。 Metro使用JAXB作为数据绑定解决方案，到目前为止，JAXB仍然是唯一的注释驱动的POJO数据绑定解决方案。 批注的使用使我们能够在单个数据绑定解决方案中同时支持契约优先和代码优先的数据绑定，这并不是每种数据绑定技术都可以说的。 主要专注于JAXB，使我们可以有效地使用我们的项目资源，而不是将我们的开发人员和用户分成每种数据绑定技术的多个筒仓。
现在，像JAXB这样的数据绑定技术存在的问题是您无法访问XML信息集。 尽管在某些情况下具有此功能，但在其他情况下（例如，当处理代码分层时，Web服务实际上仅用作传输层时）或者当您具有自己的特定于域的数据绑定方案时，这将成为问题。
因此，为此，Metro提供了通过JAX-WS访问原始XML信息集的权限。 您可以访问整个SOAP消息，也可以仅访问有效负载部分（如果要使用另一种数据绑定技术插入Metro，这很方便。）您可以使用SAAJ以DOM（如树形结构）访问DOM，也可以将其作为SAX事件进行访问，或者您可以通过StAX解析器访问它。
说到原始信息集访问，我们还致力于向您公开我们有效的内部SOAP消息抽象，以便您可以以更方便，更有效的方式访问SOAP消息。
我想值得一提的另一件事是，通过称为处理程序的机制，我们允许您将两者结合在一起。 也就是说，您可以首先将SOAP消息作为信息集进行访问，以执行一些操作，然后进行数据绑定并执行其他操作。
（5）您如何支持与其他WS实现的互操作性，尤其是.NET / WCF？
Paul Fremantle（Axis2） ：我们的团队参与了W3C，OASIS和Microsoft的互操作性活动，我们以良好的互操作性测试记录而感到自豪。 我们试图尽快解决所有与互操作性相关的问题，无论是修复我们自己的错误还是解决其他实现的已发布版本中的问题。 除了用于特定标准的各个互操作之外，我们还针对某些特定的配置文件与.NET / WCF进行了互操作，尤其是与Binary（MTOM，WSRM和WSSecurity一起使用）的Secure Reliable。 根据我们的测试，我们认为我们是最可互操作的堆栈之一。
Dan Diephouse（CXF） ：对用户而言，共有三个级别的互操作性测试对您很重要：
数据绑定：多年来，JAXB和Aegis实现已通过.NET / WCF进行了良好的测试。 我相信两个人都已经4岁了。
BasicProfile / SOAP：在此级别上，我们正在关注确保已遵循BasicProfile标准中提出的主张和最佳实践。 如果遵循这些准则，则可以保证与.NET / WCF等其他框架的良好互操作性。 但是，我们还使用.NET / WCF测试我们的服务-尤其是在诸如MTOM之类的较难互操作性区域。
WS- ：每种WS-规范都有其自己的内容，因此这里的故事将根据规范，其寿命和复杂性而有所不同。 例如WS-Security，我们使用Apache WSS4J框架，该框架已经由社区和许多使用它构建产品的组织与.NET进行了广泛的测试。 社区成员，尤其是IONA，也在发行周期的各个时间点都与WCF进行集成测试。 这不仅测试WS- *级别，还测试所有较低的级别。
Arjen Poutsma（Spring-WS） ：Spring Web Services的合同优先方法的优点之一是服务开发人员可以直接解决与其他平台的互操作性问题。 这意味着您不必“说服” SOAP引擎使用一个特定的XSD构造而不是另一个，因为它不与.NET平台互操作。 相反，您可以直接选择可互操作的结构。
Spring-WS附带的示例应用程序说明了这种方法。 这些示例显示了与Microsoft .NET 1.1，WSE 2.0和WCF的互操作性。
Thomas Diesler（JBossWS） ：我们定期参加MSFT互操作研讨会，并积极维护多个互操作端点（http://jbossws.demo.jboss.com:8080/interop/和http：//jbossws.demo.jboss。 com：8080 / jbossws / services）
川口浩辅（地铁） ：
Metro拥有庞大的敬业团队，他们的全部工作就是确保与.NET的互操作性。 正如我之前写的，事实是，通过正确的设计，您不能简单地实现互操作性。 相反，这是测试人员孜孜不倦的辛勤工作的结果。 同样，大多数工作是WSIT工作的一部分，现在已经成为Metro的组成部分。
因此，在Metro中，我们为每个WS- *模块设置了一系列测试，并不断与Microsoft端点运行互操作测试。 至少每天晚上运行一次，以确保没有回归，这是我们拥有的发布标准之一-除非所有测试通过，否则我们不会发布Metro。
我们一直与Microsoft紧密合作。 每周召开一次经理级会议，讨论各种问题，并举行各种工程师级会议，讨论并解决问题。 我们中的许多人多次去雷德蒙德参加互操作研讨会。 我们甚至邀请了一个Microsoft员工参加JavaOne主题演讲，并演示了我们的互操作性。
我们还特别注意与其他Java和非Java工具包之间的互操作相关问题，尽管我认为我们没有听到太多。 在接受损坏的输入时，我们也往往会非常宽容，并且对我们的产品更严格，这也增加了实现平滑互操作性的机会。
总而言之，我认为可以说我们在确保互操作性方面付出了真正的努力。 并且，由于W3C，WS-I的辛勤工作以及所有Web服务工具包的测试人员的努力，Web服务的整体互操作性状况已经走了很长一段路，并且这已经证明了。
（6）您对REST的立场是什么？ 您提供任何种类的REST支持吗？
保罗·弗里曼特尔（Axis2） ：支持REST有多个级别。 首先，我们有一种简单的方法，允许开发人员在任何传输方式（包括HTTP GET和POST）上执行“普通旧XML”。 它与POJO开箱即用，因此简单的XML / HTTP方案很容易。 其次，我们是唯一完全支持WSDL 2.0 HTTP绑定的WS工具包。 使用该绑定，几乎可以完全描述任何RESTful服务-例如，我们已经完成了对Atom Publishing协议的完整描述。 因此，在处理URI，在URI中进出数据，支持所有HTTP操作，在有效负载中进出数据的级别上，我们现在完全符合REST。
我们尚未攻击的REST领域之一被称为“作为应用程序状态引擎的超媒体”。 也就是说，我们现在不提供任何框架支持来处理创建具有链接的消息并正确处理这些链接。 这个（公认的难题！）问题完全留给了应用程序作者。 关于此的讨论很多，我们希望将来在RESTy方向上做更多的实验。
Dan Diephouse（CXF） ：我相信REST是构建服务的好方法。 作为一种体系结构，它具有强大的功能，但是不幸的是，它经常被误解或根本不被理解。
CXF有几个工具可帮助您构建RESTful服务。 我们有一个XML over HTTP绑定，它允许您将SOAP Web服务变成简单的Plain Ol'XML服务。 我们支持使用注释和URI模板（例如@HttpResource（“ / foo / {bar}”））将服务操作映射到资源。 我们还支持基于约定的机制，通过该机制，您的服务将被智能地转化为资源。 例如，类似getPurchaseOrder（long id）的方法将智能地映射到资源/ purchaseOrders / {id}上的GET请求。 关于JSR 311规范，还有一些工作和讨论。
Arjen Poutsma（Spring-WS） ：我认为REST是SOAP，WS- *和Plain Old XML（POX）的有趣替代。 它通过基于成熟的HTTP技术解决了WS- *空间中的许多问题。 但是，我认为REST与SOAP一样，甚至更具限制性。 编写REST服务时，您必须对要公开的资源有一个清晰的了解，它们支持哪些数据格式（REST不仅与XML有关！），对它们支持的HTTP方法，以及它们所支持的内容意思。 所有这些也必须清楚地记录在案； HTTP规范不足以实现此目的，并且我不确定WADL是否是答案。
Spring Web Services目前不支持REST编程模型，但是它将在明年年初发布的2.0版本中添加。 REST与SOAP和POX有很大的不同，例如，始终没有XML消息传入。 我们不想通过从HTTP请求创建XML消息，然后将其发送到管道中（在三毫秒后再次对其进行解析）来支持REST：这太昂贵了。 相反，我们将基于Spring Web框架提供REST支持。
Thomas Diesler（JBossWS） ：我们积极参与JSR 311，并通过Metro集成支持REST。
川口浩辅（Metro） ：就我个人而言，我非常喜欢REST。 我的其他一些项目（例如Hudson）完全基于REST。 但是我遇到的REST问题是，就像任何新技术一样，用户通常对REST有不同的理解，因此当他们说“您是否进行REST？”时， 我们需要对所讲的内容保持谨慎（作为一个例子，你们当中有多少人听说有人说“我做了我的RESTful XYZ”而其他人则大喊非REST？）
当我们将REST视为新兴技术时，当前的REST支持工作正在我们的姊妹项目Jersey中进行 。 泽西岛将REST包含在内，即使这意味着要摆脱Metro的传统编程模型。 我认为这是对的，因为如果您将REST发挥其逻辑作用，则它实际上是一种不同的编程模型。 只是以零碎的方式向现有SOAP编程模型中添加一些类似REST的功能（例如URI模板）就不会削减它。 对于REST的主要吸引力是摆脱SOAP复杂性的那些用户，这也很好地工作。
但是，展望未来，我认为我们将花大力气将Jersey纳入Metro的一部分。 我认为我们是否可以在SOAP和REST编程模型之间引入某种集成和统一性，或者它们是否真的有本质区别，将是一件很有趣的事情。
（7）您的框架成熟度如何？ 您是否可以参考任何案例研究，是否有任何依赖它的商业或开源产品？
保罗·弗里曼特尔（Axis2） ：Axis2肯定已经可以生产了。 我们定期进行浸泡测试，内存使用情况和性能测试。 您可以在这里阅读其中的一些内容：http：//wso2.org/library/588。
Axis2在许多其他框架和产品中使用，包括：Eclipse WebTools项目，Apache Geronimo，Apache Tuscany，Apache ODE，IBM WebSphere 6.01，SoapKnox，Apache Synapse，WSO2 Web服务应用程序服务器，WSO2 ESB，Intalio BPMS等。
Dan Diephouse（CXF） ：CXF历史悠久。 它基于4年前开始的XFire和也几年前开始的Celtix。 这两个项目都继承了很多代码，这有助于创建一个稳定/成熟的项目。 尽管我们仍然存在错误，但我们相信经常发布，并与用户保持紧密的反馈周期。 我们在7月发布了2.0版本，并将很快发布2.0.2。
我已经看到CXF进行了几次部署（不幸的是，由于机密，我无法谈论它们）。 也有许多与之集成的开源项目。 Mule（http://mule.codehaus.org）具有一个CXF连接器，MuleSource在商业上支持该连接器。 ServiceMix（http://incubator.apache.org/servicemix）也具有CXF集成，IONA通过捆绑称为FUSE的ServiceMix / CXF来支持CXF集成。 Guillaume Alleon创建了一个Groovy Web服务（http://docs.codehaus.org/display/GROOVY/GroovyWS）项目项目，该项目使使用Groovy构建服务和无需WSDL-> Code步骤即可调用服务成为可能。 我相信其他几个项目也正在忙于从XFire迁移到CXF，例如Enunciate（http://enunciate.codehaus.org）。
Arjen Poutsma（Spring-WS） ：8月，我们发布了Spring Web Services 1.0。 在发布此版本之前，许多人都在使用里程碑，后来又使用了候选版本，因此对其稳定性感到非常满意。 我们花了两年时间才获得1.0版本的事实是由于Interface21拥有高质量的标准。 在今年年底，我们计划发布1.1。 此版本将为其他传输（JMS，电子邮件和其他）带来支持，并增加对WS-Addressing的支持。 Spring-WS 2.0将带来对REST服务的支持。
Thomas Diesler（JBossWS） ：JBossWS产品非常成熟，经过2.5年的持续开发。 根据一项调查，超过60％的JBoss客户群使用JBossWS。
川口晃介（Metro） ：我们已经更改了名称，但是其中很大一部分代码可以追溯到2001年和Java Web服务开发人员包（JWSDP），它赢得了多个奖项，包括2005年“年度Web服务或相关工具” ”和“ 2006年JDJ读者选择奖”的认识，从那时起，基本上就是这场演出的团队。 因此，有大量的代码已在现实世界中使用多年，并由具有丰富经验的人员维护。 如果您包括Metro的前身JAX-RPC，则它是Metro的核心，JAX-WS规范也可以追溯到很久以前。 它始于2001年，在这个行业中5年是很长的时间。 因此，我们再次有了一种经过验证的技术，该技术是根据供应商和用户的反馈构建的。
然后是JAXB。 我已经完成了很多RI工作，现在还完成了规范，所以我可以向您介绍很多有关JAXB RI变得多么普遍的信息。 作为一个恰当的例子，我认为这里讨论的所有其他Web服务工具包都支持JAXB RI。 自从JAXB 2.0推出以来，如果您具有超过10个发行版本的采用水平，那么代码将变得坚如磐石。
关于成熟度，我想我们可以谈谈的另一件事是它要通过的测试量，这是拥有像Sun这样的大型组织支持项目的实力之一。 首先，Metro中的每个组件都要经过一系列测试（通常是3个，称为单元测试，SQE测试和TCK测试）。例如，在JAXB中，我们有1500+个单元测试，220 +个SQE测试和5700+个TCK测试。 一旦将组件集成到Metro中，整个过程将通过附加测试。 这包括对80多种不同平台配置的互操作测试和端到端容器测试。 我们甚至拥有专门用于测试Metro的机器集群。 当我们集成到JDK和GlassFish中时，它们也在针对Metro进行自己的测试。
如此之大的测试不会在一天之内完成–只有我们的悠久历史和数名由多个工程师组成的团队组成的团队致力于以重复，自动化的方式编写和运行测试，才有可能进行测试。 同样，Metro用户不会看到这些东西，但这就是我们在幕后为您提供优质软件的事情。
说到采用，Metro还用于其他许多项目。 如今，Metro的一个子集已在大多数应用服务器中使用，包括GlassFish，WebLogic，WebSphere，甚至在Geronimo中。 它被用作OpenESB以及其商业产品Java Composite Application Platform Suite的传输组件之一。 Sun，BEA和IBM的所有主要Java6 JDK中也使用了类似的Metro子集。 仅此一项就使Metro成为安装最广泛的工具箱，轻松实现了一个数量级。
java jax-ws
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
