导致线程死亡的的最主要的原因是RuntimeException。因为这些异常表明一个程序错误或者不可修复的错误，它们不着顺着栈的调用传递，此时，默认的行为是在控制台打印栈追踪的信息，并终止线程。

　　我们举个例子，将奴隶主比作是你写的程序，奴隶比作是线程。假如你是奴隶主，你手下有5名奴隶，你分派他们一项任务去将不断开采来的石头搬到某个地方。如果中途有奴隶逃跑，那么搬运石头的效率就会下降，如果你没有措施发现奴隶逃跑，最后连一个奴隶也没有了，没有人再去搬石头了。当你发现程序有问题，比如程序刚启动的时候处理速度很快，以后越跑越慢，最后完全停止了，你可能不知道问题出在哪儿，其实这都是因为线程泄露引起的。想解决奴隶逃跑问题，不难，给每个奴隶戴上个报警器，一逃跑报警器就给你发信息，告诉哪个奴隶，因为什么原因逃跑了，可以根据需要再增加一名奴隶，让搬石头的奴隶数量始终维持在5名或着将信息记录到文件，便于分析导致线程泄露的原意改进程序。ok,我们用代码说话

１、定义好报警器

Java代码  

1. package com.bill99.thread.test;   
2.   
3. import java.lang.Thread.UncaughtExceptionHandler;   
4.   
5. //将泄露的线程信息输出到控制台   
6. public class UEHLogger implements UncaughtExceptionHandler {   
7.     public void uncaughtException(Thread t, Throwable e) {   
8.         System.out.println(String.format("不好了，有奴隶逃跑了!奴隶姓名：%1$s,编号：%2$s,逃跑原因：%3$s", t.getName(),t.getId(),e.getMessage()));   
9.         System.out.println("还剩"+HelotPool.helotPool.getActiveCount()+"个奴隶");   
10.     }   
11. }  

package com.bill99.thread.test;

import java.lang.Thread.UncaughtExceptionHandler;

//将泄露的线程信息输出到控制台
public class UEHLogger implements UncaughtExceptionHandler {
	public void uncaughtException(Thread t, Throwable e) {
		System.out.println(String.format("不好了，有奴隶逃跑了!奴隶姓名：%1$s,编号：%2$s,逃跑原因：%3$s", t.getName(),t.getId(),e.getMessage()));
		System.out.println("还剩"+HelotPool.helotPool.getActiveCount()+"个奴隶");
	}
}

２、我们先建立一个奴隶工厂，每名奴隶出工厂的时候都会有一个报警器

Java代码  

1. package com.bill99.thread.test;   
2.   
3. import java.util.concurrent.ThreadFactory;   
4. //奴隶制造工厂   
5. public class HelotFactory implements ThreadFactory {   
6.     private volatile int helotId=0;//奴隶编号   
7.     //产生一个新奴隶   
8.     public Thread newThread(Runnable r) {   
9.         Thread helotThread = new Thread(r);   
10.         helotThread.setName("helot-Thread-"+gethelotId());//设置奴隶姓名   
11.         helotThread.setUncaughtExceptionHandler(new UEHLogger());//UEHLogger就是报警器   
12.         return helotThread;   
13.     }   
14.     private int gethelotId(){   
15.         return ++helotId;   
16.     }   
17. }  

package com.bill99.thread.test;

import java.util.concurrent.ThreadFactory;
//奴隶制造工厂
public class HelotFactory implements ThreadFactory {
	private volatile int helotId=0;//奴隶编号
	//产生一个新奴隶
	public Thread newThread(Runnable r) {
		Thread helotThread = new Thread(r);
		helotThread.setName("helot-Thread-"+gethelotId());//设置奴隶姓名
		helotThread.setUncaughtExceptionHandler(new UEHLogger());//UEHLogger就是报警器
		return helotThread;
	}
	private int gethelotId(){
		return ++helotId;
	}
}

 ３、奴隶逃跑测试,看看是否会触发报警器

Java代码  

1. package com.bill99.thread.test;   
2.   
3. import java.util.concurrent.ThreadFactory;   
4. //奴隶逃跑测试   
5. public class HelotEscapeTest {   
6.     private ThreadFactory factory = new HelotFactory();   
7.     private Thread helotThread = null;   
8.        
9.     public HelotEscapeTest(){   
10.         Runnable task = new Runnable() {   
11.             int stoneNum=1;   
12.             public void run() {   
13.                 while(!Thread.interrupted()){   
14.                     System.out.println(helotThread.getName()+" 搬第"+stoneNum+"块石头..");   
15.                     stoneNum++;   
16.                     try{   
17.                         Thread.sleep(500);   
18.                     } catch(InterruptedException e){e.printStackTrace();}   
19.                     if(stoneNum>100){   
20.                         throw new RuntimeException("又饿又累没力气搬石头了");   
21.                     }   
22.                 }   
23.             }   
24.         };   
25.         helotThread = factory.newThread(task);   
26.     }   
27.     //开始干活   
28.     public void startWork(){   
29.         helotThread.start();   
30.     }   
31.     public static void main(String[] args) {   
32.         HelotEscapeTest test = new HelotEscapeTest();   
33.         test.startWork();   
34.     }   
35. }  

package com.bill99.thread.test;

import java.util.concurrent.ThreadFactory;
//奴隶逃跑测试
public class HelotEscapeTest {
	private ThreadFactory factory = new HelotFactory();
	private Thread helotThread = null;
	
	public HelotEscapeTest(){
		Runnable task = new Runnable() {
			int stoneNum=1;
			public void run() {
				while(!Thread.interrupted()){
					System.out.println(helotThread.getName()+" 搬第"+stoneNum+"块石头..");
					stoneNum++;
					try{
						Thread.sleep(500);
					} catch(InterruptedException e){e.printStackTrace();}
					if(stoneNum>100){
						throw new RuntimeException("又饿又累没力气搬石头了");
					}
				}
			}
		};
		helotThread = factory.newThread(task);
	}
	//开始干活
	public void startWork(){
		helotThread.start();
	}
	public static void main(String[] args) {
		HelotEscapeTest test = new HelotEscapeTest();
		test.startWork();
	}
}

 运行程序后，奴隶在搬完100块石头后不干了，报警器给出提示信息

   不好了，有奴隶逃跑了!奴隶姓名：helot-Thread-1,编号：7,逃跑原因：又饿又累没力气搬石头了

这样我就能找出线程泄露的原因了。如果在线程池中发生了泄露是否也能记录？

4、奴隶池测试

Java代码  

1. package com.bill99.thread.test;   
2.   
3. import java.util.Random;   
4. import java.util.concurrent.BlockingQueue;   
5. import java.util.concurrent.LinkedBlockingQueue;   
6. import java.util.concurrent.ThreadFactory;   
7. import java.util.concurrent.ThreadPoolExecutor;   
8. import java.util.concurrent.TimeUnit;   
9.   
10. public class HelotPoolTest {   
11.        
12.     public static ThreadPoolExecutor helotPool;   
13.     private int helotNum= 5;  //奴隶数   
14.     private Random random = new Random(100);   
15.        
16.     private BlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>();   
17.        
18.     public HelotPoolTest() {   
19.         ThreadFactory factory = new HelotFactory();   
20.         helotPool = new ThreadPoolExecutor( helotNum,helotNum,1000,TimeUnit.SECONDS,queue,factory);   
21.     }   
22.     //分配任务   
23.     public void assignTask(){   
24.         final int MAX=100;   
25.         final int MIN=10;   
26.         Runnable task = null;   
27.         for(int j=0;j<20;j++){   
28.             task = new Runnable() {   
29.                 int stoneNum = random.nextInt(MAX - MIN + 1) + MIN;// 生成10~100范围的随机数   
30.                 public void run() {   
31.                     for (int i = 1; i <= stoneNum; i++) {   
32.                         System.out.println(Thread.currentThread().getName() + " 搬完"+ i + "块石头");   
33.                         if (i == 60) {   
34.                             throw new RuntimeException("搬完第60块石头不干了");   
35.                         }   
36.                         try{   
37.                             Thread.sleep(100);//休息下   
38.                         }catch(InterruptedException e){e.printStackTrace();}   
39.                     }   
40.                 }   
41.             };   
42.             queue.add(task);   
43.         }   
44.     }   
45.     //开始干活   
46.     public void startWork(){   
47.         helotPool.prestartAllCoreThreads();   
48.     }   
49.     public static void main(String[] args) {   
50.         HelotPoolTest pool = new HelotPoolTest();   
51.         pool.assignTask();   
52.         pool.startWork();   
53.     }   
54. }  

package com.bill99.thread.test;

import java.util.Random;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class HelotPoolTest {
	
	public static ThreadPoolExecutor helotPool;
	private int helotNum= 5;  //奴隶数
	private Random random = new Random(100);
	
	private BlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>();
	
	public HelotPoolTest() {
		ThreadFactory factory = new HelotFactory();
		helotPool = new ThreadPoolExecutor( helotNum,helotNum,1000,TimeUnit.SECONDS,queue,factory);
	}
	//分配任务
	public void assignTask(){
		final int MAX=100;
		final int MIN=10;
		Runnable task = null;
		for(int j=0;j<20;j++){
			task = new Runnable() {
				int stoneNum = random.nextInt(MAX - MIN + 1) + MIN;// 生成10~100范围的随机数
				public void run() {
					for (int i = 1; i <= stoneNum; i++) {
						System.out.println(Thread.currentThread().getName() + " 搬完"+ i + "块石头");
						if (i == 60) {
							throw new RuntimeException("搬完第60块石头不干了");
						}
						try{
							Thread.sleep(100);//休息下
						}catch(InterruptedException e){e.printStackTrace();}
					}
				}
			};
			queue.add(task);
		}
	}
	//开始干活
	public void startWork(){
		helotPool.prestartAllCoreThreads();
	}
	public static void main(String[] args) {
		HelotPoolTest pool = new HelotPoolTest();
		pool.assignTask();
		pool.startWork();
	}
}

 程序启动，用Jprofiler监控，刚启动时会有5名奴隶干活不一会就会有线程退出，最后5个线程全部退，报警器对每个线程退出都能记录到导致线程退出的原因。标准的Executor实现是:

在需求不高时回收空闲的线程，在需求增加时添加新的线程，如果任务抛出了异常，就会用一个全新的工作线程取代出错的那个。

JDK文档是这么说的，不过通过Jprofiler监控只有在5名奴隶全部逃跑，没人干活的时候ThreadPoolExecutor才会生成一个新线程继续搬石头，并不是只要一个线程退出就会马上生成新线程去代替。

引言

