关注SCA

Javax 即JavaExtension 是在Java2时才引入的。基本上很多以javax开头的包里面的类都不是具体实现类。大多是接口或者抽象类。

举个例子 如果你不用DOM4J 或者JDOM之类的话， 你持有的对象Document是一个接口。
所以你肯定不能这么写

Document doc = new Document();

你只能这样

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse();

要三步。
你是不是觉得sun 很傻， 对比微软阵营中使用
Set xDoc = New MSXML.DOMDocument
或者
xDoc = Server.CreateObject( "Microsoft.XMLDOM" )等方法，这样来真是太复杂了，太过度了

万事都是有原因的，以后大家就逐渐明白了。

回到DocumentBuilderFactory ， 我们发现它是抽象类，虽然newInstance() 是个实体方法，
再去看这个方法， 我们就知道了
在编译期， 我们根本不知道会拿到一个怎样的DocumentBuilderFactory 实现， DocumentBuilder 实现，Document 实现：这些统统都是接口，告诉我们这些对象有哪些操作。
到了运行期，取决于运行环境， newInstance() 方法里面会定位到它们的具体的实现类。

注意，具体的实现类是JVM知道的， 严格上来说，你仍旧无法把接口cast成一个具体实现类， 按道理你也根本不应该这么做。

当我们引用Javax包里的类时，都是这么一个过程， 我们都在面向接口编程， 我们的程序不依赖于哪个具体实现。 我们的程序架构就是面向服务的(SOA)。

如果你用javax包里的类， 你都是自觉不自觉的面向接口编程，在一个复杂系统里面，如果很多类都以接口形式暴露，这样实现者和调用者解耦合，无疑是一种比较好的架构。 但是要这么做，恐怕得需要一个注册器，把所有实现都注册到里面。因为javax里面的类有能力在运行期找到一个具体实现，我们自己写的类可不行。必须从注册器get到一个对象，并将其cast 成为需要的接口

EJB颁布了几年后，依赖注入，反转控制成了热门词汇。Spring成为了一个神秘的框架。Spring简单，对代码几乎没有侵入，也称为轻量级框架。不少人在极力推崇Rod的书， 从某种程度上来看，Spring完成了那个企业对象注册器的工作，从Spring自我介绍的第一条就能看出，当然现在Spring的贡献不止这些了。

* It addresses important areas that many other popular frameworks don't. Spring focuses around providing a way to manage your business objects.
* Spring is both comprehensive and modular. Spring has a layered architecture, meaning that you can choose to use just about any part of it in isolation, yet its architecture is internally consistent. So you get maximum value from your learning curve. You might choose to use Spring only to simplify use of JDBC, for example, or you might choose to use Spring to manage all your business objects. And it's easy to introduce Spring incrementally into existing projects.
* Spring is designed from the ground up to help you write code that's easy to test. Spring is an ideal framework for test driven projects.
* Spring is an increasingly important integration technology, its role recognized by several large vendors.

而在微软阵营， 这个注册器早已存在了，就是SCM和注册表，还有COM。 对Spring熟悉之后，再去看Essential COM， 肯定很有感觉的。

早在我们用VC VB写程序，使用任何Windows组件时，通常在编译期，只有接口在和我们打交道，我们不知道也不关心其实现是什么。运行时，windows 会替我们加载这个实现。当Java将一切推倒，并且面临着一些更为复杂的企业情况而奋力前进时，突然回头看看才发现其实走的并不远。

下面是Essential COM里面讲述COM的一张图。

现在话又说回来了， 这张COM体系结构图和现在的J2EE架构真的很像， 当然，这里面好像没有组件依赖情况的处理，组件依赖会产生很多情况，以后可以考虑一下组件依赖意味着什么又带来了哪些问题。

但这张图也反映出了一个重要问题，就是企业容器或者中间件要做哪些工作。 SCM是服务控制管理器，需要服务提供者提供的， 而组件库和应用是其他应用开发者和组件编写者提供的，
一个体系架构不能把体系上的东西强加给应用和组件。
这也是Spring与EJB的区别，也是EJB不成功的原因。
在COM时代，SCM一旦把服务派发给应用后，根据服务组件的物理位置，存在进程内调用，进程间调用，远程调用。 进程间和远程有个ORPC方式。到了Java世界，或许所有调用都要通过控制管理器来操作，通常服务管理器要能够控制、管理、调用服务组件，而客户通常只持有满足服务的一个代理实例，不会直接和服务组件交互了。

SCA，即Service Component Architecture (http://www.osoa.org)是SOA的一个工业规范
由J2EE大佬们推出的。07年3月21日 1.0正式版推出。

Tuscany 是一个SCA规范的具体实现。 实际上Tuscany和规范几乎是在同时发展中的，它给SCA规范也有不少的反馈作用。虽然是Apache下的一个孵化项目，Tuscany的Committer实际上都是IBM、Bea等J2EE厂商的正式员工。在IBM WAS6.1 SOA FeaturePack中，Tuscany已经成为了SOA的核心实现。由于Tuscany的ClassLoader很接近根，不得不让人猜想WAS7中或许Tuscany会成为WAS上众多组件的统一管理者。

其实Tuscany的主要职责是个服务管理者，用抽象代理模式比较能够更好地理解它。
每次客户请求一个服务时，Tuscany都会返回一个代理实例，当调用代理实例的方法时，Tuscany会把这个请求转发给实际的接口的实现者。

这个实现者可以是一个Java类，是一个EJB服务，或者是一个WebService。 Tuscany提供了一个Extension机制，用户可以增加自己的实现方式，实际上就是编写一个调用实现方式的stub。
一般来说，无论实现者运行在与Tuscany一个JVM中还是其他的容器中，请求和回应都被封装成了一个消息。服务请求者的运行环境中，必须要有一个Tuscany运行时，这样请求者才能通过sca-api获取服务，sca-api也是SCA规范定义的一组存取服务的接口。

从这点上来看，SCA和Tuscany真的结结实实的成为一个工业版的Spring。

在SCA规范发布后，项目出现了分支。原因我们就不得而知了， 好像所有非IBM的成员都离开了， 他们又创立了一个开源项目fabric3
这个开源项目起初host在googlecode上，后来转移到了codehaus中，可以通过http://fabric3.codehaus.org 来访问。
在这个新项目中，他们决定要完成一个事情，就是Federated Deployment.

Fabric3是一个很有趣的项目，如果他们能坚持做下去的话，会有很好的结果。因为它声称有能力将组件部署到不同的物理机器上，而fabric3如果被证明是好用易用而且还高效，那它真的会比Spring更Magic了。 Fabric3的一个主要成员是Bea的，那么Fabric3会不会成为WebLogic的核心组件呢？ 很难说了，因为Fabric3自从分出去后，感觉很冷清