CXF: getting SOAP request and response XML on the client-side - java

I'd like to have a CXF client which allows me to see the SOAP XML request made and response received.
Use case: I'm writing a test GUI for the service for people who don't have access to my CXF service's logs to get an idea what the SOAP requests need to look like and what gets returned. (Since the interface is rather complicated, a generic / dynamic GUI like SOAP UI isn't helpful).
I've already read about CXF interceptors and know how I could hook them to my client (one for the "receive" and one for the "send" phase). But I can't think of a way of making the interceptor pass the request/response XML somehow back to the client's request.
Any suggestions / ideas?

You should take a look at the code of org.apache.cxf.interceptor.Logging{In|Out}Interceptor.

Related

SoapUI - Automatic client generation with custom headers in request methods

I need to add custom headers into my requests to a web service soap.
Using SOAPUI (with axis2) I have created the client application (Java) that invokes a Web Service.
Autogenerated methods does not give the opportunity to add custom headers to the requests.
But I need to update my client application by adding client-side SOAP message some custom headers to these autogenerated request methods.
So, I've added this to my wsdl:
<soap:Header>
<header1>value1</header1>
<header2>value2</header2>
<header3>value3</header3>
</soap:Header>
And tried again to generate client code. Unfortunately it didn't work, my methods still don't give me the ability to add headers.
Is it possible to do this automatically using SOAPUI? Maybe with some option while setting client code generation...
I hope I've been clear in explaining the problem.
Thanks for any help!

Creating SOAP WS in Java and get the request as a String

I was wondering if it was actually possible to create a Java SOAP Webservice without using it's WSDL.
Context:
The idea is that I have to mock a webservice, so I have its WSDL. The mock will only read the soap request, search if there are any similar request (as key in a map) and send the matching response (as its value). This is for automated testing purpose. The problem is not the "map" part.
Anyway, I've been using Axis and eclipse to generate classes and files and load them in tomcat from the WSDL. So far it've been a mess, with a lot of compatibility issues between these components. And it's gonna be much more difficult to compare the input or serialize the output to do what I want this way.
I thought about creating a REST endpoint and send the soap request through it (so I would directly get the SOAP request !), but I rode somewhere that soap request weren't valid and wouldn't be retreived by the REST endpoint... Also, won't the client application throw an error if there is no WSDL at this address ?
My question is:
Is there a way to create an access point, that looks like a SOAP Webservice (from clients), but which allows me to get the full soap request (as a String for example) and send a response (still as a String) inside a Java app?
Complements:
I'm looking for something, a library, maybe just an annotation on Servlets, that doesn't needs (if possible) to generate a huge load of classes and xml files everywhere. The app would be running on tomcat (but I can be a basic Java app). Using maven and spring wouldn't be a problem.
Thanks in advance !
Normally, clients do not require an WSDL. But it is a nice feature - use a normal servlet and handle the "?WSDL" manually. Then use some simple XPath or parse logic to extract the payload as a DOM document.

Soap webservice request vs HTTP POST request?