IBM 对 ESB 的立场是——并且一贯是——认为 ESB 作为 SOA 中的一种体系结构模式发挥了根本性的作用。ESB 是实现成功 SOA 采用的重要入口点，并且是任何面向服务的解决方案的关键成功因素。事实上，作为对 SOA 中的 ESB 承诺的一部分，IBM 提供了实现 ESB 模式的三个战略产品。

本系列的第 1 部分描述了企业服务总线 (ESB) 体系结构模式如何适应 IBM SOA Foundation，以及 ESB与 Foundation 的其他部分如何相关。

本文介绍以下主题：

• 设计良好和实现良好的 ESB 能够为面向服务的解决方案提供的价值
• 一些在设计和实现 ESB 时要遵循的最佳实践
• IBM 对作为 SOA 组成部分 ESB 的承诺

与 SOA 相关的 ESB

IBM SOA Foundation 白皮书描述了 IBM 交付 SOA 价值的整体方法。SOA Foundation 的参考体系结构（图 1显示了逻辑模型视图）的核心中具有 ESB。该参考体系结构的描述声明“ESB 的存在是简化服务调用任务的基础”。虽然该白皮书是在 2005 年末发布的，但是其中预述的论点却随着时间推移而通过我们在采用 SOA 的客户方面的经验得到加强。

本系列的第 1 部分表明了 ESB 是称为 SOA 的更大体系结构模式中的一个关键体系结构模式。充当中间层的 ESB 提供了服务交互中参与者之间的松散耦合连接，从而提供了 SOA 的中枢。作为中间层，ESB 执行服务虚拟化以协调服务请求程序和服务提供程序之间的差异，并提供面向方面的连接以用作诸如管理和安全性等 SOA 策略的执行点。松散耦合允许解决方案中的组成部分之间彻底分离关注事项（时间上、技术上和组织上的分离），从而同时支持业务流程和 IT 系统的灵活性和敏捷性。

通过 ESB 实现的松散耦合的部分优点（包括本系列的第 1 部分详细描述的服务虚拟化和面向方面的连接中所固有的优点）如下：

• 请求程序和提供程序不必就消息格式、消息传输甚至目标地址达成一致。
• 请求消息可由多个提供程序中的任何一个进行处理，请求程序不必显式地确定提供程序。这种路由可以基于相应的版本、服务质量或其他度量。
• 现有的请求程序无需更改即可连接到新的提供程序。
• 现有的提供程序无需更改即可对新的请求程序公开。
• 可以对请求程序做出更改而不影响提供程序，或者对提供程序做出更改而不影响请求程序。
• 解决方案的横切方面，例如安全性和管理等等，可由 ESB 进行添加、执行或加强。
• 可以实现新级别的动态行为，因为 ESB 能够为请求程序和提供程序之间的每个交互实时执行策略。

作为 SOA 入口点的 ESB

一次性全面采用 SOA 可能是一项艰巨的任务。IBM 已确定了五个SOA 入口点，这些入口点提供了有关如何开始渐进地采用 SOA 的指导。渐进的采用方法允许企业以最适合需要的方式和步调采用 SOA。为什么我们要确定五个入口点？简单的原因在于众口难调；企业的在成熟度级别和特定需求方面各不相同，适合于一家企业的入口点可能不适合于另一家企业。这五个入口点基于已导致我们的客户成功实现了 SOA 的方法。存在两种类别的入口点：

• 以业务为中心的入口点——人员、信息和流程——允许您从一种侧重于基本企业资产的方法开始。
• 以 IT 为中心的入口点——连接性和重用——允许您为 SOA 奠定技术基础。

您也许已经从SOA Foundation 白皮书中预料到，连接性意味着使用 ESB 来“通过更加安全、可靠和可伸缩的方法简化 IT 环境，从而在企业内外进行连接”。IBM 认为，虽然 ESB 无疑是一种以 IT 为中心的 SOA 方法，但是“它本身交付了实际业务价值，并且是将来的 SOA 计划的核心构件”。本文中的一个关键问题（将在下面进行讨论）是如何最好地使用 ESB 来形成将来的 SOA 计划的构件，以及如何通过连接性入口点获得最大的业务价值。

存在多种利用连接性入口点的方法。有时客户已经在其环境中定义了一些服务（也许是通过合作伙伴），不过是直接连接的服务；这种情况导致缺乏灵活性并增加管理成本。如上所述，在此类环境中插入 ESB 可以提供直接的松散耦合优点。此外，ESB 的存在为将来定义附加服务、创造附加重用机会、支持新的重用渠道、降低管理成本和获得更多敏捷性的工作创造了条件。

客户通常知道 ESB 的价值并渴望开始从 ESB 中实现好处，但是他们还没有在其环境中定义服务。我们看到了两种已采用过的成功技术，这两种技术帮助在这种情况下从 ESB 获得好处。客户经常混合使用重用和连接性入口点。他们确定需要作为服务来连接的功能或应用程序（请求程序或提供程序）。同时，他们将 ESB 插入该体系结构，以提供新的服务请求程序和提供程序之间所需的松散耦合。混合方法得以流行的一个重要因素是 ESB 产品的转换和变换功能。此类功能允许使用同一个 ESB 产品作为某种形式的适配器，以便以更加可重用的形式公开功能或应用程序，并提供所需的服务虚拟化和面向方面的连接。这里成功的关键是谨慎地开始，公开少量的服务并开发对应的中介，但是这些服务和中介都在为考虑中的整个最终范围而设计的体系结构之内。

有些客户插入 ESB 以建立组织中连接的所需方向，尽管起初还没有确定要连接的服务。在此情况下，ESB 是组织的总体参考体系结构的一部分；参考体系结构提供了体系结构方向，并强制要求最终将作为解决方案一部分而创建的所有服务（请求程序和提供程序）进行松散耦合连接。ESB 是用于实现该松散耦合的首选机制。采用 ESB 实际上消除了解决方案中的直接连接不知不觉地增长的可能性。这里成功的关键是：

• 采用一个要求并演示 ESB 使用的参考体系结构。
• 考虑解决方案的整个最终范围，并支持最佳的 ESB 产品选择。
• 随着解决方案的发展而实施强有力的治理，以确保利用 ESB 来连接到引入解决方案的新服务（请求程序和提供程序）。

SOA 入口点最佳实践

存在一组 IBM 强烈建议用于任何 SOA 采用的最佳实践。这些最佳实践的最重要元素是建立一个路线图并渐进地实现该路线图，该路线图定义了实现所需业务目标的采用计划（请参见参考资料部分以获得指向文章“Service Oriented Architecture:An Introduction for Managers”的链接）。该路线图包括两个重要组成部分：

1. 战略远景，业务或 IT 的方向陈述（包括参考体系结构和治理计划），可用作决策制定、组织参与和标准采用的指导原则。
2. 一组项目计划，定义实现项目以满足当前业务驱动因素的即时和将来需要。

此类路线图允许您渐进地实现 SOA，以在每个项目步骤中回报业务价值。

您应该在执行该路线图的早期确定您业务的最佳 SOA 入口点。您应该基于从您的总体战略远景和当前 SOA 成熟度级别得出的要求来选择该入口点。该入口点可能是也可能不是连接性入口点；它可能是上述入口点的混合。但是，连接性入口点是最普遍的入口点，因为有如此多的客户具有将请求程序连接到提供程序的即时需要，并希望获得 ESB 提供的松散耦合的好处。IBM 提供了一个在线工具Business Value Analyzer，以帮助您选择 SOA 入口点。

另一个最佳实践是建立治理框架以确保组织遵循该路线图（请参见参考资料以获得指向文章“SOA Governance and Service Lifecycle Management”的链接）。SOA 所促进的灵活性增强和跨组织性质要求组织建立治理框架，以实现主动的决策制定、准确的跟踪、改进的服务能力和更好的交流。有效的治理通过在增添价值的同时平衡风险和回报，从而帮助实现企业的业务目标。

正如上面所建议的，渐进的 SOA 采用是成功的关键。IBM 建议从试验项目开始，该试验项目：

• 处理得到充分了解、重要但不关键的业务需要。
• 实现参考体系结构的某些重要方面（也许是 ESB 和一组示例服务、提供程序、请求程序，这些方面用于演示 SOA 的使用）。
• 需要一个超出当前能力的可达范围。
• 积累 SOA 技能。
• 用作对采用 SOA 治理和新的服务生命周期管理流程所进行的试验。
• 产生将会投入生产应用并将交付投资回报的结果。

通过 SOA 实现的关注事项分离甚至允许试验项目以能够积累专业经验和验证业务价值但不中断主要操作的方式引入 SOA。

SOA 连接性入口点最佳实践

除了 SOA 最佳实践以外，还存在其他更特定于 ESB 的最佳实践：

• 仅当 ESB 在您的路线图中有意义时才采用 ESB。例如，如果 SOA 入口点以业务为中心，您可以推迟通过 ESB 实现的松散耦合，尽管您的参考体系结构中包括了 ESB。
• 基于您的参考体系结构和一组跨全套项目计划的实际要求来设计 ESB 并选择 ESB 产品。我们说实际是因为您应该集中于未来几年中的需要；到您超过该时间期限时，产品和需求已经发生了改变。如果仅考虑即时需求，尤其是忽略服务请求程序和提供程序的预期需要，则会导致选择非最优 ESB 产品。您必须明确地在公司的约束内行事，例如年度资金周期和预算，但您同时还希望将短期采购和决策与考虑中的长期（三至五年）目标保持一致。
• 根据情况考虑 ESB 联合。更大型的异构企业通常作为某种自治域的联合体出现，这些自治域基于各个业务部门或者职能或治理方面。在此类环境中，某些服务可以在单个域中进行共享或重用，而其他服务可以在整个企业中进行共享或重用。在这些情况下，我们建议采用某种形式的 ESB 联合，该形式的 ESB 联合与域联合的需要相匹配。ESB 联合允许在不同的域中使用不同的 ESB 产品，并支持域需求与产品功能之间的最佳匹配。路线图和参考体系结构应该为任何给定域的产品选择提供指导原则甚至选项，以确保实现企业范围的优化。我们进一步建议使用联合服务注册中心和存储库，为企业范围的管理和可重用服务的治理提供帮助。

您是否需要 ESB 来成功采用 SOA？

前面几个部分说明了从 ESB 开始成功的 SOA 之旅。另外四个入口点不需要 ESB 即可开始该旅程。然而 IBM 认为，无论其入口点是什么，绝大多数成熟的面向服务的解决方案都将包括 ESB，以最大化 SOA 中所需的敏捷性和灵活性。因此，虽然初始项目可以不包括 ESB，但是在您的长期业务和 IT 路线图中，ESB 应该是参考体系结构的一部分，以实现成功的 SOA。如果没有 ESB 提供的敏捷性和灵活性，您会发现在面临不可避免的变更时，管理解决方案将变得非常困难，并且开销很大。

