Talk:Enterprise service bus
From Wikipedia, the free encyclopedia
Contents |
[edit] 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. 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.
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
[edit] 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)
[edit] 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...
- 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 maticulous 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.....
- 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.
- 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???
[edit] 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)
[edit] 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 (2006) Service Oriented Architecture for Dummies, IBM Edition. Wiley, 43-44. ISBN 0-470-06982-1.. n2xjk 21:20, 13 September 2006 (UTC)
[edit] EI
Which EI? I'm assuming Extreme_ironing.
