Jini(TM) Technology Starter Kit Overview V2.1 part1

Jini(TM) Technology Starter Kit Overview V2.1 part1

原文出处：http://cs.ttu.edu/~sorcer/resources/jini-docs/arch2_0.html
第一次自己翻译文章，希望还能看：）
 Jini(TM) Technology Starter Kit Overview V2.1
    这篇文档对Jini(TM) Technology Starter Kit V2.1中的新组件进行了概览，并阐述了这些组件是如何组合起来与目前现存的jini技术的底层架构进行整合的。这篇文档中的的很多信息都可以在包，接口以及类文档中找到，不过这篇文档给出了更高层的总览。在其中更帮读者指明了在哪里可以找到更多的信息。

1 Jini架构总览
Jini系统架构有三类组成：编程模型，底层框架，服务。原始的《Jini 架构说明》对这三个类别进行了以下定义：
        * 底层框架（infrastructure）是一组用来建立一个联合的Jini系统的组件。
        * 服务(services)则是这个联合系统中的实体。
        * 编程模型（programming model）是一组用来构造可靠的服务的接口。
起初，编程模型定义了租约，事件通知，和事务。底层框架由发现/加入（discovery/join）协议和查找服务（Lookup service）组成。上一个版本的Starter Kit导入了以下Jini technology-enabled服务（Jini服务）：
        * Lookup Service(reggie)
        * Transaction Manager Service(mahalo)
        * Lease Renewal Service(norm)
        * Event Mailbox Service(mercury)
        * Lookup Discovery Service(fiddler)
        * JavaSpaces(TM) Service(outrigger)
Starter Kit V2.0发行版对前两个类别（infrastructre,services）加入了一些组件，其中一些组件同时跨越了这两个类别。而且，这个发行版提供了对现有服务的升级来提供底层架构和编程模型。加入的组建按如下总结：
    对编程模型的添加：
        * Configuration
        * Exporter
        * ProxyPreparer
    新的底层框架：
        * Security
        * Invocation Constraints
        * Jini extensible remote invocation(Jini ERI)
        * Dynamic Policy
        * Preferred Class Loading
        * Discovery Protocol V2
    对服务的添加：
        每一个服务都被升级到支持使用Configuration进行配置。大多数的服务以前都是通过系统属性进行配置。这些服务现在已经可以使用在Configuration中的实体进行配置     了。新的可配置的行为是：远程服务导出（Remote service exporting）和代理准备（proxy preparation）。
1.1 目标
在Jini架构中新添加的部分的主要目标是：
        * 为基于jini技术的程序提供安全支持。（Security infrastructure）
        * 提供可配置的应用。（Configuration）
        * 统一客户端和服务器端的编程模型。（ProxyPreparer和Exporter）
        * 提供一个支持可插入的调用层行为，以及可插入的传输实现。(Provide a java rmi implementation taht supports pluggable invocation layer behavior and               pluggable transport providers)。
扩大jini架构的最主要动力来自于提供新的编程模型以及基于jini的应用程序对底层框架中的安全管理的需要。上一个发行版本中缺少在很多应用程序中需要的对安全的直接支持--即对服务远程调用的基础网络安全。这个目标已经在新的安全底层框架和基于约束的远程调用模型(constraint-based remote invocation model)中得以实现。
另外一个重要的目标就是更好的为服务的编程人员提供统一的编程模型。提供上一个版本中缺少的实现，倒入，部署服务所需的一致的API。加密的远程调用导致了客户端必须增加确认的步骤，所以这个发行版导入了一个统一的客户端API来处理远程调用前的“Preparation”步骤。另外，通过将部署时信息从应用中剥离，可以使应用程序的开发者轻松的完成部署任务。这个版本中的配置API被用来提供简单而统一的取得部署描述信息（deployment-specific）的方式。从而使得编程模型变成一个对可插入的安全，导出，传输和其他服务支持具有统一支持的框架。
最后一个目标就是，提供一个JAVA RMI编程模型的实现，该实现支持远程调用中的约束（安全模型中至关重要的部分），并且支持可插入的调用和派发行为，就如同在每个对象中基础的可插入的传输功能，这些特点是JAVA2 SDK中的RMI所不具备的功能。JINI ERI API提供了这样一个可插入的JAVA RMI编程模型的实现。

2 编程模型
在进行深入的安全架构研究之前，先理解一些增加的编程模型，配置，导出和代理预备是很重要的。他们被用来简化普通的应用开发特别是安全相关的应用开发。
2.1 配置
当一个应用程序使用一个抽象层将源代码与特殊的部署信息相互剥离，而不是仅仅的与其绑定时，这个应用将非常易于测试部署和改进。比如说服务提供者接口。这样的应用允许部署信息在部署时才被配置。明显的优势就是，应用程序的源代码不需要改变就可以按照部署需要增加组件。如果部署需要改变，只需要改变配置而应用程序无需任何改变。

