Making SOAP With Mule Runtime
Making SOAP With Mule Runtime
Writing and consuming SOAP web services in MuleSoft ESB is as simple as writing a couple of lines as code. There are still a lot of SOAP-based web services around.
Join the DZone community and get the full member experience.Join For Free
The new Gartner Critical Capabilities report explains how APIs and microservices enable digital leaders to deliver better B2B, open banking and mobile projects.
Today, we will be talking about how to use SOAP APIs with the Mulesoft ESB AnyPoint platform. SOAP-based web services have been around for a long time. With the recent advances in REST web services, most of us are moving towards REST — but there are still a lot of SOAP-based web services around. When we work in integration, sooner or later, we will come face-to-face with either writing or consuming SOAP services. Doing these two in MuleSoft ESB is as simple as a putting few lines of code and we will be done.
I will not be going into details about SOAP. Rather, I will concentrate on creating. In the next part of this blog, we will see how to consume SOAP in Mule runtime.
Let's start by creating a simple service and then by consuming it in Mule runtime.
Publishing SOAP Services
Mule runtime uses the Apache open-source CXF framework to build SOAP APIs. We can create a CXF API in Anypoint Studio by configuring a CXF component in our Mule flow to perform any of the following CXF operations related to publishing a SOAP API:
- Publish a simple service.
- Publish a JAX-WS service.
- Proxy a published service.
There are three main parts of exposing the SOAP API in Mule runtime using CXF.
1. Inbound Endpoint Element
It receives requests and sends responses, both containing XML SOAP envelopes. Some of the valid endpoints are HTTP, HTTPS, JMS, and VM.
2. CXF Component
SOAP web services are exposed using WSDL (web service descriptive language). WSDL is a contract between client and server. A WSDL can be accessed by adding
?wsdl to the APIs URL when performing a request.
Through CXF, you present a WSDL contract using one of the following methods:
- WSDL-first. Start with a WSDL file that you created yourself, import it into your Mule project, then reference its location from the CXF component.
- Code-first. Start with an annotated Java class, then have JAX-WS compile a WSDL file based on it.
The CXF component is implemented as annotations on Java classes. There is a direct relationship between the WSDL structure and the Java annotations needed. When you use a WSDL, Java POJOs are generated with the correct annotations. You can also force an existing Java POJO to adhere to a WSDL spec. The Anypoint Studio can also create flows to act as SOAP clients.
3. Other Component
This component is simply a combination of components that performs the operations on the API.
The Java Interface
The interface should be annotated with
javax.jws.WebService. This is the only thing you need to do to the interface that creates the contract of your web service.
The Java Class
The next remaining thing is to implement the service class and give an implemenation to your web service.
This implementation class is where you put all the business logic of your web service. As shown in above image I have put various method with different types of input arguments.
Now let's start the project and see how the WSDL file looks and how can we access it: http://localhost:63081/hello?wsdl.
With this, we are done with creating the SOAP-based web service server. In the next blog, I will show how we can use this web service and create a client for it using Mule runtime.
Let me know what you think!
Opinions expressed by DZone contributors are their own.