Ross Mason has spoken up to talk about the ESB, what it is, and how it compares to SOA. He discusses ESB as a framework, a product and an emerging standard in the form of JBI. However, he then goes on to say how he sees the ESB as an enterprise integration pattern or an Architecture style.

Conclusion

I think it's a little naive to expect a single technology such as web services, as flexible as it is, to satisfy all the needs of any organisation. We should be able to recognise by now there is no 'silver bullet' to solve all our enterprise requirements; as the technology advances so does our expectation of what we should be able to achieve with the technology. The ESB and WS are just different, yet complimentary patterns in the SOA fabric. The use and implementation of each will be driven by the requirements and technology focus of the organisation and the feasibility of a solution within current infrastructure constraints.

The advantage of a properly implemented ESB is that it can leverage all the advantages of WS with the added bonus of integrating with technologies that are not suitable for the web services model. Each SOA technology should be viewed as an architectural pattern in the enterprise architect toolbox along with J2EE, .NET and emerging methods such as Grid computing.

What is the business case for ESB?

There are some good points made in this entry, but I wouldn't go so far as to call Enterprise Service Bus an "integration pattern". To me, ESBs are simply a productization of the simpler concept (and pattern) of the message bus. In this way, ESB's suffer the same risks that Web Services in general do - a valid concept that will be marketed and in some cases adopted to the point where its real value is diluted by over-exposure.

Actually the same thing. The Web Service if bind with SOAP is also a Message-base system, but emphasize the sync. If a Web Service bind with JMS, it will looks more like ESB, can emphasize the async.

On the current stage, if some businesses can be exposed as Web Services, they can be connected will a specific ESB which can connect to other legacy systems will adapters among the routers. Of course, finally is can integrate with Web Services.

It's important to note, ESB should be considered as a true implementation of the ideas and concepts behind SOA's archiecture model.

Sometimes, both concepts are misunderstanding, but SOA = architecture model and ESB = model implementation.

Please let me know your comments about this ideas.


Regards,

Jorge

It's important to note, ESB should be considered as a true implementation of the ideas and concepts behind SOA's archiecture model.

IMO - This is only true if you make the assertion that SOA architecture always equals application or service integration, which is not necessarily the case.

It's important to note, ESB should be considered as a true implementation of the ideas and concepts behind SOA's archiecture model.

IMO - This is only true if you make the assertion that SOA architecture always equals application or service integration, which is not necessarily the case.

I agree. I am beginning to hate the ESB acronym :-) because there is an integration stigma associated with it. For me, it's about connecting applications to applications and applications to information in a non-binding way. SOA encompasses this notion, but SOA is a model for software development and people/companies want tangible products that address a particular problem space. So ESB was touted for integration, but really the philosophy behind it is far more widespread.

I like the term Enterprise Service Network, it more true to the way enterprise messaging systems (should) work. In reality you need to mix Web services, BPEL, Jms, Integration adapters, grids and a variety of other technologies and protocols in order to develop enterprise-wide applications. These are not all arranged neatly on the bus but the do have a common communication network using many transports and delivery methods, namely synchronous, asynchronous and request-reply. The goal of Mule is to provide a homogenous way of constructing these service networks allowing you to mix protocol and delivery methods together in a rich messaging platform.

I'm happy to drop ESB in favour of ESN. Someone mentioned that ESB was a dinosaur; the name is but its intent isn’t.

ESB and SOA do not go far enough. The next step is to build operating system-like (event driven) application servers that know how to service requests; both synchronous and asysnchronous. This is where, I think, BPEL and the like are heading.

The business case for ESB is that as teams develop their software using SOA that you don't want to end up with "service silos" just as we have "data silos" currently. In this sense, ESB is, for me, more of a service repository (UDDI/ebXML Registry). I think that this is where products like Flashline CMEE come into play.

I see the ESB in SOA as a sort of stovepipe, I think a looser more flexible architecture would make sense, like Enterprise Services Network that some have proposed.

I think a looser more flexible architecture would make sense, like Enterprise Services Network that some have proposed.

Could you elaborate on where ESBs are too rigid (or not loose enough) or where they are lacking flexibility?

Thanks,

Oliver

ObjectWeb started an initiative targeting the federation of open-source technologies for enterprise service buses.

The initiative is structured around three working groups:
- technical solutions
- use cases (ie, business requirements)
- business models

A handful of existing, production-ready open-source components provide good building blocks for ESB related projects: Joram, JOnAS, Bonita, Shark, JaWE, XQuark... Sorry to those I forgot.

The first outcomes of this initiative are very intersting, as they show that:
- visions and understandings of "what an ESB is" vary a lot, and the all Java / all JBI doctrine appears a little shortsighted
- the ESB is often seen as a flexible tool suited to an iterative approach to integration. It might be designed as a toolbox rather than a packaged product
- when addressed from the requirements side, it appears that end user companies no always think in terms of ESB, but rather in terms of integration, a broader picture in which the ESB is a subsystem -- and then comes the question of orchestration
- open source components for the ESB as provided by ObjectWeb can be assembled and complemented to market commercial offers, be it products or services

