4. Basic Webservices – Web Service Style
A web service is a service which uses a set of web standards (e.g., HTTP, SOAP, JSON,
etc...,) to expose its interface to its clients and interact with them. Two main web
service flavors are:
WS-*
RESTful
With WS-* web services, a client application utilize XML messages using the SOAP
standard. Such a request is recognized by the web service and returns a response to
the client. If a client does not know what operations a web service provides, then the
WSDL for the service can be queried to see what operations are supported before
the request is made.
WS-* services can be constructed using various technologies – Axis, CXF and .NET
being the most popular – and clients can also invoke these services using any of
these technologies. Mule enables the use of web services by providing an Axis and a
CXF transport.
RESTful services on the other hand are invoked using a URI and unlike WS-* are not
restricted to use SOAP XML payloads. RESTful services make use
5. Basic Webservices – Web Service Style (Contd)
of the HTTP APIs to expose different services, unlike WS-* which uses a
WSDL to define the API.
Both of these web service styles are typically synchronous, client sends a request
and it expects a response.
Mule and Web Services
6. Mule and Web Services
The diagram here shows how Mule can interact with web services. On the left, we can
see that a third-party item (such as an application) is making a web service call, which
refers to a service that is hosted in Mule. This web service call is nothing more than an
inbound endpoint for the service. By using inbound web service endpoints, Mule can host
web services that are accessible to any other application.
On the right side, we can see that a service in Mule is making a web service call to a third-
party item. This web service call is nothing more than an outbound endpoint for the
service. By using outbound web service endpoints, Mule can connect to web services
hosted by any other application.
7. Web Service Security in Mule
Since REST is dependent on the HTTP transport, it is very simple to use the security layer
of the HTTP to secure a REST service. These include
• HTTPS Transport Level Security
o Authentication using Certs
o Confidentiality (Encryption)
o Integrity
• HTTP Basic Authentication using Spring
When SOAP services are being hosted on HTTP, which is in most cases, the above options
are also available. However, since SOAP services are aimed at being transport neutral,
they also provide a set of standards covered by the WS-* umbrella, some of which are:
• XML Encryption
• XML Signature
With SOAP services, Mule also offers SAML integration for single sign-on.
8. Jersey Framework
In Mule, support for REST is provided through the Jersey module, which leverages the
JAX-RS API to produce and process REST messages.
Using Jersey, the message’s payload is not restricted to any particular structure.
Therefore, payloads such as text, JSON, XML, and binary may be used. However, this
module may only be used in conjunction with the HTTP transport.
REST
REST is an architectural style for accessing information on the web.
In the REST architectural style, information on the server side is considered a resource,
which may be accessed in a uniform way, using web URIs (Uniform Resource Identifiers)
and HTTP.
Since REST uses HTTP as the communication protocol, the REST style is constrained to a
stateless client/server architecture.
9. Jersey Framework - REST
Important HTTP methods:
GET (gets a resource, similar to WWW)
PUT (updates a resource, not commonly found in WWW)
POST (creates a new entry, similar to WWW)
DELETE (removes a resource, not commonly found in WWW)
JAX-RS
JAX-RS uses annotations to build RESTful web services. Annotations, along with the
classes and interfaces provided by the JAX-RS API, allow to expose simple POJOs as
web resources.
There are a number of JAX-RS implementations including Jersey (which is what
Mule uses to provide REST support), Restlet and RESTEasy.
10. Jersey Framework – JAX - RS(Contd)
Eg: Example for how to use these annotations to annotate POJO to be configured later as a REST service.
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
@Path("/")
public class HelloRestComponent {
@GET
@Produces("text/plain")
@Path("/greeting/{name}")
public String greet(@PathParam("name") String input){ return "Hello "+ input; }
}
In the above Java class, we are telling our JAX-RS server that this component should be hosted on the resource
URI “/”, using the @Path annotation, hence if the server is listening on http://localhost:8080/hello, then our
HelloRestComponent will be listening on http://localhost:8080/hello/. The greet() method is annotated as a
GET method, and with the @Path having a value of /greeting/{name}. This means that when the client asks for
the resource http://localhost:8080/hello/greeting/mule, the greet() method will be invoked passing the mule
parameter from the URI into the input parameter on the greet() method. The mule parameter is injected in the
input parameter through the @PathParam annotation.
11. Deploying the JAX-RS service in Mule
Deploying the JAX-RS service in Mule
Exposing a REST service in Mule is as easy as configuring an HTTP inbound
endpoint followed by a Jersey resource element containing the
component as shown here:
Eg:
<flow name="RestHelloFlow">
<http:inbound-endpoint address="http://localhost:8080/hello" />
<jersey:resources> <component class="com...HelloRestComponent" /> </jersey:resources>
</flow>
If the flow is not going to be followed by other message processors
following the Jersey resource, then use a shortcut configuration to
configure your service:
Eg:
<simple-service name="RestHelloService" component-class="com...HelloRestComponent" type="jax-rs"
address=" http://localhost:8080/hello"/>