这是否意味着在准备好包括 ESB 在内的所有体系结构组件之前，您还没有拥有真正的 SOA 呢？此问题没有正确或错误的答案，并且可能存在许多选项。在某种程度上，此问题并不重要——重要的是在实现新的 SOA 项目以及解决方案根据您的路线图逐渐变得成熟时，您要渐进地向业务交互越来越多的价值。

我们的客户好像同意这个观点。几乎我们的所有采用 SOA 的客户都从 ESB 开始，或最终在解决方案中使用了 ESB，并从 ESB 支持的灵活性和敏捷性中获得了重大的 IT 和业务价值。

IBM 的 ESB 产品系列

IBM 对 ESB 的重视及其对 ESB 的承诺体现在我们如何使用产品来履行对 SOA Foundation 的承诺上。IBM 推出了一个产品系列，其中包括三个实现 ESB 体系结构模式的产品：

• IBM WebSphere® Message Broker是一个成熟的产品，此产品在多年前就已实现了该模式。
• IBM WebSphere Enterprise Service Bus于 2005 年推出，此产品专门设计用于在侧重于标准的环境中实现该模式。
• IBM WebSphere DataPower Integration Appliance XI50于 2006 年推出，此产品以可容易地部署和管理的工具的形式封装了该模式。

为什么要推出三个产品？同样是由于众口难调。所有三个产品都实现了 ESB 模式，但是分别强调了使它们适合于特定情况的特定功能。您将在developerWorks上找到许多文章和IBM 红皮书®，编写这些内容的目的是为了帮助在面向服务的解决方案中使用这些产品。

结束语

本文再次强调了 IBM 一如既往的信仰，即 ESB 是称为 SOA 的更大模式中的一种基本体系结构模式。您通过阅读本文了解了 ESB 如何帮助从 SOA 获得业务价值，以及 ESB 如何成为成功的 SOA 采用的重要入口点——ESB 模式是如此重要，以致于 IBM 目前在 SOA Foundation 组合中推出了三个实现该模式的战略产品。

　　2005年11月， IBM、BEA、IONA、Oracle、S等几家厂商就合作建立新的业内规范来简化 SOA 应用发展达成了一致，共同发布了两项针对SOA的重要构件模型规范——SCA 0.9和SDO。此后，该团体陆续吸引了Red Hat、普元、TIBCO等多家公司的加盟，形成了OSOA（Open Service Oriented Architecture）联盟，目前成员数量达到18家。OSOA联盟旨在为SOA起草一系列的规范，并以免版税的许可方式提供给业界使用。AP

　　2007年3月，OSOA联盟宣布了SCA和SDO规范中关键部分的完成，发布了SCA 1.0和SDO 2.1，并将其正式提交给OASIS，通过其开放式标准过程进行推动。

　　SCA规范旨在简化服务的创建和合成，对于运用基于SOA方式服务的应用构建十分关键。随着SCA规范的完成，联盟合作厂商希望将其标准化过程提交给OASIS。此外，联盟厂商也已完成了SDO规范，旨在实现对多个站点中多种格式数据的统一访问，并将把SDO基于Java的规范开发和管理提交给Java社团过程（Java Community Process，JCP）组织，而基于非Java的规范（C++）提交给OASIS。

　　SCA和SDO规范能帮助企业更便捷地创建新的以及改造现有的IT资产，使之可复用、易整合，以满足不断变化的业务需求。这些规范提供了统一服务的途径，大大降低了在应用开发过程中，因程序设计语言与部署平台的不同而产生的复杂性。SCA和SDO规范都是用于简化业务逻辑和业务数据呈现的新兴技术。

　　“我们对OSOA联盟取得这一里程碑成就，并选择了在接下来通过开放标准过程继续推动这一重要工作表示欢迎和赞赏，”OASIS CEO和总裁Patrick Gannon说，“我们希望能进一步推进SCA规范，实现标准化，获得最广泛的行业应用。”

　　OASIS不只是研究和产生标准，同时也跟其他国际组织一起合作推动标准的采用和技术的发展。通过十多年的努力，OASIS已经得到广泛的承认，可以直接向国际标准组织、国际电联和联合国相关标准组织直接提交标准提案。

　　SCA是一种规范，它使开发人员可以将注意力集中在业务逻辑的编写上。更直接地说，它是一种大大改进了的部署描述符，它可以使用任何语言而不限于Java。此外，编程人员还可以使用编程式语言和声明式语言，比如BPEL和XSLT（eXtensible Stylesheet Language Transformation，扩展样式表转换语言）。SCA的特别之处在于，它对安全性、事务和可靠消息传递之类的特性使用了声明式策略的理念。

　　SCA是专门针对SOA设计的，而不像J2EE只是面向SOA做了修改。SCA关注的是如何描述按照各种编程模型和协议编写的组件所组成的程序集。SCA允许开发应用程序集而不考虑特定的API或具体语言。中间件

　　SCA的核心概念是服务及其相关实现。服务由接口定义，而接口包含一组操作。服务实现可以引用其他服务，称为引用。服务可以有一个或多个属性，这些属性是可以在外部配置的数据值。

　　SCA中的一个关键推动因素是SDO（Service Data Object，服务数据对象）。SDO用于表示业务数据、参数以及服务调用的返回值，当它遍历服务网络时，它还是一种表示数据的方式。注意，也可以使用XML Beans及其他技术。

　　SCA组件被组成为程序集。程序集是服务级的应用程序，它是服务的集合，这些服务被连接在一起，并进行了正确的配置。SCA程序集运行在两个级别：第一种情况，程序集是系统内的一组松散连接的组件；另一种情况，程序集是模块内的一组松散连接的组件。二者的区别在于，一般来说，模块是组件的集合，而系统是模块的集合。此外，系统对应于“大规模编程”（programming in the large或megaprogramming），而模块对应于“小规模编程”（programming in the small），比如构建当今的典型应用程序。

　　将组件连接到它所依赖的服务的方式就是服务网络“装配”的方式。程序集已经在许多技术和框架中广为应用，比如CORBA、J2EE、ATG Dynamo和Spring，也就是说，它并不是新出现的。从这些技术中我们可以知道，程序集提供了许多重要的优点，比如更轻松的迭代开发，以及避免使业务逻辑依赖于中间件容器。SCA使用程序集解决了许多SOA开发中的重要问题，包括：

　　*业务逻辑与底层基础架构、服务质量和传输的分离。

　　*“小规模编程”与“大规模编程”的联系。

　　*为架构的设计、编码和操作性部署在自底向上（bottom-up）和自顶向下（top-down）两种方法中来回切换提供了一种统一的方式。

3. 你们的测试组还在用Word写测试用例么？　
 不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
 
4. 你们的项目组有没有建立一个门户网站？　
　要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

5. 你们的项目组用了你能买到最好的工具么？　
　应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是"你能买到最好的"。
 
6. 你们的程序员工作在安静的环境里么？　
　需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
 
7. 你们的员工每个人都有一部电话么？
需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊："某某某电话"。《人件》里面就强烈谴责这种做法。
 
8. 你们每个人都知道出了问题应该找谁么？　
　应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

9. 你遇到过有人说"我以为…"么？　
　要消灭"我以为"。Never assume anything。
 
10. 你们的项目组中所有的人都坐在一起么？　
　需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
 
11. 你们的进度表是否反映最新开发进展情况？ 　
　应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
 
12. 你们的工作量是先由每个人自己估算的么？　
　应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
 
13. 你们的开发人员从项目一开始就加班么？　
　不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
 
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？　
　不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
 
15. 值得再多花一些时间，从95%做到100%好值得，非常值得。　
　尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
 
16. 登记新缺陷时，是否写清了重现步骤？
　要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。
 
17. 写新代码前会把已知缺陷解决么？
 要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
 
18. 你们对缺陷的轻重缓急有事先的约定么？　
　必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。
 
19. 你们对意见不一的缺陷有三国会议么？
 必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
 
20. 所有的缺陷都是由登记的人最后关闭的么？ 　
　Bug应该由Opener关闭。Dev不能私自关闭Bug。
 
21. 你们的程序员厌恶修改老的代码么？　
　厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
 
22. 你们项目组有Team Morale Activity么？　
　每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。
 
23. 你们项目组有自己的Logo么？　
　要有自己的Logo。至少应该有自己的Codename。
 
24. 你们的员工有印有公司Logo的T-Shirt么？　
　要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

25. 总经理至少每月参加次项目组会议要的。　
　要让team member觉得高层关注这个项目。
 
26. 你们是给每个Dev开一个分支么？　
　反对。Branch的管理以及Merge的工作量太大，而且容易出错。
 
27. 有人长期不Check-In代码么？　
　不可以。对大部分项目来说，最多两三天就应该Check-In。
 
28. 在Check-In代码时都填写注释了么？　
　要写的，至少一两句话，比如"解决了Bug No.225（给bug编号）"。如果往高处拔，这也算做"配置审计"的一部分。
 
29. 有没有设定每天Check-In的最后期限？　
　要的，要明确Check-In Deadline。否则会Build Break。
 
30. 你们能把所有源码一下子编译成安装文件吗？ 　
　要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。
 
31. 你们的项目组做每日编译么？　
　当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。

32. 你们公司有没有积累一个项目风险列表？　
　要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。
 
33. 设计越简单越好越简单越好。　
　设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。
BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是"软件复用"的体现。
 
35. 你们会隔一段时间就停下来夯实代码么？　
　要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，"夯"这个字念"hang"，第一声。

36. 你们的项目组每个人都写Daily Report么？　
　要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。

37. 你们的项目经理会发出Weekly Report么？　
　要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
 
38. 你们项目组是否至少每周全体开会一次？　
　要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
 
39. 你们项目组的会议、讨论都有记录么？　
　会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。
 
40. 其他部门知道你们项目组在干什么么？　
　要发一些Newsflash给整个大组织。Show your team's value。否则，当你坐在电梯里面，其他部门的人问："你们在干嘛"，你回答"ABC项目"的时候，别人全然不知，那种感觉不太好。
 
41. 通过Email进行所有正式沟通
Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。

42. 为项目组建立多个Mailing Group 　
　如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。
 
43. 每个人都知道哪里可以找到全部的文档么？　
　应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。
 
44. 你做决定、做变化时，告诉大家原因了么？　
　要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。
 
45. Stay agile and expect change 要这样。　
　需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。
 
46. 你们有没有专职的软件测试人员？　
　要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。
 
47. 你们的测试有一份总的计划来规定做什么和怎么做么？
 这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。
 
