Paradigms of ESB Usage

1. Different ESB Implementations

1. GeoServer
2. Architectural Layout
3. Mule Configuration
 Different ESB Implementations
- Introduction (1/2) -

• Interoperability among different ESB implementations.

– How Mule does transformations between HTTP REST and
HTTP SOAP requests.
– The testbed implementation presented the provision of OGC
compliant GIS services to GIS SOAP enabled clients through
two middleware applications.
– As implementations of an open source ESB components Mule
and ASM are successively deployed between the GIS client
and GeoServer.
– Tools involved:
• GIS SOAP client, ASM, Mule and GeoServer.
 Different ESB Implementations
- Introduction (2/2) -

– The testbed and the exploratory testing will illustrate how the Mule
ESB platform will extend GIS systems interoperability by adding
SOAP interfaces (e.g. SOAP over HTTP or JMS) to the OGC
compliant GIS server.
 Different ESB Implementations
- GeoServer (1/2) -

• The OGC compliant GIS server (GeoServer) employs non-

standard B2B communication channel.
– A HTTP interface where the request parameters are
passed:
• Through the query string of a GET request.
• Or through an XML document, which is the payload of
a POST request.
• This concrete scenario represents the more generic case…
– An ESB is placed in front of an application that only
employs custom defined interfaces, so that standards
based interfaces for the application are exposed by the
ESB.
 Different ESB Implementations
- GeoServer (2/2) -

• Moreover, this testbed illustrates an example where, for

technical or administrative reasons:
– “Application Domain 2” exposes services only through its
preferred ESB (Mule).
– “Application Domain 1” has deployed an interoperability
solution solely based on ASM.
– Cross domain interoperability, such as the consumption
of a service of domain 2 by a client application of
domain 1, requires interoperability between the ESB
solutions of the two domains.
 Different ESB Implementations
- Architectural Layout (1/11) -

• The ESB interoperability is demonstrated, tested and assessed by the

GIS client.
– Invokes GIS services through interconnected ASM and Mule.
 Different ESB Implementations
- Architectural Layout (2/11) -

• One of the challenges of the testbed is the interoperability

and the testing of the interoperability between two ESB
implementations of similar but not identical nature.
– ASM is a JBI container.
– Mule, is not a JBI container as it has adopted a wider
approach in the field of ESB.
• Whereas in JBI the messages exchanged are strictly XML
described in WSDL, Mule does not make this assumption
and also allows exchanging of Java Strings, binaries,
MIME, etc.
 Different ESB Implementations
- Architectural Layout (3/11) -

• The level of mutual compliance between the XML/SOAP

interfaces provided by ASM and those provided by Mule will
be assessed.
• Also, protocol translations (REST/HTTP to SOAP/HTTP
through Mule) will be deployed and tested.
• Any incompatibilities unveiled will be bridged by adaptations
in either Mule or ASM.
 Different ESB Implementations
- Architectural Layout (4/11) -

The broadening of the scope of technical interoperability by

presenting interoperability among different ESB platforms.
• While each ESB is assumed to facilitate interoperability
among the applications of a single administrative technical
or applications domain, the integration of the ESBs extends
the interoperability across the borders of the domains.
 Different ESB Implementations
- Architectural Layout (5/11) -

• The architecture that is described in the following section

aims at covering two objectives in a single testbed.
– Mule will be placed as front end of the GeoServer and it will
expose GIS services over the protocols supported by Mule
(e.g. SOAP).
– ASM will be connected to Mule in order to consume GIS
services, on behalf of a GIS client, which will be connected to
ASM.
– The GIS client will be the actual consumer of the GIS services.
 Different ESB Implementations
- Architectural Layout (6/11) -

• The integration between Mule and GeoServer is based on client-server

architecture.
– The GeoServer allows users to view and edit geographical data by sending
simple requests, hiding the complexity of performed geospatial operation from
users.
– Clients, in the case Mule, communicate with GeoServer using the REST
HTTP based protocol.
– The server queries are simple HTTP GET or POST requests.
 Different ESB Implementations
- Architectural Layout (7/11) -

• In Mule, an UMO component must be built for invoking REST

