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.