48. 你是先写Test Case然后再测试的么？　
　应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。
 
49. 你是否会为各种输入组合创建测试用例？　
　不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合--但要想清楚，你是否有时间去运行那么多test case。

50. 你们的程序员能看到测试用例么？　
　要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

51. 你们是否随便抓一些人来做易用性测试？ 　
　要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳--臭的看久了也就不臭了，不方便的永久了也就习惯了。
 
52. 你对自动测试的期望正确么？　
　别期望太高。依我看，除了性能测试以外，还是暂时先忘掉"自动测试"吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能"矫枉必须过正"了。

53. 你们的性能测试是等所有功能都开发完才做的么？　
　不能这样。性能测试不能被归到所谓的"系统测试"阶段。早测早改正，早死早升天。
 
54. 你注意到测试中的杀虫剂效应了么？　
　虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。
 
55. 你们项目组中有人能说出产品的当前整体质量情况么？　
　要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。
 
56. 你们有单元测试么？　
　单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了--可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。

57. 你们的程序员是写完代码就扔过墙的么？　
　大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。
 
58. 你们的程序中所有的函数都有输入检查么？　
　不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
 
59. 产品有统一的错误处理机制和报错界面么？　
　要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
 
60. 你们有统一的代码书写规范么？　
　要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
 
61. 你们的每个人都了解项目的商业意义么？　
　要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。
 
62. 产品各部分的界面和操作习惯一致么？　
　要这样。要让用户觉得整个程序好像是一个人写出来的那样。
 
63. 有可以作为宣传亮点的Cool Feature么？　
　要。这是增强团队凝聚力、信心的。而且，"一俊遮百丑"，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。
 
64. 尽可能缩短产品的启动时间要这样。　
　软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
 
65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。
 
66. 你们根据详细产品功能说明书做开发么？　
　要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。
 
67. 开始开发和测试之前每个人都仔细审阅功能设计么？　
　要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说"你看，当初我就是反对这么设计的，现在吃苦头了吧"

68. 所有人都始终想着The Whole Image么？
要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。
 
69. Dev工作的划分是单纯纵向或横向的么？　
　不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个"层"都有一个Owner来Review所有人的设计和代码，保证consistency。
 
70. 你们的程序员写程序设计说明文档么？　
　要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。
 
71. 你在招人面试时让他写一段程序么？　
　要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。
 
72. 你们有没有技术交流讲座？　
　要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。

73. 你们的程序员都能专注于一件事情么？　
　要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。
 
74. 你们的程序员会夸大完成某项工作所需要的时间么？　
　会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。
 
75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。　　Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。
 

记住建议就是建议！！！

(2) 在方法中定义一个类(局部内部类，匿名内部类)

1、揭露类中内部类

      我们首先看看类中内部类的两个特点：

     (1) 在外部类的作用范围内可以任意创建内部类对象，即使内部类是私有的(私有内部类)。即内部类对包围它的外部类可见。

(2) 在内部类中可以访问其外部类的所有域，即使是私有域。即外部类对内部类可见。

       问题来了：上面两个特点到底如何办到的呢？内部类的"内部"到底发生了什么？

      其实，内部类是Java编译器一手操办的。虚拟机并不知道内部类与常规类有什么不同。编译器是如何瞒住虚拟机的呢？

     对内部类进行编译后发现有两个class文件：Outer.class和Outer$Inner.class。这说明内部类Inner仍然被编译成一个独立的类(Outer$Inner.class)，而不是Outer类的某一个域。虚拟机运行的时候，也是把Inner作为一种常规类来处理的。

        但问题来了，即然是两个常规类，为什么他们之间可以互相访问私有域那(最开始提到的两个内部类特点)？这就要问问编译器到底把这两个类编译成什么东西了。

        我们利用reflect反射机制来探查了一下内部类编译后的情况（关于探查类内部机制的代码提供在下面的附件里Reflect.java）。

        (1)、编译代码2生成Outer$Inner.class 文件后使用ReflectUtil.reflect("Outer$Inner")对内部类Inner进行反射。运行结果发现了三个隐含的成分：          

      好了，现在我们可以解释上面的第一个内部类特点了：为什么外部类可以创建内部类的对象？

     首先编译器将外、内部类编译后放在同一个包中。

        然后在内部类中附加一个包可见构造器。

        这样，虚拟机运行Outer类中Inner in=new Inner();实际上调用的是包可见构造： new Outer$Inner(this,null)。

        因此即使是private内部类，也会通过隐含的包可见构造器成功的获得私有内部类的构造权限。

     (2)、编译代码3生成Outer.class文件，然后使用ReflectUtil.reflect("Outer")对外部类Outer进行反射。 运行结果发现一个隐含成分如下：

      现在可以解释第二个特点了：为什么内部类可以引用外部类的私有域？

        原因的关键就在编译器在外围类中添加了静态方法access$0。 它将返回值作为参数传递给他的对象域data。这样内部类Inner中的打印语句：

                     System.out.println(data);

         实际上运行的时候调用的是：

                 System.out.println(access$0(Outer));

总结一下编译器对类中内部类做的手脚吧：

(1)  在内部类中偷偷摸摸的创建了包可见构造器，从而使外部类获得了创建权限。

(2)  在外部类中偷偷摸摸的创建了访问私有变量的静态方法，从而使内部类获得了访问权限。

这样，类中定义的内部类无论私有，公有，静态都可以被包围它的外部类所访问。

2、方法中内部类的特点

      方法内部类也有两个特点

      (1)  方法中的内部类没有访问修饰符，即方法内部类对包围它的方法之外的任何东西都不可见。

      (2)  方法内部类只能够访问该方法中的局部变量，所以也叫局部内部类。而且这些局部变量一定要是final修饰的常量。

      这又是为什么呢？

      (1) 我们首先对Outter类进行反射发现，Outter中再也没有返回私有域的隐藏方法了。

      (2) 对Inner类的反射发现，Inner类内部多了一个对beep变量的备份隐藏域：final int val$i;

      我们可以这样解释Inner类中的这个备份常量域，首先当JVM运行到需要创建Inner对象之后，Outter类已经全部运行完毕，这是垃圾回收机制很有可能释放掉局部变量beep。那么Inner类到哪去找beep变量呢？

      编译器又出来帮我们解决了这个问题，他在Inner类中创建了一个beep的备份，也就是说即使Ouuter中的beep被回收了，Inner中还有一个备份存在，自然就不怕找不到了。

      但是问题又来了。如果Outter中的beep不停的在变化那。那岂不是也要让备份的beep变量无时无刻的变化。为了保持局部变量与局部内部类中备份域保持一致。编译器不得不规定死这些局部域必须是常量，一旦赋值不能再发生变化了。

      所以为什么局部内部类应用外部方法的域必须是常量域的原因所在了。

内部类：定义在其他类里面的类。
使用内部类的理由：
1.内部类方法能够访问外部类的任何数据成员包括私有成员。
2.对同一个包的其他类，内部类是不可见的。
3.匿名内部类能够方便的定义回调而不用写太多代码。

非静态内部类没有默认的构造函数(无参数的)，非静态内部类的构造函数都有一个final的外围类对象引用this$0。
内部类的特殊语法规则：
1.相对内部类，引用其外部类隐式对象的形式：OuterClass.this
2.调用内部类的构造函数：outerObject.new InnerClass(construction parameters);
3.外部类外面引用内部类：OuterClass.InnerClass

内部类是一种编译器现象与虚拟机无关。编译器将内部类翻译为用$分隔外部类名和内部类名的常规类文件，虚拟机对此并无所知。
使用javap -private OuterClass$InnerClass。javap这个工具确实挺不错的，对分析字节码和源码都有很大的帮助。
可以看出详细的内部类源码清单，其中包括了编译器自动添加的部分：
public class Outer
{
 public class Inner
 {
 }
}
当内部类是非静态内部类时相应的内部类的详细源码如下：
Compiled from "Outer.java"
public class Outer$Inner extends java.lang.Object{
    final Outer this$0;  //编译器自动在内部类里面添加了指向外部类对象的引用
    public Outer$Inner(Outer);  //内部类的构造函数默认有一个外部类对象作为参数。
}

当内部类是静态内部类时：
Compiled from "Outer.java"
public class Outer$Inner extends java.lang.Object{
    public Outer$Inner(); //没有了对外部类对象的引用
}

如下代码模拟了上面内部类的情形唯一不同的是这里的Inner没有访问Outer私有数据的权限：
class Outer{
   Inner in = new Inner(this);
}

class Inner{
   public Inner(Outer outer){
      this.outer = outer;
   }
  
   private Outer outer;
}

//那么权限是如何控制的呢？当内部类中的方法访问到外部类的私有数据时(注意如果内部类没有方法去访问外部类的私有数据不会生成该静态方法static int access$000(Outer);)
public class Outer
{
 private int i;
 public void methodOne()
 {
 }

 class Inner
 {
  public void print(){
   System.out.println(Outer.this.i);
  }
 }
}

相应的外部类详细源码如下：
public class Outer
{
   public Outer();

   public void methodOne();
   static int access$000(Outer); //由编译器合成的用于内部类对外部类进行特殊访问权限的控制：这也是
                                //为什么内部类能够访问外部类中的私有数据的原因。
   private int i;
}

内部类访问外部类的private数据的这种方式很可能导致危险，虽然access$000不是一个合法的Java方法名，但是熟悉class文件结构的黑客可以使用十六进制编辑器轻松创建一个用虚拟机指令调用那个方法的类文件。由于隐秘的访问方法需要拥有包可见性，所以攻击代码需要与被攻击类放在同一个包中。总之，如果内部类访问了外部类的私有数据域，就有可能通过附加在外部类所在包中的其他类访问私有数据。

局部内部类：定义在方法之中，因此局部类没有public和private修饰符。对外界是完全隐藏的。
局部类不仅能够访问外部类，还能访问方法中的局部变量(或方法的参数)。不过那些局部变量要声明为final的。

匿名内部类：用外部类+$+数字的形式表示。一个外部类中有多个匿名内部类时，其生成的class文件对应有Outer$(1、2、3)的形式表示。注意到该匿名内部类是final的。
final class Outer$1
{
   Outer$1(Outer);

   public void method();

   final Outer this$0;
}

嵌套类：当内部类不需要访问外部类的数据成员时应该使用嵌套类。注意只有内部类可以声明为static的其他不行。
在接口中声明的内部类自动转换为public static的，在接口中定义的成员自动都是public static的。

内部类构造函数的可见性与其类的可见性相同。当内部类是private时其构造函数也是private的，当内部类是public的其构造函数也是public的。

