答案:第五节 再谈谈一些J2ME规范
在 J2ME内还有很多子规范, J2ME的重要的部分如下:PersonalJava、K虚拟机 (KVM)、Java嵌入服务器以及 PersonalJava的两个扩展规范: JavaPhone和 JavaTV应用程序接口。 你可以想象, JavaPhone是一个定位于无线电智能电话和互联网络可视电话的应用程序接口,而 JavaTV则满足机顶盒市场的需求。
下面我想详细的谈一谈以上的规范:
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还没有。 读者请去Sun相关网站去看看( http : file://java.sun.com/products/personaljava)。
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实例化、运行一样,服务空间就是以实例化的服务的聚集地。服务空间管理安装、实例化、执行、终止以及卸载服务;它也提供应用程序接口供服务交互作用。
上一个:Java嵌入式开发之二(上) 转自yesky
下一个:文档位置...