Mule ESB – The anatomy of a flow

Mulesoft’s Anypoint Platform is an integration platform which is especially interesting for Java developers. It is based on the Spring framework and leverages Java technologies like CXF or JAXB which are well known Java software frameworks. Therefore, Java developers are able to get along with the platform fast.

As the developers have direct access to the underlying Spring framework, the Mulesoft’s platform can be easily extended by own components, beans and additional functionality. A pattern based architecture style is supported, that, in combination with Spring and the Mulesoft testing framework MUnit provides a rich feature set for testing.

However, let us dive a little bit deeper into integration with Mulesoft.

Let us assume that we want to build a soap based webservice proxy. As we do not want to start from scratch, we have a look at the Anypoint Exchange, which is a webportal provided by Mulesoft to share examples, connectors and more. It is always a good starting point when having a new use case.

The Proxying a soap API example is exactly what we are looking for which can be easily imported to the Anypoint Studio via the downloadable zip file. The Anypoint studio is an Eclipse based IDE for the Anypoint platform.

mule_flow_components

The integration logic is structured with the help of flows. A flow consists typically of three parts (see image above):

  1. An inbound connector, which triggers the execution of an integration flow
  2. The processors which contain some logic, for example transformations
  3. An outbound connector to communicate to other systems.

In the example, the inbound endpoint (1) is a http-listener listening for requests on port 8080.

mule_flow_http

The listener is followed up by several processors. The configuration for a soap based webservice is done via the CXF component which determines namespaces, service and port as well as the computation logic.

mule_flow_cxf

This is followed by a proxy client definition, which prepares the flow to send a request to another service configuration and a http request component which actually performs the request execution and executes the soap http post.

mule_flow_proxy

Basically, you need at least 4 components to proxy a service:

  • The inbound endpoint, which is the http listener
  • The CXF component to configure the soap based webservice endpoint
  • Another CXF component to act as a client
  • And a http request

However, in the example we have 6 components because a sub flow with the name copy-headers is called twice. Mule provides the functionality to extract reoccurring patterns and to place them into sub flows that can be called by other flows similar to methods or functions. In the example http headers are copied from the request to the client request as well as from the client response to the service response. The XML-view of the flow gives further details about what actually happens inside of the sub flow.

mule_flow_xml

In the example there is no difference between the WSDL for the service and client call. The actual request body is simply passed through. Usually, some kind of transformation of the body request is necessary which can be easily achieved via a huge variety of mule components, for example data weave, a language provided by mule to simplify transformation logic, XSLT, XQUERY and XPATH as well as Java or Groovy. A full overview of these components is provided by the Mulesoft documentation.

Dieser Beitrag wurde unter Architecture, English, Integration, Java, SOA veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s