net.jini.config.Configuration API通过提供一个简单的统一的方式来得到配置应用程序所需的的对象来完成这项工作。一个应用程序可以从Configuration中得到对象而不是明确的自己来组建一个实例，从而避免与部署信息绑定。典型的对象应该从一个Exporter或者ProxyPrepare的Configuration中得到（后面讨论）。
一个应用可以使用net.jini.config.ConfigurationProvider来得到Configuration的实现。在应用中使用ConfigurationProvider允许应用程序的部署器在部署时指定最合适的配置实现。一个给定的配置实现可以从文件，数据库或其他地方得到读取配置信息。
标准的默认的配置实现是net.jini.config.ConfigurationFile。它使用java语言实现从配置文件或者URLS中读取配置信息产生产生对象的功能。
2.2 导出器和服务器端实现模型
在基于jini技术的应用程序中，调用一个jini服务的方法有统一的client端模型：一个客户端只是简单的调用服务代理的一个方法来初始化与服务对象的远程通讯，这是一个尊从通用的JAVA RMI模型的调用语法。
而Jini应用的服务器端实现模型却并不是统一的。一个应用开发者通常实现一个服务，并将其直接与特定的实现以及特定的远程通讯模型相互绑定后导出。如果服务的服务的导出方式发生轻微的改变，则需要改动服务器端应用程序的代码。例如，一个应用的部署方式要求使用一个不同的端口号或Socket工厂导出一个服务，甚至服务需要以全新的方式进行远程通讯，比如说不同的RMI编程模型实现。
net.jini.Exporter接口通过为导出和卸载远程对象提供一个抽象层统一了服务器端的实现模型。具体的导出和卸载行为包括远程调用的通讯协议，和增加的调用语法在特殊的Exporter接口的实现中进行定义。

本次的发行版提供了很多标准的Exporter实现，同时也是Java RMI的编程模型。以下的列表列出了这些实现：
           Exporter                        Equivalent Class
   net.jini.jrmp.JrmpExporter       java.rmi.server.UnicastRemoteObject
   net.jini.iiop.IiopExporter       javax.rmi.PortableRemoteObject
   net.jini.jeri.BasicJeriExporter  itself

应用程序可以将Exporter Interface与Configuration一起使用从而使用一种在部署时可配置的方法导出远程对象。下面的代码展示了可配置的导出：
    import java.rmi.*;
    import net.jini.config.*;
    import net.jini.export.*;
    public class Example implements Remote{
        public static void main(String[] args) throws Exception{
            Configuration config = ConfigurationProvider.getInstance(args);
            Exporter exporter = (Exporter)config.getEntry(
                "Example","exporter",Exporter.class);
            Remote proxy = exporter.export(new Example());
            System.out.pringln(proxy);
            exporter.unexport(true);
        }
    }
这个应用可以将下面的配置文件作为命令行参数进行配置（配置文件使用ConfigurationFile语法）。配置文件描述Exporter为一个JrmpExporter，一个能够产生使用JRMP协议代理的Exporter。
    import net.jini.jrmp.*;
    Example{
        exporter = new JrmpExporter();
    }
或者，可以为部署指定一个BasicJeriExporter（一个使用Jini ERI导出远程对象的Exporter）Exporter，用来在任何的匿名TCP端口上导出对象。
    import net.jini.jeri.*;
    import net.jini.jeri.tcp.*;
    Example{
        Exporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0));
    }

2.3 ProxyPreparer和Client-Side Invocation Model
新的安全模型需要应用在调用一个服务代理的方法前执行它的一些pre-invocation“准备”。这是因为一个应用也许会从没有取得信任的来源获取服务代理。因此，在应用使用代理之前，应用应该执行诸如确认代理中的信任信息等操作，一旦信任信息被确认后还要为代理分配权限。

这些安全需求给client-side调用模型增加了一个步骤。net.jini.security.ProxyPreparer接口将"proxy preparation"的操作提炼到了一个单独的方法中。prepareProxy，以此来统一客户端在跨越使用安全和非安全的代理的调用模型。

一个ProxyPreparer可以与Configuration一起使用来允许可配置的Proxy Preparation。以下的代码是从hello例子中提取出来的：
    ProxyPreparer preparer = (ProxyPreparer)config.getEntry(
        "com.sun.jini.example.hello.Client","preparer",ProxyPreparer.class,new BasicProxyPreparer());
    server = (Hello)preparer.prepareProxy(Server);
    System.out.println("Server says:" + server.sayHello());
对getEntry的调用为没有在配置文件中定义的实体提供了一个默认的(new BasicProxyPreparer())。一个net.jini.security.BasicProxyPreparer的实例可以使用指定的参数进行初始化。该参数说明是否有一个proxy将被被传给它的prepareProxy方法中，来确定信任信任信息，以及其他的安全相关的操作。一个没有使用参数初始化的BasicProxyPreparer指出了"do nothing" proxyPreparer，只是简单的将传入的proxy返回。
如果一个应用部署有安全需要，那么这个应用可以使用一个被正确的参数初始化的BasicProxyPreparer，或者其他的ProxyPreparer实现进行部署。