We Keep Coding

Bypassing JAX-WS SOAP overhead with JAX-RS/Jersey?

The only web services I've ever integrated with or used have been 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.
With REST, I use a JAX-RS client called Jersey that makes hitting RESTful endpoints a piece a' cake. 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):
// 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. If I understand the setup correctly, the general process is this:
Obtain an XML document called a WSDL from the service provider; this appears to be a language-agnostic description of all the available endpoints
Run a JDK tool called wsimport on the WSDL which actually generates Java source code, which implements JAX-WS APIs and actually represents my SOAP client
Import those generated source files into my project and use them
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? Why couldn't I achieve SOAP-based conversations with Jersey, and bypass all this source-generation boilerplate?
For instance, say the same endpoint exists, but is governed by 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; it's an HTTP "conversation". So why couldn't I hijack a REST framework like Jersey to HTTP POST messages, and in doing so, bypass this SOAP overhead?

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).
RESTful webservices standard, for many purposes is quite amorphous - many businesses prefer the comfort of a contract in the form of a 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. 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

Jersey client creation in a REST service

i am creating a http REST service that consumes other http REST services.
I am using Jersey Client to call other services and i have many doubt about which creation pattern of the http client is the best.
Currently i am using EJB with injection of the client that is a Singleton shared by every methods, but i would like to remove java ee dependency and use Jetty as embedded application server.
I see from the doc that Client creation is an expensive operation so i cannot create one every time i need it.
I think about creating 1 in the constructor of every Servlet/Rest class is the simpler solution but i am not sure about the lifecycle of the servlet (if an instance is created for every request, this method is quite the same as the previous)
Or maybe is better to create a Singleton shared by every Servlet/Rest class
Or maybe better a pool of N client.
About this last two solution i need some advice... What do you think it's the better solution?
Thanks

According to you, there is a REST Service deployed in some environment and there is one application, a client or consumer, which wants to access that service.
If i am writing a normal Java class as client using Jersey API, then i will write something lime this :
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
import com.sun.jersey.api.client.WebResource;
Client client = Client.create();
WebResource webResource = client
.resource("http://localhost:8080/rest/example/employees");
ClientResponse response = webResource.accept("application/json")
.get(ClientResponse.class);
String result = response.getEntity(String.class);
Now say you are writing a servlet, which does some defined job in you application, also it makes a call to the REST Service using client block of code, everytime you access the servlet it will create a instance of com.sun.jersey.api.client.Client each time.
If you want to avoid this then you can create a initial class that will create an instance of com.sun.jersey.api.client.Client, one and only, and make it static and use the same reference where ever you want. WebResource should be created as and when required, because you might be interested to call different URIs.
I would have followed this approach, if i were in your situation.

WebService Client in Java

I have the following problem: I am completely new to java EE (know only about servlets and JSPs) and especially web services.
I need to develop a client for a web service (it needs to query the service for useful information once in a minute).
In my mind this client would be a simple java-SWing-based program, which would query the web service through simple Socket when the application client runs. How can that be done?
Is it possible to do in that way? If not, which is the easiest way to create such a client?

I would suggest using Apache CXF. Simple and powerful framework.
And yes, that is possible to implement what you said using this framework. Just read tutorials and play around for a bit with it.

Inorder to connect to a web service using a java client follow the below mentioned steps:
1. Get the URL in which the webservice is hosted. This is usually of the fomat http://<IP_OF_SERVER>:<PORT_OF_SERVER>/<WEB_APP_NAME>?wsdl
2. Get the qualified name of the service:
// 1st arg is the service URI
// 2nd is the service name published in the WSDL
QName qname = new QName(<Service_URI>, <SERVICE_NAME_PUBLISHED_WSDL>);<br/>
3. Create a factory for the service:
Service service = Service.create(url, qname);
4. Extract the endpoint interface, the service "port":
<Port_Class_Name> eif = service.getPort(<Port_Class_Name>);
5. Now use the methods on the Port, which are the actual methods in your webservice.

You might want to try REST Webservice, try Jersey REST (or others). With rest you can connect it with http connection (GET and POST).

