Web Services are software components which dynamically interact with other systems. They use an open standard technology based on XML – this allows communication among systems, a feature which makes them unique in the way they work.
Web Services enable the connection among several systems for everyday business financial tasks (orders, invoices, payments and so on). These different functions can be used as construction blocks to build anything. An application can be built by several Web Services dynamically assembled together from different Web sources.
Web Services are reusable components. This means a drastic reduction of the total cost while developing an app. They also represent some standard interfaces among interfaces and they make their connection obsolete through rigid points to point solutions.
However, like any type of very flexible technology, Web Services have quite a bit of complexity and require an architectural approach.
Essentially, an Enterprise Bus Service (ESB) is a middleware application (we have talked thoroughly about it in this article), whose aim is to guarantee interoperability for all the different communication protocols. It is a software infrastructure which works as a middle layer and gives support services to complex SOA architectures. Integration and reuse of services are simplified with a great level of reliability, strength, security, management, flexibility and communication amongst services.
Through an ESB, different services implemented through different technologies can be connected in an easy way. It works as a go-between for different and, often incompatible, middleware products and protocols.
MULE ESB
MULE ESB is MuleSoft development tool that I will use for some examples. The same company also shares a free editor, Anypoint Studio, similar to Eclipse that has two different tools to create applications:
- a visual editor, which enables drag-and-drop of the fundamental components
- an XML editor
Every change done through one editor is automatically translated into the other one.
Let’s have a look at how a standard application can be created:
FLOWS
A flow is a simple mechanism which is, at the same time, very flexible. It allows the orchestration of services using the capacity of messages that flow in there.
A message that enters in a flow can be:
- Validated
- Enriched
- Transformed in a new format
- Elaborated from a custom-coded business logic
- Linked to a database
- Evaluated to determine which answer to give back to whom sent the original message
Elements that create a flow are:
- Connectors – providers of a way of communication for SaaS Services and on-premise applications.
- Scopes – they supply advanced elaborations such as asynchronous invocations, polling, and flows.
- Components – through them a better flow is created: they link functionalities such as logging, output display, secondary flows. They also write business logic that can be used blended together with our chosen scripting language.
- Transformers – they modify the message header or the message payload that is being elaborated within the flow.
- Filters – they can work on their own or together. They define if a message can continue to a specific flow.
- Flow controls – they are used for specifying how the messages are channeled through the several Message processors within a flow. They can also elaborate messages (or aggregate, divide or reorganise) before forwarding them to other message processors.
- Error Handlings – to specify different procedures whilst handling exceptions.
SOME PRACTICAL EXAMPLES
Let’s have a look at some simple examples:
- an easy “Hello World”,
- relational database interrogation,
- creating a message whilst using a Java class,
- using an external REST serviceo.
EXAMPLE 1: HELLO WORLD!
Let’s begin by first altering the payload of a message after joining the port 8081, locally, to path /hello.
We need to create an HTTP Listener config element in the Global Elements domain, which is going to start listening to the 8081 port of our localhost.
The flow will be formed by a Listener (HTTP) which uses the newly created connector which will then identify the path /hello. Using the Set Payload component we can set the message which will be then visualised on the browser.
This is the final result:
EXAMPLE 2: CONNECTING TO A DATABASE
Now we want to interrogate a relational database. We create a new global element (Database config) which will be set up in the following way.
We create a flow with a Listener (HTTP) working on path /getallcustomers. We then insert theDatabase > Select element, which contains the query and which uses the global element we have already created to connect to the database. The browser will display the query result in a JSON format, using a Transform Message (see below).
The result we obtain is the following:
EXAMPLE 3: USING JAVA COMPONENTS
In this example, we want to obtain a random number, created by a method written in a Java class, with the option of passing or not the range we want for the number.
We create a flow which:
- Can listen to the path /generate-random-number .
- With a component Choice you can make sure if parameters mix and max:
a) if it finds min and max, through the Java connector > Invoke static uses method generate number (Double, Double) from the GenerateNumberTransformer class which creates a random number in the past range;
b) without parameters, through the Java connector > Invoke static uses method generateNumber () of the GenerateNumberTransformer class which creates a random number. - The result will be in JSON format.
The flow will be like this:
EXAMPLE 4: REST API
Let’s analyse an external service for weather forecast as our last example:
http://api.openweathermap.org/data/2.5/weather?
here, the GET call needs two parameters: q = name of the city e appid = registration token.
we will then give the name of the city to the path /weather:
http://127.0.0.1:8081/weather?city=Venezia
to get the forecasts for the city of Venice.
We then create an HTTP Request configuration amongst the Global Elements that will be configured in the following way. This will enable us to connect to the weather forecast provider.
We have an HTTP Listener element with path /weather in the flow. With a Set Variable element we then save the name of the city that we get from the parameters of the http call and with a Request element (HTTP) which uses the global connector previously created we can then make the call to the service setting all the parameters needed.
If the call has a positive outcome we will be able to see JSON with the weather forecast data of the place we wanted to see. If the call goes KO, the flow has the chance of exceptions handling: we can understand the error 404 – Not Found from a generic error setting two different error messages – this happens when we set up the correct messages in the payload.
The image shows the result you obtain.
If you simulate two examples of KO you will have:
This was the last example for all the possible applications.
See you next time!
YOU MIGHT ALSO LIKE:
Enterprise Service Bus: everything you need to know
Virtual Reality: creating virtual worlds through Unity
Htcap: Segment’s web application scanner
