Java嵌入式开发之J2ME规范
下面我想详细的谈一谈以上的规范：
1、PersonalJava
PersonalJava应用程序环境目标是 Web连接消费设备——常常执行来自网络的小应用程序。问题是 PersonalJava如何适合 J2ME的配置和简表方案。 答案是 PersonalJava将被包容进 Connected Device Configuration中，最终将被定义为 Personal简表，即前面所谈到的Personal简表。
另一方面，有一段时间将有两个 Java应用程序接口为嵌入开发世界服务： PersonalJava和 EmbeddedJava. PersonalJava偎依在 J2ME大伞之下， 可为什么 EmbeddedJava不呢？ EmbeddedJava不和 PersonalJava同在 J2ME内，是因为在 PersonalJava和 EmbeddedJava应用程序之间有一个基本的差别。 PersonalJava应用程序期望连接到某类网络中下载并执行小应用程序。 按照这种观点， PersonalJava设备就是一般用途的消费设备； 它们的能力可以被扩展。
相比之下， EmbeddedJava设备则惨了点。 它们执行的功能都非常具体的，基本没有必要提供下载新的代码到 EmbeddedJava设备的能力。 Hence， PersonalJava设备使用可扩展 Java应用程序接口； 而EmbeddedJava设备则没有，因为没有必要使用。
PersonalJava可以以两种形式得到： 由原码形式的，提供给那些对把PersonalJava移植到其他设备感兴趣的开发者，那些已经把 PersonalJava移植到某个具体的操作系统和处理机的组织提供二进制形式的 PersonalJava环境。有兴趣探索 PersonalJava的开发者如果没有二进制平台也可以使用 PersonalJava模拟环境 （ PJEE ）。 这个模拟器运行于 Solaris/SPARC或Windows并且在许多配置中可用。 这些多种多样的配置基于" look and feel"和类库支持 （环境是否提供 PersonalJava规范中规定的最低限度的或最大的类库）。PJEE包括类文件，一个应用程序 launcher和一个 appletviewer （两者都是为了调试功能并使其最优化）和其它的附带的文件 （例如字体叙述文件）。
J2ME家族的另一位成员 JavaCheck实用程序，提供了 PersonalJava的补充支持。 你把应用程序传过 JavaCheck，它将告诉你你的应用程序在一个 PersonalJava环境中能否顺利地执行。 JavaCheck检查类之间的依赖关系，如果应用程序调用了一个在 PersonalJava不可用的应用程序接口，它就会给出一个警报信号。 （据我所知，目前有两种JavaCheck的版本可用，一个是用于检验 PersonalJava 1.0版应用程序，另一个用于检验 1.1.x版程序。 当前的 PersonalJava应用程序接口规范是 1.2，用于这一版本的 JavaCheck还没有。
2、KVM
前面我也说过，KVM是用于 J2ME平台最小的虚拟机，并且是用于CLDC配置的虚拟机。可是J2ME应用程序并不一定非要使用 KVM，J2ME技术可以使用任何虚拟机，不过至少应当有 KVM这样的功能。
为了满足基于KVM的设备一般只有狭小的内存空间和有限的处理能力的事实， KVM使用 C编写 （它不是现有的VM改进了的以后的产品）。 此外， KVM是模块化的， 也就是说，它是由模块构建的，当某个模块实现了预先设定的目标后，就可以很容易地把这一模块卸载。 可选的某块包括： 大的数据类型 （ long、 float和 double ），多维数组、类文件验证等。
KVM的本地界面以轻便性为原则构建，所以在KVM中任务切换不依赖硬件产生的记时器中断，因此在这种意思上来说不是抢先式。任务切换发生在虚拟机执行了一个预设编号的字节码之后。 并且， KVM的无用单元收集利用一个标记清扫（mark and sweep）算法来实现无用单元释放。 因此，对象引用是直接的，就像标准 Java一样。
当然，除了虚拟机以外还有许多可用的执行环境，在小型设备中，虚拟机必须要么被扩展，要么在附加工具协助下提供一个更加完整的运行期环境，正是这个原因， KVM需要附带的工具，比如说， JavaCodeCompact工具提供了预链接和预加载类， 允许Java类被直接地链接进虚拟机中。（（设备上所有的应用程序使用的类 can直接地嵌入虚拟机。）
KVM一个可选的附件就是 Java Application Manager （ Java应用程序管理器，简称 JAM ）。JAM的工作就是处理下载、安装、执行和卸载 CLDC设备上的应用程序的细节问题，因为资源有限，在CLDC设备上有可能不存在这些功能。JAM也处理更新安装应用程序的操作。（如果更新过程失败，它甚至可以重新使用旧的应用程序。 ）
3、Java Embedded Server（Java嵌入服务器）
Java Embedded Server（ Java嵌入服务器，简称 JES），在 PersonalJava基础上建立，是一个用于嵌入式网络设备的运行期环境。为了理解 JES，你必须理解两个核心概念：服务和服务空间结构。后者是前者的容器。服务程序是运行于一个 JES服务器上的组件化程序；服务空间结构是为服务程序提供生命周期 支持的环境。
技术上说，服务程序是界面的实现，事实上，它是一个实现特定活动的Java类集合。比如说，假如把 JES配置为一个家庭的气候控制系统的服务器，可以把从模数转换器读到的温度数据放进一个数据组件程序中。我就可以称这个组件为ReadThermostats服务程序。
在 JES的领域，服务的封装媒介称为 bundle.简单地说，bundle就是一个带有特殊内容的JAR文件。服务程序和bundle之间有一对一关系，一个bundle带有一个服务程序。服务程序和 bundle之间有一对一关系，一个 bundle带有一个服务程序。可这也不一定，一个 bundle可以设置多个服务程序索引 （注意， JES提供的所有的核心服务，每个 bundle中只有一个 ）。
正如前面提到的那样，服务空间的一项工作就是管理服务程序的生命周期，这个工作的很大的部分包括解决服务隶属关系。bundle内容的一个重要的部分是bundle服务的依赖信息。所以，当服务空间打开一个bundle安装它的服务时，服务空间就可以确定外部需要什么服务。而且，一个服务的依赖关系并不是静止不变的，它们可以随某些事件改变。比如说当服务程序更新时的变化就是一个很好的例子。一个服务的新的版本可以添加或去除依赖关系。服务空间跟踪并解决这样的动态依赖关系。如果服务空间处理所有服务程序的生命周期，这就暗示了服务空间被赋予知晓一切的能力，那就是说，它能够推论结构、依赖、安装的细微差别等所有它负责的服务。服务空间通过在 bundle内伴随服务的 Java代码模块处理一些任务，这些模块被称作 wizard（向导）。JES向导是根据它们完成的任务命名的：
Dependencies -向导告诉调用者一个bundle依赖关系是什么。
Installer-向导处理bundle中服务的安装和删除操作。
Activator -向导知道如何启动和终止服务。
Updater -向导控件更新bundle中的服务。（更新向导不仅知道更新一个服务，而且知道在何时和什么情况下更新服务。 ）
About -这个向导，就像它名称意味的那样，返回关于 bundle内容的信息。
Dispatcher -这是一种元向导（meta-wizard）。服务空间调用dispatcher向导定位一个bundle的其他向导。
当一个 JES服务器启动的时候，服务空间并不是完全没有启动服务。JES定义一组核心服务（可选），这些都是任何 JES服务器的组成部分。这些核心服务包含：
HTTP服务
日志 -记录错误和事件日志
日期 -精确到秒的日期/时间服务
连接管理器 -提供网络服务和Socket绑定，也处理连接接收。
线程管理器 -管理服务器提供的线程。thread管理器支持线程池并允许有效使用线程上界的规范。
计划程序 -提供未来的事件计划安排 （可用于告诉服务器某某动作必须在某某事件发生 ）
RMI
SNMP
控制台 -提供远程管理服务器功能
基于 HTTP的远程应用程序接口实现
基于 RMI的远程应用程序接口实现
如果你把服务空间结构当成 JavaBean中的容器的话， JES就变得容易理解了。在这种类比关系中，服务程序就相当 JavaBean.那么，正象组件容器提供一个环境供 JavaBeans实例化、运行一样，服务空间就是以实例化的服务的聚集地。服务空间管理安装、实例化、执行、终止以及卸载服务；它也提供应用程序接口供服务交互作用。
