The Phases in the Inbound chain - When does marshaling occur ?

In our last post we saw a simple Interceptor that read the request and modified it before sending it to our endpoint. The interceptor was executed in the PRE_INVOKE phase

Interceptors in CXF

In an earlier post I used JAX-WS Handlers to modify the soap body and soap headers. The same can be achieved by directly writing CXF Interceptors . Consider our random web service operation that returns a random result. I decided to add an interceptor to modify the SOAP body

The Holder class in JAX-WS. Why and How ?

Consider the operation in the below wsdl file. It talks about a simple Port that has one operation - to update the data received. Nothing fancy about it. The service will return the updated and if necessary modified data.

The Different Type of JAX-WS Handlers available

In the last post we saw how we could use Handlers to access various properties associated with the web service requests and responses. But can we modify them ? I guess it is time the CrazyHandler actually did something crazy !

handleMessage method of Handler being called twice ?

In our previous post we saw how a handler is invoked with CXF. We also saw that our handler was invoked twice - once as a part of the inbound flow and once as a part of the outbound flow. There is a slight problem here. The same handleMessage method of the same Handler instance is used in both cases - which means the same code executes twice!

Handlers and Interceptors in CXF - Are they related ?

I have been trying out some things in CXF (and also feeling pretty good about it :P ) The other day I needed to modify the message of more than one web service in a common manner. I achieved the same using a CXF interceptor. However another team member did the same task using Handlers. Interestingly Handler is more a part of the JAX-WS vocabulary than Interceptor. So I decided to look at this option too.

SOAP Action Header

How does a simple WSDL file look?
There will be a portType element that is like an interface definition of the web-service. It would tell us :

SOAP Header at Client

In the previous post we saw CXF endpoints could set a soap header in the response. But what if the server needs to process a soap header ? The CXF website recommends using interceptors for reading headers. As I still do not have a very clear idea about the concept I decided to look for a different solution.

Headers in SOAP

What is a soap header ?
From w3schools:

The optional SOAP Header element contains application-specific information (like 
authentication, payment, etc) about the SOAP message. If the Header element is 
present, it must be the first child element of the Envelope element. All immediate 
child elements of the Header element must be namespace-qualified.

So the soap message would be something like :

Injecting Dependencies in a CXF Endpoint

We have seen how easy it is to create CXF endpoints. In the previous post on WSDL first web services we had defined server endpoints as:

<jaxws:endpoint id="randomWs"
   implementor="com.ws.service.samplews_ns.SampleServiceOperationsPortTypeImpl"
   address="randomService" />

The "randomWs" endpoint is a CXF endpoint capable of processing SOAP requests, It is also a spring managed bean.

DataBinding Options with CXF

When using CXF, the marshaling and unmarshaling of data happens under the covers. So when we make the call through java, the request is marshaled to XML by CXF client. It sends it over the wire to the server.

Conduits in CXF

If we observe any page request sent by a browser, it will be seen to be composed of multiple headers. Consider the below screenshot taken for a simple AJAX request.

Interceptors and Logging

The CXF architecture provides us with interceptors – or the ability to intercept outgoing request and responses. One useful scenario could be logging. CXF in this case has stayed one step ahead and already built custom Log Interceptors.

Contract First web service with CXF

In the post on Spring web services, I had used a contract first approach for development. This being the only style supported by Spring.
JAX-WS and also CXF on the other hand support both code first and contact first approaches.
I decided to use the same wsdl file from my Spring post:

Building Clients with the CXF API

In the previous posts we saw how to run a CXF application and test the web services using a JAX-WS client. While our previous client was built using classes from the JAX-WS API, there are other ways to execute the code too.

The first CXF Service - 2

In the previous post we created and deployed the Echo webservice. Now to test the same. For this I created a simple client.

The first CXF Service

In the previous post we saw how JAX-WS 's RI implementation could be used to build and interact with web services. I decided to work with one of the other implementations - Apache CXF. I decided to create and run a code first webservice using CXF implementation.

Learning web services

In the various programming environments supported by Java, I have found web-services to be the most difficult to penetrate (That and JNDI) . The thing is there are several web-service providers in the Java community. They all make various claims, add to already vague terminology and almost always leave a novice reader confused.
So when I got a chance to implement web services using Spring's web service framework, I was pleasantly surprised with the well explained Spring docs. And while learning some cool stuff, I also realized that Spring web services is quite different from some of the other implementations.
So when I got the chance today, I decided  to do some investigation on few of these frameworks. I have earlier blogged on how Spring allows us to expose our application as a web service. 
Spring's web service implementation is not related to JAX-WS. Spring's implementation as we saw, only supports contract first development. There are several advantages to the same. In the words of Spring web services creator Arjen Poutsma

SOAP Webservices using Spring -3

As of now we have configured the web service and have also made our contract (or WSDL ) visible to the client. But what happens when the client actually sends a request? How do we handle it?

SOAP Webservices using Spring -2

In the previous example we saw how to set up the application and add the WSDL and XSD files needed. We also configured a MessageDispatcherServlet to handle the operations exposed by our web-service.