陆汝钤，计算机语言的形式语义.北京:科学出版社,1992
屈延文，形式语义学基础与形式说明.北京:科学出版社,1998
周巢尘，形式语义学引论，长沙：湖南科学技术出版社，1985
另外上海师范大学物理信息学院陈仪香教授对此也有深入研究。以下对四种语义学的简介来即自陈教授"形式语义的论语理论研究进展"一文（见下列著作第二章：陆汝钤主编，《知识科学与计算科学》.北京：清华大学出版社，2003）

操作语义的基本思想是建立一个抽象机器以模拟程序在执行过程中如何进行数据处理。
指称语义的思想是使语言的每一成分对应于一个数学对象，该对象称为该语言成分的指称，程序看作输入域到输出域的映射，输入域和输出域统称为论域。因此论域与映射是指称语义的基本研究对象。
公理语义实在程序正确性验证的基础上发展起来的，它给出一种方法，使人们在给定的前提下，验证某种特性是否成立。
代数语义的基本思想是把描述语义的逻辑体系和满足这个逻辑系统的各种模型统一在一起，同时把模型的集合看成是以代数机构，研究这些模型之间的关系。

戴维民主编的《信息组织》一书（高等教育出版社.2004 面向21世纪课程教材）中认为语法、语义和语用信息的分法是"按照信息组织的层次分"，具体解释如下：
"从认知的角度，可把信息分为语法信息、语义信息和语用信息。由于主体具有观察力，能够感知事物运动状态及其变化方式的外在形式，由此获得的信息称为语法 信息；由于主体具有理解力，能够领悟事物运动状态及其变化方式的逻辑含义，由此获得的信息称为语义信息；又由于主体具有明确的目的性，能够判断事物运动状 态及其变化方式的效用，由此获得的信息称为语用信息。"有一定道理，好像又不是很确切。不知道这种理解出自何处？语言学？哲学？认识论？

计算机形式语义学参考书：

1、周巢尘，《形式语义学引论》，湖南科技出版社（绝版）
2、周之英，翻译，《计算机形式规范概论》，清华大学出版社（绝版）
3、屈延文，《形式语义学基础与形式说明》，科学版（绝版）
4、陆汝钤，《计算机语言的形式语义》，科学版
5、陈意云，（实际是编译的），《形式语义学基础》，中国科技大学出版社
6、陈意云，（实际是编译的），《程序设计语言理论》，中国科技大学出版社
7、宋国新，翻译，《程序设计语言的形式语法及语义》，机工版

从发展来说，国内的形式语义学或程序理论的教材，落后国外十年以上。国外现在最流行的几本教材是：

1、《Semantics of Programming Languages》（Carl A.Gunter）MIT Press 1992
这是目前也许是最流行的一本教材，主要采用了简单类型的Lambda Calculus和范畴学来表达语义学，内容取舍比较合理，章节安排也不错，属于高级教程，评价也很高，很多大学都推荐使用。

2、《The Formal Semantics of Programming Languages》（Glynn Winskel）MIT Press 1993
另一本流行的一本教材，作者Winskel是剑桥大学的教授，该书在欧洲几乎成为标准教材了，评价也很高，中高级教程，很多大学都推荐使用，已经出了中文版，大家可以到书店买到。

3、《Foundations for Programming Languages 》（John C. Mitchell ）MIT Press 1996
作为桌案上的参考书就最好了，作者是斯坦福教授。这本书是一本巨作，内容齐全，大量泛代数内容，绝对是超高级教程，但作为教材的话内容太多了，850页，真的是本大部头

4、《Theories of Progamming Languages》（John C. Reynolds）Cambridge Press 1998
Reynolds是CMU教授，他的这本教材出发角度和上面的几本有所不同，按作者的话来说，就是尽量避免使用高深的数学理论，诸如范畴学之类的东西，同时这本书内容涉及也比较广，甚至有并发理论和CSP。该书在评价非常高，推荐大家看。

5、《Semantics of Programming Languages》（R.D. Tennent）Prentice-Hall 1990
这本书的最大特点就是采用imperative language作为研究对象，和国内的教学最符合了，国外很多大学，特别是欧洲的大学，普遍采用函数式汝ML语言作为研究和教学语言。作者R.D. Tennent在八十年代初，曾经出版过一本《Principles of Programming Languages》，国际国内都很多人参考过这本书。

6、《Introduction to the Theory of Programming Languages》（Bertrand Meyer）Prentice-Hall 1988
作者大家都很熟悉了，他的另一本书《Object-Oriented Software Construction》前几年就已经引进中国了。这本书几乎没有高深的数学内容，可能这本书出的比较早些，书的内容要比前面的几本书都要容易浅些，但作为入门的书，我推荐这本。

XML技术自出现以来发展非常迅速，在许多领域内得到广泛的支持而有着广阔的应用前景。例如电子数据交换、电子商务等更是将XML作为一种基础性、支柱性的技术来看待。

1、数据库简史

数据库系统是随着计算机技术的不断发展，在特定的历史时期、特定的需求环境下出现的。在1946年的第一台计算机到20世纪60年代这漫长的20年里，计算机操作系统主要局限于文件的操作，对数据的管理也主要是通过文件系统来实现。进行计算所需要的各种数据存放在各自的文件里，使用这些数据时将文件打开，读取文件中的数据到内存中，当计算完毕后，将计算结果仍旧写入到文件中去，它的不足主要集中在无法对数据进行有效的统一管理。针对文件系统的重要缺点，人们逐步发展了以统一管理数据和共享数据为主要特征的系统，即数据库系统。1964年，美国通用电气公司开发成功了世界上的第一个数据库系统IDS(IntegratedDataStore)。IDS奠定了网状数据库的基础，并得到了广泛的发行和应用，成为数据库系统发展史上的一座丰碑。1969年，美国国际商用机器公司(IBM)也推出世界上第一个层次数据库系统IMS(InformationManagement System)，同样在数据库系统发展史上占有重要的地位。

70年代初，E.F.Codd在总结前面的层次、网状数据库优缺点的基础上，提出了关系数据模型的概念及关系代数和关系演算。在70年代，关系数据库系统无论从理论上还是实践上都取得了丰硕的成果。在理论上确立了完整的关系模型理论、数据依赖理论和关系数据库的设计理论；在实践上，世界上出现了很多著名的关系数据库系统，比较著名的如SystemR、INGRES、Oracle等。

与文件系统相比，数据库系统有几个方面的特点：向用户提供高级的接口；向用户提供非过程化的数据库语言(即SQL语言)；查询的处理和优化；并发控制；数据的完整性约束。

进入80年代之后，计算机硬件技术的飞速提高促使计算机应用不断深入，产生了许多新的应用领域，例如计算机辅助设计、计算机辅助制造、计算机辅助教学、办公自动化、智能信息处理、决策支持等。这些新的领域对数据库系统提出了新的要求。但由于应用的多元化，不能设计出一个统一的数据模型来表示这些新型的数据及其相互关系，因而出现了百家争鸣的局面，产生了演绎数据库、面向对象数据库、分布式数据库、工程数据库、时态数据库、模糊数据库等新型数据库的研究和应用。

2、XML简介

XML推荐标准1.0版发布于1998年2月，之后迅速在全球掀起了XML应用的浪潮。XML是一种描述型的标记语言，与HTML同为SGML(标准通用标记语言，ISO-8879国际标准)的一种应用。由于XML在可扩展性、可移植性和结构性等方面的突出优点，它的应用范围突破了HTML所达到的范围。

一篇XML文档由标记和内容组成。XML中有六种标记：元素(elements)、属性(attributes)、实体引用(entityreferences)、注释(comments)、处理指令(processinginstructions)和CDATA段(CDATAsections)。XML与HTML最显著的不同是XML文档中引入了“文档类型声明”(Document Type Declarations)。DTD使文档可以与分析器交流关于它的内容的元信息。DTD的出现，赋予了XML文档可扩展性、结构性和可验证性，使XML具备了类似于数据库的一些性质，可以利用XML来组织和管理信息；又可以与HTML一样在浏览器中方便地表示，在Internet上高效地传递和交换。考虑到与HTML的兼容，DTD并不是XML文档必需的成份。具有DTD的XML文档称作“Valid”，否则就是“Well-formed”。

目前，处理XML文档的方式主要有SAX与DOM两种。SAX(SimpleAPIforXML)是一种基于流的、以事件处理方式工作的接口。SAX 2.0在2000年5月发布，增强了许多功能，包括对名字空间的支持。DOM(Document Object Model)则是在对XML文档进行分析后，在内存中建立起一个完整的树结构，然后在此基础上进行各种操作。简单地比较来看，SAX对系统资源要求低、速度快，但对文档的操作是只读的；DOM的处理能力强大，但要求大量的系统资源，尤其是对于大的文档。而后还出现了Xpath和Xpointer用以完成XML的搜索和转换；XSL、XSLT和SOAP用以完成XML的远程对象访问，XML Query Languages的出现使XML查询语言可用于任何XML文档。

3、XML与数据库

XML文件是数据的集合，它是自描述的、可交换的，能够以树型或图形结构描述数据。XML提供了许多数据库所具备的工具：存储(XML文档)、模式(DTD，XMLschema，RE1AXNG等)、查询语言(XQuery，XPath，XQL，XML-QL，QUILT等)、编程接口(SAX，DOM，JDOM)等。但XML并不能完全替代数据库技术。XML缺少作为实用的数据库所应具备的特性：高效的存储、索引和数据修改机制；严格的数据安全控制；完整的事务和数据一致性控制；多用户访问机制；触发器、完善的并发控制等。因此，尽管在数据量小、用户少和性能要求不太高的环境下，可以将XML文档用作数据库，但却不适用于用户量大、数据集成度高以及性能要求高的作业环境。

随着Web技术的不断发展，信息共享和数据交换的范围不断扩大，传统的关系数据库也面临着挑战。数据库技术的应用是建立在数据库管理系统基础上的，各数据库管理系统之间的异构性及其所依赖操作系统的异构性，严重限制了信息共享和数据交换范围；数据库技术的语义描述能力差，大多通过技术文档表示，很难实现数据语义的持久性和传递性，而数据交换和信息共享都是基于语义进行的，在异构应用数据交换时，不利于计算机基于语义自动进行正确数据的检索与应用；数据库属于高端应用，需要昂贵的价格和运行环境。而随着网络和Internet的发展，数据交换的能力已成为新的应用系统的一个重要的要求。XML的好处是数据的可交换性(portable)，同时在数据应用方面还具有如下优点：(1)XML文件为纯文本文件，不受操作系统、软件平台的限制；(2)XML具有基于Schema自描述语义的功能，容易描述数据的语义，这种描述能为计算机理解和自动处理；(3)XML不仅可以描述结构化数据，还可有效描述半结构化，甚至非结构化数据。

