Building Web Services with CXF
This page describes how to build a CXF web service and use it in Mule.
Mule provides three ways to build a web service.
- Use the JAX-WS front end to build a code-first web service employing the standard JAX-WS annotations with the JAXB databinding
- Use the JAX-WS front end to build a WSDL-first web service
- Use the "simple" front end in CXF to create a web service from simple POJOs
Creating a JAX-WS Service
The JAX-WS specification defines a series of APIs and annotations that help you build web services. This section describes how to create a very simple JAX-WS web service.
You begin by writing the service interface. As the following sample shows, you can write an operation called "sayHello" to greet anyone who submits his or her name through a web browser:
Your implementation of the Web service interface will look like this:
Configuring the Service
To configure Mule to use the service, simply declare your service and use a CXF endpoint as shown in the following example:
Navigate to "http://localhost:63081/hello?wsdl", which displays the WSDL generated by CXF.
To use a POJO instead of an annotated JAX-WS service, host the POJO as a component in Mule, then use the simple front-end client with its CXF inbound endpoint.
Injecting Resources into JAX-WS Services
If you need to access JAX-WS resources, you can have them injected into your service implementation class. Simply add an annotated field such as this:
To implement injection into your service class, declare it as a Spring bean so that the CXF processor can perform the injection.
If your component and the injection execute on different threads, limitations in CXF cause the injection to fail. In practical terms, this prevents you from using injection with the following:
Creating a WSDL First JAX-WS Service
In addition to the code-first approach outlined above, you can also use CXF to implement WSDL-first services. The CXF distribution includes many additional examples of how to do this.
Next, write a service implementation class that implements your service interface, then use this implementation class in the Mule configuration exactly as in the previous example.
Supplying the Original WSDL to CXF
You can specify your original WSDL to CXF by using the @WebService attribute:
Another approach involves specifying the wsdlLocation property on the endpoint:
CXF is able to locate this WSDL inside your webapp, on the classpath, or within the file system.
Creating a Simple Front-end Web Service
A simple front end allows you to create web services which don't require annotation. First, you write the service interface. As in the example above, you could write an operation called "sayHello" that says "Hello" to anyone who submits his or her name.
You can use an implementation class instead of a service interface, although the service interface makes it easier to consume the service. See Consuming Web Services for more information.
Your implementation would then look like this:
Configuring the service
To configure Mule to use the service, simply declare your service and use a CXF message processor as shown in the following example:
If you go to "http://localhost:63081/hello?wsdl", you will see the WSDL that CXF generates.
Validation of Messages
The following code enables schema validation for incoming messages by adding a validationEnabled attribute to your service declaration:
Changing the Data Binding
You can use the databinding property on an endpoint to configure the databinding that will be used with that service. The following databinding types are available through CXF:
- JAXBDatabinding (Default)
The following code specifies the databinding class:
The <cxf:databinding> element can be used with any CXF front end.
Setting the Binding URI
The bindingUri attribute specifies how your service operations are mapped to resources. You configure this attribute as follows:
Changing the Default Message Style
By default, CXF uses the Document/Literal message style. However, you can change the service to be exposed as RPC (instead of as a document) or configure it to send complex types as
wrapped instead of
literal. To change the message style, set the @SOAPBinding annotation on the service's interface, specifying the following:
In the following example, the parameter style is set to BARE. This means that each parameter is placed into the message body as a child element of the message root. This is WRAPPED by default.
For more information on the supported message styles, consult: Optional Annotations.