请记住,Java Card 应用程序并不是独立的,而是端到端应用程序的一部分:
图 1. Java Card 应用程序的典型组件
Java Card 应用程序通常由以下部分组成:
卡片读取器、卡片终端 或者 卡片接入设备 ,提供了主机应用程序和卡片内部 applet 之间的物理接口。
卡片内部的物理接口是 Java Card applet 和 Java Card 框架。请注意,在访问 applet 之前,主机应用程序必须提供证书并进行自我身份验证。
编写主机应用程序 —— 访问 Applet
位于客户端的主机应用程序处理用户、Java Card applet 和提供器的后端应用程序之间的通信。主机程序访问由 applet 所提供的服务。它存储在终端或卡片接入设备上,例如工作站、销售终端点( POS )、手机或者机顶盒。回想一下,主机和 applet 使用 ISO-7816 APDU 命令通过卡片读取器或终端进行交互。
目前,大多数经过部署的手机集成了智能卡读取器,以便访问与该读取器捆绑的 SIM 卡片。使用即将引入的 JSR 177, 用于 J2ME 的安全性和信任服务应用编程接口(SATSA)、J2ME 设备的广泛采用,我们能够预计各种主机应用程序将使用移动设备上的 Java 技术编写。SATSA 的意图就是启用 Java Card 主机应用程序来运行基于 J2ME 的设备。目前,JSR 177 处于 JCP 团体审查阶段。
OpenCard Framework 简介
为了实现厂商无关性,OCF 定义了两个软件层:
CardTerminal 层提供了卡片读取器抽象,例如 CardTerminal ( 表示物理卡片读取器 ) APDU、CommandADPU 和 ResponseAPDU。
当编写主机端基于 OCF 应用程序时,您基本上要将该应用程序分为两个部分:
主要的应用程序对象,它与终端或读取器进行交互(初始化 OCF、等待卡片插入、中断 OCF ),并公开高级卡片访问方法,例如 getBalance()。
Applet 代理,它实现实际的低级通道管理和 APDU I/O。当把来自应用程序的 APDU 细节隐藏起来的时候,该代理设计模式允许公开面向对象的接口。
图 2. OCF 应用程序的结构
总而言之,OCF 应用程序有一个或多个 main 对象,它们在主机上或者在执行的线程上创建。这些 main 应用程序对象公开特定于应用程序的高级调用,最终将它们委托给 applet 代理。这些对象利用 OCF 应用程序入口点的 SmartCard 对象,启用应用程序初始化并中断 OCF,并等待卡片被插入。main 对象可以实现即将看到的 CTListener,这个侦听器提供卡片插入和拔出等类似事件的异步通知。