Chapter 37. Pojo-Based Route


37.1. Processing Messages in POJO Format

Overview

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 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.

Demonstration location

The code presented in this chapter is taken from the following demonstration:
cxf-webinars-jboss-fuse-6.2/customer-ws-camel-cxf-pojo
For details of how to download and install the demonstration code, see Chapter 33, 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.
Note
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 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 org.apache.cxf.message.MessageContentsList.
  • 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:
  1. Obtain a copy of the WSDL contract that is to be integrated into the route.
  2. 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 Customer.
  3. Instantiate the Camel CXF endpoint in Spring, using the cxf:cxfEndpoint element.
  4. Implement the route in XML, where you can use the content-based router to sort requests by operation name.
  5. 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 37.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 37.1. Sample POJO Route

Sample POJO Route
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.