4、XML文件的存储

XML文件的存储方式有三大类：(1)将文件存储于文件系统(StoringDocumentsinthe File System)；(2)将文件存储于BLOB(Storing Documents in BLOBs)，利用数据库的事务管理、安全、多用户访问等优点。此外许多关系数据库提供的检索工具可以进行全文检索、近似检索、同义词检索和模糊检索。其中某些工具将会支持XML，这样就可消除将XML文件作为纯文本检索所带来的问题。(3)将文件存储于原生XML数据库(Native XML Databases，NXD)。NXD是专用于存储XML文件的数据库，支持事务管理、安全、多用户访问、编程API和查询语言等。与其它数据库的唯一区别在于其内部模型是基于XML的。其中，最重要的存储方式当属原生XML数据库。

4.1、原生XML数据库

原生XML数据库(NativeXMLDatabases)为XML文档定义了一个(逻辑)模型，并根据该模型存取文件。这个模型至少应包括元素、属性、PCDATA和文件顺序。其例子有XPath数据模型、XMLIn-foset以及DOM所用的模型和SAX 1.0的事件。它以XML文件作为其基本存储单位，对底层的物理存储模型没有特殊要求。例如，它可以建在关系型、层次型或面向对象的数据库之上，或者使用专用的存储格式，比如索引或压缩文件。

NXD最适于存储以文档为中心的文件。这是由于NXD保留了文件、顺序、处理指令、注释、CDA-TA块以及实体引用等，而支持XML的数据库XED(XML-enableddatabase)无法做到。XED是在原有数据库基础上扩展了XML支持模块，完成XML数据和数据库之间的格式转换和传输。从存储粒度上，可以把整个XML文档作为RDBMS表中一行，或把XML文档进行解析后，存储到相应的表格中。为了支持W3C的一些XML操作标准，Xpath、XED提供一些新的原语(如Oracle9iR2增加了一些数据包来操作XML数据等)，并优化了XML处理模块。

NXD一般采用层次数据存储模型，保持XML文档的树形结构，省掉了XML文档和传统数据库的数据转换过程。NXD还适用于存储“天然格式”为XML的文件，NXD还可以存储半结构化数据、在某种特定情形下提高存取速度以及存储没有DTD的文件(良构的文件)。

4.2、原生XML数据库的结构

原生XML数据库的结构可分为两大类：基于文本的和基于模型的。

基于文本的NXD(Text-BasedNativeXMLDatabases)将XML作为文本存储。它可以是文件系统中的文件、关系数据库中的BLOB或特定的文件格式。基于文本的NXD与层次结构的数据库很相似，当存取预先定义好层次的数据时，它比关系数据库更胜一筹。和层次结构的数据库一样，当以其它形式比如转置层次存取数据时，NXD也会遇到麻烦。这个问题的严重程度尚未可知，很多关系数据库都使用逻辑指针，使相同复杂度的查询以相同的速度完成。

基于模型的NXD(Model-BasedNativeXMLDatabases)是根据文件构造一个内部模型并存储这个模型。有些数据库将该模型存储于关系型和面向对象的数据库中，例如在关系型数据库中存储DOM时，就会有元素、属性、PCDATA、实体、实体引用等表格。其他数据库使用了专为这种模型优化了的存储格式。使用专用存储格式的基于模型的NXD如果以文件的存储顺序读取文件，其性能与基于文本的NXD相似。

4.3、原生XML数据库的特性

原生XML数据库的特性(FeaturesofNativeXML Databases)有：(1)文件集(Document Collections)，支持集合(Collection)的概念，其作用相当于关系数据库中的表和文件系统中的文件夹。(2)查询语言(Query Languages)，最常用的有XPath(对多个文件的查询作了扩充)和XQL，以及专有的查询语言。(3)更新和删除(Updates and Deletes)，NXD对文件的更新和删除方式从简单的替换或删除现有文件，到修改当前活动的DOM树，以及用于指定如何修改文件片断的语言。(4)事务、锁定和并发(Transactions，Locking，and Concurrency)，支持事务处理。锁定通常是对整个文档的，所以多用户并发性相对较低。问题的大小取决于应用程序以及“文件”的构成。(5)原生数据库提供应用程序接口API(Application Programming Interfaces，APIs)。(6)NXD的一个重要特性是它可以为XML文档提供“往返车票(round-trip)”。可以将XML文件存放在NXD中，而且再取回“同样的”文件。对于以文档为中心的应用程序来说非常重要，因为CDATA部分、实体用法、注释和处理指令是这些文档不可缺少的组成部分。特别是对于法律和医学文件，按规定这些文档必须要保持原样。(7)外部数据(Remote Data)，某些NXD可包含有外部数据，它来自存储在数据库中的文档。通常这些数据通过OD-BC、OLE DB或JDBC从关系数据中取出，模型可以是基于表格的或对象-关系型映射。(8)支持元素和属性的索引。

5、结论

XML技术的出现，使数据处理从文件方式到数据库系统再到文件方式的循环，但新的文件方式已经与最初的文件系统有了本质的区别----格式化文档。XML和关系数据库在数据应用和数据管理方面各有优势。

一方面，我们要研究数据库的新技术、探索数据库的发展方向；另一方面，在数据库的基本实现基础上，添加必要的新技术是探索新数据库的发展方向。

    目前，正当用户们准备引入真正的XML数据库产品之时，Microsoft和IBM等传统数据库厂商已经发起了更加猛烈的竞争攻势。此外，Oracle和Sybase也在努力说服企业IT部门采用自己的下一代数据存储技术以及与之相关的数据管理和应用开发工具。

498)this.style.width=498;" border=1>

热烈欢迎XML

在IDC最近发布的一份报告中，500家受访企业的IT部门中有29%称，正在大量使用XML存储库和数据库；约有同样比例的受访者称，正在探索这方面的使用前景。此外，这项研究还发现XML技术的使用是非常广泛的，包括编辑器、基于XML的电子表格和XML图表等。其中，约有三分之一的受访者都在使用其中的一种技术，其比例与声称正在探索此类技术使用前景的受访问者几乎相同。随着用户兴趣的提高，传统数据库厂商开始调整自己的产品计划，而原有的XML服务器厂商则更加野心勃勃地投身于市场的竞争。

微软公司在2005年年底发布了代号为Yukon的SQL Server 2005。该产品可以存储和处理XML数据，且无须将这些数据转换为关系列和行，更不需要将其存储为二进制大型对象。编程人员可以使用XML Query或称XQuery来检索XML数据。这种语言即将获得World Wide Web Consortium（W3C）的批准。

IBM正在对其DB2 Viper进行测试。该产品可以存储传统的关系数据和XML数据。按计划，Viper将于今年晚些时候正式推出。IBM已经明确指出，Viper的XML数据管理能力完全符合面向服务架构（SOA）的要求。在面向服务的架构中，用户可以使用标准的Web服务界面对程序和所有格式的数据进行分类、查找、访问和使用。

目前，W3C创建XQuery最终建议的工作已经完成。XQuery 将创建出一种标准的查询语言，能够对已经存储的XML数据进行访问和处理。在XML的环境中，该语言相当于SQL语言在关系数据库中的地位，并且可以大幅度地简化XML应用的编程过程。

XML将提高非结构性文件的通用表达能力，这类文件包括文档、报告和表格。Gartner集团高性能市场事业群的副总裁Rita Knox说：“高端出版应用（如航空航天和汽车工业的技术手册）在很久以前就开始使用XML。但目前，XML正在朝着更贴近人们日常生活的领域进军（如银行业）。美国银行业中正在开发一种名为可扩展商业报告语言（XBRL）实现通用的XML表达，主要用于向联邦储蓄保险公司发送资产及负债报告和其他信息。”
拿来做些什么

厂商的热捧并不奇怪，但更为关键的问题是提供内容服务方面能够用XML做些什么事？IDC内容技术项目主管Melissa Webster说，下一阶段的开发工作就正在这些方面作出努力。

大体上看，原有的XML数据库产品和传统数据库中新展现出的XML能力在基础工作方面的表现都非常好，比如良好的扩展性、出色的性能、管理XML文档版本的能力，以及链接内容中各部分的能力等等。但Webster也认为，真正的优势来自两个更高级的领域。其中一个就是连续修改内容，例如将技术手册的更新或修改与工程师创建的注释和说明结合在一起。Webster将这一方面的能力称为配置管理。

其二，是将已存储的XML信息与关键业务流程联系起来。例如处理一份按揭贷款或修理一架喷气式客机，您可以从飞机的CAD工程图纸开始着手，并为发动机维修技师生成最终技术文档，然后将修理单与特定的说明和图纸一并提交给有关的维修人员。同时，维修工作流中的重要事件将被反馈到发动机的维修历史中，并将这些内容写入那些提交给制造商和联邦航空管理局的报告中。

Webster指出：“过去，技术手册与使用它的业务流程相互隔离。在此过程中，需要有人才能把两者联系起来。而现在，则可以借助智能XML内容服务把业务流程和特定内容结合起来。”

这种潜力进一步刺激了原有XML产品厂商在市场中的野心。尽管IBM、Microsoft和Oracle等厂商在这方面的声势很大，但投资者们显然非常看好像Mark Logic这类新兴的XML内容服务厂商。

Mark Logic公司负责客户解决方案的副总裁Max Schireson指出：“如果XML内容只是由XML包装的简单数据，那么，用户就没有理由不用Oracle或Microsoft的产品。” 但是，如果是在复杂的文档和流程中，关系数据库就很难对文档和其他内容实施有效的智能管理了。

比如O'Reilly Media公司使用Mark Logic服务器创建了一个系统。利用该系统，大学教授可以针对不同的课程创建定制的阅读教程。教授们可以对O'Reilly 那些以XML文档形式存储的图书和出版物内容库进行复杂搜索，他们还可以添加一些自己编写的内容，并且根据需要下订单，由出版商负责将其印刷出来并直接交付到教授们的手中。

链接：XML数据库的应用先驱

其实，XML数据库最初只是应用于一种特殊产品。 Command金融出版社是美国纽约的一家金融信息出版商，该公司使用Ixiasoft XML服务器来存储和管理其共有基金客户的募股说明书。每一家客户都有多种基金，因此该公司需要每年出版大量的此类信息。Command公司IT部门的项目管理主管Will Montgomery说：“很多数据都是独一无二的，但其中也有很大一部分对于所有客户的基金来说都是通用的。”

