Ant 将提供了很多可以重用的task，例如 copy, move, delete 以及junit 单元测试Maven 则提供了很多可以重用的过程。 我们可以把 Maven 看成是一个 "build container"这个容器可以让我们重用从一系列的项目中抽像出来的build过程。

使 用过Ant的朋友都会有这样的体会吧。 Ant提供的task级别描述，我们可以通过想写shell一样一个Java项目的build过程来进行描述。我们可以写好一个build.xml 文件，来解决我们在Java程序运行编译过程中需要解决的classpath，以及相关参数的配置问题，只有是项目中的主要结构以及依赖的库不变，我们很 少去修改build.xml。但是如果我们要开发一个新的项目即使原有项目的build.xml写的即使再好，其能够复用得模块还是比较少的。特别是对项 目的结构进行修改后，想不修改build.xml都很困难。这是因为Ant 所提供的可重用的task粒度太小，虽然灵活性很强，但是我们需要纠缠很多细节的东西。

正 如你所在使用Servlet 容器时，并没有告诉它如何去解包WAR文件，在你使用Maven 时，你也不需要告诉Maven 如何build你的项目。 Maven提供了一套抽象层用来分离项目的build 逻辑。 许多人一开始就被Maven所提供的依赖管理（可以通过XML来描述项目所依赖的库的关系）打动，但是使用Maven的主要好处还是它能为提供一个标准的 开发构架用来对多个项目进行管理。 依赖管理只是这个标准开发构架所提供的一个副产品。

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

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的一个实现方式，而不是唯一的选择。

使用过Log4J 的朋友应该有这样酷的体会，通过修改配置文件可以很方便得实现对应用程序的日志行为进行定义，而这些都不需要修改任何的应用程序代码。也许你会说，这些在Java中是很容易实现的（使用classforname 就可以很容易实现了）。

但是对于使用C++来进行日常开发的朋友，如果要实现这样的功能又如何来做呢？因为C++语言本身并不支持这样的通过读取配置文件动态创建对象的功能。