随着移动商业从时髦的口号逐渐变成现实，对于移动用户和无线应用程序开发人员这类人而言，事务安全性正在成为一个重要方面。网络整体安全性的强度取决于其最薄弱环节，而在移动商业网络中，最薄弱环节是客户机端设备。无线信号的可截取本质以及大多数手持设备有限的内存和计算能力，使无线系统极易受到数据窃贼的攻击。
但客户机并非移动商业网络上的唯一薄弱环节。随着 Web 服务技术成为因特网领域中日益重要的组件，无线网络将面临一些全新的弱点。Web 服务使用开放通信协议并在组织的防火墙之外运行，当在企业中部署这些系统时，这将会造成非常实际的安全性威胁。
解决方案正在形成，尽管尚需时日。尤其是，Web 服务本身可以用来提供安全性解决方案。新的 Web 服务规范计划标准化和集成使用 XML 消息传递的先进的安全性解决方案（如 Kerberos 认证和授权、数字证书、数字签名和公／私钥加密）。
可互操作的 Web 服务可以将那些安全性解决方案用作产品和服务供给商的一类实用程序。但即使正在出现这些有希望的解决方案，对于您如何有效地保护自己的无线应用程序及运行应用程序的网络而言，开发平台的选择将始终起到举足轻重的作用。
在本文中，我们将重点讨论在 Java 2 Platform，Micro Edition（J2ME）上进行开发的优缺点。我们首先对 J2ME 的基本概念和优点作简单概述。接下来，我们将深入研究基于 J2ME 的应用程序相对于其它无线备选应用程序（如 WAP 和本机应用程序）的潜在安全性优点。
我们将说明当前在 J2ME 平台上可用的应用程序安全性模型，以及该平台对于一些可预料未来趋势的适用性。作为讨论的一部分，我们将提出一些增强 J2ME 应用程序的网络和数据安全性的可能方法。在结束部分，我们将总结使用 J2ME 技术开发用于最小型无线设备的高级安全应用程序的可行性。在整篇文章中，我们将主要集中讨论当前的和即将出台的（2.0）MIDP 规范，假定 MIDP 是最广泛使用的 J2ME 概要文件。
因为 Web 服务承诺了在移动商业和无线安全性的发展中扮演重要角色，所以在整篇文章中，我们都将讨论包含 Web 服务的技术。我们将花一些时间研究 Web 服务对您的 J2ME 开发策略的影响。
J2ME 基础知识
将 Java 平台用于无线设备开发的最大优点是能够生产可在多种平台上运行的可移植代码。但即使有这个优点，各种无线设备在内存、处理能力、电池寿命、显示屏大小和网络带宽等方面的能力差异还是相当大的。不可能将运行在成熟的机顶盒上的应用程序的全部功能都移植到移动电话上。即使对于类似的设备（如 PDA 和高级智能电话），在两者间建立可移植性也经常使一种设备超负荷而另一种设备利用不充分。只能在多组类似设备之间实现真正的可移植性。因为熟悉到一种规格并不能适合所有设备，所以小心地设计 J2ME 以在可移植性和可用性之间取得平衡。
什么是 Web 服务？
Web 服务是具有基于因特网接口的自包含的、自我描述的、动态发现的应用程序。Web 服务由远程方法调用驱动，这些调用是用标准的、基于 XML 的消息和编码封装的，如简单对象访问协议（Simple Object Access Protocol (SOAP)）。Web 服务用 WSDL（Web 服务定义语言）定义了它们的编程接口并通过 UDDI（通用描述、发现和集成）注册中心来发布它们本身。Web 服务在开放的因特网上通过 HTTP 协议与客户机和其它 Web 服务通信。
这种“HTTP 上的 XML”模型致力于通过在服务接口之间添加一个开放、健壮和轻易被人理解的抽象层来消除它们之间的耦合。Web 服务是松散耦合、与平台无关、可重用的分布式软件组件。它们成功的要害在于开放的标准和服务供给商之间的互操作性。
J2ME 分成几种不同的配置和概要文件。配置包含用于一系列设备的 Java 语言核心库。当前有两种配置：连接的设备配置（Connected Device Configuration (CDC)）被设计用于相对较大和功能强大的设备（如高端 PDA、机顶盒与网络设备）；有限连接设备配置（Connected Limited Device Configuration (CLDC)）被设计用于小型的资源有限的设备（如移动电话和低端 PDA）。CDC 的安全性、计算能力和 I/O 功能比 CLDC 高级得多。
每个配置上面都有几个概要文件。概要文件定义了更高级的、特定于设备的 API 库，包括 GUI、联网和持久存储 API。每个概要文件有自己的运行时环境并适合于一系列类似的设备。为一个特定概要文件编写的 Java 应用程序可以在由该概要文件支持的所有硬件／OS 平台之间进行移植。移动信息设备概要文件（Mobile Information Device Profile (MIDP)）和 PDA 概要文件（PDA Profile）是 CLDC 的两个比较重要的概要文件。基础概要文件（Foundation Profile）和个人概要文件（Personal Profile）是 CDC 的两个重要的概要文件。
个人概要文件构建在基础概要文件之上，以便在高端 PDA 上运行。个人概要文件配置了完全兼容 Java 2 的虚拟机实现。个人概要文件应用程序可以利用所有基于 Java 2 标准版（J2SE）域的安全性治理器，以及大量可用于 J2SE 应用程序的密码术和安全性库。总之，个人概要文件提供了成熟的安全性解决方案，它们类似于用于 J2SE 应用程序的那些解决方案。
实现安全 MIDP 应用程序要困难得多，因为 CLDC 配置的数学计算能力有限并且许多底层设备的处理能力不足。但是，MIDP 设备是使用最广泛的无线设备，因此在那些设备上启用安全应用程序很重要。在本文中，我们主要集中讨论 MIDP 应用程序的安全性挑战以及当前可用的或处于开发中的解决方案。
J2ME vs. WAP
我们的经验是，无论是在特性还是安全性方面，本机应用程序和 J2ME 应用程序都比那些以无线应用程序协议（Wireless Application Protocol (WAP)）构建的应用程序提供多得多的功能。但 WAP 是一种瘦客户机开发协议，J2ME 是一种专用于智能应用程序的开发平台。无论应用程序是用 J2ME 还是本机技术构建的，智能应用程序都比 WAP 应用程序多提供了下列安全性优点：
由于中间没有 WAP 网关，智能应用程序能够提供从后端到无线设备的可伸缩的端到端安全性。当后端发展成消息驱动的 Web 服务框架时，这一点就尤其重要。
智能应用程序能够在本地存储和处理数据，因此减少了网络流量。这不仅节省了宝贵的无线带宽和减少了延迟时间，而且降低了要害信息被截取或阻断（例如，通过拒绝服务攻击）的可能性。
智能应用程序有效地利用了设备处理能力。胖客户机可以根据内容建立全面分级的安全性策略，而不是无论是否需要都以相同的密钥强度加密所有内容。
因为智能应用程序比 WAP 页面能干得多，所以，运行智能应用程序确实增加了软件崩溃和／或病毒攻击的风险。接下来，我们将讨论，与那些设备本机应用程序相比，J2ME 应用程序有哪些处理和安全性优点。
J2ME vs. 本机平台
正如我们已经提到的，与本机平台相比，Java 平台的主要优点是它答应我们编写可移植的应用程序。Java 平台的可移植性来自其执行模型。具体地说，它是由于在运行时使用 JVM 来将 Java 字节码处理成机器码，因而在硬件之上提供了一个兼容性层。Java 平台的执行模型还引入了一些在设备本机应用程序中缺乏的重要安全性优点。这些优点如下：
JVM 验证类装入器中所有的类并确保应用程序不会执行任何危险操作。因为对于 MIDP VM 而言，运行时类验证在计算上代价很高，所以 MIDP 有非凡的两步字节码验证模式。我们将在后面一节中讨论这种方案。
JVM 有用来防止运行时应用程序错误的监控机制。垃圾收集器是一个好示例。JVM 能够在运行时自动清理应用程序内存堆。这有助于避免发生内存泄漏，内存泄漏是导致本机应用程序崩溃的主要原因。
JVM 可以提供用于应用程序的安全性治理器或沙箱。从 Web 上偶然下载的病毒和其它敌意代码可能造成严重的安全性风险。在 Java 平台上，可以对整个应用程序（例如 JAR 文件）进行数字签名。
JVM 安全性治理器根据签名者的信任级别，向签名的应用程序授予访问特定 API（域）的特权。与 WAP 和本机应用程序相比，智能的、注重可用性的设计和 Java 平台内置的执行模式赋予了 J2ME 应用程序显著的性能和安全性优势。但 J2ME 并不完美。在后面的一节中，我们将研究 J2ME 安全性框架的优缺点，尤其是当它应用于 MIDP 应用程序时。我们将首先研究应用程序安全性，然后继续讨论网络和数据安全性。
字节码验证
正如我们已经讨论的，JVM 提供了防止恶意代码进入企业系统的服务。字节码验证过程保证了应用程序不能访问内存空间或使用其域外的资源。字节码验证还防止应用程序重载 Java 语言核心库，这是一种可以用来绕过其它应用程序级安全性措施的方法。
但是，由于这种操作高昂的计算开销，MIDP VM 不在运行时执行完整的字节码验证。相反，应用程序开发人员必须在把应用程序部署到移动设备中之前，在开发平台或登台区域上预先验证类。预验证过程优化执行流，创建应用程序中包含指令目录的堆栈映射（stackmap），然后将堆栈映射添加到经预验证的类文件。在运行时，MIDP VM 迅速地对字节码进行线性扫描，将每个有效的指令与合适的堆栈映射项相匹配。
因为 MIDP 缺少完整的安全性模型，所以在 MIDP 中禁用了一些 J2SE 特性以使潜在的安全性风险降到最低。例如，为了防止对核心类的非法重载，MIDP VM 不答应用户定义的类装入器。MIDP 也不支持 Java 本机接口（Java Native Interface (JNI)）或反射（reflection）。即使适当地采取了这些安全性措施，也并非所有通过字节码验证的代码都被答应运行。