requests to the GeoServer.
– Allows to expose the GIS services through all Mule transports
supporting this feature e.g. SOAP transport.
• Additionally Mule can be configured to accept SOAP requests
over different transports.
– Not only as HTTP, but also JMS and SMTP.
• It could be also possible to replace the GeoServer with another
OGC compliant GIS server.
– The replacement should be transparent to applications
consuming GIS services through Mule.
• In our example the GIS services will be made available over a
SOAP enabled Mule endpoint.
 Different ESB Implementations
- Architectural Layout (8/11) -

• The integration between ASM and Mule is based on a middleware

to middleware architecture.
 Different ESB Implementations
- Architectural Layout (9/11) -

• Mule exposes the GIS services over SOAP.

• On behalf of its clients, ASM connects to Mule using one of its binding
components that implement the SOAP protocol.
– Servicemix-http: implementing SOAP over the HTTP transport.
– Servicemix-jms: for the JMS transport.
• The binding component embraces the implementation of the protocol and
the transport.
• The instantiation of the binding component, based on the given
configuration, comprises the “service provider endpoint”.
– Connects ASM to its GIS service provider (Mule).
• ASM exposes the GIS services through its “service consumer endpoints”.
– Different endpoints can be setup and made available to service
consumers, by configuring servicemix-http and servicemix-jms
binding components appropriately.
 Different ESB Implementations
- Architectural Layout (10/11) -

• The GIS client employs a SOAP/HTTP interface.

• Through this interface it connects to ASM for using GIS services,
exposed by ASM through the supported protocols.
 Different ESB Implementations
- Architectural Layout (11/11) -

• Overall Architecture

• GeoServer requires that incoming queries are to be in a form of HTTP requests.

– The messages sent to the GeoServer have to be converted into such requests by Mule
components.
• Mule exposes the GIS services over SOAP protocol, enabling the interoperation with
ASM.
• ASM connects to Mule using a binding components that implement the SOAP protocol.
• As the end user, GIS client connects over SOAP/HTTP to the respective service
consumer endpoint of ASM and presents requested data.
 Different ESB Implementations
- Mule Configuration (1/8) -

• Mule enables a large variety of configurations.

– However an UMOManager is to be defined in each case,
as it is a core part of a configuration.
• Mule is configured using a simple interface that can be
invoked on the Mule server start-up.
• Three configuration builders are available in Mule:
• Default Mule XML Configuration Builder.
– Used in Mule and GeoServer integration.
– Spring Builder.
– Groovy Builder.
 Different ESB Implementations
- Mule Configuration (2/8) -

• Configuration file for Mule and GeoServer integration.

– Mule receives SOAP requests, transforms the message
from SOAP to HTTP request and passes the message to
the GeoServer.
– Such a sequence of actions requires an UMO object.
• For a message format transformation.
– Once the message has been transformed, it is routed to
the GeoServer.
 Different ESB Implementations
- Mule Configuration File (3/8) -

• Connector Declaration

<connector name="axisConnector"
className="org.mule.providers.soap.axis.AxisConnector">
<properties>
<property name="treatMapAsNamedParams"
value="false" />
</properties>
</connector>
 Different ESB Implementations
- Mule Configuration File (4/8) -

• Message Transformers Declaration

<transformers>
<transformer name="HttpRequestToSoapRequest"
className="o.m.p.s.transformers.HttpRequestToSoapRequest"/>
</transformers>

• HttpRequestToSoapRequest transformer:
– Allows to make simple SOAP requests through HTTP GET
requests.
– The transformer automatically converts a GET request into SOAP
request.
 Different ESB Implementations
- Mule Configuration File (5/8) -

• UMO Object Declaration

<model name="gis">
<mule-descriptor name="GisService"
implementation="umo.GisService">
<inbound-router>
<endpoint address="stream://System.in" />
<endpoint address="axis:http://<Mule-Host@PSNC>:80/services"
transformers="HttpRequestToSoapRequest" />
</inbound-router>
<properties>
<property name="wmsServiceUrl"
value="http://<GeoServer-Host@PSNC>:8090/GeoServer/wms"
/>
<property name="wfsServiceUrl"
value="http://<GeoServer-Host@PSNC>:8090/GeoServer/wfs"
/>
<list name="serviceInterfaces">
<entry value="umo.IGisService" />
</list>
<map name="axisOptions">
<property name="wsdlPortType" value="geoPort" />
<property name="allowedMethods"
value="
getCapabilities,
getCapabilitiesWithOptionalParams,
sendRequest,
getMap,
getFeature,
getMapWithOptionalParams,
describeFeatureType,
transaction" />
</map>
 Different ESB Implementations
