Talk:Enterprise service bus

So... what is it, again?

I read the article, waiting for the substance. I'm still hungry, and I needed to know this stuff yesterday. Oh yeah, that diagram on the right contains absolutely no information. Someone should remove it. —Preceding unsigned comment added by 96.227.250.101 (talk) 03:20, 25 December 2009 (UTC)

It's better to improve Introdcution part —Preceding unsigned comment added by 121.242.128.86 (talk) 06:56, 7 January 2011 (UTC)

Insert a Queuing System between your systems, have it support multiple Protocols, Add Routing — Preceding unsigned comment added by 68.100.172.252 (talk) 01:34, 4 September 2013 (UTC)

Please can people on this page give up going on about queuing, there is no need for an ESB to have any queues, are they useful yes, required no! — Preceding unsigned comment added by 160.83.42.137 (talk) 14:55, 25 February 2015 (UTC)

Central components

IMHO an ESB is more a marketing term than a technological one, and it is useful mainly for ESB vendors to make money.

COMMENT: The above comment seems to forget that one of the purposes of an ESB is to abstract systems from each other through loose coupling. This, in effect, makes any ESB interchangable with the next thereby facilitating moving from one ESB vendor to another. The trick for the Enterprise and ESB Solutions Architects is to ensure the ESB contains the minimum of business logic that must be unraveled when one ESB is substituted for the next (better?) one. One way to do this is to ensure the ESB has clear interfaces to the BRE and WF engines that it uses.

An SOA is more a network of services talking each other, without needingly having to use an intermediate component (as the concept of a "bus" implies) to do so. This is the power of a SOA: the ability to talk to any other service.

COMMENT 1: SOA does no such thing. Using an OO approach to describe SOA - SOA provides properties and methods - How does SOA deal with events? Almost all "SOA" enabled applications seem to see themselves at the centre of the enterprise and getting events from them is generally problematic. The Master Data management connundrum is a great example - try synchronising customer data stores over five SOA applications that are subject to 99.999 availability that each have thier own customer stores.

COMMENT 2: Imagine if you have 4 SOA apps talking directly to each other. Each App has 3 connections to each other app and they become tighly coupled. Each app should comunicate only with the ESB which make subsituting each application far easier.

The only central component in such architecture is a service registry/directory, i.e. a UDDI server. But it does not take part in every communication, but is needed in order for peers to find each other before talking. The idea of a "bus" to allow services to interoperate collides both with such free architecture, and moreover totally clashes with the idea of an UDDI server.

Nonetheless, functions typically performed by ESB products may be needed; only I see them just as additional, optional modules being part of a SOA, but not needingly the central, mandatory hub of it. These functions are: 1) Allowing for asynchronous communications (temporal decoupling) 2) Allow for publish/subscribe messaging (functional decoupling) 3) Perform transformation of messages 4) Perform routing of messages

1) and 2) are needed in the vast majorities of SOAs, but not in every messaging interchange inside it.

3) and 4) are also usually needed, but again only in selected interactions. But there is no reason why they have to be implemented by a single, specialzed component; any service in the SOA can perform them as needed, using whatever technology is deemed proper to implement it. Plus, UDDI gives the flexibility to dynamically register such services so that peers start using them, instead of having them contacting always the "bus". E.g. if service A wants expects interface I from service B, but service B does not offer it, then service B' must be created (by whatever means) which acts as an adaptor, offering I to A. B' is registered in the UDDI, A finds it and invokes it - that's all, without needing to change A, or of any central bus.

Besides, in my view it is a great mistake to concentrate all the transformation and routing logic in a single component, since then it becomes the holder of more and more business logic. Thus, it ends up being yet another repository of business logic, with its own means of being developed and administered, besides the own services. -- anon - 24 May 2005

ESB-related vendors

I would suggest deleting the list of vendors in this article. It has become an incredibly spammy link repository, and Wikipedia is not a link repository. In general, inserting a list of "vendors", "dealers", "providers", etc. into an article seems to eventually turn it into a haven for spam. —Veyklevar 05:52, 12 May 2006 (UTC)

It has gotten even spammier since I wrote that. I am going ahead and removing it. —Veyklevar 08:34, 16 May 2006 (UTC)

I believe that the link list should be reverted, many of the links that were removed as "non notable" belong to vendors that lead this market.

e.g.

Vendor	Package	Reason
Progress	Sonic ESB	The pioneers of ESB
Tibco	ActiveMatrix Service Bus	The most widely installed.
Software AG	webMethods ESB	Also very widely installed.

