2. Introduction
Mule ESB allows different integration scenarios using Web
services:
Consuming existing Web services
Building Web services and exposing them to other
applications
Creating a proxy/gateway to existing Web services (for
example, adding security to an existing Web service)
Here we explore in a deeper way what options exist in each of
these scenarios and direct you to other documentation
sources and examples.
3. CXF Module Overview
Before explaining the different Web service scenarios that you
can accomplish using Mule ESB, it is important to understand
that the main technology on which it relies on is Apache CXF.
Apache CXF is an open-source services framework that helps
you build and develop services using front-end programming
APIs, like JAX-WS and JAX-RS. Mule ESB now bundles the CXF
Module that provides Web services integration for consuming
existing Web services and building new ones.
4. Consuming Web Services
If you invoke an existing Web service, you usually build a Web service client to
perform the call. If you have ever experienced this, you will understand it
requires some code generation—you can learn about different ways to
accomplish this with Apache CXF here).
With Mule ESB you can simplify the way Web services can be consumed, but
mainly you have many features out-of-the-box when invoking the service (e.g,
security) and to handle and process the results, such as transformations and
using the results in a complex flow.
Mule ESB provides different alternatives to consume web services:
Generate and use a client from a WSDL
Use a Client Based on the Interface of a JAX-WS Service
Use a client based on the interface of a "simple" frontend web service
Use the JAX-WS Java Client API
5. Generate and use a client from a WSDL
This is a good approach when you need to consume third-
party web services or in other cases where you don’t have the
web service code.
When consuming a web service this way, do the following:
Generate a CXF client using the WSDL to Java tool from CXF or the
Maven plugin.
Configure the client in the Mule configuration XML file using the
<cxf:jaxws-client> component.
Configure an endpoint in the Mule configuration XML file that will be
the transport to request the service (usually HTTP).
6. Use a Client Based on the Interface of a JAX-WS
Service
If you have access to the code used to build the Web service,
you can build a client for your JAX-WS services with no need
to generate a client from the WSDL.
To consume a web service this way, do the following:
Copy your service interface and all your data objects locally.
Configure the client in the Mule configuration XML file using the
<cxf:jaxws-client> component.
Configure an endpoint in the Mule configuration XML file that will be
the transport to request the service (usually HTTP).
7. Use a Client Based on the Interface of a "Simple"
Front-End Web Service
If you are not using the JAX-WS service, you have a copy of your
service interface and all your data objects locally, and the service is
simple enough you may consider building a client for your simple
front end-based services without generating a client from the
WSDL.
In order to consume a Web service this way, do the following:
Copy your service interface and all your data objects locally.
Configure the client in the Mule configuration XML file using the
<cxf:simple-client> component.
Configure an endpoint in the Mule configuration XML file that will be the
transport to request the service (usually HTTP).
8. Use the JAX-WS Java Client API
You can also use a Web service client API to communicate
with Web services outside of Mule configurations. This means
that you can invoke services from within your Java classes that
can then be used from within Mule ESB.
As before, based on whether you will use the WSDL or
whether you’ve built your service via "code-first"
methodologies, there are two ways to use CXF clients:
Use the JAX-WS Client API.
Build a Client Proxy.
9. Exposing Web Services
Mule ESB can be used to host your own Web services. In the
same way you can consume Web services from Mule ESB, you
can also build and expose them. Here are three different ways
to do this:
Create a JAX-WS Service.
Create a WSDL First JAX-WS Service.
Create a Simple Front-End Web Service.
10. Create a JAX-WS Service
The JAX-WS specification is a series of APIs and annotations
to help you build web services. To build and expose a Web
service this way you will need to accomplish the following:
Write a Java class that represent Web services (with the @WebService
annotation) to expose its methods so that they can be invoked
remotely.
Configure the endpoint that will be accepting requests to the Web
service (usually a HTTP inbound endpoint).
Configure the service in the Mule configuration XML file using the
<cxf:jaxws-service> component.
11. Create a WSDL First JAX-WS Service
This is where you first define the WSDL and then code the
web services. To build a Web service this way and configure it
in Mule you should:
Generate your Web service interface from your WSDL using WSDL to
Java tool from CXF or the Maven plugin.
Write the service implementation class that implements your service
interface.
Configure the endpoint that will be accepting requests to the Web
service, usually a HTTP inbound endpoint.
Configure the service in the Mule XML configuration file using the
<cxf:jaxws-service> component.
12. Create a Simple Front-End Web Service
This is the best approach if you want to create a simple Web service
out of an existing POJO. In this way, you need not use annotations,
and though writing an interface is not required, it is recommended as
it will make the Web service easy to consume. To build a Web service
this way and configure it in Mule, do the following:
Use an existing simple Java class (POJO) or write a new one.
Configure the endpoint that will be accepting requests to the Web service
(usually a HTTP inbound endpoint).
Configure the service in the Mule configuration XML file using
the <cxf:jaxws-service> component.
13. Proxying Web Services
Using Mule ESB as a Web service proxy is a feature that you may want to use
when:
You need to add security to an existing 3rd party web service (you don’t have the
code or own the infrastructure).
You need to add or remove HTTP headers.
You need to validate or transform input or output of the Web service.
You may need to transform the SOAP envelope.
You may want to take advantage of the CXF Web service standards support to use
WS-Security, WS-Addressing or to enforce WS-Policy assertions.
Introduce custom error handling.
There are many other scenarios where you may also need to consider proxying
Web services.
You have two types of proxying:
Server-side Proxying
Client-side Proxying