A good way to take part in the discussion is to join the esb <at> objectweb.org mailing list. A wiki site will soon be up too. Some results of the initiative will be presented during a tutorial session at the upcoming ObjectWebCon '05.

See:
* "ObjectWeb to Federate Open Source ESB" - http://www.objectweb.org/phorum/read.php?f=25&i=68&t=68
* "ObjectWeb federates commercial grade open-source projects for business integration" - http://www.objectweb.org/phorum/read.php?f=25&i=79&t=79
* "ObjectWeb Open-Source ESB Initiative is Gaining Industry Attention" - http://www.objectweb.org/phorum/read.php?f=25&i=75&t=75
* Tutorial Integrating Enterprise Data and Applications with Enterprise Service Bus - http://wiki.objectweb.org/ObjectWebCon05/Wiki.jsp?page=Tutorials

Oliver,

    Check out this article:

http://www.looselycoupled.com/blog/lc00aa00073.html

Also, Radovan Janecek has a good blog that has been addressing this issue for awhile:

http://www.radovanjanecek.net/blog/

Hope this helps,
John

Oliver,&nbsp;&nbsp;&nbsp;&nbsp;Check out this article:http://www.looselycoupled.com/blog/lc00aa00073.htmlAlso, Radovan Janecek has a good blog that has been addressing this issue for awhile:http://www.radovanjanecek.net/blog/Hope this helps,John

I was actually responding to the looselycoupled entry when I wrote this. :)

The point I was making is that the ESB shouldn't be viewed as a product and not as a replacement for WS. The ideals behind the ESB are complimentary to not competing with the WS-* standards.

Speaking from a pure SOA perspective, whether web services are employed or not, I think that mandating all service communications occur through an ESB is a problem and an architectural stovepipe in my mind. I like Janocek's notion of an ESN (Enterprise Services Network) or one I had considered EST (Enterprise Services Taxonomy) make more sense. If one of the nodes on the network or taxonomy happens to be a MOM-style bus then that is fine. However, dictating that all of an SOA flows through an ESB seems quite restrictive.

Also, Radovan Janecek has a good blog that has been addressing this issue for awhile:http://www.radovanjanecek.net/blog/

Radovan's "Bus Stop" article rightly calls ESB a "dinosaur". A bus as a hub only thwarts the amorphous topology of a grid. What matters most is that services can be categorized in unstable registries and the registries then cross-reference each other in arbitrary hierarchies for reliability and availability. A bus is a misleading metaphor for such a SOA grid. Imagine how lame music swapping would be if a bus metaphor were imposed. Services deserve better.

The business case for ESB is that as teams develop their software using SOA that you don't want to end up with "service silos" just as we have "data silos" currently. In this sense, ESB is, for me, more of a service repository (UDDI/ebXML Registry). I think that this is where products like Flashline CMEE come into play.

I think this is trivilaizing the power from ESB. It is not just a service repository. It is far more than that. It is a true middleware integration fabric.

As others in this thread pointed out, there certainly is the risk of "locking" the application to one vendor's ESB. But this can easily be addressed. To mitigate this risk may help to look for these attributes:
1) The key application "assets" in an ESB environment are the service implementations/wrappers and the biz-process. Rest of the plumbing is a pure runtime configuration & setup. The latter can be vendor specific. The former should, to the extent possible, be vendor neutral.
2) When defining services consider ESB vendors supporting JBI & WSDL2. If a servcie is written as per JBI or even just WSDL2, the application artifact (asset) may still be "portable" to other ESB/SOA runtimes with minimal effort.
3) Biz process should be in BPEL . In th eleast, the ESB vendor should support "exporting" the biz process to BPEL. Then even the biz process becomes portable.
(More on this..)

Cheers,
Ramesh
- www.pramati.com

<blockquoteWhen defining services consider ESB vendors supporting JBI &amp; WSDL2. If a servcie is written as per JBI or even just WSDL2, the application artifact (asset) may still be "portable" to other ESB/SOA runtimes with minimal effort.
Hello,

how can you write a service "as per JBI"? My understanding was that JBI is a Service Provider Interface and e.g. specifies a contract defining how the provider of a Service Engine can plug into the JBI environment; services would execute within such service engines.

The early draft I read explicitly pointed out that this spec does not define APIs for _implementation_ of services?

What did I misunderstand?

Thanks a lot,

Oliver


(Please note that I believe that JBI may be a significant step in the right direction, so the above does not critize JBI as such.)

Ramesh,

