|
文章来源：《J2ME无线设备程序设计（第二版）》 作者：Roger Riggs，Jim Van Peursem，Mark P 4.2.1 架构概述 典型的CLDC设备的大体架构如图4.1所示。CLDC实现的中心是一个Java™ Virtual Machine，此虚拟机除了本章后面讨论的特殊之处，是遵循Java™ Virtual Machine Specification和Java Language Specification的。在典型情况下，虚拟机运行于一个宿主操作系统之上，宿主操作系统为虚拟机提供管理底层硬件的必要能力。如同在第3.4.3节解释过的，CLDC Specification只对宿主操作系统的能力作最低程度的假设。 位于虚拟机上层的是Java类库。这些类库被大致分为两类： 1. 由CLDC定义的类库（CLDC Libraries）； 2. 由profile（如MIDP）定义的类库和可选包。 由CLDC定义的类库在第5章讨论。由profile定义的类库不在CLDC Specification的范畴之内。MIDP支持的类库在第8到第20章讨论。 4.2.2 Java应用程序的概念 CLDC并不针对任何特定设备类别。许多CLDC目标设备都拥有高级的图形用户界面，但也有一些设备只能通过字符界面操作，甚至还有一些设备根本就没有任何可视的用户界面或显示屏。为了适应这种设备间的巨大差异，CLDC Specification特意将应用程序模型定义得非常简单。 在CLDC Specification中，术语“Java应用程序”指的是一组Java类文件，其中包含一个独一无二的main方法作为应用程序的启动入口点。按照Java™ Virtual Machine Specification（JVMS）第5.2节和第2.17.1小节的定义，这个main方法必须声明为public、static和void，如下所示： public static void main(String[] args) 遵循CLDC的虚拟机将通过调用这个main方法来启动一个Java应用程序。 MIDP等J2ME profile可以定义其他应用程序模型来扩展或取代CLDC Specification中定义的基本应用程序模型。 4.2.3 应用程序安全性 Java 2 Platform, Standard Edition中投入到安全性方面的代码量远远超过了CLDC要求的总内存容量。因此，在定义CLDC应用程序的安全模型的时候，有必要作一些简化。基本上，CLDC的安全模型可以分为3个层次： Ÿ 底层安全性（Low-level security，也叫做虚拟机安全性）。确保在虚拟机中运行的应用程序遵循Java编程语言的语义，防止病态或敌意的类文件使设备崩溃或以任何其他方式伤害设备。 Ÿ 应用程序级的安全性（Application-level security）。指运行在设备上的Java应用程序只能访问那些设备和Java环境允许它访问的类库、系统资源和其他组件。 Ÿ 端到端的安全性（End-to-end security）。这个模型用于确保设备上发起的任何事务到为此事务提供服务的实体（如Internet上的一个服务器）的整个传输路径中来回都是安全的。可能需要用加密或其他手段来达到此目的。端到端的安全性超出了CLDC Specification的范畴。 下面我们更详细地讨论底层安全性和应用程序级的安全性。 底层安全性 底层安全性是运行在移动信息设备上的Java虚拟机的一项关键要求。虚拟机中运行的应用程序绝不能损坏设备或使设备崩溃，虚拟机正运行在这个设备上。在标准的Java虚拟机实现中，这个约束是由类文件验证器（class file verifier）保证的，类文件验证器确保类文件中存储的字节码和其他内容不会包含非法指令，不会以非法的顺序执行，并且不会包含指向无效内存或Java对象存储区域（对象堆）之外的引用。简单来说，类文件验证器的角色是确保装载进虚拟机的类文件不会以Java™ Virtual Machine Specification所不允许的任何方式执行。 CLDC Specification要求遵循CLDC标准的Java虚拟机必须能够拒绝无效的类文件，这一点后面会详细解释。这一要求由第4.2.2小节讨论的类文件验证技术来保证。 应用程序级的安全性 虽然类文件验证在保证Java平台的安全性上扮演了关键角色，但单靠类文件验证器提供的安全性是不充分的。类文件验证器只能够保证给出的程序是一个有效的Java应用程序。还有其他一些潜在的安全威胁是验证器发现不了的。比如，访问外部资源如文件系统、打印机、红外线设备、本地程序库和网络等等，都超出类文件验证器力所能及的范围。应用程序级的安全性意味着Java应用程序只能访问那些设备和Java环境允许它访问的类库、系统资源和其他组件。 在CLDC中，应用程序级的安全性通过一种被比喻成“沙箱”的封闭机制来实现。CLDC应用程序运行在一个封闭的环境中，在这个环境中，应用程序只能访问由configuration、profile、可选包定义的类库和设备支持的其他类。Java应用程序不能越出沙箱，不能访问不属于这些预定义功能的任何类库或资源。沙箱机制保证了恶意或错误的应用程序不能获得对系统资源的访问权。 说得更详细一点，CLDC沙箱模型要求： Ÿ 类文件必须被正确验证，并保证它是有效的Java应用程序。（类文件验证将在第4.4.2小节详细讨论。） Ÿ 在设备上下载、安装和管理Java应用程序的过程中，应用程序开发者都不能修改或跳过虚拟机标准的类装载机制。 Ÿ 应用程序开发者可以使用在CLDC、profile、可选包或厂商专用类库中定义的一组封闭的、预定义的Java API。 Ÿ 虚拟机可以访问的本地（native）函数集是封闭的，也就是说应用程序开发者新下载的任何类库中都不能包含新的本地功能，或者访问任何不能在CLDC、profile、可选包或厂商专用类库提供的Java类库中找到的本地函数。 出于安全理由，CLDC Specification还就系统类和应用程序类间的相互影响作了一些额外的要求。例如，一份CLDC实现必须确保应用程序开发者不能覆盖、修改或添加任何类到系统包如java.*、javax.microedition.*中，或profile的专用包中，也不能以任何方式修改内建的类文件查找顺序。类文件查找顺序在第4.4.3小节详细讨论。 另外，还要求CLDC应用程序只能从它自己的Java Archive（JAR）文件中装载应用程序类。这个约束保证了设备上的Java程序间不会互相干扰，也不能互相窃取数据。设备制造商和服务提供商可能会提供一些Java类作为系统程序的一部分，这个约束还保证了第三方应用程序不能访问这些类中的private和protected成分。 MIDP等J2ME profile可以在CLDC提供的安全性解决方案之上增加自己的方案。MIDP的安全性将在本书第16章和第18章讨论。 4.2.4 应用程序管理 许多小型的资源受限设备都没有文件系统或者其他任何传统机制来在设备上存储动态下载的信息。因此，不要求一份CLDC实现能够在设备上持久地存储下载自外部来源的Java应用程序。它可以仅仅装载应用程序，并在运行结束后立即丢弃这个程序。 不过，对许多潜在的CLDC设备来说，如果能重复执行同样的Java应用程序又不必一次又一次地下载它是有好处的。如果应用程序是通过无线网络下载的，这一点就显得尤为重要，因为可以免去用户昂贵的下载费用。如果一个实现了CLDC的设备能够持久地存储应用程序，我们自然会认为它也能够管理存储在设备上的应用程序。粗略来说，应用程序管理指的是这样的能力： Ÿ 下载和安装Java应用程序。 Ÿ 查看已存储在设备上的Java应用程序。 Ÿ 选择并启动Java应用程序。 Ÿ 删除现有的Java应用程序。 CLDC系统可以允许多个Java应用程序并发执行，也可以限制系统在同一时间只允许运行一个Java应用程序，这取决于设备上的可用资源。至于是利用底层宿主操作系统的多进程能力，还是通过多个逻辑虚拟机实例来运行并发的Java应用程序，则交由各个CLDC实现去决定。 由于潜在的CLDC设备间的显著区别和功能差异，应用程序管理的细节是高度依赖于具体实现和设备特性的。应用程序管理的实质细节超出了CLDC Specification范畴。MIDP环境中的应用程序管理在第19.2节讨论。 |