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 ?

任何帮助AP preciated。

Any help appreciated.

推荐答案

其实他们是彼此完全不同。 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之间合作开发的技术。它是更远文摘服务一个步骤的方法。例如，如果您使用HTTP上的SOAP的Web服务，或者你使用JMS，或者你使用JSON与HTTP POST。所有这些意味着一个特定的协议和有效载荷/消息格式。通常情况下，你必须硬code来表示，协议和格式在某些时候。如果你可以通过围绕什么是不关心底层协议的抽象形式？这就是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企业服务总线产品。我不知道如果它已被更名或没有，但我有它的工作在一个点，当它被这个名字闻名。这是一个产品，帮助实现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.

作为互补的，而不是互相矛盾的抽象的技术的另一个例子，见的问题优点SCA遍地开花我的回答（和其他答案）

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屋！