“An ESB” or “the ESB”

Posted in ESB | Tuesday, May 2nd, 2006 | Trackback

For the people that know me there should be now doubt in their mind that I see ESB as a concept (an ESB) and not a product (the ESB). The reason I bring this up is that I have just read the article “Applying ESB” in the April edition of the CBDi Journal.

It is my conception that CBDi agrees with my view of an ESB, but I have a critique of their latest article where they start to try and specify what is, and what is not, a part of an ESB. In my world an ESB should be viewed as a paradigm which can be used in a SOA. How the ESB is to be perceived within the individual architectural context is part of making a successful SOEA.

The following table is just some of the aspects which should be considered when conceptualizing your ESB – what do you need, what is nice to have and what doesn’t matter?

Communication

Service interaction

· Routing

· Addressing

· Protocols and standards (HTTP, HTTPS)

· Publish / subscribe

· Response / request

· Fire & forget, events

· Synchronous and asynchronous messaging

· Service interface definition (WSDL)

· Substitution of service implementation

· Service messaging models required for communication and integration

· (SOAP, XML, or proprietary Enterprise

· Application Integration models)

· Service directory and discovery

Integration

Quality of service

· Database

· Legacy and application adapters

· Connectivity to enterprise application integration middleware

· Service mapping

· Protocol transformation

· Data enrichment

· Application server environments (J2EE and .Net)

· Language interfaces for service invocation (Java, C/C++/C#)

· Transactions (atomic transactions, compensation, WS-Transaction)

· Various assured delivery paradigms (WS-Reliable Messaging or support for Enterprise Application Integration middleware)

Security

Service level

· Authentication

· Authorization

· Non-repudiation

· Confidentiality

· Security standards (Kerberos, WS-Security)

· Performance

· Throughput

· Availability

· Other continuous measures that might form the basis of contracts or

· Agreements

Message processing

Management and autonomic

· Encoded logic

· Content-based logic

· Message and data transformations

· Message / service aggregation and correlation

· Validation

· Intermediaries

· Object identity mapping

· Service / message aggregation

· Store and forward

· Administration capability

· Service provisioning and registration

· Logging

· Metering

· Monitoring

· Integration to systems management and administration tooling

· Self-monitoring and self-management

Modelling

Infrastructure Intelligence

· Object modelling

· Common business object models

· Data format libraries

· Public versus private models for business-to-business integration

· Development and deployment tooling

· Business rules

· Policy-driven behaviour, particularly for

· service level, security and quality of service capabilities (WS-Policy)

· Pattern recognitio

[Source: Patterns: Implementing an SOA using an Enterprise Service Bus]

After having completed the conceptual definition of your ESB you can start identifying if there are any products which will cover your needs, and you will probably find that no single product will. What will often happen is that you will build your ESB of several products.

Selecting how to implement your ESB is not an easy task, not only due to the complexity of the task, but also because you are essentially building the heart of your enterprise!

“Define your needs – select the product that fits”

 

2 Responses to ““An ESB” or “the ESB””

  1. Asim Hanif Says:
    May 8th, 2006 at 10:59 am

    Hi Rasmus

    I am one of these persons, who talk about ESB as a product. So thank u! How do u so define ESB?

  2. site admin Says:
    May 8th, 2006 at 6:50 pm

    Hi Asim,
    My view on an ESB is that it is a concept. A conception that ESB might just fit that which has been implemented by one of the many vendors who claim to sell an ESB, but what most important is that you don’t let the implementations control you definition of an ESB. Often the best way of implementing an ESB is though a collection of products.
    This was in fact also what IBM used to argue. But then all their suddenly all where selling products which they called ESB’s and suddenly IBM had not only one but two ESB’s for sale. In terms of the product nothing had really changed, all in all just a marketing stunt.

    An ESB is such a central part of your architecture that you must be very careful when listening to the many sales pitches!

    Bottom line you create an Enterprise Architecture – you don’t buy it.

    /Rasmus

Leave a Reply

You must be logged in to post a comment.