I am coming from servlet/web application world and started learning web services(SOAP based). I have gone through some of the webservice
tutorials. I am trying to draw the parallel between normal http request and webservice request. Here are my observations ;-
1)Both are HTTP request. Webservice is a also post request which contains soap envelope as request body. Soap envelope
is just a normal xml which contains the data
2)java Stub internally marshal the XML , creates HTTP request and send it to consumer
3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service.
Is my observation correct ? I know there may be other complexities but i tried to put the comparison in simple manner.
Your assumptions are generally correct. Yet, the subtelties can lead to huge differences.
Claim 1 : both are HTTP.
SOAP is generally used with an HTTP "binding". Yet it does not have to be that way. SOAP is designed to be fairly transport agnostic. It is not uncommon to have SOAP being used over JMS (although one might consider this an overuse of JMS, and an over architected protocol), it is certainly in production in many places. Rarely seen are SOAP/SMTP or SOAP/TCP without HTTP, but these exist too.
Webservice is a also post request which contains soap envelope as request body
A SOAP call over HTTP is a POST request. It may not be of content-type xml, though, as some variants such as SwA (SOAP with attachments) or XOP+MTOM variants may produce HTTP payloads that are MIME/Multipart (the first part of which is the SOAP Enveloppe in its pure XML form).
This use cas is most common when on is to send large binary content over a SOAP Call, and for which binary encoding may add a large weight to the request (base64 is a 1.3x factor in weight).
java Stub internally marshal the XML, creates HTTP request and send it to consumer
That is the usual way it is done, Axis framework and JAXWS frameworks work primarily this way.
The older SAAJ API, a standard EE API, requires you to build your SOAP Message by hand, using the DOM APIs, (see SOAPMessageFactory), and then send it.
If you look at Spring WS, you'll have something close to your claim, but where each part is fairly exposed and in your control (you may elect to build certain calls with a DOM Api, others by using JAXB marshalling, ...).
3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service
Again, this is how things generaly work. But you can also have an implementation that works outside a servlet container. (See Endpoint Service API in JAX WS).
Your assumptions are right:-
Yes, Servlet request and Web service request both are normal HTTP request and yes, SOAP web service internally use HTTP POST.
Yes,java internally marshal the XML. Also, at client end one java web service client(may be a wrapped in servlet) un-marshal it. A SOAP message or SOAP type web service has many characteristics like:-
SOAP message mostly send data using XML format. XMLs are technology independent. So, SOAP can interact with two heterogeneous web applications built in two separate technologies and exchange data using XML.
SOAP web services send XML using HTTP protocol. Data are sent wrapped in an XML using the payload of HTTP.
SOAP web services can be secured. For an example, all the payment related transactions using credit card and bank info are done using secured SOAP web services.
A SOAP web service accepts XML in request and returns XML in response. In case of errors this return XMLs can also contain SOAP faults. SOAP faults contain the description of error and an error code.
Web services can carry attachment document also like PDF, Word etc. with its XML payload. Java provides separate API for this type of web services. There is an API available in java called SAAJ to accomplish this.
I think that you can find a very good response in this blog post by Ben Klopfer.
Mainly the difference between XML/SOAP vs HTTP/REST is that the former is most response verbose while the latter is lighter.
But this is not the only aspect you have to take into account.
REST represents the state of the resource and is a little bit easier to use and to understand, and always remember that it comes afterwards compared to SOAP.
In addition SOAP it is not limited to using HTTP/HTTPS, but can be also used with other transports like SMTP, JMS, etc.
Resuming the post reminds you:
Use SOAP when:
All you need is simple operations, like read only methods
Implementing a one-way or one-object service for something like data exchange or transfer
You want finer control over the specific transport of data, or can’t always use HTTP
Rigid specifications need to be enforced on incoming requests, and you want to minimize additional documentation needed for use
You can rely on client ability to parse XML, or more preferably SOAP itself
You need built-in error handling when things go wrong with requests
Use REST when:
Operations are complex, like create/read/update/delete on objects
Implementing a multi-faceted service for a variety of different objects
You want to easily and quickly target a variety of consumer end user devices as clients
Requests are generally stateless, like call and response compared to a conversation
Your clients may have limited bandwidth or processing power
You can leave it up to the client to get their requests correct and to deal with problems

How to get xml request and xml response from netbeans client to ws

I have created web-service client to the existing service in netbeans, and ide makes all in oop style correctly, but I need to log xml request and response to and from service, how to log these information?
For the purpose of logging the request and response of your web service, you need to create your custom soap handler for JAX-WS which implements SOAPHandler<SOAPMessageContext> interface.
The method to do anything you like with a message is handleMessage(SAOPMessageContext messageContext). From the message context you will be able to get the SOAP message and log it.
See my post here how to implement SOAP handler interface and override handleMessage method for the specific requirements.
This post leads to what you are trying to achieve.
Take a look at this article. It might be helpful as well. If you are not able to set up your handler, come back with more specific problem.

It there any standard way to redirect SOAP request?

The problem is following:
Some client tries to access an SOAP webservce
Webservice implementation anylizes request and comes to conclusion that it is not able to proccess the request itself. However, the webservice knows what some additional webservice should be called instead of one.
???
Client calls "additional webservice" like he did at step 1
It there any specific standard or technique for this?
Use the proper HTTP status code for redirection. A status of 303 See Other comes to mind.

Categories