Lookup Library: 组件通信的解决方案
这是lookup库的实现主页，lookup主要目的是解决每个基于组件系统必须面对的问题：不同的组件如何注册到系统以及系统的其它部分如何找到它们。
已经有一些库试图解决该问题，通常这些库都是通过一个接口查询然后找到相关的实现。最出名的有jini，该平台主要用于分布式网络服务的开发。我们lookup库做类似的事件，但试图更小和更容易使用。NetBeans Lookup库主要专注于由互相独立的模块组成的模块化应用程序，这些模块需要彼此通信。Lookup库没有去试图解决网络或遗留系统的集成。Lookup简单但更有用。
为何你要用Lookup库？
一个写的好的模块程序分离了开发和部署。在许多情况下，一个组件需要一些功能但并不需要关心这些服务是如何实现的。由部署或安装应用程序的系统管理员去决定使用那个实现。
允许其他实现被插入的最简单和最常用的方法是系统属性模式：
public Toolkit getDefaultToolkit () {这个想法很简单。部署人员启动Java虚拟机时加上标记
java.awt.Toolkit t = null;
String classname = System.getProperty ("java.awt.Toolkit");
if (classname != null) {
try {
Class c = Class.forName (classname);
t = (java.awt.Toolkit)c.newInstance ();
} catch (Exception ex) {
System.out.println ("Cannot initialize toolkit: " + classname);
ex.printStackTrace ();
}
}
// fallback
if (t == null) {
t = new GenericAWTToolkit ();
}
}
-Djava.awt.Toolkit=org.myorg.MyToolkit，这个类有缺省的构建器并且在getDefaultToolkit方法中的代码可以构建类的实例并能使用它。
从原理上，这个解决方案是足够通用且工作的很好，除了写上面的代码容易出错且执行时需要传送参数给虚拟机。如果仅仅将包含MyTookkit类的jar文件放到应用程序的classpath中就可完成注册登记会更好。
实际上这个已经被JDK的开发团队实际实现并作为JDK1.3提供者扩展机制的一部分。MyToolkit可以通过添加一个/META-INF/services/java.awt.Toolkit文件到包含MyToolkit实现的jar文件中完成注册，文件中包含一行org.myorg.MyToolkit的内容。getDefaultToolkit方法中的代码会扫描所有classpath中的JAR文件并搜索那个文件，创建MyToolkit实例，然后使用它。部署人员可以添加相应的JAR文件到classpath中来调整toolkit实例的创建。
当然代码访问META-INF/services/中的文件比属性模式更容易出错。那么这就是lookup库能助解决问题的地方。lookup库用一个简单的接口提供了一个搜索算法实现。只要如下写：
import java.awt.Toolkit;
import org.openide.util.Lookup;;
Toolkit t = (Toolkit)Lookup.getDefault().lookup(Toolkit.class);
然后如果包含MyToolKit的JAR文件在classpath中，上面简单的调用就可完成剩下的工作。所以
无任何时，一个人写一个被分为几个独立模块的应用程序，模块的开发和部署又是独立的，都需
要注册和发现组件。首先，定义一套接口用于模块之间的通信（如java.awt.Toolkit抽象类）。
然后写一套模块具体提供实现（MyToolkit和其他一致的实现），然后，无任何时一个模块通
过lookup访问Toolkit想活动实际功能时，一个实际具体的实现会被返回。
找到一个服务请求的合适实现并返回一个实现服务的对象是lookup的职责。这是最基本的功
能，然而库为你提供了多一点，连这个简单用发也会非常有用：客户代码不知道有关实现相关
内容而且实现可以在部署时进行切换，只要简单替换具体的实现jar文件即可。其它代码不需要
修改。
本地lookup用法
待续。。。。。。