Funny how the article is about ESB and mentions TIBCO ActiveMatrix™ BusinessWorks as an example. From their website I understand that their ESB product is "TIBCO ActiveMatrix® Service Bus" and that BusinessWorks can be used to "develop new services, automate business processes, and integrate heterogeneous applications", so it uses the ESB but is not the ESB. — Preceding unsigned comment added by 160.83.30.194 (talk) 17:34, 2 August 2013 (UTC)

References

(broken link) — Preceding unsigned comment added by 160.83.30.194 (talk) 17:40, 2 August 2013 (UTC) http://www.oracle.com/us/corporate/analystreports/infrastructure/forrester-wave-esb-q2-2011-395900.pdf Troll-Life (talk) 07:38, 30 May 2011 (UTC)

Key disadvantages?

I would suggest removing that section since it is highly non-objective. Some examples are:

• Value of the ESB requires many disparate systems to collaborate on Message Standards - WHAT? interconnecting with ESB is based on adapters that make changing the legacy system unnecessary...

Uh yeah and if you have 10 disparate systems, you would need up to 10*9/2 = 45 adapters unless you standardize on messages.160.83.32.14 16:43, 23 April 2007 (UTC)

I believe the point being made is logistical, not technical. It means getting different groups from different backgrounds together to collaborate, and this can cause problems and be a headache...

• Versioning of messages between systems, if not planned for, can cause tight coupling instead of the intended loose coupling ... but it beats the basic SOA architecture since you can CONFIGURE these dependencies and remove when no longer needed. And yes, it takes meticulous work or problems arise....
• Requires more hardware to run - ??? Whare dit this come from? It all depends.
• New skillset to learn to configure ESB... true but you can, after this learning curve change configuration to make parts interact or interact differently with each other, WITHOUT coding! Which seems a key advantage to me.....

In a dreamworld or marketing ad this is possible. Which large company has a group that knows the entire company's systems and how each interacts with one another? Probably zero. It is a false promise that changing anything is as easy as a parameter change.160.83.32.14 16:43, 23 April 2007 (UTC)

• Extra translation layer when compared to regular messaging solutions (Think about translating to Latin to get from English to Russian, just because you can) - not true. You COULD use separate messaging translations IF NEEDED, not because you can. New projects should focus on reusing the existing canonical data model.

yet the most critical applications of any established company are probably those that are written already.160.83.32.14 16:43, 23 April 2007 (UTC)

• Rarely realizes ROI on first project to implement ESB. Second project generally breaks even. Third project may beging to realize ROI... Sounds like a sound statement - does not ring alarm bells though. Apparently, after an initial investment and a learning curve, we get more value for money - where's the disadvantage???

the disadvantage is that it may take a long time (maybe more time than the company can afford) before the company realizes ROI. 160.83.32.14 16:43, 23 April 2007 (UTC)

We've waited for months for a citation for this claim. Since there was none forthcoming, I've removed this very blatent anecdotal implementation-specific (at best) claim.Bardcom (talk) 12:05, 29 November 2007 (UTC)

Where did this come from?

To my mind the biggest failing of this article is its failure to give any background on where the concept and terminology came from. Normally there's some seminal paper, some evangelical vendor, some crusading consultant behind such things. I expect to get *some* hint of this in the first or second paragraph of the article... --Snori 02:29, 15 June 2006 (UTC)

The whole article is fatally flawed because there is no single accepted definition of either SOA or ESB. Claiming an ESB is what an SOA can be built upon is an opinion, not a fact. Stilkov 08:54, 27 October 2006 (UTC)