- Mule Configuration File (6/8) -

• UMO Object Declaration

<map name="soapMethods">
<property name="getCapabilities"
value="service;string;in" />
<property name="getCapabilitiesWithOptionalParams"
value="service;string;in,
version;string;in,
format;string;in,

updateSequence;string;in" />
<property name="sendRequest"
value="service;string;in,
requestBody;string;in"
/>
<property name="getMap"
value="
version;string;in,
layers;string;in,
styles;string;in,
srs;string;in,
bbox;string;in,
width;string;in,
height;string;in,
format;string;in" />
 Different ESB Implementations
- Mule Configuration File (7/8) -

• UMO Object Declaration

<property name="getMapWithOptionalParams"
value="
version;string;in,
layers;string;in,
styles;string;in,
srs;string;in,
bbox;string;in,
width;string;in,
height;string;in,
format;string;in,
transparent;string;in,
bgColor;string;in,
exceptions;string;in,
time;string;in,
elevation;string;in" />
<property name="describeFeatureType"
value="
service;string;in" />
<property name="getFeature"
value="
service;string;in,
typenameList;qname{:Array:http://schemas.xmlsoap.org/soap/encoding/};in" />
<property name="transaction"
value="requestBody;string;in" />
</map>
</properties>
</mule-descriptor>
</model>
 Different ESB Implementations
- Mule Configuration (8/8) -

• UMO Object Declaration

– The GisService UMO component is a GIS adapter which invokes GeoServer operations.
– The wmsServiceUrl and wmsServiceUrl properties points to a host where GeoServer is
installed (currently http://150.254.173.202).
– The adapter is a Java interface which is automatically exposed as a web service, using
Axis implementation.
– Generally the <endpoint> element defines an URI address where component receives
events. In this case it uses the axis connector on <Mule-Host@PSNC>:80/services
(http://150.254.173.202:80/services). However the <endpoint> could be also a standard
input stream. The UMO object declaration contains also properties regarding both Axis
options and the UMO object itself. The properties of GisService component define both
URL addresses, where its services are accessible, and an interface description including
names of exposed methods and their parameters.
– Current IP address (2008/Q1). IP addresses are likely to change in the course of the
project
– Current IP address (2008/Q1). IP addresses are likely to change in the course of the
project
 Summary (1/4)

• ASM is a novel, rapidly developing but still immature ESB implementation.

• Its well structured design and the support of pluggable JBI components
significantly facilitates the design of extendable networks of interoperable
applications.
• However, in the implementation phase the developer is confronted with the
immaturity of the product.
– In the context of this task, the development team faced significant difficulties in
finding documentation concerning:
• The message routing capabilities, which is a key functionality of ASM.
• The security capabilities of the end-points; particularly the digital
signatures framework was quite unclear and undocumented. I
– In many aspects the development team was forced to follow a trial and error
approach, rather than implementing solutions based on well documented
components and paradigms.
 Summary (2/4)

• Despite the difficulties, the experience with ASM was

positive.
• The pluggable nature of the ASM service units, assemblies
and components significantly assists modular design.
• In the course of the task, new components emerged as well
as documentation and examples for existing components,
tackling some of the difficulties that the development team
faced in early stages.
• The learning curve remains significant, but ASM is rapidly
improved in terms of both functionality and documentation.
 Summary (3/4)

• Contrary to ASM, Mule presents maturity which is realised

in both the stability of the product and the completeness of
the documentation.
• The learning curve for the development teams of this task
was quite reasonable.
• The shortcoming recognised in Mule is that (at least up to
the current version) it does not abide to the JBI
specification, but instead it comprises a “JBI Complaint”
ESB.
 Summary (4/4)

• Both ESB implementations (ASM and Mule) served well

their purposes by providing or enhancing interoperability
between different software components as required.
 References

• http://mule.mulesource.org/display/MULE2USER/Architectu
re+Guide