过去，在编写、校对、修改和再次校对等过程中，即使是那些通常应保持完全一致的模板文件也必须经常修改。Montgomery说：“如果客户有100个基金，他们就必须进行数百次修改。” 而在使用Ixiasoft XML服务器之后，客户在Microsoft Word 2003中完成这些修改工作只需一次即可，修改后的内容可随时复制到有关的文档。
现在，Command金融公司正在评估另外一种做法，即在股东报告这种非结构性文件中使用这种技术。

一.学术界与工业界的两种不同索求

Ronald Bourret 在他那篇著名的《XML Database Products》中，将XML数据库产品分为中间件(Middleware)、支持XML的数据库(XML-Enabled Databases)、纯XML数据库(Native XML Databases)、XML服务器(XML Servers)、Wrappers、内容管理系统(Content Management Systems)、XML查询引擎(XML Query Engines)、XML Data Binding、Discontinued products等九种，在业界影响很大。但是，在XML数据库的研究和开发人员眼里，或许只有支持XML的数据库、纯XML数据库能够称得上是真正意义上的XML数据库。支持XML的数据库可以被看做是支持XML数据的数据库系统，它可能是关系数据库、对象数据库等。就在一年半以前，还有相当多的人在争论关系库支持的XML数据库和纯XML数据库孰优孰劣的问题。但是，纯XML数据库却在这种争论中悄然进步，在技术上有了长足的发展。

人们已经越来越倾向于认为XML数据库就是纯XML数据库。随着金融界确立XBRL(XML的一个子集)标准和政府规范电子政务的XML格式，实践推动着XML数据库技术不断向前发展。

XML数据库系统从最初简单的查询引擎，不断地加入查询优化、事务处理、触发器、并发控制、代数系统等传统的数据库技术，一步步地从性能和功能上完善自己。

从目前XML数据库的产品情况来看，学术界的实验系统和市场产品之间有着些许微妙的差别，尽管它们的主流技术是一致的。

学术界完成的实验室原型系统一般侧重于下面的一些特点：

● 专注于查询性能的提高，对查询优化的研究较多。为了提高查询效率，学术界十分重视索引结构的设计，先后提出二十几种适合于XML数据的索引方式，比如影响很大、简单易用的三元组索引，并在此基础上开发出了以结构化联接为基础的查询模式匹配方法。

● 强调平台无关性。在XML数据库研究的早期，业界曾存在一个争论:到底将XML数据存储在关系库中，还是另外开发存储XML的物理数据库。这在一定程度上影响着XML的研究者，在设计索引结构时必须考虑使索引过的XML数据可以存储在多种数据库结构中。

● 从理论的角度较多地考虑了XML数据库的模式设计规范化问题。设计了基于键的函数依赖推理，在如何优化XML数据库设计、消除数据冗余和不一致方面有了一些实质上的进展。

工业界的XML数据库产品更加强调实用，有着一些与学术界原型系统不尽相同的特点：

● 现有的主流XML数据库产品都在底层提供collection数据结构，以存储XML元素节点，通过B+树结构来索引这些元素节点。这一点与关系库系统的底层处理如出一辙。在collection之上一般还会有一级或两级索引，以加快查询处理速度。这一点比平台无关的实验原型系统更高效实用。

● 市场上的数据库产品通过引入日志管理，建立了较完善的事务处理机制，这为上层的数据库应用开发提供了便利。目前的商用XML数据库一般提供事务处理功能，包括提交、回滚和日志文件。通过提供事务日志机制，纪录系统执行的每个事务的详细情况，保证在系统出现问题后可以完全恢复。

● 增强了对异构数据源的集成管理。树型结构的XML数据有其难以管理的一面，但是，XML技术的可扩展性又使得它具有集成异构数据源的强大能力。因此，市场上的XML数据库产品普遍具有较强的集成多种数据源的功能。这也是当前市场上的XML数据库产品的一大亮点。

二.实验室的原型系统和商用化产品

最近几年以来，在学术界和工业界的共同推动下，如雨后春笋般诞生出大量的XML数据库原型系统和商用产品。

在Ronald Bourret的《XML Database Products》中一共列了36种XML数据库产品，大致上可分为三大类型：

● 商业类(commercial)：如Ipedo、Tamino、Natix、Xyleme等。其中，美国Ipedo公司的Ipedo XML Database和德国Software AG公司的Tamino是其中的佼佼者，成为目前市场上的主流产品。

● 研究类(research)：如Stanford大学早期开发的Lore等。

● 开放源码类(open source)：其中影响较大的是Berkeley DB XML、dbXML、XDB和Xindice。

需要指出的是， Lore database systems 只是Stanford大学早期针对半结构化数据而开发的数据库系统。Lore连同其专设语言Lorel都是为半结构化数据而写的。尽管说XML数据在某种程度上也是一种半结构化数据，但是，两者之间还是有着一些差别，导致Lore database systems很难成为一种完全意义上的XML数据库系统。

事实上，在学术界，真正受到关注的XML数据库原型系统有三家：密歇根大学安阿伯分校的Timber、西雅图华盛顿大学的Tukwila和威斯康星大学麦迪逊分校的Niagara。其中，影响最大的是Timber，在该系统的实施过程中，产生了许多有关XML数据库的新的概念和方法。当然，多伦多大学的Tox也是一个相当不错的系统，尤其是其出色的索引结构。但是，总体上不如前面的三家有名。

三.核心技术的进展

综合XML数据库的实验室原型和商业产品的共性，XML数据库的核心技术主要包括：

1.查询语言

自从1995年XML技术的研究和开发逐渐升温以来，形形色色的XML查询语言不断问世。比较有代表性的如早期的XML-QL、XQL、UnQL，后来的Quilt、Xpath，以及由Quilt发展而来的XQuery。在W3C的极力推动和学术界、工业界的大力支持下，XQuery逐渐在这些查询语言中脱颖而出，成为事实上的工业标准。

XQuery的FLWR语句规范，有着与关系数据库的SQL完全类似的表达方式，使得它在一般用户眼里，也变得友好起来。

而Xpath可以理解为是XQuery的一个子集。Xpath表达式在相关文献中被证明与查询模式树是等价的，这也与学术界推崇的模式树查询方式一致，使得实验室系统可以毫不困难地处理Xpath查询表达式，并能进行查询优化。这一点在XML数据库研究中显得颇有价值。

2.XML文档解析

在图1中，将XML文档载入数据库时，会经过一个XML数据解析器。数据解析器会依据一定的规则对XML数据进行解析后装入数据库。目前的数据解析器一般提供SAX(simple API for XML)和DOM(document object model)两种方式。

SAX和DOM是针对XML文档的两种不同的应用程序编程接口API。SAX更多地依赖语法制导(syntax driven)，而DOM则提供一组功能程序来开发与XML数据相关的应用。

SAX解析器是边读入边解析，带有一定的实时性，特别适合于XML流数据的处理。而DOM解析器是待整个文档均导入内存后才开始解析，在一定程度上受到内存容量的限制。目前的XML数据库产品均支持这两种解析方式。

3.查询处理

查询处理的方式和效率，一直是XML数据库研究和开发者关注的首要问题。

如图1所示，XML数据库的查询处理一般是从解析查询语言(如XQuery)的查询语句表达式开始的。XML数据库的查询解析器将表达式解析为一棵查询模式树(有的系统叫做语法树)。

假设一个XQuery表达式为：

book [tittle = ‘XML’] // [ year = ‘2000’]

它所对应的模式树如图2所示，它表示我们要查询的 book节点满足下面的条件：

● 有一个子节点tittle，它的内容为串值XML;

● 它有一个后代节点year，它的内容为串值2000。

从语义上来说，就是：查找“一本2000年出版的、名为XML的书”。

接下来就是到XML数据库中去匹配这棵树，得到最终的XML结果文档。

在如何匹配模式树的技术上，实验室原型系统与商业产品之间有着一些差别。

比如，在Timber中，考虑了一种叫做“结构化联接”的技术。它的基本思路是将上述的模式树分解为二元关系序列。而在此之前，也已经将XML文档库做了索引处理，文档中每个元素节点均被标以一个三元组索引，形式为：(文档标识符，开始位置：结束位置，层号)。

于是，该查询模式可以分两步来完成:在索引过的XML数据库中匹配上述分解的二元结构关系;将查找到的二元结构匹配结果组装(stitching)成最终的符合上述查询表达式的完整文档。

结构化联接技术在2002年被提出并在Timber中实现以后，在学术界引起过较大的反响。自2002年以来不断有技术上的改进文章出现在数据库的三大国际会议(VLDB、SIGMOD/PODS、ICDE)上，其中较有影响的成果是隐检整枝联接(holistic twig join)技术，可以用相互连接的多栈结构一次性生成查询结果文档。

在商用产品中，由于文档元素节点均存储在B+树结构中，可以直接到底层的数据库中去查找相关的匹配节点序列，再根据其指针关联，将结果节点集组装成结果文档。

总的来说，实验室产品在输入节点序列较长时效率会较高，尤其是隐检整枝联接技术。而商用产品在查询的文档较大时更显优势。

在查询处理阶段，实验室产品做了而商用产品没做的事情就是模式树的最小化。它的主要思想就是，模式树的匹配效率依赖于模式树的规模(元素节点的多少)。而一般的模式树均存在一定量的冗余节点，可以通过最小化算法予以去除。

根据复旦大学数据库研究中心XML小组的实验结果表明，在随机建立的XML查询模式树集合中，最小化算法平均可以消除30%的冗余节点。

当然，模式树最小化算法的时间复杂度比较高，目前的关注点主要在于时间复杂度的降低上。最新算法的时间复杂度已经降低到低阶的多项式时间了。这项技术的实用化是值得期待的。

4.事务处理和版本控制

目前的商用XML数据库一般提供事务处理功能，包括提交、撤回和日志文件。我们知道，事务为数据库的一组操作，这些操作组成一个逻辑单元，执行时要么全部完成，要么全部不做(do all or do nothing)。XML数据库通过提供事务日志机制，纪录系统执行的每个事务的详细情况，保证在系统出现问题后可以完全恢复。

事务遵循的ACID性质 (原子性、一致性、独立性和持久性) 保证了大部分事务处理稳定地运行。

商用XML数据库也包含对XML文档的版本控制功能。使用版本控制，用户或应用程序可以检入(check in)或检出(check out)XML文档，利用版本号、日期或者标签获得以前版本的文档，以及显示XML文档的版本历史信息。每一个处于版本控制之下的文档都有自己的历史信息，纪录了修改文档的作者以及时间等。使用者可以根据文档或用户或日期来查看整个的版本历史信息。

版本控制允许用户通过查询更新原信息。通过更新引擎可以注释、修改和精炼信息。内置的版本系统跟踪信息的变化，提供这些变化的历史信息。

