JBI与SCA的区别

最近我在做有关ESB的开发工作，发现我们的产品（开源的Celtix  http://celtix.objectweb.org） 要支持JBI和SCA两个标准。这让我困惑了好久，JBI和SCA有什么区别呢？

前几天好好在网上收罗了一番，现在把收获到的东西和大家分享一下：

JBI definition http://www.theserverside.com/news/thread.tss?thread_id=35053

SCA 与JBI的区别 http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html

上面的链接有详细的讨论，我简单整理了一下。

JBI 的由来

Java One 2005 had a very heavy emphasis on JSR-208, Java Business
Integration. However, he says, "there seemed to be some folks with
confused looks on their faces in some JBI talks." As a response, he's
written a blog entry on what JBI actually is
<http://radio.weblogs.com/0112098/2005/07/07.html#a530>.

JBI是提供了一些简单的API定义， 这些定义包括 Normalized
Message Service , 在一个Router组件，以及一个管理模型用来管理服务
的部署集成，例如  routing engines, BPEL engines, rule systems, transformation engines

JBI提供了一个逻辑的XML消息网络， 这一网络能够很容易的映射到
HTTP, email 和 JMS/MOM ，并很方便地适应遗留系统，二进制地传输，
和RPC系统（EJB和CORBA)。 JBI可以看做是对JMS的更高层次的逻辑
抽象，并提供了不同的消息交换方式（ 单步， 请求应答等）

 

什么是SCA ，它试图解决什么样的问题？
WSDL 在增强应用之间的可连接性以及互操作性方面迈出了一大步。
然而，WSDL只关注了服务接口，它并不提供描述一个服务所依赖的其它服务，
以及这个服务所需要使用的配置策略和服务之间的依赖关系。

单独通过WSDL 很难实现服务之间的组合调用。

SCA比WSDL走的更远的方面是定义了一个服务组件模型以及一个服务组装模型。服务模型提供了比WSDL更多的功能，它允许服务开发者不单定义服务的接口而且还可以定义 这个服务和其他服务的依赖关系，以及这些交互（事务，安全，以及可靠 传输）之间的策略 还有服务所可能提供的配置功能。

一个SCA模型对等于一个SOA项目，模型允许开发者组装一组服务组件，解决引用依赖和使用策略。这是一个很大的进步，因为当前的SOA平台需要开发者自己获取那些私有的服务部署引用，甚至有时要在他们的服务实现中写hard code.

 

SCA与JBI的区别

SCA的美丽之处在用它关注的重点只是SOA开发这 所看到和接触到的。 SCA并没有关注用来执行SCA模块的runtime是如何构架的。 这个runtime可以实现为一个将所有的SCA服务组件编译成为Java classes的丑陋的单一服务，或者是一组模块化的引擎（每个组件一个的那种），这些引擎可以通过 一个企业服务总线来进行通讯。

JBI从另一个方面来说就是一组关注创建一个开发的，可扩这的以及标准组件的企业服务总线。 这样它的内核是和SCA有一些重合的地方。同时两者之间也存在互补的机制。

说它们互补，为什么不把他们绑定在一起呢。 这里有两方面的原因。
第一个原因 是JBI关注的是如果将一组引擎组装并运行 于一个JVM中。 相反SCA在另一方面并不将一个模块约束单个JVM中。 一个SCA模块可以执行在一个JVM中，同时它也可以很方便的将这些引擎部署在不同的进程甚至是不同的节点上。
第二个原因 是 SCA不但支持Java而且还支持C，在今后也许还会支持C#,php。 而JBI只是SCA的一个实现方式，而不是唯一的选择。

转自:http://jnn.blogbus.com/