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

Question

I began to study software architectures, and I came across these terms ESB and SCA . Now I have found these terms rather confusing, since they seem to serve the same purpose (I know that this may seem ridiculous to the people of the masters in these topics, nonetheless).

Can someone explain the differences?

Any help was appreciated.

Answer 1

In fact, they are very different from each other. ESB stands for Enterprise Service Bus. This is a template to separate the services that you use in your enterprise. It is also a cop of traffic, routes messages (again a template, not a technology) to various services and converts these messages into the expected format and protocol of services.

SCA stands for Service Component Architecture. This is a technology that was developed jointly between IBM and Apache. This is a way to abstract services one step further. For example, if you use SOAP through HTTP for a web service, or maybe use JMS, or maybe use JSON with HTTP POST. All of them imply a specific protocol and payload / message format. Usually you should “hard code” this protocol and format it at some point. What if you can convey an abstract format that does not care about basic protocols? This is what SCA buys from you. You interact with services that are open using the SCA API. And behind these service definitions, the actual formats / protocols used are used.

Now these sounds are competing, but it is not. You can create an entire SOA-based architecture using only SCA or using an ESB template. Or ... you can use them to complement each other.

In this way, you can define an ESB and connect each of its services using SCA interfaces. This allows your bus to translate messages between SCA interfaces and forward messages to these services. And SCA takes care of hiding / abstracting the basic format and protocol of these services.

Thus, they really do not contradict each other. Just different abstractions to help solve different problems. Abstractions that can be complementary.

As an example of a product ..... IBM introduced a product called WebSphere Enterprise Service Bus. I do not know if he was rebranded or not, but I worked with him at some point when it was known by that name. It was a product that helped implement the ESB template and provided tools to expose systems as services. WESB (as it was called short) also used SCA as a means to connect these services, even if the services were SOAP / HTTP, JMS, MQ, JSON, etc.

For another example of abstraction technologies that complement each other and not contradict each other, see the SCA Advantages over Spring question and my answer (and other answers)