The history of the ESB is short, and pretty straightforward. Sonic Software invented the thing, as a way of leveraging their asynchronous messaging queue product as a type of integration middleware. There were some rather silly claims made by TIBCO a while back, claiming to have invented the ESB first, but TIBCO generally assumes that they first invented any computer technology that uses message passing. Further confusion has arisen from the actions of integration middleware vendors, which have attempted to redefine ESB (to be whatever their technology does), or to deny that there is such a product category (this was IBM's famous "it's a pattern, not a product" stance, until they reversed it a while back; now an ESB is "web sphere integrator and web sphere Message Queue", according to IBM.)

The seminal paper that Snori is looking for is the book cited in the article, written by David A. Chappell of Sonic software, the inventors of the technology. The fog of misinformation, and pointless arguments over definitions, comes from other vendors in the integration middleware market. That the original book (and the definition of ESB) was written by the chief technology evangelist of a commercial enterprise is regretable, but they did invent the thing. The book is actually quite vendor-neutral, with some minor exceptions. It is certainly the "original source" for the definition of ESB, and ought to be used as such in this article. 192.18.128.5 20:30, 18 December 2006 (UTC)

Salient Characteristics

Is there any integration-related functionality not supported by ESB? Appears that the definition of ESB should be "an integration approach that can do anything". The article would be more useful if it differentiated ESB from other EAI models. 167.127.24.25 22:47, 15 June 2006 (UTC)

In addition the definition here of ESB conflicts with the EAI article. Specifically "Contrary to the more classical EAI approach of a monolithic stack in a hub and spoke architecture" is inaccurate as an EAI can also be implemented in a bus approach (does not have to be hub and spoke).

I don't think the statement "It is an implementation of Service Oriented Architecture" is correct. You can have a SOA without ESB, and you can have an ESB without SOA. However, a SOA does need some sort of message broker in place of ESB. See Service Oriented Architecture for Dummies, IBM Edition. Wiley. 2006. pp. 43–44. ISBN 0-470-06982-1.. n2xjk 21:20, 13 September 2006 (UTC)

False book citations aside, there really is a book, cited in the article, which is the best source for a reasonable definition of ESB. The shouting we hear about the definition of ESB is chiefly caused by vendors of either ESBs or other integration middleware, in an attempt to create confusion. I know the book was written by David A. Chappell of Sonic Software (now Progress), the company that has the most reasonable claim to having invented the ESB concept in the first place. If you read the book (I have), you'll find it is a reasonably vendor-neutral picture of ESBs, except for a rather pointed set of attacks on the use of Java EE application servers. I suggest that original sources (such as the inventor of the technology) ought to have precedent over shrill commercial gamesmanship. 192.18.128.5 20:18, 18 December 2006 (UTC)

EI

Which EI? I'm assuming Extreme_ironing.

Book

Isn't it advisable to put the Redbooks that are mentioned in the links in the books section? Mylenereiners 07:48, 19 December 2006 (UTC)

Software

removed section per Wikipedia is not a directory. Wikipedia is not a repository for lists, directories or Advocacy of commercial products and/or websites. NPOV requires views to be represented without bias, this applies not only to article text, but to companies, company lists, products, external links, or any other material as well.--Hu12 18:17, 20 December 2006 (UTC)

This article isn't very good

I was hoping it would explain what ESB is exactly in a way comprehensible but it reads like an ESB ad written by any number of ESB vendors. I'd help rewrite it but I'd have to find some actual information with meaningful verbiage. Can someone explain what one ACTUALLY is. Reboot 12:32, 8 February 2007 (UTC)

I agree, it may be better to simply delete it and wait until somebody who actually knows what an ESB is comes along and starts another one. Mnd999 11:54, 1 March 2007 (UTC)

If you wait long enough, you won't need to update it as the IT Managers will have moved on to the next FAD — Preceding unsigned comment added by 68.100.172.252 (talk) 01:28, 4 September 2013 (UTC)

The trouble with this page is that it is wrong and misleading. It desperately needs a total rewrite213.205.194.154 (talk) 07:45, 26 February 2015 (UTC)Oliver Buckley-Salmon

High Importance?

Seriously, high importance? It's just a marketing phrase coined by some middleware vendors. Mnd999 20:54, 7 August 2007 (UTC)

I agree, ESB seems to be mainly hot air. I have been working in EAI (which as term itself has been rather hyped as well) for years now and I have neither in this article nor anywhere else seen anything new that ESB offers. A standard-based approach is of course interesting but this is more an evolution of the underlying technology than a new concept. And everything listed in the characteristics section was provided by EAI solutions already long before the term ESB was coined. Robertpollai 20:54, 7 August 2007 (UTC)

Section Added

I'm pretty new to editing Wikipedia, and this is the first substantial content I've added to any article. However, I decided to be bold and just add my contribution to article itself. A major complaint that I've encountered on this talk page is the lack of any context. I have tried to rectify that by adding a "What is ESB" section that explains the idea to someone new to the concept. I'm afraid that by doing so that I have created a bit of redundancy in the article, but I did not feel confident enough to delete anything.

Basically, I would like this article to be an accessible introduction rather than a confusing jumble of buzzwords and disconnected sentences. There are a couple of paragraphs in the introduction that I don't think make much sense. (I don't know how to quote so I'm just going to use "pre" tags. If there's a more acceptable way please edit this.)

An ESB generally provides an abstraction layer on top of an implementation of an [[enterprise messaging system]], 
which allows integration architects to exploit the value of messaging without writing code. Contrary to the more 
classical [[enterprise application integration]] (EAI) approach of a monolithic stack in a [[hub and spoke]] architecture, 
the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with 
distributed deployment where needed, working in harmony as necessary. 