I agree with you that ESB is more than just a repository but is also Orchestration/Workflow services as well. And there is a business case in there as well - self-documented processes. My point is that what most CIOs would "hear" as a business case is - "you already have data silos, ESB/ESN helps you avoid service silos". They get that more than the business case around "self-documented processes".

Some folks would view Orchestration/Choregraphy/Workflow as just another service in an SOA world ("one service to rule them all") so then they wonder what the whole ESB thing is anyway.

So where are we on standardizing this anyway? Most vendors don't want to buy into anything until it is sufficiently standardized and I would argue that this area is not yet.
Brian

I agree that what folks understand from SOA varies considerably.
I perceive SOA as an enterprise architecture in which the boundaries between
different security and application domains are clearly defined in a technology
independent manner. SOA is an unifying concept. Therefore communications between
"different security and application domains" are an essential characteristics.
ESB enters the picture here. Since we want the communication and the interaction
between the pieces that make up SOA to take place in a lousely-coupled manner we
need to have something like PCI bus in PCs. ESB , as its name implies, functions
as a bus: a communication highway that provide pluggable interfaces for enterprise
systems to connect to and communicate with other systems

Seems pretty clear from what has been said here that there is no consensus decision on what an ESB actually is.

Blame Gartner.

Seems pretty clear from what has been said here that there is no consensus decision on what an ESB actually is.Blame Gartner.

Sort of... And this is part of the point of ESBi (the ESB initiative). Unlike other areas (eg appservs, with J2EE), there are "missing standards" in the ESB space. However, there are good technology bricks around, and users that have real business needs. Open source can be a way to close the gap and leverage the ESB concepts (as fuzzy as they may be) to deliver actual value through iterative development of the missing software parts.

There definitely is a business case for using ESBs for integration. Enterprise architects will soon realize (I have) that point-to-point application integration will lead to an uncontrollable mess.

The business case for building an ESB from grounds up as a "service backbone" (hey, I just invented a new term :-) is simply not there. As to the content of article, I particularly liked and can easily envision a scenario where we have several ESBs in an enterprise, serving a particular application portfolio (either separated by business function, organizational unit or some other way), these ESBs then integrate to fulfill the enterprise wide cross-cutting requirements.

IMO, any large corporation cannot base its architecture on one ESB (the "one ESB to rule them all" syndrome). There will have to be a number of ESBs which will interoperate using Web Services. Perhaps we will even see some patterns in inter-ESB integration :-)

There definitely is a business case for using ESBs for integration. Enterprise architects will soon realize (I have) that point-to-point application integration will lead to an uncontrollable mess.The business case for building an ESB from grounds up as a "service backbone" (hey, I just invented a new term :-) is simply not there. As to the content of article, I particularly liked and can easily envision a scenario where we have several ESBs in an enterprise, serving a particular application portfolio (either separated by business function, organizational unit or some other way), these ESBs then integrate to fulfill the enterprise wide cross-cutting requirements.IMO, any large corporation cannot base its architecture on one ESB (the "one ESB to rule them all" syndrome). There will have to be a number of ESBs which will interoperate using Web Services. Perhaps we will even see some patterns in inter-ESB integration :-)

Exactly! Also, I do not just see a lot of message buses, but rather a network of nodes that host services or groups of services, communicating over many protocols, using different delivery methods. I think the bus metaphor has become synonymous with integration bus, but we're really talking about an "service metropolis" (hey I invented one too :)), that can span enterprises or just as easily to scale down to a simple client/server application.

According to Gartner, an ESB should provide the following 4 functionality at a minimum. They are Guranteed messging, Message transformation, content based routing & out-of-box webservices support. In addition to that some vendors also support process orchestration/workflow(BPM) and BAM capabilities. This indicates ESB is another way for achieving SOA in SOE(Service Oriented Enterprises). Some vendors use Message Brokers(BEA, IBM etc in APS) while others(SONIC) us a more distributed mechanism for this. I believe it's a little different from the Information Bus concept that came few years ago. Info bus was a pure pub/sub mesaging infrastucture in a enterprise for message broadcasting. That's about it. They were proprietry. I used Tibco message bus using Rendezvous few years ago. With ESB catching up, vendors are now turning towards a more specification & standards based ESB. They use JMS for messaging, SOAP/XML/UDDI/WSDL for webservices and BPEL for orchestartion. I am not very clear about the fate of JSR208(JBI) since IBM & BEA are not supporting it now. I feel ESB with Webservices will be pretty helpful in achieving SOA & EDA(Event driven Architecture as RFID gets more popular)in an organization.

Bijan

As usual it depends.  We're looking at ESB as an EAI solution to replace tons of custom plumbing we've written.  The business case is fairly clear.  We're not looking at all the BPM stuff because our organisation would need to change drastically to accommodate that.

 

I've listed some generic considerations here: http://soaprobe.blogspot.co.uk/2012/10/enterprise-service-bus-esb-building.html

 

Robert