The simplest way to proxy a SOAP/HTTP Web service is to treat the request and reply messages as HTTP packets. This type of proxying can be used where there is no requirement to read or modify the messages passing through the route. For example, you could use this kind of proxying to apply various patterns of flow control on the WS messges.
Figure 8.1 shows an overview of how to proxy a Web service using an Apache Camel route, where the route treats the messages as HTTP packets. The key feature of this route is that both the consumer endpoint (at the start of the route) and the producer endpoint (at the end of the route) must be compatible with the HTTP packet format.
The following Apache Camel endpoints can be used as consumer endoints for HTTP format messages:
Jetty endpoint—is a lightweight Web server. You can use Jetty to handle messages for any HTTP-based protocol, including the commonly-used Web service SOAP/HTTP protocol.
Camel CXF endpoint in MESSAGE mode—when a Camel CXF endpoint is used in MESSAGE mode, the body of the exchange message is the raw message received from the transport layer (which is HTTP). In other words, the Camel CXF endpoint in MESSAGE mode is equivalent to a Jetty endpoint in the case of HTTP-based protocols.
A Jetty endpoint has the general form,
jetty:. To configure the Jetty
endpoint to be a proxy for a Web service, use a
HttpAddressHttpAddressHttpAddress0.0.0.0 (which matches all of the network interfaces on
the current machine).
<route>
<from uri="jetty:http://0.0.0.0:9093/Customers?matchOnUriPrefix=true"/>
...
</route>Normally, a Jetty consumer endpoint accepts only an exact match on
the context path. For example, a request that is sent to the address
http://localhost:9093/Customers would be accepted, but a request sent to
http://localhost:9093/Customers/Foo would be rejected. By setting
matchOnUriPrefix to true, however, you enable a kind of
wildcarding on the context path, so that any context path prefixed by
/Customers is accepted.
The following Apache Camel endpoints can be used as producer endoints for HTTP format messages:
Jetty HTTP client endpoint—(recommended) the Jetty library implements a HTTP client. In particular, the Jetty HTTP client features support for
HttpClientthread pools, which means that the Jetty implementation scales particularly well.HTTP endpoint—the HTTP endpoint implements a HTTP client based on the
HttpClient3.x API.HTTP4 endpoint—the HTTP endpoint implements a HTTP client based on the
HttpClient4.x API.
To configure a Jetty HTTP endpoint to send HTTP requests to a remote SOAP/HTTP Web
service, set the uri attribute of the to element at the end of the
route to be the address of the remote Web service, as follows:
<route>
...
<to uri="jetty:http://localhost:8083/Customers?bridgeEndpoint=true&throwExceptionOnFailure=false"/>
</route>The HTTP component supports a bridgeEndpoint option, which you can enable
on a HTTP producer endpoint to configure the endpoint appropriately for operating in a
HTTP-to-HTTP bridge (as is the case in this demonstration). In particular, when
bridgeEndpoint=true, the HTTP endpoint ignores the value of the
Exchange.HTTP_URI header, using the HTTP address from the endpoint URI
instead.
 |  |  |
 |