This paragraph is difficult to understand, and provides no context at all. While the information it is trying to convey is valuable, it probably should not be the second paragraph of the article.

This conflicts with a statement elsewhere in the article that ESB can be either centralized or distributed. Robertpollai 20:54, 7 August 2007 (UTC)

Most ESB providers now build ESBs to incorporate SOA principles and increase their sales, e.g. [[Business Process Execution Language]] (BPEL).

Aside from the fact that this is a completely unjustified statement, I'm not even sure exactly what it means.

Timwswanson 06:01, 1 November 2007 (UTC)

paragraph 3 needs help badly.

it says an ESB is not necessarily SOA, then the next sentence says it is. I do not know how to fix this at this time.

For those who are wondering when this comes up, I am encountering the term in a discussing of RTMP vs AMF in the context of LiveCycle, BlazeDS and Flex, though there are probably other venues where it arises.

I'd say more, but I came here to find out what the term means myself :) —Preceding unsigned comment added by Elinruby (talk • contribs) 02:25, 13 September 2008 (UTC)

Another note: I found the following article, which does not appear to be cited, somewhat helpful. http://www.ibm.com/developerworks/webservices/library/ws-esbscen/

Yet another note -- though i am confused on this topic also, I do not believe that it is true that XML is a sine qua non. The article I am looking at discusses it in terms of serialization and a stream of binary data. I know from various seminar presentations that a feature of LiveCycle is that it is therefore much faster than XML-based solutions. Unless, of course, the fact that XML is not involved makes LiveCycle not-an-enterprise-service-bus :) I am currently an agnostic on this :) Still reading.

it says an ESB is not necessarily SOA, then the next sentence says it is

It depends which one your customer is prepared to pay more for. Rogerborg (talk) 13:57, 16 July 2009 (UTC)

ESB as hardware product

I suggest the article mentions an ESB can be a hardware product too (currently it says it is either an architectural style or a software product. 204.104.55.241 (talk) 15:55, 15 September 2008 (UTC)

Distributed SPOF?

another problem: in the list of benefits and disadvantages, there is a bit of a paradox: The ESB has no centralised broker, but it becomes a single point of failure. Also prior to this in the article itself, there is disagreement about whether a centralised or distributed architecture must be used.

The concept of a BUS comes from hardware architecture, where a long piece of copper wire connected several components, allowing these to communicate in a fully connected graph. This in itself is not centralised - it's more like smart endpoints - however, buses started having controllers, intelligence, etc. and these in turn are centralised and introduce the SPOF. And that is not at all clear in this article. Maybe I'll get a chance to clean it up a bit once I have completed my research. Ooskapenaar (talk) 10:08, 16 December 2009 (UTC)

Removed list of Vendors

As per WP:NOT I removed the list. It was getting out of hand, with no indication of notability of any of the products. --HighKing (talk) 16:25, 18 April 2010 (UTC)

Reader Opinion

This article is closer to 100% buzzword compliant than anything else I think I've ever read on Wikipedia.  :-) --Baylink (talk) 16:53, 27 January 2012 (UTC)

Ambiguous use of the term ESB in commerce

This section contains the sentences:

Most modern providers of Message-oriented middleware have adopted the ESB concept as de facto standard for SOA. Today's implementations of ESB use event-driven and standards-based Message-oriented middleware in combination with message queues as technology frameworks.

Being fairly uninformed, I had doubts as to how many people consider ESB the "de facto standard for SOA". It turns out the reference for this claim has a broken link. I hope someone more knowledgeable could either site a reputable source for this claim, or provide a more balanced presentation of ESB's adoption in Message-oriented middleware.

References behind paywalls

There is a link to a Forrester report that costs $499 in the reference section. I think that should be removed. — Preceding unsigned comment added by Sourcedelica (talk • contribs) 12:56, 4 October 2014 (UTC)

A specialty variant of client-server?

How is ESB a special kind of client-server? It's the other way round. Rp (talk) 20:25, 29 November 2014 (UTC)

Article contradicts itself

Key benefit is loose coupling of the system, while key disadvantage is tightly coupling the system. Ummm .... okay. 75.82.248.221 (talk) 03:59, 7 July 2015 (UTC)

New open-source ESB

We create new open-source ESB OpenHub. It is ESB based on Apache Camel and adds many usefull functions. It is possible to download from GitHub It is possible add link into section Products and Open-source software? — Preceding unsigned comment added by Roman.havlicek (talk • contribs) 15:44, 31 January 2018 (UTC)