Chapter 35. Pojo-Based Route
35.1. Processing Messages in POJO Format
By default, the Camel CXF component marshals incoming Web service requests into the POJO data form, where the In message body is encoded as a list of Java objects (one for each operation parameter). The POJO data format has advantages and disadvantages, as follows:
- The big advantage of the POJO data format is that the operation parameters are encoded using the JAX-B standard, which makes them easy to manipulate in Java.
- The downside of the POJO data format, on the other hand, is that it requires that the WSDL metadata is converted to Java in advance (as defined by the JAX-WS and JAX-B mappings) and compiled into your application. This means that a POJO-based route is not very dynamic.
The code presented in this chapter is taken from the following demonstration:
For details of how to download and install the demonstration code, see Chapter 31, Demonstration Code for Camel/CXF
Camel CXF component
The Camel CXF component is an Apache CXF component that integrates Web services with routes. You can use it either to instantiate consumer endpoints (at the start of a route), which behave like Web service instances, or to instantiate producer endpoints (at any other points in the route), which behave like WS clients.
Camel CXF endpoints—which are instantiated using the
cxf:cxfEndpoint XML element and are implemented by the Apache Camel project—are not to be confused with the Apache CXF JAX-WS endpoints—which are instantiated using the
jaxws:endpoint XML element and are implemented by the Apache CXF project.
POJO data format
POJO data format is the default data format used by the Camel CXF component and it has the following characteristics:
- JAX-WS and JAX-B stub code (as generated from the WSDL contract) must be provided.
- The SOAP body is marshalled into a list of Java objects.
- One Java object for each part or parameter of the corresponding WSDL operation.
- The type of the message body is
- The SOAP headers are converted into headers in the exchange's In message.
Implementing and building a POJO route
To implement and build the demonstration POJO-based route, starting from scratch, you would perform the following steps:
- Obtain a copy of the WSDL contract that is to be integrated into the route.
- Generate the Java stub code from the WSDL contract using a WSDL-to-Java converter. This gives you the SEI,
CustomerService, and its related classes, such as
- Instantiate the Camel CXF endpoint in Spring, using the
- Implement the route in XML, where you can use the content-based router to sort requests by operation name.
- Implement the operation processor beans, which are responsible for processing each operation. When implementing these beans, the message contents must be accessed in POJO data format.
Sample POJO route
Figure 35.1, “Sample POJO Route” shows an outline of the route that is used to process the operations of the
CustomerService Web service using the POJO data format. After sorting the request messages by operation name, an operation-specific processor bean reads the incoming request parameters and then generates a response in the POJO data format.
Figure 35.1. Sample POJO Route