应该说，在事务处理和版本控制机制上，实验室产品的考虑是不够的，所提供的事务处理的功能显得简单。尽管加州大学洛杉矶分校的数据库实验室在XML的版本控制方面有一些突出的成果，但是，目前尚未形成产品。

还有一个需要说明的是多事务并发控制机制和加锁协议。这项技术的研发目前刚刚起步。现今的商用XML数据库只在逻辑层面提供并发加锁协议，但粒度为整个文档。随着单个XML文档的增大，这个粒度显然太粗。这一点可能要等待研究界开发出粒度为文档元素节点的并发协议了。

5.代数系统和模式规范化

代数表达式和数据库模式设计理论曾经是关系数据库理论的精髓。代数系统成为关系库查询优化的重要工具，而范式理论的提出也曾为RDBMS设计优化的库结构提供了依据。那么，人们不禁要问，在XML数据库中是否存在相类似的理论和方法?

由于这两个问题有一定的难度，注定只能是由学术界的实验系统先行一步。

学术界公认的三大实验系统都设计了相应的代数系统，其中影响最为广泛的是Timber中实现的TAX(Tree Algebra for XML)。TAX以整个文档树作为操作的基本单位，在逻辑层提供选择、投影、联接等类似关系库的9种基本操作和5种附加操作，以匹配模式树得到实例树(witness tree)为基本操作方法。在物理层提出7种基本操作实现上述逻辑运算。

Timber依据TAX对XML查询语句进行改写和优化，但是效果并不理想。业界对TAX存在问题的看法是，过分地模仿了关系库的代数系统而忽略了对XML文档本身特点的考虑。

XML模式规范化理论的早期开拓者是宾夕法尼亚大学的樊文飞等人。从定义XML的键(key)和函数依赖，到XML和DTD范式，再到基于约束的XML数据库的模式规范化，XML数据库的模式规范化理论在稳步地推动着。国内的复旦大学数据库研究中心等单位也有着不错的研究进展。在未来两年内，估计会有较成熟的XML数据库模式设计理论投入到实验室产品和商用系统中。

6.多数据源的集成

多数据源的集成是数据库市场对XML数据库系统提出的要求。从1970年IBM公司的E.F.Codd提出关系数据库的概念以来，关系数据库在几乎所有的应用领域都取得了巨大成功。XML数据库是一个新事物，它从诞生的那一天起，就面临着关系数据库一统天下的局面。有人说，关系数据库完全战胜层次和网状数据库用了将近20年时间，XML数据库也会用20年时间战胜关系数据库。这种看法并不全面。至少从目前来看，两者应该各展所长，共同服务于巨大的数据库市场。

那么，XML数据库的优势在哪呢?用XML技术来进行多数据源的集成就是其中之一。

从2001年以后，面对多数据源的集成这个传统关系型数据库系统做不了的事情，Ipedo等商用数据库系统将自己的数据库系统扩展为一个集成平台，它可以将关系数据库系统、MIS系统、OA系统、文件系统等集成在同一个平台上，给用户提供统一的界面。如Ipedo公司的Ipedo XML智能平台，为用户提供XML View来统一访问底层的异构数据。人们也从这一点上进一步看到了XML技术的力量。

四.未来的技术发展方向

经过近5年业界同仁的共同努力，XML数据库技术取得了很大的进展，已经有若干种XML数据库产品问世并服务于社会生活的各个方面。但是，XML数据库的事业才刚刚开始，还有很多问题等待着我们去解决。

未来几年，XML数据库技术有可能在下述方面取得进展：

● 异构数据源的集成。XML数据库对多数据源的集成，是对XML技术可扩展性这一长处的极好发挥。但是，就目前的集成程度和在应用层上所提供的功能来看还是远远不够的。如何从对数据的集成过渡到对系统的集成，从而在远景目标上实现类似于网格计算(grid computing)概念的系统，恐怕是XML数据库工作者的核心任务之一。

● 底层索引结构。目前的商用XML数据库系统优于实验室原型系统的特点之一就是其底层的索引结构。但是，现有的商用XML数据库的底层索引结构一般都是B+树。虽然B+树索引是一种成熟的索引结构，但是，研究结果显示，在XML数据库中，它的性能表现并不是最好的。学术界已经开发出了若干种适用于XML数据的索引结构，如XR树、XB树等，需要XML数据库工作者来进一步关注。

● 并发加锁协议。在现有的XML数据库系统中，加锁的粒度是整个文档，事务并发的层次也在文档一级。随着应用级文档的日益增大，这个粒度在一定程度上将会成为系统效率的瓶颈。如何通过边锁(edge lock)机制来实现元素节点级粒度的加锁?这一工作现在吸引了不少研究者的目光,而且，上述的锁协议是在逻辑层，如何将它映射到底层的B+树索引(或者XR树索引)上，也是必须要做的一件事情。

● XML模式规范化是一个值得关注的方向。一旦取得突破，将会使我们可以像在关系库中那样方便地设计XML数据库的结构，消除数据的冗余和不一致现象。目前，这一领域已经成为学术界关注的热点。但是，完整的、为业界所公认的理论体系尚未建立。

通用惟一标识符（UUID）是128位比特的数字，用来惟一地标识因特网上的某些对象或者实体。

A Universally Unique Identifier is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labelled with UUIDs can therefore be later combined into a single database without need to resolve name conflicts. The most widespread use of this standard is in Microsoft's Globally Unique Identifiers (GUIDs) which implement this standard.

一个UUID 是一个标识符标准用于软件架构，是由开放软件基金会（OSF）作为分布式计算环境（DCE）的一部分而制定的标准。UUIDs的目的就是使分布式系统可以不需要重要的中央调合系统而能唯一地标识信息。这样，任何人能创造一个UUID 和使用它来标识一些东西，而且，你有足够的信心来确定这个标识是永远不会被任何人无意地使用在任何东西上。因此，信息加上了UUID标签就能合并到单个数据库中而不用去解决命名冲突的问题。这个标准的广泛应用在微软的全球唯一标识符（GUIDs）上，GUID实现了这个标准。

A UUID is essentially a 16-byte number and in its canonical form a UUID may look like this:

:550E8400-E29B-11D4-A716-446655440000

And has this structure in the C programming language:

typedef struct {
unsigned32 time_low;
unsigned16 time_mid;
unsigned16 time_hi_and_version;
unsigned8 clock_seq_hi_and_reserved;
unsigned8 clock_seq_low;
byte node6;
} uuid_t;

The J2SE 5.0 release of Java provides a class that will produce 128-bit UUIDs. The API documentation for the class refers to ISO/IEC 11578:1996.

关于UUID的定义，详细内容可参考http://www.ietf.org/rfc/rfc4122.txt，文档里面还有C语言对UUID标准的各种实现。

GUID

A Globally Unique Identifier or GUID is a pseudo-random number used in software applications. While each generated GUID is not guaranteed to be unique, the total number of unique keys (2128 or 3.4028×1038) is so large that the possibility of the same number being generated twice is very small.

一个全球唯一标识符 或 GUID 是一个假随机数用于软件中。虽然每个产生的GUID是不保证唯一的，但不同的标识符总数是（2128 也就是3.4028×1038）如此之大，以至于相同的数字被产生两次的机率是很相当小的。

The GUID is an implementation by Microsoft of a standard called Universally Unique Identifier (UUID), specified by the Open Software Foundation (OSF).

GUID 是微软对UUID这个标准的实现。UUID是由开放软件基金会（OSF）定义的。

UUID还有其它各种实现，不止GUID一种，其它的在此不详细说明。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/nidehong/archive/2006/11/22/1406125.aspx

UUID是是128位整数(16字节)的全局唯一标识符(Universally Unique Identifier)，指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成UUID的API。UUID按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。由以下几部分的组合：当前日期和时间(UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同)，时钟序列，全局唯一的IEEE机器识别号（如果有网卡，从网卡获得，没有网卡以其他方式获得），UUID的唯一缺陷在于生成的结果串会比较长。关于UUID这个标准使用最普遍的是微软的GUID(Globals Unique Identifiers)。

UUID，其格式为：xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx(8-4-4-16)，其中每个 x 是 0-9 或 a-f 范围内的一个十六进制的数字。而标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxxxx-xxxxxxxxxx (8-4-4-4-12)

       在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。数据库的主键生成有多种方式，每种方式都有其优点和缺点，应该根据不同的需求在主键的时间和空间效率上做平衡折中，从而选择不同的主键生成策略。归纳起来，对主键的选择主要有以下四种方式：

1.     自动增长字段

         自动增长型字段允许我们在向数据库添加数据时，不考虑主键的取值，记录插入后，数据库系统会自动为其分配一个值，确保绝对不会出现重复。

2.     手动增长字段

         手动增长型的字段，也就是说主键的值需要自己维护，通常情况下需要建立一张单独的表存储当前主键键值。

3.     GUID类型

         GUID是Globally Unique IDentifier的缩写，是一个128位的随机数,并保证不产生重复。

4.     COMB类型

         COMB（combine）型可以理解为一种改进的GUID，它通过组合GUID和系统时间，以使其在索引和检索事有更优的性能。

COMB数据类型的基本设计思路是这样的：既然GUID数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么能不能通过组合的方式，保留GUID的10个字节，用另6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与GUID组合起来，在保留GUID的唯一性的同时增加了有序性，以此来提高索引效率。

下面转自：温少，首发于博客园

替代方案之一，就是使用关系数据库的自增长字段，自增长字段的一个问题是，无法预先创建一个ID，只能够在保存的时候才能生成ID，这对于批量关联插入数据来说，不满足需求。

替代方案之二，就是使用一个记录ID的表，每次加一，在事务中使用Select FOR UPDATE来读取然后UPDATE SET FVALUE = FVALUE + 1，或者使用我之前文章中所提到的CAS算法。 这样做，会导致性能低下，每生成一个ID的成本都很高。

替代方案之三，就是把ID分成两部分，Seed和IncrementID。Seed采用上面的方案二或者其他办法生成，IncrementID使用一个AtomicInteger来每次递增生成。SEED转化为九进制数字，这样SEED就不会包含9，于是使用9作为分隔符，把SEED和IncrementID隔开。这样做，就可以做高性能产生ID，而且确保不重复。甚至可以更进一步，SEED由一个中心服务器生成。使用9个分隔符号隔开SEED和IncrementID，好处是SEED是变长，而不是使用固定位数来保存SEED，这样产生的ID会更短，可读性更好。

举例，34915，其中34时SEED，15是IncrementID，9是分隔符，SEED部分采用九进制表示法，确保不出现9，第一个9之后的内容属于IncrementID。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/happyflystone/archive/2007/11/27/1903854.aspx