From Geostandards

Though ESB plays a crucial role in practical usage, there is not much attention paid to SOA in the geo domain. This does not mean that in the IT environment of the organisation that implements SOA, the ESB is present (mostly by available software products).

To make things clear, we are therefore going to focus attention on ESB in this module. It is an essential part of the architecture.

Contents 1 What does an ESB do? 1.1 ESB mediates 1.2 ESB standardises communication 1.3 ESB transforms 1.4 ESB orchestrates 1.5 ESB monitors 2 Why an ESB? 3 Government Service Bus (OSB)

What does an ESB do?

In short the tasks of an Enterprise Service Bus (ESB):

• An ESB ‘mediates’ between applicants of the service and providers of the service;
• An ESB ensures standardisation of the communication with applicants of the service;
• An ESB conducts the transformation of data between applicant and provider;
• An ESB orchestrates the handling of requests and forwarding to providers;
• An ESB monitors the service requests and reports on the use of the requests.

The various tasks are described below.

ESB mediates

An Enterprise Service Bus (ESB) is an architectural software construction (pattern) which makes communication between the consumers of ‘services’ and the providers offering them easier. The ESB offers the applicant of the service an Interface which both applicant and provider have agreed upon beforehand. This may be a Web service but, for example, it could also be a SMTP (email) interface or one of the many other possibilities. The ESB offers the provider the ability to communicate with the ESB via the interface that was pre-agreed on with the provider. Thus it can happen that the applicant of a service communicates in a completely different way with the ESB than the provider does. The figure indicates this schematically.

ESB standardises communication

By adding the ESB component within software architecture, the way in which service applicants communicate with providers of services can be standardised. There can surely only be agreement between the ESB and the applicant, or applicants, if they use the same service.

ESB transforms

It is the task of the ESB to translate the information which arrives with a request, and its associated information, in the right way (transforming it) into the format which is expected by the provider of the service.

ESB orchestrates

The ESB component is responsible for ensuring that the delivery of the request goes to the right place, to the right provider or, perhaps, providers of services. In dealing with these requests, the ESB ensures that errors are dealt with and, if necessary, it prioritises requests. In other words, which request should be handled first? The totality of the request, its handling and the associated verification process is described as the ‘orchestration of service requests’.

The following aspect of an ESB component is ensuring the security of requests and the associated data. As well as the security of the communication canal (e.i. a secured web service via HTTPS) there is also the question as to who (which user or role) is allowed to request a service?

ESB monitors

A last, frequent task of an ESB component is monitoring the received requests and recording statistical data about those requests. .

For example:

• How often a service is invoked;
• How often do errors occur and when is it fine;
• How long does a request take?

Based on this information, reporting can be done, but a direct reaction can also be given if, for example, within the orchestration of a request a service is invoked that executes an error. Monitoring also includes the checking of prior stated Service Level Agreements for a service that is defined in the ESB with actions if an SLA is not achieved.

Why an ESB?

Below is a concise list of the reasons why an ESB should be used and the benefits it provides.

1. Complete decoupling or partial decoupling (loosely coupled) of service providers and service applicants. In this way applicants communicate with the ESB and not directly with the provider.
2. Simplifying and standardising of interfaces between providers and applicants. This creates one generic way of communication with the ESB; the ESB ensures communication with the underlying systems.
3. Stimulating re-use. Because services become available at a central level, (within the ESB) and easily accessible they can be applied faster in other systems.
4. Central and generic way of service monitoring. Within the ESB services can be monitored and verified via pre-agreed SLAs in a generic way. Monitoring no longer has to be set up for each service provider but occurs centrally in the ESB.
5. Reduce “time-to-market” by re-use and less implementation time. This way the organisation (business) reacts to changes in the organisation or environment.

Without the use of an ESB, applicants and providers have so-called ‘Point-to-Point’ connections which run criss-cross through the organisation. Through the applications of an ESB, applicants have one standardised interface with the ESB and requests will be settled via the ESB.

In conclusion we may say that an ESB is indispensable as an ‘enabler’ in an organisation in which a Service Oriented Architecture (SOA) is being developed. The ESB ensures the right infrastructure at a higher level and (business) thought processes are regarded from a functional point of view and how they can be improved within an organisation.

► For the source and more information about this, see wikipedia

Government Service Bus (OSB)

The Dutch government has set up a Government Service Bus (OSB). This is a national implementation of an ESB. The OSB is a collection of (technical) standards to make electronic data exchange possible between government parties. The OSB standards ensure that the exchange between parties will run safely, reliable and efficiently. OSB also provides several (technical) provisions that make it easier for parties to be able to meet the OSB standards.

The program ensures four provisions:

• OSB Standards
• OSB Service Register;
• OSB Gateway;
• OSB Compliance provisions.

The goal of the Government Service Bus is to strongly standardise and simplify the mutual data exchange between government organisations. The Government Service Bus is the 'postman' that sends message traffic of basis registers back and forth between service providers and service clients. It is an innovative infrastructural standard with associated provisions that sends, guards and secures mutual data between registers and clients.

← previous

Service Enterprise Bus

next →