My attempt is to present a simplistic view of my take on the purpose of an ESB (enterprise service bus) and SCA (service component architecture). This entry is in response to my esteemed colleague's commentary on "A decision makers concern about ESB " where in the two concepts of ESB and SCA were being compared. I must add that I am in complete agreement with Yogish on the fact that ESB vendors are adding to the confusion of what is and what is not part of the "core feature set" of an ESB.
My own opinion (misplaced it might be!!) is that ESB vendors tend to bundle a lot of "service creation"utilities and "adaptors" into the base ESB stack, in an attempt to achieve "product differentiation". This very act causes ESBs to become both ridden with "service behavior" which may also lead to "slow performance" of the ESB based mediation. The reason being that it becomes very difficult to performance tune an architecture component that is doing multiple things - it breaks the rule of "high cohesion" in doing "service mediation" and "service behavior execution"!!! The former is a high through-put pass through activity while the later could have fairly intense computation business logic or data processing logic.
Now back to the ESB vs. SCA topic.
ESB - promotes the abstraction of the service provider from the service consumer. Here it is assumed that the goal of exposing the service provider interface is to enable the reuse of the service provider business behavior. ESB' core theme being service mediation.
SCA - promotes the abstraction of wiring in of the external resource dependancies and external transport protocol bindings from that of the core and reusable business behavior of the service. Here the assumption is that the component parts of service provider can be re-assembled in various combinations to assemble services that are invoked from multiple consumer contexts. SCA' core theme being service assembly.
ESB enables service interaction/ mediation from multiple service consumer contexts while SCA enables service provider component parts to be assemble for "servicing" multiple service consumer contexts.
In both cases, the attempt is to decouple service usage from reusable service behavior.
Your comments on this topic are invaluable.
surekha -
Subscribe to:
Post Comments (Atom)
-
The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differen...
-
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
-
One of the key ingredient for success is clearly defining the roles and responsibilities within IT. There are multiple stake holders in IT w...
2 comments:
Surekha:
I think you are right on when comparing ESB and SCA. Another way to look at it, is to think in terms of how loose coupling is achieved. I have created this model of loose coupling:
http://www.ebpml.org/blog/40.htm
and an ESB is really about creating the code that bridges the internal interface with the external interface, while SCA is about assembling external interfaces with each other. This in particular why SCA can rely safely on interface signature as part of the assembly mechanism.
ARE YOU FED UP BY SEARCHING FOR A GOOD COLLEGE AND GOOD EDUCATION? DON’T WASTE YOUR
VALUABLE TIME, WE PROVIDE YOU DETAILS OF GOOD EDUCATIONAL COLLEGES AND OUR EXPERTS
WILL GIVE YOU GOOD COUNSELING ABOUT YOUR FUTURE. SO GO AHEAD AND click here
HAVE A BRIGHT FURTRE.
Post a Comment