architecturesoaesbsca

Differences between SCA (Service Component Architecture ) and ESB (Enterprise Service Bus)?


i have started learning about Software architectures and i came across these terms ESB and SCA. Now these terms i found quite confusing as they seems to serve the same purpose (i know this could sound ridiculous to people masters in these topics, still).

Can anybody please explain the differences ?

Any help appreciated.


Solution

  • Actually they are quite different from each other. ESB stands for Enterprise Service Bus. It is a pattern for how to decouple services that you use across your enterprise. It is also a traffic cop of sorts, routing messages (again the pattern, not the technology) to different services and transforming those messages to the expected format and protocol of the services.

    SCA stands for Service Component Architecture. It is a technology that was developed collaboratively between IBM and Apache. It is a way of abstracting services one step farther. An example, if you use SOAP over HTTP for a web service, or perhaps you use JMS, or perhaps you use JSON with HTTP POST. All of those imply a particular protocol and payload/message format. Normally you have to "hard code" to that protocol and format at some point. What if you could pass around a abstracted format that doesn't care about the underlying protocols? This is what SCA buys you. You interface with services fronted by the SCA APIs. And behind those service definitions are the actual formats/protocols used.

    Now, these sound sort of competing, but they are not. You could develop an entire SOA-based architecture using just SCA or using an ESB pattern. Or....you can use them to complement one another.

    So you can define an ESB and connect each of your services using SCA interfaces. This allows your bus to transform messages between the SCA interfaces and to route messages to those services. And the SCA takes care of hiding/abstracting the underlying format and protocol of those services.

    So they really aren't in contention with one another. Just differing abstractions to help resolve differing problems. Abstractions that can be complementary to each other.

    As a product example....., IBM had a product called WebSphere Enterprise Service Bus. I don't know if it has been rebranded or not, but I worked with it at one point, when it was known under that name. This was a product that helped to implement the ESB pattern and provided tools for you to expose systems as services. WESB (as it was called for short) also utilized SCA as its means of connecting those services, even if the services were SOAP/HTTP, JMS, MQ, JSON, etc.

    As another example of abstraction technologies complementing each other, rather than conflicting, see the question Advantages of SCA over Spring and my answer (and other answers)