本发明涉及智能卡技术领域，特别是要求支持Java功能的智能卡领域。
背景技术：
Java卡是Sun微系统为智能卡开发平台而制定的一个开放的标准。使用Java卡平台创建的智能卡上存有Java applet。在卡发行后也可以把applet加到卡上或修改卡上已有的applet。它们把数据存储在一个集成的微处理器芯片里。然后applet被下载到微处理器的内存里，由Java虚拟机来运行。
Java卡分为两层结构，底层为按照JavaCard规范实现的JavaCard平台，向上提供规范定义的接口(API)，通常支持JavaCard API和GP API。上层为按照应用需求开发的Applet，相当于Native卡片上的ADF。可以根据不同类型的应用，开发多个Applet。这些Applet相互独立，通过AID来选择。结构图如图1所示。
Native卡通过卡片操作系统(COS)来实现所有的功能。COS内部也按照功能的不同，分为多个层次，包括应用层具体交易APDU的实现，通讯协议层的实现，以及和芯片的具体交互等等。通常通过创建不同的ADF文件的方式，来区分不同的应用。结构图如图2所示。
Java卡相比于Native卡优缺点都比较明显：
优点：
1.提供一整套标准的JAVA卡编程的API，使得开发人员无需了解复杂的智能卡硬件和智能卡专用的技术，就可以进行智能卡应用的开发；
2.支持一卡多用途，可灵活支持多个应用，并且应用之间有防火墙进行安全隔离；
3.支持应用后开发和加载。开发一个全新的Applet应用。不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。
缺点：
1.执行效率低，性能较差
a)指令需要先经过Java平台进行预处理才能传给应用；
b)Java应用的执行依赖于Java平台的字节码解析；
c)Java语言为面向对象，无法直接操作底层硬件设备，任何对硬件的操作都需要使用平台的API。
2.发卡空间消耗大
由于Java应用需要创建各种对象，比如：密钥对象、算法对象、数组对象和变量等。而对象的管理是需要消耗用户空间的。实际需要5k用户数据空间的应用，用Java应用实现可能要消耗8-10k。
以上可以看出，Java卡虽然有很多优点，但是缺点也很明显。尤其对于智能卡行业来说，缺点变得尤其突出，性能差会导致产能的下降、用户体验效果降低甚至出现兼容性；发卡空间大导致卡片成本变高，多应用项目发卡空间存在局限性。所以设计一种Java与Native相结合的系统架构，将二者取长补短变得尤为有意义。
本发明设计了一种Java平台与Native应用相结合的系统架构，在固件层之上Java平台与Native应用可以并存，并且APDU可以分发给Java平台或者Native应用。但是将两者简单结合到一起仍存在一些不足。比如：无法实现APDU指令在Java平台和Native应用之间动态切换；两者的用户空间也无法实现统一规划(只能强制给Java平台和Native应用提前开辟一定大小的空间，无法交叉使用，势必造成一定空间浪费)。
为了解决上述两点不足本发明还在固件层之上设计了OS层，在该软件层中实现了主流程派发和内存管理两个单元。主流程派发单元可以实现APDU在Java平台和Native应用之间动态切换。内存管理单元可以实现两者用户空间统一分配和回收，以实现用户空间利用率最大化。
技术实现要素：
本发明的目的在于提供一种将Java平台和Native应用有机的整合到一起的系统架构，使其既支持标准的Java卡功能，同时又支持传统的Native应用。主流程派发机制和独立的内存管理单元可以将Java COS和Native应用的优点集于一身，既能实现Native应用的性能高、空间省的优点，又能实现Java COS的安全性高、支持后下载等优点。
本发明设计的Java平台+Native应用的系统架构将Java平台和Native应用有机的整合到一起。其架构如图3所示。该架构包括：硬件层、固件层、OS层(包括主流程派发单元和内存管理单元和其它服务单元)、Java平台和Native应用。Java平台和Native应用共用硬件层、固件层和OS层，从OS层之上开始区分Java分支和Native分支。硬件层和固件层与纯Java COS或纯Native COS一致，无需特殊处理。其中硬件层为芯片的物理介质。固件层基于硬件层实现各硬件模块的驱动比如：IO通讯驱动、算法模块驱动等，供上层软件调用。
OS层实现统一内存管理、主流程派发机制等功能。其中主流程派发机制和统一内存管理为本架构设计的关键。
主流程派发机制如图4所示。当智能卡收到终端发送的APDU指令时，在OS层通过特殊派发机制确定该指令应该走Java分支还是Native分支。基于该派发机制，不仅可以实现当前指令走Java分支还是Native分支，还可以实现Java应用和Native应用在不复位的情况下切换。
内存管理单元将硬件存储介质统一进行管理。不论Java COS还是Native应用只要操作硬件存储介质，都需要通过内存管理单元实现。传统Native应用是直接操作物理内存，实现读写等功能。而标准Java COS中本身包含内存管理单元，可以实现内存的动态分配、读、写、回收等功能。如果按照传统方式需要将物理内存进行强制划分，一部分给Native应用，由Native应用直接操作物理内存。另一部分给Java COS，由Java COS内存管理单元进行管理。这样中方案的缺点是内存强制划分，容易造成空间浪费，而且不能动态调整。本设计将Java COS中的内存管理单元提取为通用单元，将内存读、写、分配、回收等功能封装成标准API。这样Java COS和Native应用都可以调用标准API，从而实现整片物理内存的统一管理，大大提高内存使用率。
附图说明
图1标准的Java Card系统架构
图2标准的Native Card系统架构
图3Java平台+Native应用的系统架构
图4主流程派发机制的处理流程
图5一种Java平台+Native应用的智能卡系统架构实例
具体实施例
为了更清楚地说明本发明的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，附图仅仅是本发明的一个实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据该附图获得其他的附图。
本发明提供的技术方案是：将Java平台和Native应用同时置于固件层之上；在OS中设计一套主流程派发机制，实现APDU指令流的派发，从而确定当前APDU应该交给Java COS还是Native应用处理。同时在OS层中设计内存管理单元。将Java COS中的内存管理单元封装出标准API，实现内存分配、读、写、回收等功能。Java COS和Native应用都使用API操作内存，从而可以实现内存的统一管理。
为了使本发明的技术方案更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用于解释本发明，并不用于限定本发明。
图3为Java平台+Native应用的系统结构图。说明主流程派发单元和内存管理单元，在整个智能卡COS中所处的位置。
图5为Java平台+Native应用的智能卡系统结构处理流程图，说明从COS启动、初始化、接收APDU、派发指令以及指令处理的流程。
下面以支持Java平台的智能卡为例，讲述本发明的设计步骤。
在Java COS的软件结构中，将原Java平台的初始化内容(全局变量、Java状态等数据)进行拆分。一部分作为通用的初始化内容，另一部分作为Java平台特有的初始化内容。
在COS循环接受命令状态机中增加一套主流程派发单元(如图4)。上述通用初始化内容仍在主流程派发机制之前完成。主流程执行原理如下：第一条APDU分发选择：
Case1:"00A40400XX aid"，先去java应用注册表中查找，
如果找到AID，则切换当前环境为jcre。
如果没有找到，检查默认环境
如果默认环境不是nare寻找nare的top级应用，如果找到，切换环境为nare。如果也没找到，切换环境为jcre。
Case2:"00A4000002fid"
如果默选环境是nare，交给默认环境处理。
如果默选环境是jcre：
检查当前java默选应用是否是ISD：
如果是ISD，切换环境为nare，交给nare环境处理。
如果不是ISD，交给默认环境处理。
其他case：
交给默认环境处理。
非第一条APDU分发选择：
Case1:"00A40400XX aid"，先去java应用注册表中查找：
如果找到应用，则切换当前环境为jcre；
如果没有找到，寻找nare的top级应用：
如果找到交给nare；
如果没找到交给上一条apdu的环境处理。
Case2:"00A4000002fid"
交给上一条apdu的环境处理。
其他case：
交给上一条apdu的环境处理。
Java平台特有的初始化内容，在主流程派发后的Jcre分支内完成。Native应用特有的初始化内容，在主流程派发之后的nare分支内完成。
将Java平台的内存管理单元封装出标准API，作为公共服务单元。API参考如下：
●内存分配
memref app_nvm_alloc(u32size)；
功能：申请nvm空间，大小为size字节。
●内存读
void app_nvm_read_array(memref dest,memref src,u16size)
功能：读取NVM中的数据到RAM中
u8app_nvm_read_u8(memref src)；
功能：读取u8类型NVM中的数据值。
u16app_nvm_read_u16(memref src)；
功能：依照大端字节序读取u16类型NVM中的数据值。
u32app_nvm_read_u32(memref src)；
功能：依照大端字节序读取u32类型NVM中的数据值。
●内存写
void app_ram_write_u8(memref dest,u8value)
功能：写入u8类型数据值到RAM中。
void app_ram_write_u16(memref dest,u16value)；
功能：依照大端字节序写入u16类型数据值到RAM中。
void app_ram_write_u32(memref dest,u32value)；
功能：依照大端字节序写入u32类型数据值到RAM中。
void app_nvm_write_array(memref dest,memref src,u16size)；
功能：将RAM中的数据写入NVM中。
●内存回收
void app_nvm_free(memref address,u32size)；
功能：释放申请到的nvm空间
Native COS中所有关于内存的操作，都使用上述API，先分配，后使用
(读、写)，用完之后执行内存回收。
综上所述，当智能卡COS需要同时支持Java平台和Native应用时，可按上述步骤进行设计，既能实现Native应用的性能高、空间省的优点，又能实现Java COS的安全性高、支持后下载等优点。
以上所述仅为本发明的较佳实现方案而已，并不用以限制本发明，凡在本发明的精神和原则之内所做的任何修改、等同替换及改进等，均应包含在本发明的保护范围内。
