Idea Transcript
EAI vs. SOA vs. ESB
Enterprise Integration EAI vs. SOA vs. ESB Author - Omer Qadri
Page 1 of 6
EAI vs. SOA vs. ESB
TABLE OF CONTENTS 1
INTRODUCTION ................................................................................................ 4
2
SOA .................................................................................................................. 4
3
EAI ................................................................................................................... 5 3.1 3.2
HUB/SPOKE.................................................................................................. 5 BUS .......................................................................................................... 7
4
ESB ................................................................................................................... 9
5
CONCLUSION .................................................................................................. 10
6
TAKEAWAYS SUMMARY................................................................................... 12
Page 2 of 6
EAI vs. SOA vs. ESB
1 INTRODUCTION This paper aims to bring clarity to terms EAI, ESB, SOA and provide a clear distinction. Also this paper would discuss arch itecture opt ions av ailable f or en terprise in tegration an d wh at these opt ions are most su itable for. F inally this paper would addr ess the dis cussions we have seen in various forums about whether EAI is going to be replaced by SOA or ESB.
2 SOA Service or iented architecture is approach to have software resources in a n enterprise available and discoverable on ne twork as well defined services. Each service would achiev e a predefined business objective and perfor m discrete units of work. The services ar e independent and do not depend on the context or state of th e other services. They work within distributed systems architecture. Earlier SOA used COM or ORB based on CORBA specifications and recent SOA stress on web services using standar d description (WSD L), di scovery (UDDI) a nd messagi ng (SOAP ). Service oriented architecture may or may not use web services but yes web services provide a simp le way towards service oriented architec ture al beit wi th the age old security and reliability limitations.
3 EAI Enterprise applicat ion integration is a bu siness n eed t o mak e div erse appl ications in an enterprise including pa rtner sy stems to com municate to each other to achi eve a busi ness objective in a seamless reliable fashion irrespective of platform and geographical location of these applications. It is a business need and business never dies it only evolves. I have seen people say ing th at EAI is a t hing of past n ow SOA is h ere, it is just l ike say ing “transportation is a thing of past now road is here”. EAI comprises of message acceptance, tra nsformation, translation, routing , messag e delivery and b usiness process manage ment. Us ually messages transp ortation is asynchronous bu t for a busi ness need i t can be sync hronous as well. There ar e two basic architectures to achieve this, bus and hub/spoke architecture. Both of these can be used to develop services and then it also becomes service orientated architecture.
3.1 HUB/SPOKE Hub/Spoke arch itecture u ses a cen tralized broker (Hub) and adapters (Spoke) whi ch connect applicat ions t o Hu b. Spok e con nect t o applic ation an d con vert applicat ion dat a format to a format whi ch Hub understands and vice versa. Hub on the other ha nd brokers all messages and takes care of content transformation/translation of the incoming message into a format the destination system underst ands and r outing the message. Adapters take data from s ource application and publish messages to the message broker, which, in turn, does transformation/translation/routing and p asses messages to sub scribing adapter which sends it to dest ination applicat ion(s). Ha ving a single Hub makes system with this architecture easy to ma nage but scalability takes a hit. At some point of time as number of messages increase, sc alability gets dependent on hard ware. Having a bigger b ox to scale application h as n ever been an ideal so lution so t o ov ercome t his l imitation m ost v endors have incorporated the concept o f federated hu b an d spok e arch itecture in wh ich mu ltiple hubs can be present, each h ub would have l ocal m etadata an d ru les as w ell as globa l metadata. Changes to gl obal rules and meta data are automatically propagated to other
Page 3 of 6
EAI vs. SOA vs. ESB hubs. Fed erated hu b spoke archi tecture al leviates scalability issue while c entral management of mu ltiple h ubs mak es t his arch itecture easy t o man age an d brings dow n support cost.
3.2 BUS Bus archite cture uses a central messaging backbone (bus) for message propagation. Applications would p ublish messages to b us using adapters. These messages would flow to subscribing appl ications u sing me ssage bu s. Su bscribing appl ications w ill h ave adapt ers which would take mes sage from bus and transform the message into a format required for the applicat ion. Key difference between hub/sp oke and bus topology is that for the bus architecture, the i ntegration engi ne that perf orms message transfo rmation and routing is distributed in the applic ation adapters and bus architectur e requires an application adapte r to run on the same platform as the original applications. Since adapters have i ntegration engi ne and run o n sa me pl atform on w hich source a nd target appli cations ru n, t his scales mu ch bet ter an d is complex t o main tain compared t o hub/spoke topology.
Page 4 of 6
EAI vs. SOA vs. ESB
4 ESB Enterprise service bus is an infr astructure to facilitate SOA. It gi ves API which can be used to develop services and makes services interact with each other reli ably. Technically ESB is a messaging backbone which does protocol conversion, message format transformation, routing, accept and deliver messages from variou s services and application which are linked to ESB. Current EAI landscape is seeing many vendors who offer enterprise se rvice bus and claim it to be a brand new concept. This brings a question on what exactly is the difference between ESB and the bus based imp lementations which have been there in market for quite a long time now. Actually there is not much difference between E SB and proprietary buses except for a few s ubtle ones. Main difference between ESB and proprietary bus implementation is of cost which is sign ificantly low for E SB. Reason f or this cost diff erence is t wo f old, f irst proprietary bus of fers lot of bu ilt in f unctionalities as a s uit of produ ct wh ich need t o be developed for ESB implementations based on business requirem ent, second most proprietary buses use some pr oprietary for mats to enhance the performance and that increases the cost. ES B on the other hand is us ually st andard based, so it is a t radeoff between performance and cost be tween proprietary bus and E SB. Main advantage of ESB is that it costs much less then hub/spoke or b us based product suits and that it is standard based.
5 CONCLUSION Following table give a quick comparison of hub/spoke, bus based product suits and ESB. Also all these three architectures can be service oriented depending on implementation which is reflected in this comparison.
Evaluation Parameter
Installation Effort
Administration
Cost
Hub Architecture
Less installation effort compared to solutions with bus architecture. Easy to maintain and administrate because of central hub. High
Bus Architecture Proprietary bus based product suit Moderate effort
ESB
Administration may be complex depending upon the integrated systems High
Administration may be complex depending upon the integrated systems Low cost because it does not use proprietary formats to enhance performance. Also it does not provide all the services usually provided by proprietary product suits.
Moderate effort
Page 5 of 6
EAI vs. SOA vs. ESB Scalability
Standards
SOA
High if federated architecture is used otherwise limited by the hardware of box used to host Hub Mostly standard based but may use proprietary internal formats Can be implemented as service oriented
Highly scalable
Highly scalable
Mostly standard based but may use proprietary internal formats Can be implemented as service oriented
Standard based
Service oriented
SOA brings cost effective, reusable and low le ad time solutions to an organi zation but EAI and SOA are both going to coexist. Web servic es alone as SOA can not handle the complex, secure and SLA base d applications of a n enterprise currently and unless we see a technological break through it is going to remain that way. Enterprise service bus would enable low cost integration and wo uld be used by companies with limited IT resources and environments that involve a handful of systems and moderate transaction volumes. Packaged EAI solution s woul d ha ve SOA as basi c tenet and wo uld continue to be used for large scale integration by companies having huge number of diverse system a nd high transaction volumes. Next generation EAI sol utions would use more an d more of SOA to provide reliable, secure, low cost and flexible solutions.
6 TAKEAWAYS SUMMARY 1. SOA brings cost effective, reusable and low lead time solutions to an organization but EAI and SOA are both going to coexist. 2. SOA is more then web services, in fact web services alone can not handle the complex, secure and SLA based applications of an enterprise. 3. Enterprise service bus would enable low cost integration and would be used by companies with limited IT resources 4. Packaged EAI solutions in future would have SOA as basic tenet and would continue to be the prime choice for large scale integration.
Page 6 of 6