转自:http://jnn.blogbus.com/
最近我在做有关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
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的一个实现方式，而不是唯一的选择。
====================================================
多少年来，Three Tier的架构似乎已经成为了教科书式的软件体系范本。它不断地提高软件灵活性和高聚合性的，时至今日，当软件复杂度更上一个数量级的时候，这种体系也开始孕育又一次重生。这就是最近的Buzz Words: SOA，也即SCA + SDO
受CHRIS在BLOG上所托，稍微关注了一下这方面的。
其实SDO已经有比较长的历史了，IBM去年就在从事该规范相关的开发。
而SCA相对来说更新鲜一些，主要是针对在面向服务的计算环境里，组件的实现方法。同时，它强调了这些组件与现有的平台，组件之间的关联，并描述怎样通过已有的技术、平台甚至于现有的组件来实现面向服务组件。另外，在将这些服务组件实现以后，它们的接口以及这些接口的语义是怎样描述的。其实，新的组件描述应该是技术独立、平台独立、语言独立的，也就是说它是一个开放的规范，这样就可以让很多IT厂商在不同的平台上用不同技术和语言来参考和实现这些技术。
除此之外，面向服务的组件需要相互之间的交互，这种交互应该是松耦合的，也就是说需要打破过去那种紧耦合的现象。因为不管是.NET、J2EE还是更早的CORBA等技术，它们在支持分布式计算时，其组件往往和平台、语言以及实现技术紧密相关。
过去，如果一个组件要调用另外一个组件的功能，它需要知道后者的接口在什么位置，使用什么协议和消息格式，这往往与其实现技术有直接的关系，所以技术、平台、语言和位置等各种各样的因素的透明性对于组件之间的交互就是非常重要的一件事情了，而SCA恰恰就规定了这一部分的内容。
另以方面，SDO其实与SCA是一对具有对应关系的规范。我早先就说过:软件=服务+数据。SCA更加关注业务逻辑，而SDO则更侧重于业务数据。
过去我们所采用的技术中，不管是.NET也好，J2EE也好，它们都有基于自身平台下的规范，比如在J2EE环境下，我们就会通过JDBC、Entity Bean这样的方式访问数据库或者其它数据源;而在.NET下同样有类似ADO这样的方式来访问各种不同的数据源。这里面的问题在于，平台透露了太多的技术细节，程序员需要了解很多相关的内容，比如他需要创建一个JDBC或ODBC的数据源，再利用这些规范所提供出来的编程接口来想办法得到数据源中的数据，为达成这个目标，程序员还需要去做对象-关系映射，以实现对象到关系数据库或者与之相反的数据转换。目前有一些技术可以用来解决这些问题，比如前段时间在Java社群中一直都非常流行的Hibernate等，诸如此类的方法和工具很多，他们都是用来协助程序员处理上述工作的。但无论如何，你都无法逃避地要看到很多这些方法中非常底层的技术细节，而且，程序员需要学习所有这些不同的技术，了解它们适应于什么情况，处理各种情况下的不同技术细节。事实上，程序员需要抽象层次更高的东西，比如业务数据对象(Business Object)以及它内部各种细粒度数据对象之间的关联，这是可以用一致、通用的方式来表示和操作的。有了抽象层次更高的模型，程序员就可以通用的方式来定义和访问业务数据，从而以统一的方式来描述和访问不同的数据源，降低对程序员技能的要求，提高生产率，更容易在不同的应用环境交换。
这样，不管是Java或者C++语言描述下，程序员都不必去了解平台上的技术细节，用一个XML Schema描述这样的通用、简单的的业务数据模型，然后在运行将对象持久化到你的关系数据库、XML或者其它数据源中。
从技术上看，SDO规范做了如下几件事情:它定义了一个连接器，可以使用JDBC、ADO等各种不同的方式去和多种数据源交互，数据源也是多种多样，不单单局限于关系数据库，也可以是不同类型的XML文件，甚至是内存中的一块区域。同时它还提供诸如连接池、缓存(Cache)、断开连接时数据访问(Disconnected Access)等高级特性，提供了跨越B/S,C/S的边界。
另外，SDO还定义了一个中介转换器(Mediator)，它与连接器交互，来完成数据持久化的工作，这个协调器能够理解我们定义好的Schema，让程序员能直接看到一个直观的对象图表(Object Graph)。它根据业务的语义定义一个完整的Schema，不仅能清晰地定义各种数据对象，而且还能有效地描述各种对象之间的联系，充分利用了XML强大的自描述能力。通过它，人们可以很方便的操纵数据对象。
综合起来说，SCA/SDO都是基于已有的技术，它们所要做的就是怎样在现有技术的基础上，为异构、分布的松耦合计算环境提供一个统一、开放的组件及其服务的描述。
IBM在其SCA的实现中，也就是WPS 6.0所提供的SCA运行时环境，有多达八种不同的组件实现形式可供选择。我想更理想的实现应该是提供一个可以扩展的接口。即使在语法上、数据结构上有很大的不同，甚至是某公司自己语义上的东西，也可以方便地纳入SOA的架构里。
这样一个规范目前受到了IT技术主流的技术厂商的支持，它的建立为基于SOA的下一代计算环境下的编程模型打下了一个坚实的基础。
与古老的CORBA技术(请允许我用这样的词来描述它，呵呵～)想比，两种技术的背后都有很一致的哲学。但是受限于当时的技术发展条件，我们回顾历史的时候，CORBA在很多细节上的处理并不是太好，而且，CORBA是基于面向对象思想的，与之不同的是SCA基于面向服务的思想，其实抽象程度要相比过去的提高很多。
这里我引用一下Gartner的报告:
- 随着商业和技术的推动，SOA将成为将来的发展趋势已经没有人怀疑了;
- 2007年，超过50%以上的公司将SOA作为IT战略来考虑;
- 2008年还没有将SOA引入到公司的IT实现中去，那么该公司将成为一只恐龙，也就是说这个公司很落后了。
目睹这些年软件的迭代更新，我有时也在想，是不是这就是软件自己的“摩尔定律”，所不同的是，用来度量软件的不是单晶片上可以集成的晶体管数，而是单个软件工程师所能Handle的软件复杂度，姑且叫它"logic per brain"吧。
