SCA与JBI的联系与区别

最新推荐文章于 2020-12-03 15:15:44 发布

Blugel

最新推荐文章于 2020-12-03 15:15:44 发布

阅读量3.1k

点赞数

分类专栏：大赛文档文章标签： binding assembly 扩展引擎 java 语言

大赛文档专栏收录该内容

4 篇文章 0 订阅

订阅专栏

原文见：http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html

1 SCA是什么

WSDL的弱点:

WSDL在应用之间提高了连接性和可互操作性.但是,WSDL仅仅聚焦于一个服务的接口,不含服务依赖其他服务以及服务和它的依赖之间采取什么策略配置的任何信息.

SCA一方面超越WSDL,定义了服务构件模型和服务组合模型. 服务构件超越了WSDL,允许服务开发者定义服务的接口,还可以定义服务对其他服务的依赖,还可以定义交互之间的策略(事务、安全、可靠传输等)，以及服务可展示的潜在配置接口。
SCA不干涉服务的实现。可以用任何语言实现SCA构件

图1

SCA定义了服务Assembly的标准－SCA Module。以前的构件开发以专有的部署描述符或者硬编码的方式获得服务与依赖之间的引用从而来Assembly服务。

图2

另一方面，SCA定义了一个框架，让开发者可以以POJO的方式轻松开发构件：SCA提供了一套注解，例如用于把POJO转换为服务、会话管理、异步通信等。

构件和组装元数据对于SCA来说，其实现是不限制的、可扩展的。

注解1：构件与装配元数据对实现不可知且可扩展的，所以能很方便的扩展对C#或其他你想用来实现服务的语言/模形的支持。

注解2：SCA包括了这样的一个binding的概念：它允许multiple services在被组装起来时，不要求需要SOAP（SCA能提供殊如：REST binding, Java Binding, JMS binding。）这些都是对WSIF的进一步的改进。

2 JBI和SCA的区别

SCA的一个亮点就是它只聚焦于SOA开发人员所见到的和所接触到的东西。SCA并不关注于SCA的module在被组装后是如何执行的。执行可以是以单服务器的方式来运行，服务器把SCA服务组件编译成Java类; 或者执行能被实现成modular的引擎集（每个组件类型是一个引擎）通过ESB来使得它们之间进行交互。

JBI在另一个角度来说是一些聚焦于建立一个开放、可扩展、模块化的ESB的API集。所以SCA和JBI在核心上说是很少重叠的。相反，我认为他们之间是相互补充的。

假如它们之间是相互补充的，为什么不把它们集成起来呢？这里有2个原因，1）JBI聚焦于把同一个JVM内运行的引擎组装起来；而在别一方面，SCA并不限制于在一个JVM中，它能使引擎集在不同的进程中很好的交叉运行，甚至可以在不同的Nodes上。2）JCA不仅支持Java，还支持服务的其他语言的实现如C，在将来还将支持C#，PHP等。所以说JBI是实现SCA系统的一种方式，不是唯一的方式。