Chapter 38. Pojo-Based Route
38.1. Processing Messages in POJO Format
- The big advantage of the POJO data format is that the operation parameters are encoded using the JAXB 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 JAXB mappings) and compiled into your application. This means that a POJO-based route is not very dynamic.
Camel CXF component
cxf:cxfEndpointXML 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:endpointXML element and are implemented by the Apache CXF project.
POJO data format
- JAX-WS and JAXB 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
- 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
CustomerServiceWeb 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 38.1. Sample POJO Route