SCA(服务组件架构)和 ESB(企业服务总线)的区别? [英] Differences between SCA (Service Component Architecture ) and ESB (Enterprise Service Bus)?

问题描述

我已经开始学习软件架构，并且遇到了这些术语ESB 和SCA.现在我发现这些术语非常令人困惑，因为它们似乎具有相同的目的(我知道这对于掌握这些主题的人来说仍然很荒谬).

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 ?

感谢任何帮助.

推荐答案

实际上它们彼此有很大不同.ESB 代表企业服务总线.它是一种用于如何分离您在整个企业中使用的服务的模式.它还是某种类型的交通警察，将消息(同样是模式，而不是技术)路由到不同的服务，并将这些消息转换为服务的预期格式和协议.

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 代表服务组件架构.它是 IBM 和 Apache 合作开发的一项技术.这是一种进一步抽象服务的方法.例如，如果您将 SOAP over HTTP 用于 Web 服务，或者您可能使用 JMS，或者您可能使用带有 HTTP POST 的 JSON.所有这些都意味着特定的协议和有效载荷/消息格式.通常，您必须在某个时候对该协议和格式进行硬编码".如果您可以传递一种不关心底层协议的抽象格式怎么办?这就是 SCA 给您的东西.您与 SCA API 前端的服务交互.在这些服务定义背后是实际使用的格式/协议.

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.

现在，这些听起来有点竞争，但事实并非如此.您可以仅使用 SCA 或使用 ESB 模式来开发整个基于 SOA 的架构.或者……你可以用它们来相互补充.

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.

因此您可以定义 ESB 并使用 SCA 接口连接每个服务.这允许您的总线在 SCA 接口之间转换消息并将消息路由到这些服务.SCA 负责隐藏/抽象这些服务的底层格式和协议.

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.

作为产品示例.....，IBM 有一个名为 WebSphere Enterprise Service Bus 的产品.我不知道它是否已更名，但我曾与它合作过，当时它以该名称为人所知.这是一个帮助实现 ESB 模式的产品，并为您提供了将系统作为服务公开的工具.WESB(简称为)也使用 SCA 作为连接这些服务的手段，即使这些服务是 SOAP/HTTP、JMS、MQ、JSON 等.

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.

作为抽象技术相互补充而不是冲突的另一个例子，请参阅问题Advantages ofSCA over Spring 和我的答案(和其他答案)

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)

这篇关于SCA(服务组件架构)和 ESB(企业服务总线)的区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！