Inorder to connect to a web service using a java client follow the below mentioned steps:
1.URL wsdlUrl = new URL("your wsdl url);
2.QName qname = new QName("targetNamespace in ur wsdl file","service name in your wsdl file");
Service service = Services.create(wsdlUrl,qname);
4.suppose getData() is your SEI
GetData data = (GetData)service.getPort(GetData.class);
5.call the your methods using data object
ex:data.getId(String name); this will return your response

What's a good Java library for dynamic SOAP client operations?

I've been searching for SOAP client libraries for Java and have found a plethora of libraries based on the idea of building stub and proxy classes based on a WSDL. I'm interested in allowing the user to enter a WSDL at runtime, parsing the WSDL, then allowing the user to perform operations on the Web Service.
Does anyone know of a good SOAP client library which will allow this runtime use? Or is there a way I can use the axis2 wsdl2java functionality to build stubs into the classloader and use them at runtime?

Later than never. :)
You should achieve that in two steps:
1) parse the WSDL informed by the user to retrieve the available operations. Refer to this question to know how to do this in a simple way.
2) Create a dynamic client to send a request using the selected operations. It can be done by using the Dispatch API from Apache CXF.
Build the Dispatch object for the dynamic client (It can be created on the fly by informing web service endpoint, port name, etc):
package com.mycompany.demo;
import javax.xml.namespace.QName;
import javax.xml.ws.Service;
public class Client {
public static void main(String args[]) {
QName serviceName = new QName("http://org.apache.cxf", "stockQuoteReporter");
Service s = Service.create(serviceName);
QName portName = new QName("http://org.apache.cxf", "stockQuoteReporterPort");
Dispatch<DOMSource> dispatch = s.createDispatch(portName,
DOMSource.class,
Service.Mode.PAYLOAD);
...
}
}
Construct the request message (In the example below we are using DOMSource):
// Creating a DOMSource Object for the request
DocumentBuilder db = DocumentBuilderFactory.newDocumentBuilder();
Document requestDoc = db.newDocument();
Element root = requestDoc.createElementNS("http://org.apache.cxf/stockExample", "getStockPrice");
root.setNodeValue("DOW");
DOMSource request = new DOMSource(requestDoc);
Invoke the web service
// Dispatch disp created previously
DOMSource response = dispatch.invoke(request);
Recommendations:
Use ((BindingProvider)dispatch).getRequestContext().put("thread.local.request.context", "true"); if you want to make the Dispatch object thread safe.
Cache the Dispatch object for using later, if it is the case. The process o building the object is not for free.
Other Methods
There are other methods for creating dynamic clients, like using CXF dynamic-clients API. You can read in project's index page:
CXF supports several alternatives to allow an application to
communicate with a service without the SEI and data classes
I haven't tried that myself but should worth giving it a try.

JAX-WS vs SAAJ Style, Which to Use

What is difference, philosophical or otherwise, between calling a web service from Java code using Service and Dispatch classes, vs a SOAPConnection class?
For example, something like this:
SOAPConnectionFactory scf = SOAPConnectionFactory.newInstance();
SOAPConnection soapConnection = scf.createConnection();
SOAPMessage reply = soapConnection.call(soapMessage, url);
vs something roughly along these lines?
svc = Service.create(url, serviceName);
Dispatch<SOAPMessage> dispatch = svc.createDispatch(portName, SOAPMessage.class, service.Mode.MESSAGE);
SOAPMessage reply = (SOAPMessage)dispatch.invoke(soapMessage);
What is the difference between these, and why select one approach over the other?

The following line are excerpt from Java SOA Cookbook - O'Reilly
"The SOAP connection allows you to send a SOAP message to a resource at the end of
a URL. This is convenient to use in any situation, but necessary if that service does not
have a defined WSDL. That’s because calling Service.create requires passing in the
location of the WSDL. It may be rare that you don’t have a WSDL with a SOAP-based
service, but it does happen, and you’ll be prepared.
To create a connection to a web service that does not expose a WSDL, you can use the
SOAPConnection class to communicate directly with the remote resource. You then create a URL object representing the remote
resource (servlet) you want to call. Pass the SOAP request message and the endpoint
you want to invoke to the call method on your connection object, and then wait for
it to return a SOAP response.
• The endpoint URL passed to the connection.call method can be either a string or
a java.net.URL."

I have a feeling that at the end, the Dispatch simply delegates the actions to a SAAJ layer. However, I haven't been able to confirm that.
From the perspective of what's a better practice, then i feel the Dispatch methodology is more appropriate since it abstracts away some of the overheads of working with the lower level SAAJConnection API. Like - there's no need to do a close() on the connection instance, the dispatch reference need not be re-created unlike the SOAPConnection instance.