[英]Bypassing JAX-WS SOAP overhead with JAX-RS/Jersey?
The only web services I've ever integrated with or used have been RESTful. 我曾经与之集成或使用过的唯一Web服务是RESTful。 I'm now trying to integrate with a 3rd party SOAP service and am awe-struck at how seemingly convoluted SOAP appears to be.
我现在正在尝试与第三方SOAP服务集成,并对SOAP看起来似乎有些费解感到震惊。
With REST, I use a JAX-RS client called Jersey that makes hitting RESTful endpoints a piece a' cake. 在REST中,我使用了一个称为Jersey的JAX-RS客户端,该客户端使RESTful端点的实现成为一个难题。 For instance, if a service is exposing a
POST
endpoint at http://api.example.com/fizz
(say, for upserting Fizz
objects), then in Jersey I might make a service client that looks like this (pseudo-code): 例如,如果某项服务在
http://api.example.com/fizz
公开了一个POST
端点(例如,用于提升Fizz
对象),那么在泽西岛,我可能会制作一个如下所示的服务客户端(伪代码) :
// Groovy pseudo-code
class Fizz {
int type
boolean derps
String uid
}
class FizzClient {
WebResource webResource = initAt("https://api.example.com")
upsertFizz(Fizz fizz) {
webResource.path("fizz").post(fizz)
}
}
But Java-based SOAP clients seem , at first blush, to be fairly more complicated. 但是基于Java的SOAP客户端乍一看似乎要复杂得多。 If I understand the setup correctly, the general process is this:
如果我正确理解安装程序,则一般过程如下:
WSDL
from the service provider; WSDL
的XML文档; this appears to be a language-agnostic description of all the available endpoints wsimport
on the WSDL
which actually generates Java source code, which implements JAX-WS APIs and actually represents my SOAP client WSDL
上运行一个名为wsimport
的JDK工具,该工具实际上会生成Java源代码,该代码实现JAX-WS API,并且实际上代表了我的SOAP客户端 First off, if anything I have said about this process is incorrect, please begin by correcting me! 首先,如果我对这个过程所说的话不正确,请先纠正我! Assuming I'm more or less correct, what I don't understand is: why is this necessary if its all an HTTP conversation?
假设我或多或少是正确的,我不明白的是: 如果这全部是HTTP对话,为什么需要这样做? Why couldn't I achieve SOAP-based conversations with Jersey, and bypass all this source-generation boilerplate?
为什么我不能与Jersey进行基于SOAP的对话,而绕开所有这些源代码生成样板?
For instance, say the same endpoint exists, but is governed by SOAP: 例如,假设存在相同的端点,但是由SOAP来控制:
class FizzClient {
WebResource webResource = initAt("https://api.example.com")
FizzSerializer serializer // I take Fizz instances and turn them into XML
FizzDeserializer deserializer // I take XML and turn them into Fizz instances
upsertFizz(Fizz fizz) {
String xmlFizz = serializer.serialize(fizz)
webResource.path("fizz").post(xmlFizz)
}
}
If I understand SOAP correctly, its just a way of utilizing HTTP verbs and request/response entities to send app-specific messages around; 如果我正确理解SOAP,那只是利用HTTP动词和请求/响应实体来发送特定于应用程序的消息的一种方式。 it's an HTTP "conversation".
这是一个HTTP“对话”。 So why couldn't I hijack a REST framework like Jersey to HTTP POST messages, and in doing so, bypass this SOAP overhead?
那么,为什么我不能将诸如Jersey的REST框架劫持到HTTP POST消息中,而绕过此SOAP开销呢?
This is going to attract opinion-based answers, but first, you should understand that 这将吸引基于意见的答案,但是首先,您应该了解
jax-rs is much younger than jax-ws ( jax-ws had a final draft in 2006 , JAX-RS came out in 2008-9 ). jax-rs比jax-ws小得多( jax-ws 于2006年发布了最终草案 ,JAX-RS于2008-9年问世)。
RESTful webservices standard, for many purposes is quite amorphous - many businesses prefer the comfort of a contract in the form of a WSDL. 出于许多目的,RESTful Web服务标准是完全不稳定的-许多企业更喜欢以WSDL形式签订合同。
Not to mention that JAX-WS, in concert with WS-I provides many other standards that govern security, message reliability and other enterprise-goodies (under the generic "WS-*" banner) that businesses care about. 更不用说JAX-WS与WS-I一起提供了许多其他标准,这些标准管理企业关心的安全性,消息可靠性和其他企业用品(在通用的“ WS- *”旗帜下)。 There's a hodge-podge of libraries that are attempting to get that kind of uniformity on to the jax-rs platform, but for now, jax-ws /WS-I is the industry standard
有各种各样的库正在尝试将这种统一性引入jax-rs平台,但是就目前而言, jax-ws / WS-I是行业标准
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.