专利名称：在高端平台上支持小程序的制作方法
背景技术：
智能卡是具有提供有各种功能的嵌入式电路的卡。当前，智能卡可用于信用卡或者借记卡、移动电话的SIM卡、付费电视的确认卡、访问控制卡、电子钱包、公交付费卡、以及其它各种目的。智能卡快速增长的一个领域为数字识别领域。作为用于校验和维护数字识别信息的工具，智能卡越来越普通。在所述数字识别领域使用智能卡的一个原因就是该卡被设计的安全和防窜改。
总而言之，当前的智能卡大约为信用卡大小(虽然该卡可依其功能更大或更小)。智能卡上的嵌入式电路的类型和数量也不同。当今使用的典型智能卡将包括约512字节的易失性存储量(如，RAM)、略微大一点的非易失性存储量(如，大约16k字节的EPROM)、以及小型微处理器。
因此，为现有智能卡所写的软件必须紧凑以在现有智能卡有限的计算资源环境之中执行。用于开发和执行现有智能卡的应用程序的软件架构实例为Sun Microsystem的Java卡2.2技术(“Java卡”)。为了使用现有智能卡上的有限资源，Java卡提供了包括标准Java卡虚拟机(如，Java卡虚拟机(“JCVM”))简略版本的操作架构。JCVM执行标准Java卡虚拟机指令的一个子集。
因为JCVM不包括所有的标准Java卡虚拟机指令，所以用于现有智能卡的应用程序被压缩为专用CAP文件格式。被压缩的小程序(applet)或“CAP”文件为传统的Java类(class)文件，其通过把标准Java虚拟机指令翻译成更紧凑的格式而被压缩。这通过生成CAP文件的类文件中剥离不必要的信息以及减少调用可用的命令和函数的数量来进行。
在基于Java的环境中，剥离不必要的信息可包括用权标(如，表示长字符串的少量字符或少量数字)来替代长字符串。例如，初始类文件可对“JavaCard.Framework.Shareable”库进行外部调用。转换工具翻译该调用以便外部“JavaCard.Framework.Shareable”调用的所有实例被引用该特定库的权标(通常为一个单字节大小)所代替。因此，包含28个字符(或28字节)的初始命令就显著减小。因此，CAP文件的大小就远小于常规的类文件。注意，在把类文件转换为CAP格式之后，为了在多个应用程序中将外部调用(和名称)保持一致，可将调用到所述权标的映射存储在单独的文件(如，JCA或EXP文件)。然后，当翻译其它应用程序时，那些应用程序可使用特定调用的相同权标。以这种方式，仅需要把带有权标化名称的外部资源的一个副本存储在智能卡环境中。
此外，由于智能卡资源有限，所以智能卡的虚拟机一般支持规范虚拟机会支持的指令的子集。因此，在翻译进程期间，类格式的指令(如，Java字节代码)就被翻译成类似的CAP指令。通常，多个类文件指令必须减小到单个指令以执行类似功能。一般来说，压缩命令减少了功能。在许多情况中，类文件指令并不是简单地被智能卡支持。在那些情况下，转换工具因其不能完成翻译而终止，或者其可简单地忽略命令、进入例外、提示用户改变类文件指令、键入相应的CAP文件指令、或启动调试接口。因为由现有智能卡支持的有限数量的命令，所以大大减小了应用程序的大小。
为了进一步减少智能卡上虚拟机的大小，转换工具可采取附加步骤以在把文件转换成CAP格式之前对其进行预处理。基本上，这意味着在将文件转换成CAP格式之前就执行了现有Java虚拟机执行的一些任务。例如，在标准Java环境中，一般在启动程序时或使用在变量时初始化该静止变量。在类到CAP的转换过程中，静态变量被预初始化，并且类文件中的符号引用在转换该文件之前被分解。此外，为了进一步减少执行CAP文件所需要的资源，Java类被检查以确认其被正确形成，并且在把类文件转换成CAP格式之前仅使用由智能卡平台正确支持的Java编程语言的子集。该通过减少智能卡需要执行的查错和纠错数量，该预处理过程使现有智能卡上的Java虚拟机尽可能小。
在Java类文件被转换到CAP格式之后，在一些情况下，还可创建诸如Java类汇编(“JCA”)文件或导出(“EXP”)文件的附加文件。如上所述，这些附加文件包括关于CAP文件中类的公共接口信息，并且提供关于每个CAP文件及其任一相关文件中的域和方法的信息。
一旦类文件被转换成CAP格式，则可使用卡上安装程序(installer)和硬件将CPA格式的文件(“CAP文件”)下载到现有智能卡。
然而，正在开发下一代智能卡，其将提供比现有智能卡大得多的计算资源。(注意虽然下一代智能卡具有比现有智能卡(如，“传统(legacy)智能卡”)大得多的计算资源，但是计算资源与其它计算设备(例如，笔记本电脑、蜂窝手机、个人计算机等)相比依然相对有限)。因为更大的计算资源，下一代智能卡可提供比传统智能卡更复杂的计算环境。结果，软件开发人员开始开发用于下一代智能卡的更复杂的软件。
例如，SunMicrosystem的下一代Java卡技术通过创建可执行Java类文件的虚拟机等来利用所述下一代智能卡的更多资源。通过给Java类文件提供支持，下一代Java卡虚拟机就扩展智能卡之所能。例如，新虚拟机可执行大得多的Java类库(如，串，可在多线程环境中执行应用程序，并且可利用许多Java访问控制机构。基本上，下一代Java卡环境支持许多或所有Java的传统特征。
此外，通过提供对Java类文件的支持，因为可采用传统开发工具开发应用程序，且无须对该应用程序设计或代码进行大的改变来进出新的平台，所以减少了用于新智能卡平台的应用程序开发成本。由此，下一代Java卡平台极大地减少了对CAP文件的需要。
事实上，合乎情理地，当在下一代智能卡上试图执行CAP格式的应用程序时就可能发生问题。例如，CAP文件被设计成按单线程应用程序来运行。结果，传统智能卡上的应用程序被设计成共享公共资源(如，应用程序数据单元或特定系统文件)。在下一代智能卡环境中，在多个应用程序中共享单个公共资源使JCVM降低速度，这是因为JCVM必须执行附加检查来标记引用的不安全存储。例如，应用程序可包括正由不同应用程序使用的APDU对象的引用。JCVM执行检查来标记这些坏引用。另外，应用程序可使用其存储的引用来访问APDU对象中的信息，即使假定另一应用程序对它进行了控制。
仅在运行时间性能问题之外，支持下一代智能卡上的CAP文件或其它传统应用程序的另一问题是实施两个虚拟机的等同物的开发和资源成本，其中，一个虚拟机支持CAP文件而另一个支持类文件。尽管下一代智能卡具有比传统智能卡更多的计算资源，但它们通常不具有足够的资源来实施两个不同的虚拟机(或其等同物)。
一种提议的解决方案是简单地更新传统应用程序，使之与下一代智能卡兼容。然而，涉及更新并升级CAP文件和其它传统应用程序的成本和时间都是相当可观的。软件用户可能没有时间来等待新的软件发布，并且即便有时间，在发布软件时他们可能也没能力支付得起更新的应用程序。类似地，软件开发人员也不可能把更新较旧的应用程序置于高优先权。因此，可能历时数月或数年才(甚或不可能)更新应用程序。
总的来说，用于使传统和非传统应用程序能够在下一代智能卡上执行的现有解决方案并不令人满意。
本节中描述的方法可以被推行，但不一定是先前已经构思或推行的方法。因此，除非本文另外指出，否则本节中描述的方法相对于本申请的权利要求来说不是现有技术，而且也并不被本节中所含内容认为是现有技术。
发明内容
本文描述了用于在下一代智能卡架构中执行传统智能卡应用程序的方法。传统智能卡应用程序通常指的是单线程应用程序，其期望是在任一给定时刻的唯一有效的应用程序。下一代智能卡架构通常是指多个应用程序可在其中同时执行的多线程智能卡环境。在传统智能卡环境中，为了确保传统智能卡应用程序的安全执行，仅通过可共享接口对象许可由其它应用程序对传统智能卡应用程序的访问。
因此，在下一代智能卡架构的一个实施例中，创建专有单线程环境，使得传统智能卡应用程序能够安全执行。专有环境的一个方面包括代理对象。代理对象包括传统智能卡应用程序的可共享接口对象，以控制其它应用程序如何访问传统智能卡应用程序中的方法、对象、引用、功能、以及例程。在一个实施例中，代理对象仅允许一个应用程序在某一时刻访问可共享接口。
此外，在一个实施例中，下一代智能卡架构中的专有环境创建在传统智能卡环境中被共享的对象的新副本。在一个实施例中，无论何时另一应用程序请求访问共享的对象，都生成对象的新副本。在一个实施例中，用于创建副本的数据量仅限于对象类型本身。
本文还描述了一种方法，用于把传统智能卡应用程序从诸如CAP文件格式的压缩格式转换成未压缩的格式。
附图是用于实例示出而不是用于限制本文描述的系统和方法。贯穿附图类似参考标号用于表示类似元素和特征。
图1是示出根据本发明实施例的下一代智能卡架构的框图；图2是示出根据本发明另一个实施例的用于将传统应用程序转换成下一代智能卡应用程序的机构的框图；。
图3是示出根据本发明实施例的用于把传统应用程序转换成下一代智能卡应用程序文件的程序的流程图；图4是示出根据本发明另一个实施例的用于生成在下一代智能卡环境中执行传统应用程序的专有环境的程序的流程图；以及图5是示出其上可实施根据本发明实施例的计算机系统的框图。
具体实施例方式
本文描述了执行为传统智能卡以及下一代智能卡平台上的其它低资源环境开发的应用程序的技术。为了解释的目的，阐述了许多具体细节以提供各种系统和方法的透彻理解。然而，非常清楚，没有这些具体细节也可以实施本文描述的系统和方法。在其它实例中，公知的结构和设备用框图的形式示出，以避免对本发明有不必要地混淆。
综述本文描述了用于在下一代智能卡上执行传统智能卡应用程序(“传统应用程序”)的技术。在一个实施例中，该技术包括了用于将传统应用程序转换成在下一代智能卡平台上可执行的格式的机构。例如，在基于Java的下一代智能卡环境中，转换器机构把CAP文件翻译成Java类文件。
本文所述的技术还提供在下一代智能卡上模拟(或重新创建)传统应用程序被设计成在其中中执行的专有环境。例如，因为资源有限，所以传统智能卡常常要求传统应用程序与其它交替运行的应用程序共享公共对象。结果，那些传统应用程序被期待设计成独享给定的资源直到完成命令处理周期。本文所述的技术提供了创建共享对象的新实例使得传统应用程序排他性访问以前所共享对象的机构。
此外，该技术提供了管理传统应用程序和下一代应用程序之间交互作用(例如，通过把对传统应用程序的调用串行化)的机构。例如，在一个实施例中，创建代理机构以管理传统应用程序和非传统应用程序之间的通信。
提供这些和其它技术使得传统应用程序可与更复杂的应用程序共存，而无须严重影响传统应用程序和非传统应用程序两者的性能。此外，这些技术和机构帮助在下一代智能卡上创建运行时间环境，其又兼容于由传统应用程序期望的那种环境。注意到，这些技术和机构可通过智能卡、计算机或其它设备上的应用程序来实施，或者通过基于服务器的和基于客户的组合的应用程序实施，或者通过其它方法来实施。
JAVA卡环境本发明所述的程序和工具经常根据Java卡2.x技术(“Java卡”)以及下一代Java卡开发和运行时间环境来描述。这些环境仅是用于在其中使用本发明的技术的示例性环境。在可选实施中，该技术可在其它环境中使用。
I.下一代智能卡的通用架构图1示出了用于下一代智能卡的架构100的实施。在一个实施例中，架构100为基于Java的软件架构，其被设计为提供下一代智能卡上的开发和运行时间环境。架构100允许用户平衡(leverage)现有的开发环境和工具以开发在下一代智能卡上执行的应用程序。架构100还允许软件开发人员平衡在下一代智能卡上可用的增加计算资源，以给用户提供更多的功能。此外，在一个实施例中，架构100提供必要的机构来创建向后兼容的环境，其中，传统应用程序可无须显著影响性能和执行安全性而执行。
一般地，架构100提供了运行时间环境，其中，可执行诸如基于小服务程序(servlet)的应用程序101和扩展小程序107的非传统应用程序(non-legacy application)以及诸如传统小程序120的传统应用程序(legacy application)。注意到，非传统和传统应用程序在本文中可统称为“应用程序”。在架构100中执行的应用程序可执行广范围的功能。例如，它们可做为用单个用户名字和口令来提供对多个不同计算资源进行访问的单点登入(single-sign-on)服务器，通过验证用户对数字媒体的访问权限来提供数字权限管理服务，通过将用户的email经过智能卡进行传递来过滤垃圾邮件(spam)以及其它功能。
图1示出了在该架构中的示例性组件，其提供了功能并支持在虚拟机102上执行所有类型的应用程序。例如，架构100可包括一组下一代智能卡API(“新API”)103、一组公共访问的API(“公共API”)104、一组传统API(“传统API”)108、小服务程序API106、小服务程序容器105、小程序容器109、以及小程序API110。在其它实施例中，架构100可包括不同组的组件。
A.基于小服务程序的应用程序在图1中，基于小服务程序的应用程序101为可在架构100中执行的实例应用程序。基于小服务程序的应用程序101包括特别为下一代智能卡架构设计和编写的应用程序。正是如此，基于小服务程序的应用程序101一般不需要从一种文件格式转换成奖杯虚拟机102执行的另一种文件格式。在下一代Java卡环境中，基于小服务程序的应用程序101为Java类文件。
B.扩展的小程序除基于小服务程序的应用程序101之外，架构100还可执行扩展的小程序107。扩展小程序指的是已被软件开发人员编写以利用下一代智能卡架构100的新库和底层功能的传统应用程序。扩展小程序107不是压缩类文件或压缩类文件的翻译版本。在下一代Java卡环境中，扩展小程序107可以是被编写以包括Java类特征的Java类文件。
C.传统小程序在图1中，传统小程序120通常指的是被设计成在传统智能卡上运行以及从更完整特征的版本转换为压缩格式来在传统智能卡的有限资源环境上运行然后翻译回原始文件的功能等同物的应用程序。在下一代Java卡环境中，传统小程序120包括被翻译成CAP文件格式然后又被翻译回Java类格式的文件。
D.虚拟机在架构100中，通过虚拟机102解译非传统应用程序和传统应用程序。虚拟机102通常指的是用于解译下一代智能卡上的应用程序的任何软件解译程序。依赖于该实施，虚拟机102可基于Java，使得虚拟机102运行Java类文件。在其它实施例中，虚拟机102可执行其它类型的文件。
虚拟机102被设计成在下一代智能卡的资源环境中运行。此外，在一个实施例中，虚拟机102还创建传统应用程序可在其中执行的运行时间环境。为了帮助创建传统应用程序可在其中执行的环境，虚拟机102包括代码，其使用对象的单个共享副本从运行时间环境转移到创建用于每个应用程序的单独对象的环境，从而避免死锁和其它安全问题。此外，在一个实施例中，虚拟机102包括代码以生成控制对传统应用程序访问的代理对象。通过这样做，传统应用程序可作为单线程应用程序在多线程环境中运行。在各种实施中，这些特征可由不同于虚拟机102的其它组件执行。
注意到，除执行用于传统应用程序的单线程环境以外，虚拟机102还可进一步增强以改善整体的应用程序性能。一般地，虚拟机102被设计成改善在下一代智能卡上运行的所有应用程序的性能。
E.其它构件块图1示出了架构100中的一组其它构件块的实例，其可用于连接虚拟机102来执行应用程序。那些其它构件块包括新API103、公共API104、传统API108、小服务程序API106、小服务程序容器105、小程序容器109、以及小程序API110。这些API和容器在本文都统称为“其它构件块”。架构100中的其它构件块的数量基于特定的下一代智能卡环境、其实施、其资源限制等而改变。
每个其它构件块都可为软件模块。例如，其它构件块可为应用程序编程接口、动态链接库文件、单独应用程序、虚拟机102的集成组件、或定义虚拟机102和应用程序之间接口的一些其它软件工具。此外，每个其它构件块可指多于一个模块或软件文件。例如，小程序容器109可指包含用于由扩展小程序107所调用的对象和方法的对象定义的多个文件。
例如，通过卸载对一些应用程序来说为公共的代码，由其它构件块提供的功能通常帮助减少单独应用程序所需的整体资源数量。举例来说，新API103提供了具体针对下一代智能卡环境的一组构件块例程、协议以及工具，使得开发人员在设计和编写虚拟机102上运行的软件时可在该环境上进行调用。例如，基于小服务程序的应用程序101可被设计成使用提供用于在虚拟机102上运行的应用程序的公共接口的新API。由于应用程序将会具有类似的接口，所以使得用户易于使用应用程序。在下一代Java卡环境中，新API103包括提供具体针对下一代Java卡虚拟机的例程、接口、协议以及功能(如，对串的支持)的API。
在一个实施例中，类似于新API，公共API104将对应用程序和虚拟机102的访问提供给所共同请求的功能、例程、协议和接口。举例来说，如果多个应用程序共同调用相同的功能(如，数据排序功能)，该功能就可被编写为单独的辅助文件并被组装成一个公共API104。
在一个实施例中，小服务程序容器105和小服务程序API106包括诸如使基于小服务程序的应用程序101能够正确执行的类、功能、接口、以及例程的附加资源。例如，小服务程序容器105创建了非传统应用程序可在其中产生多个线程的环境。小程序容器109和小程序API110可帮助提供传统和非传统应用程序可在其中执行的环境。例如，它们可产生多个线程使得非传统应用程序可以最高性能来执行，并且它们还可提供传统应用程序保持线程安全并可靠执行的环境。
传统API108还包含其它类和资源，诸如Java卡2.x API，其提供了接口、功能和例程使得虚拟机102可执行扩展和传统小程序。当扩展和传统应用程序在执行时，小程序容器109以及小程序API110可提供附加支持和库文件，使得可正确执行那些应用程序。
在一个实施例中，其它构件块(或其子集)，特别是小程序容器109以及小程序API110可帮助提供传统应用程序在其中执行的专有运行时间环境。
在一个实施例中，架构100包括类预加载机构，如在Violleau等人申请的“Class Pre-Loading Mechanism”中所描述的。该类预加载机构将诸如传统API106的传统应用程序库文件和代码从架构中的多线程应用程序中隔离出来。通过从多线程应用程序隔离库文件，许多传统应用程序得代码就变得不可访问非传统应用程序。结果，传统应用程序可更可靠地运行，这是由于仅在单线程模式中运行的传统应用程序才可访问代码。
II.下一代架构中的传统应用程序如上所述，基于小服务程序的应用程序101和扩展小程序107是被设计并更新为在下一代智能卡架构中运行的应用程序。另一方面，传统小程序120为被开发以在传统智能卡环境中运行并且未被更新以在下一代智能卡环境中运行的传统应用程序。结果，传统小程序120包括与下一代智能卡架构不兼容的压缩文件格式的应用程序。
在一个实施例中，为了在下一代智能卡架构中执行传统应用程序，传统应用程序从其压缩格式转换成与下一代智能卡兼容的格式。然后，下一代智能卡架构，特别是运行时间环境被修改以重新创建传统应用程序被设计在其中执行的专有环境。例如，下一代智能卡架构创建先前被共享过的新对象。此外，下一代智能卡架构使用代理对象来控制对传统应用程序的访问。以这种方式，传统应用程序可作为单线程应用程序在下一代多线程智能卡架构中运行。
这些步骤可相互独立执行或组合起来执行。
A.传统应用程序规范器工具为了与下一代智能卡运行时间架构兼容，传统应用程序通常需要从为传统智能卡的有限资源环境创建的格式转换成与下一代智能卡兼容的格式。例如，在下一代Java卡环境中，最底层的虚拟机并不直接支持CAP文件。这一般是设计方面的决定，基于提供对非传统和传统应用程序的直接支持将会消耗太多的计算资源这一事实。因此，在一个实施例中，在执行传统应用程序之前，传统应用程序文件被转换成与下一代智能卡的虚拟机兼容的格式。
在实施例中，规范器(normalizer)工具将压缩类文件翻译成未压缩类文件格式。规范器工具主要重新创建在传统应用程序文件中丢失的信息。例如，在最基本的设置中，用户把CAP文件导入到规范器工具中，以将该CAP文件转换成一种或多种类文件。然后，规范器工具创建新文件并把每个CAP文件指令映射到相应的类文件指令，并将翻译的指令置于新文件中。一旦翻译了所有这些指令，新文件就作为类文件被存储起来。
作为转换传统应用程序的一部分，注意到，该进程可试图重新创建初始以未压缩格式编写的文件或应用程序。在这种情况下，难以生成生成传统应用程序的原始文件的完全副本。因此，在一个实施例中，规范器工具将传统应用程序转换成与原始文件功能相同的文件。一般地，规范器工具生成基本复制了原始应用程序功能的代码。例如，在下一代Java卡环境中，规范器工具将CAP文件转换回可由下一代虚拟机执行的并在功能上等同于原始Java类文件的文件。虽然在一些实施中，规范器工具也能够尽其全部地重新创建原始未压缩的文件。
注意到，存在应用程序直接编写为CAP文件的一些情况。在这种情况下，规范器工具未试图重新创建原始文件，而工具却试着来创建基本执行与CAP执行的相同功能的下一代智能卡应用程序文件。
图2示出了用于将传统应用程序转换成下一代智能卡应用程序的系统200。在一个实施例中，系统200将CAP文件转换成类文件。在其它实施例中，传统和非传统应用程序文件是不同的类型。
在一个实施例中，用于转换传统应用程序的系统200为下一代智能卡架构的一部分。在该实施例中，传统应用程序在传统应用程序在下一代智能卡上被启动的时刻被转换。可选地，系统200从下一代智能卡中分离。例如，可从传统智能卡中下载传统应用程序，以及经过脱卡规范器工以将传统应用程序转换成可由下一代智能卡解译的格式。
在一个实施例中，系统200包括规范器工具201，其接收带有任一相关的辅助文件203的传统应用程序202作为输入并且输出“转换的代码”204。转换的代码204通常指任何未压缩的应用程序格式。例如，它可能指的是类文件或一些其它未被编译的指令集、字节代码、非传统应用程序、或执行与传统应用程序202等效功能的应用程序的其它符号表达式。在一个实施例中，转换的代码204为Java类字节代码。
为了示出规范器工具201如何进行工作，考虑将CAP文件转换成类文件的实例。一般地，CAP文件(与任何相关的辅助文件一起)包括足够的信息来创建类文件，类文件可具有生成CAP文件的原始类文件的等效功能。用于把CAP文件转换成类文件的进程通常包括将该CAP文件及其组件文件中的指令翻译成类文件中的对应指令集。
在基于Java的环境中，规范器工具201将CAP文件和任何相关文件(例如，包含关于与CAP应用程序相关的外部类的信息的EXP文件)当作输入。包含在CAP文件及其相关文件中的指令被转换成Java类指令并被存储为Java类文件，例如，转换的代码。
转换CAP文件中的指令的进程由规范器工具201执行。该进程包括确定CAP文件中的指令以及在索引或表中执行查找以确定对应的类指令集。在以下表3中，示出了具有其对应Java类字节代码指令的CAP文件指令的字节代码转换表实例。注意到，在表3中，表的前三列涉及CAP文件指令数值、对应的HEX(或字节)值、以及指令的对应文本表达式。后三列涉及Java类字节代码指令数值、对应的HEX(或字节代码值)、以及符号表达式。在一些情况下，指令还包括其所做的什么或为何其以特定方式被映射的简单描述。
表3为了将CAP转换成类文件，规范器工具201在整个CAP文件上迭代，把每个CAP指令映射为其相应的类指令。例如，使用表3作为向导，假设规范器工具201遇到CAP文件指令(0x70)。规范器工具执行表查询以找到相应的Java类指令(0xA7)，并且用转换的代码204中的Java类指令来代替CAP指令。
在转换进程期间，规范器工具201还可参考附加的辅助文件。例如，如果CAP文件包括使其映射存储在EXP文件中的外部功能或者例程的指令，则规范器工具参考用于适当调用映射的EXP文件。最终，规范器工具201生成执行CAP文件等效功能的转换的代码204。在这个实例中，最终转换的代码为Java类字节代码。
如上所述，规范器工具201试图创建执行原始应用程序登效功能的文件。一般地，通过规范器工具201创建的转换的代码204与原始类文件之间的差应该为极少。一些更常见的差距可能包括以下这些1)在小程序包中的非公共(non-public)和非可共享的(non-shareable)类的名称可不同。当把类转换成CAP格式时这就可发生，类文件的名称一般被转换为权标或数值表达式。然后，当CAP文件被转换回来时，类名称就被转换为不同的。举例来说，如果类文件初始命名为Person，然后被转换到CAP格式。在CAP格式中，Person类现在可以是数值权标(如，12)。在该翻译期间，Person类的实际名称因为对于计算机来说名称并不意味着什么故而被丢失。因此，当CAP文件被翻译回来的时候，规范器工具201可能不得不自动生成用于Person类的新名称，如，“Class 1”。注意到，虽然该名称已改变，但最主要的功能将会保持不变。
2)出于类似原因，非公共的方法和字段的名称可不同于它们初始被命名的名称。
3)在不是从另一包中类继承的小程序包中的公共字段和方法的名称也可发生变化。
4)最后，用于类文件的源文件属性(如，定义该源的属性和用于类的目标目录)可不同于初始属性。
虽然这些为四个最常见的差别，但应注意到，在一些实例中，与类文件相关的某些属性也可能不容易再生。例如，类中的一些方法具有可能不能被规范器工具重新创建的可选例外属性。类似地，线号和局部变量表属性也可在CAP文件被相反转换后而不同。最后，由于在将类文件转换成CAP文件之前发生的字节代码的优化，所以转换的代码204可不同于原始类文件中的字节代码。
在一个实施例中，一旦传统应用程序被转换成转换的代码204，签名者(signer)工具206就用私人关键字208给转换的代码204签名，使得其它应用程序和用户可校验所提供类207的完整性。
B.用于将CAP转换成类文件的过程为了进一步分析把传统应用程序转换成非传统应用程序的进程，考虑图3所示的过程。该图示出了用于把传统应用程序转换成非传统应用程序的实例过程300。该过程涉及三个主要步骤1)读取和校验传统应用程序和相关文件310，2)生成对应于传统应用程序320的传统文件，以及3)将非传统文件写入盘中以便它们能被测试330。
1.读取和校验CAP文件在步骤310中，规范器工具(如图2中所示的规范器工具)读取诸如CAP文件的传统应用程序以确认其完整性。在一个实施例中，脱卡的工具可被用来执行这个步骤。确认其完整性的步骤包括确认该文件是完整的且不包含错误或其它不一致(例如，坏的指令或对无效例程的调用)。如果传统应用程序有效并完整，那么，应用程序就被翻译成其相应的非传统应用程序格式。
2.生成非传统文件在步骤320中，规范器工具(如图2所示的规范器工具)生成相应的非传统应用程序文件。例如，假设规范器工具用于把CAP文件转换成相应的类文件结构。在该实例中，那些文件结构包括用于单独类的单独文件，以及在每个类中，用于常数的区、用于定义类中各种接口和例程的表、勾画类中变量和字段名称的字段表、以及在CAP文件中确定单独方法的方法表。规范器工具分析CAP文件以识别每个与CAP文件相关的类以及初始与类文件相关的类文件结构。一旦每个类及其对应的结构被识别，则规范器工具(使用预定的偏差)将CAP文件命令转换成对应的类文件指令并且将适当的信息填充进转换的类文件。为了帮助转换进程，规范器工具可使用转换表，如图3所示的转换表300，以将CAP文件指令映射到相应的类文件指令。
规范器工具被设计成知道其应该遇到CAP文件中的指令的顺序并且知道那些命令应该以什么顺序置于相应的类文件中。在实施例中，通过包括在CAP文件本身中的描述符组件(或可选地，它们相关构造文件之一)定义原始类文件结构及其顺序。描述符组件可定义整个类及其相应的类文件结构。例如，描述符组件可正确勾画类应该列出诸如其主要和次要版本号的一些基本类识别信息的事实。描述符组件还可勾画可生成用于类的哪些常数池条目，以及诸如访问标记信息、接口定义及其它字段数据的附加特征。最后，描述符组件可定义在类中方法和属性定义在哪里适合。
在一些实施例中，具体的描述符组件也许并不可用。在这种情况下，规范器工具可分析在开始时的CAP文件的完整性，以确定其定义的结构，然后使用该信息来开发相应的类文件。
注意到，一般来说，描述符组件由于其包含关于CAP文件中所有类的信息而作为用于使该信息有必要建立一个或多个类文件的起始点。然而，在一个实施例中，即使具有描述符组件，规范器工具可执行多次跨越CAP文件的传递，以提取定义类文件结构的信息，然后将信息输入那些类文件结构中。
例如，建立类文件的进程可要求规范器工具执行多次跨越相应CAP文件的分析性传递。在实施例中，第一次跨越CAP文件的传递包括规范器工具分析描述符组件以确定相应类文件的基本组件并把关于被实施的接口、字段、方法和属性的基本信息添加到类文件的常数池部分。在后续跨越CAP文件的传递中，规范器工具可把附加信息添加到关于正被引用的其它类的常数池，包括与那些其他类相关的接口、字段、和方法。在一个实施例中，在分析CAP文件及其相关文件之后，创建常数池计数以描述在该常数池中条目的数量。该信息识别需要在类中建立的附加结构的数目。此外，常数池计数可为指示符，以确定用于具体值的偏差和将被插入类文件的指令。
除创建常数池之外，在跨越CAP和相关文件的传递期间，规范器工具可创建用于类文件的附加占位符(placeho1der)类型结构，例如，接口阵列和方法阵列。这些结构的类型和数目将基于正被分析的实际文件以及CAP文件、类文件和规范器工具的实施而改变。
在一个实施中，为类中每个一般结构创建占位符结构(如，阵列)(例如，创建用于常数、标记、接口、方法、字段、属性等地阵列。这些占位符结构包括用于在类中直接实施的接口、标记、字段、方法和属性的索引。创建这些占位符结构的原因是，在CAP文件中，难以准确确定哪些组件是由正被处理的类直接实施(例如，CAP文件可包含关于当前类和其所有超级类的信息)。因此，这些占位符指的是跟踪哪些接口属于哪个类。
一旦识别了所有单独结构(如，每类有多少方法、标记、接口等)，规范器工具就执行跨越CAP和相关文件的附加传递以填写用于每个识别结构的信息。例如，规范器工具执行跨越CAP文件的传递以识别并提取用于每个所识别方法的信息。然后，规范器工具将那些指令转换成其相应的Java类指令，并将指令置于相关方法文件结构中。
注意到，在转换进程期间，规范器工具可能找不到用于特定方法的名称。在这种情况下，由规范器工具自动生成方法名称(尤其用于私人或组件私人方法)。如果可找到方法的名称，规范器工具就执行检查以校验该方法名称在其它地方(如，在超级类中)并未正在使用，并且命名该方法。
此进程的结果为规范器工具把所有代码都转换成“转换的代码”。CAP中的每个指令及其相关文件都被估计并映射到相应的类文件指令。
一旦转换进程完成，如上所示，在原始类文件和由规范器工具生成的类文件之间可存在差异(例如，一些名称、访问标记和属性可些许不同)，这些文件本身应该表现出相同功能。
在其它实施例中，不同组的组件和结构可用于从传统应用程序解析和提取信息。
3.写入和测试类文件一旦创建了类文件，在步骤330，检查类文件以确保其有效性。在一个实施例中，规范器工具生成JAR文件，其包含所有新近创建的非传统应用程序文件以及传统应用程序文件。存储这两者的原因是两组文件可进行关于后续安装的比较，以确保数据的完整和正确。在实施例中，其它文件和类(诸如代理可共享接口对象类)可被添加到JAR文件以帮助转换的应用程序在下一代智能卡架构中执行。此外，在实施例中，例如，通过使用Java类加载器将其加载来测试新近创建的文件。
一旦为传统应用程序创建了用于下一代智能卡架构的可执行文件，工具和技术就重新创建应用程序在其中执行的专有环境。
C.传统应用程序环境为了确保下一代智能卡架构中的传统应用程序的安全执行，专有环境被创建用于传统应用程序。专有环境确保传统应用程序能够执行为单线程应用程序。
为了理解如何创建用于传统应用程序的专有环境，这里提供了有关传统智能卡环境的附加信息。在传统智能卡环境中，当启动传统应用程序时，运行时间环境(包括虚拟机)创建在其中存储其的对象和操纵数据。由运行时间环境创建的对象被创建它的应用程序所拥有。防火墙机构保护每个传统应用程序免于间断的外部访问。因此，传统应用程序不能访问另一应用程序的对象或对象方法，除非它们被显式共享。
1.防火墙防火墙机构是为传统智能卡环境创建的虚拟机运行时间所执行的保护。例如，在Java卡环境中，Java卡虚拟机通过其防火墙机构确保应用程序隔离。结果，传统应用程序可在其自己的上下文内访问资源，但不能超出它的范围。防火墙对访问应用程序进行控制的方式就是通过当应用程序初始执行时就把对象空间(称为“上下文”)分配给卡上的每个应用程序。传统智能卡环境的防火墙机构创建并管理每个生成的上下文。在传统环境中，仅仅一个上下文在任何一个时刻都是有效的(例如，因为传统环境是单线程的)。当外部资源试图访问被防火墙保护的资源时，防火墙机构检查该调用，以确定是否应该允许访问。一般地，当从相同上下文中进行调用时，就允许访问所调用的资源。另一方面，来自不同上下文种的应用程序或资源的调用一般被防火墙禁止。
但是，当来自于不同上下文的应用程序需要共享数据时就存在许多情况。因此，当必要时，传统智能卡环境提供共享数据的安全方式。在Java卡环境中，这些机构包括入口点对象(EPO)、全局阵列、和可共享接口对象(SIO)。
简要来说，EPO为Java卡中的机构，其允许特定对象被标记(例如，通过运行时间的虚拟机或通过开发人员)为入口点对象。一旦被标记，这些方法就可访问任何上下文。
全局这列是指特定的数据结构，通过其自然属性可在任何上下文中访问。例如，对于进行通信的应用程序，APDU消息在应用程序之间传送。APDU(“应用程序数据单元”)缓冲器保持这些消息直到它们能够被处理。为了使应用程序发送和接收那些消息，应用程序必须对它们进行访问。因此，APDU缓冲器被实施作为全局阵列，来自任何上下文的应用程序和资源都能够对其进行访问。
2.可共享接口对象虽然EPO和全局阵列为两个用于在应用程序之间最终在Java卡环境中共享某些数据的机构，，可共享接口对象(“SIO”)为用于访问另一应用程序方法的机构。
SIO通常指的是实施可共享接口的类的实例。通过可共享接口，对象可“导出”其方法到其它应用程序。因此，如果开发人员想要应用程序中的某些方法被导出，那么这些方法就在扩展标记接口“javacard.framework.Shareable”的接口中被声明。对于Java卡运行时间环境来说就指明这些方法可从其它上下文中进行访问。当所定义的接口在类中被实施并被实例化成为该类的对象时，新创建的对象为SIO。
要求访问通过接收应用程序所持有的对象的请求器(requestor)应用程序对接收应用程序发送调用，其确定它是否与请求器应用程序共享所请求的对象。在Java卡环境中，请求器应用程序可调用“JCSystem.getAppletShareableInterfaceObject()”方法来访问另一应用程序的对象接口。一旦接收该调用，如果接收应用程序确定其可授权访问请求器应用程序，则接收应用程序将引用(SIO类型)返回给所请求的对象。
然后，请求器应用程序可使用SIO来调用方法。例如，请求器应用程序调用SIO中的接口以在接收应用程序的上下文中访问适当的对象或对象方法。
因此，在Java卡中，应用程序可仅通过SIO机构从另一应用程序调用方法。这就防止了绕过接口限制的明显篡改，诸如对对象引用进行类型转换来获得对所有公共对象方法的访问。
D.重新创建传统应用程序环境在卡上执行期间使用技术以提供传统应用程序的专有运行时间要求，而无须显著降低其它应用程序的性能。
为了在下一代智能卡架构中重新创建专有传统应用程序环境，机构创建了先前被共享的对象的新副本。创建先前被共享的对象的新副本的原因是从防火墙中去除了监控被共享对象的引用并防止应用程序保持这些对象的非局部引用等负担。
1.被共享的对象如上所示，传统智能卡具备非常有限的资源。结果，在传统智能卡环境中，应用程序经常共享对一个以上应用程序所共用的对象。例如，在传统智能卡环境中使用的最常用的对象之一为APDU(应用程序数据单元)。APDU缓冲器用于便于在应用程序之间交换消息。当APDU在应用程序间被交换时，大量敏感信息通过APDU被传递。例如，作为校验用户对一个数据媒体具有的权限的进程的一部分，随着APDU从媒体播放器到智能卡来回被传送，一条消息包含用户访问数字内容的口令。
在传统智能卡环境中，因其大小的缘故，APDU常被共享和/或重新利用。共享APDU创建了安全疏漏之隐患。例如，由于APDU可被共享和/或重新利用，对于一个应用程序来说可以从存储在APDU中的另一应用程序访问信息(因为APDU和在APDU中的信息对两个应用程序是共有的)。因此，应用程序可窥探和捕获对另一应用程序具有保密意义的信息。
例如，通过监控APDU，请求应用程序可找出响应应用程序的名称以及用于响应应用程序的监控消息。因此，为了防止这些类型的安全性泄漏，传统智能卡环境被授权对APDU进行排他性访问，直到应用程序终止。然而，在授权访问其它应用程序之前，APDU缓冲器被清空。因此，传统应用程序期望对特定共享对象进行排他性访问而开发。
在下一代智能卡架构中，执行传统智能卡限制导致对非传统应用程序不必要的性能损失。例如，假设用户正在播放经过加密的视频。为了对数字视频信号进行加密，智能卡用于校验用户的访问权限。对数字视频信号进行解密涉及通过该卡处理相当多的数据。在传统智能卡环境中，视频播放性能被由其操作环境利用的限制所严重影响。通过去除许多传统智能卡限制，下一代智能卡架构改善了再现性能。
例如，在图1中，下一代智能卡架构100提供了用于创建先前在传统智能卡环境中被共享的对象的单独副本的机构。在实施例中，为每个应用程序创建的新对象不是现有对象的副本，而是被创建来与特定应用程序或线程同时工作的新对象。
根据实施例，虚拟机102创建先前被共享对象的新副本。
在实施例中，虚拟机102在应用程序每次调用示生成存储器中被共享对象的新副本。因此，在架构100中，允许繁衍先前被共享的对象。例如，在一个实施例中，在虚拟机102上执行的传统小程序120从外部进程接收APDU。该APDU密封在APDU对象之中。一旦接收APDU对象，在传统智能卡环境中，传统小程序120使用相同APDU进行响应。传统智能卡环境中的问题是必须等待下一个命令处理周期(例如，等待执行的下一应用程序)，直到APDU对象直到其可开始被处理被释放之后。在下一代智能卡架构的实施例中，虚拟机102分配一个APDU对象，以密封发送自和返回于传统小程序的APDU，但现在，不同APDU对象可用于下一个命令处理周期。
创建先前被共享对象的新副本帮助虚拟机102避免了当应用程序访问相同对象/资源(例如，虚拟机102不需要执行附加检查以对由应用程序存储的坏对象引用进行标记)时可出现的潜在性能隐患。以这种方式，下一代智能卡架构100创建了传统应用程序可在其中平稳执行的环境。
进一步来说，通过创建先前被共享对象的新副本，传统应用程序的安全性问题就减到最小。换句话说，每个新对象都被崭新创建，使得在任一被共享对象中的数据量最小化。因此，即使敏感数据添加到被共享对象，传统应用程序不会对被共享对象的引用保持太久。这就意味着，即使另一应用程序访问先前被共享的对象，任一特定对象中的信息很快变得不再准确。
2.代理对象在一个实施例中，下一代智能卡架构100提供了传统应用程序可在其中执行的多线程环境。然而，为了在多线程环境中确保执行安全性以及非线程应用程序的完整性，代理对象被引进到下一代智能卡架构100中。代理对象用作传统应用程序SIO的代理。此外，代理对象帮助防止传统应用程序不必要地阻塞资源以及降低其它应用程序的性能。
即使在下一代智能卡架构中，传统应用程序假设其在任何给定时刻都是唯一有效的应用程序。但是，如上所述，在下一代智能卡环境中，该项假设也许并不准确。其它应用程序(非传统或者传统)可同时运行。为了避免潜在冲突，在实施例中，架构100创建了控制访问传统应用程序的代理对象。因此，对于传统应用程序，其看起来好似为唯一运行的应用程序。
例如，在下一代智能卡架构100之中，发送到传统应用程序的消息可以是APDU形式。传统应用程序以单线程方式接收并响应那些消息。因此，当传统应用程序120接收APDU时，它就期望能够在接收任何附加信息之前处理整个请求并且回应调用服务。
同时，在架构100中，非传统应用程序(例如，基于小服务程序的应用程序101和扩展小程序107)可同时运行，产生了新的线程。例如，当基于小服务程序的应用程序101接收HTTP消息时，其就可用指明消息被接收并正被处理的消息来进行响应。同时，基于小服务程序的应用程序可启动单独线程来开始处理该调用。因此，在架构100中，多个线程可在任何给定时刻运行。结果，多个同步调用可由传统应用程序产生。
在一个实施例中，为了处理那些调用，传统应用程序的SIO由代理对象密封。代理对象通常指类“代理”形式的对象。在一个实施例中，每个SIO都存在代理对象。
根据一个实施例，代理类型用作SIO周围的包封，使得当调用被接收时，代理对象简单地检查来看另一线程是否正在执行SIO的传统应用程序代码。如果是这样，正在调用的线程就被挂起，直到访问传统应用程序代码的线程终止。在一个实施例中，其使用Java线程同步基元来执行这些功能。
在其它实施例中，代理类实施确保SIO和传统应用程序代码在某一时刻被一个线程访问的方法和接口。例如，在实施例中，代理类包括方法和属性以截取和存储打算用于SIO的消息。因此，代理类通过相关方法实施列表、队列、堆栈、或阵列来存储打算用于SIO的消息。在另一实施例中，代理对象以某些其它方式来对SIO对象执行调用串行化。此外，代理类还实施方法来控制对SIO对象的访问。例如，代理类可包括初始化SIO的方法，在完成来自特定请求应用程序的所有调用之后破坏SIO的方法，访问SIO的方法的调用方法，控制如何及何时请求器应用程序被允许访问SIO的同步方法，确定接收应用程序应该在其中响应调用的优先权的优先权方法，确定传统应用程序是否繁忙的轮询方法，校验调用有效的查错方法，校验请求器应用程序识别的识别方法，把APDU消息发送到传统应用程序的正向传送方法，存储并正向响应来自后退到请求应用程序的传统应用程序的回答方法，以及在控制访问SIO中可能有用的各种其它方法。注意到，以上列举的方法为示例性方法，并且根据实施，可随着架构的不同而变化。
访问传统应用程序代码的其它企图可由APDU分派程序(dispatcher)管理。APDU分派程序为系统组件(或虚拟机组件)，其接收APDU消息，以及根据接收将被传统应用程序代码处理的APDU消息来检查来看另一线程是否正在执行传统应用程序代码。在一个实施例中，APDU分派程序经由用于串行化对传统小程序SIO的调用的相同锁定机构来执行该检查。如果传统应用程序代码是自由的，那么APDU分派程序就可授权访问传统应用程序代码。
在实施例中，通过使用执行上下文锁或全局容器锁来控制对传统应用程序的访问。换句话说，代理对象可使用同步机构(诸如在Java中找到的那些)以确保在给定时刻仅一个应用程序访问传统应用程序。
根据一个实施例，下一代智能卡架构100自动检测何时传统应用程序被调用。在一个实施例中，规范器工具把标记插入代码以指明应用程序为传统应用程序。因此，当传统应用程序的SIO被调用时，架构100检查指明传统应用程序的标记并且把用于传统应用程序SIO的代理对象实例化。然后，所有对传统应用程序的SIO的调用被代理对象截取并在调用原始SIO的方法之前被串行化。在可选实施例中，传统应用程序可一些其它方式被确定(例如，通过检查类的主要或次要版本，维护识别哪些应用程序为传统应用程序的登录表或列表等)。
在一个实施例中，小程序API110创建用于传统应用程序的代理对象。可选地，虚拟机102在传统应用程序被调用时自动对代理对象进行实例化。
3.创建代理对象的实例重新参考架构100，假设非传统应用程序从传统应用程序调用信息。在一个实施例中，架构100截取调用并且检测到该调用正被传送到传统应用程序。因此，在一个实施例中，架构100启动传统应用程序以及对用于传统应用程序SIO的代理对象进行实例化。在一个实施例中，SIO在此时也可被实例化。此外，架构100创建其应用程序列表中的条目，以把发送到传统应用程序的任何消息重新引导到代理对象。
一旦实例化了代理对象，打算用于传统应用程序的原始消息被正向传送到代理对象。在一个实施例中，该消息被串行化并被处理。当消息最终被代理对象处理时，在一个实施例中，代理对象调用适当方法和/或通过传统应用程序SIO调用的调用数据。
在一个实施例中，一旦应答了调用，传统应用程序把响应发送到其后将响应正向传送到请求应用程序的代理对象。通过经过代理对象发送响应，代理对象可追踪何时传统应用程序可用。此外，代理对象可确保特定级别的性能。另外，传统应用程序直接响应请求应用程序。
假设在传统应用程序正在创建对第一接收消息的响应的间隔期间，来自其它应用程序的多个其它调用被同时发送到传统应用程序。在一个实施例中，那些消息被重新引导到代理对象，使其串行化。然后，每次传统应用程序完成对消息的响应，代理对象都处理下一个消息。以这种方式，代理对象就防止SIO丢弃正在到来的消息。
基本上，当调用从传统应用程序的外部源到来时，代理对象就代为请求。当正在使用SIO时，代理对象保持其它调用，直到SIO被释放。然后，代理对象通过SIO来调用所请求的信息。因此，请求应用程序可与传统应用程序进行通信。
参考图1，假设了传统小程序120正在架构100中执行。因此，架构100已经生成了用于传统小程序SIO的代理对象。因此，当基于小服务程序的应用程序101从传统小程序调用数据时，在实施例中，虚拟机102检测从基于小服务程序的应用程序101发送到传统小程序120的调用。调用被重新引导到代理对象，然后通过SIO把调用正向传送到传统小程序120。之后，传统小程序120处理该调用。
现在，假设在传统小程序完成了处理来自基于小服务程序的应用程序101的调用之前，扩展小程序107也发送调用到传统小程序120。在实施例中，来自扩展小程序107的调用被代理对象所截取并保持，直到传统小程序120完成处理来自基于小服务程序的应用程序101的调用并释放其资源。类似地，如果其它调用由传统小程序120产生，那么那些调用就被代理对象截取并保持，直到可服务调用。
以这种方式，传统小程序120可继续发挥作用而无须被其它应用程序折中。应注意到，代理对象不应该创建大量性能缺陷。仅试图访问传统应用程序的应用程序才直接受到影响。其它进程和应用程序围绕着传统应用程序继续执行。
E.用于创建专有环境的过程图4示出了用于在下一代智能卡架构中创建传统应用程序在其中执行的专有环境的示例性过程。为了示出该进程，假设多个应用程序已在下一代智能卡虚拟机(例如，结合图1所述的虚拟机102)上执行。在步骤410中，用户在下一代智能卡环境中打开传统应用程序。在一个实施例中，当用户打开传统应用程序时，下一代智能卡架构检测应用程序为传统应用程序并要求用于其的专有环境以安全执行。
因此，在步骤420中，为传统应用程序创建专有环境。在一个实施例中，下一代智能卡虚拟机创建并管理专有环境。如上所述，传统应用程序通常仅可通过SIO来访问其它应用程序。由于下一代智能卡环境允许多个应用程序同时执行，所以传统应用程序可在某一时刻接收许多调用(即使其SIO被设计成在某一时刻仅处理一个调用)。结果，在一个实施例中，创建代理对象以密封SIO。通过如此操作，可控制对SIO的访问。基本上，代理对象截取调用并随着完成每个以前的调用而把它们都正向传送到传统应用程序(通过SIO)。因此，在某一时刻仅允许一个调用(或无论SIO能够处理多么多的调用)访问可共享接口。
在一个实施例中，通过创建打算被单线程应用程序共享的的对象的副本，下一代智能卡的虚拟机也可进一步增强专有环境。这样做是通过检测在传统智能卡环境中传统应用程序何时访问打算被共享的储器中的对象来进行的。当下一代智能卡架构检测对象时，其简单创建了存储器中对象的新副本。因此，所述对象不再是被共享的对象。
在步骤430中，一旦创建了专有环境，传统应用程序就能够安全执行。
硬件综述图5是示出计算机系统500以及本发明的实施例可在其上实施的智能卡的框图。计算机系统500包括总线502或其它通信机构，用于信息交换；以及与总线502连接的处理器504，用于处理信息。计算机系统500还包括主存储器506(例如，随机存取存储器(RAM)或其它动态存储装置)，连接到总线502，用于存储信息和将由处理器504执行的指令。主存储器506还可用于在处理器504执行指令期间存储临时变量或其它中间信息。计算机系统500还可包括连接到总线502的只读存储器(ROM)508或其它静态存储装置，用于存储用于处理器504的静态信息和指令。提供诸如磁盘或光盘的存储装置510，连接到总线502，用于存储信息和指令。
计算机系统500可经由总线502连接到用于将信息显示给计算机用户的显示器512(例如，阴极射线管(CRT))。包括字母数字和其它键的输入装置514连接到总线502，用于将信息和命令选择传输到处理器504。另一种类型的用户输入装置是诸如鼠标、跟踪球、或光标方向键的光标控制器516，用于将方向信息和命令选择传输到处理器504，并用于控制显示器512上的光标移动。该输入装置通常具有在第一轴(例如，x)和第二轴(例如，y)的两个轴上的两个自由度，这使装置指定平面内的位置。。
本发明涉及本文所述工具技术的计算机系统500的使用。根据本发明的一个实施例，响应于执行包含在主存储器506中的一个或多个指令的一个或多个序列的处理器504，通过计算机系统500提供工具和技术。这些指令可从诸如存储装置510的另一机器可读的介质读入主存储器506。执行包含在主存储器506中的指令序列使得处理器504执行本文描述的处理步骤。还可使用多处理配置中的一个或多个处理器，以执行包括在主存储器506中的指令序列，在可选实施例中，可以用硬连线电路代替软件指令或与软件指令相结合以实施本发明。因此，发明的实施例不限于硬件电路和软件的任何具体组合。
本文使用的术语“机器可读介质”指的是参与将指令提供给处理器504用于执行的任何介质。这种介质可采用多种形式，包括但不限于非易失性介质、易失性介质、和传输介质。举例来说，非易失性介质包括诸如存储装置510的光盘或磁盘。易失性介质包括诸如主存储器506的动态存储器。传输介质包括同轴线缆、铜线和光纤，包括构成总线502的导线。传输介质还可采用声波或光波的形式，诸如在无线电波和红外数据通信中生成的那些波。
例如，机器可读介质的通常形式包括软盘、柔性盘、硬盘、磁带、或其它磁性介质、CD-ROM、DVD、或任何其它光存储介质、穿孔卡、纸带、任何其它具有孔式样的物理介质、RAM、PROM、EPROM、FLASH-EPROM、任何其它存储芯片或盒式磁带、下文中描述的载波，或计算机可读取的任何其它介质。
各种形式的机器可读介质可参与将一个或多个指令的一个或多个序列传送到理器504用于执行。例如，指令可最初承载在远程计算机的磁盘上。该远程计算机可将指令加载进其动态存储器并使用调制解调器通过电话线发送这些指令。计算机系统500的本地调制解调器可接收电话线上的数据并使用红外发射器将数据转换为红外信号。红外探测器可接收红外信号中携带的数据，并且适当的电路可将数据放到总线502上。总线502将数据传送到主存储器506，处理器504从主存储器506中取得数据并执行指令。由主存储器506所接收的指令可在处理器504执行之前或之后可选地存储在存储装置510上。
计算机系统500还包括连接到总线502的通信接口518。连接到与局域网522相连的网络链路520的通信接口518提供双路数据通信。例如，通信接口518可以是综合服务数字网络(ISDN)卡或调制解调器，用于提供到相应类型的电话线的数据通信连接。作为另一个实例，通信接口518可以是局域网(LAN)卡，用于提供到兼容LAN的数据通信连接。还可实施无线链接。在任何这样的实施中，通信接口518发送和接收承载表示各种类型信息的数字数据流的电信号、电磁信号或光信号。
网络链路520一般通过一个或多个网络向其它数据装置提供数据通信。例如，网络链路520可通过局域网522提供到主机524或者到由互联网服务商(ISP)526所操作的数据设备的连接。ISP526又通过现在通常称作“互联网”528的全球分组数据通信网络提供数据通信服务。局域网络522和互联网528都使用携带数字数据流的电信号、电磁信号或光信号。通过各种网络的信号和在网路链路520上并通过通信接口518的信号，其将数字数据传送到计算机系统500和从计算机系统500传送数字数据的信号，是传输信息的载波的示例性形式。
计算机系统500可通过网络、网络链路520、和通信接口518发送消息和接收数据(包括程序代码)。在互联网实例中，服务器550可通过互联网528、ISP 526、局域网522、和通信接口518传输用于应用程序的请求代码。根据本发明，一个这样的下载应用程序提供本文所描述的技术。
当代码被接收到时，所接收的代码就可被处理器504执行、和/或存储在存储装置510或其它非易失性存储装置中用于以后执行。这样，计算机系统500可获得载波形式的应用程序代码。
权利要求
1.一种方法，包括在智能卡上的多线程运行时间环境中执行一组应用程序，其中，在所述一组应用程序中的至少一个应用程序是被设计为在单线程环境中运行的单线程应用程序，以及其中，所述单线程应用程序通过可共享接口对象对于所述一组应用程序中的其它应用程序是可访问的；以及在所述多线程运行时间环境中生成可安全执行所述单线程应用程序的专有环境，其中，所述专有环境包括密封所述可共享接口对象的代理对象，以及其中，所述代理对象控制由所述一组应用程序中的所述其它应用程序对所述可共享接口对象的访问，使得仅允许一个应用程序在某一时刻访问所述单线程应用程序中的代码。
2.根据权利要求1所述的方法，还包括检测所述单线程应用程序正在访问存储器中被所述单线程应用程序试图共享的对象；以及创建存储器中所述对象的新副本，以使所述对象不再被共享。
3.根据权利要求2所述的方法，其中，生成所述对象的所述新副本包括仅把最少量的数据添加到所述对象的所述新副本中。
4.根据权利要求1所述的方法，其中，所述一组应用程序中的其它应用程序与所述单线程应用程序同时运行。
5.根据权利要求1所述的方法，其中，所述可共享接口对象被设计成在某一时刻仅处理一个调用。
6.根据权利要求1所述的方法，其中，所述代理对象截取调用以访问所述可共享接口对象。
7.根据权利要求1所述的方法，其中，所述代理对象保持其它调用直到所述可共享接口对象完成当前调用的执行。
8.根据权利要求1所述的方法，还包括在多线程运行时间环境中执行所述应用程序之前，将所述单线程应用程序从压缩格式转换成未压缩格式。
9.根据权利要求8所述的方法，其中，所述压缩格式为CAP文件格式，以及所述未压缩格式为类文件格式。
10.根据权利要求1所述的方法，其中，仅允许一个应用程序在某一刻访问所述可共享接口包括把对所述单线程应用程序的调用串行化。
11.一种机器可读介质，包括用于执行以下步骤的指令集在智能卡上的多线程运行时间环境中执行一组应用程序，其中，在所述一组应用程序中的至少一个应用程序是被设计为在单线程环境中运行的单线程应用程序，以及其中，所述单线程应用程序通过可共享接口对象对于所述一组应用程序中的其它应用程序是可访问的；以及在所述多线程运行时间环境中生成可安全执行所述单线程应用程序的专有环境，其中，所述专有环境包括密封所述可共享接口对象的代理对象，以及其中，所述代理对象控制由所述一组应用程序中的所述其它应用程序对所述可共享接口对象的访问，使得仅允许一个应用程序在某一时刻访问所述单线程应用程序中的代码。
12.根据权利要求11所述的机器可读介质，还包括检测所述单线程应用程序正在访问存储器中被所述单线程应用程序试图共享的对象；以及创建存储器中所述对象的新副本，以使所述对象不再被共享。
13.根据权利要求12所述的机器可读介质，其中，生成所述对象的新副本包括仅把最少量的数据添加到所述对象的所述新副本中。
14.根据权利要求11所述的机器可读介质，其中，所述一组应用程序中的其它应用程序与所述单线程应用程序同时运行。
15.根据权利要求11所述的机器可读介质，其中，所述可共享接口对象被设计成在某一时刻仅处理一个调用。
16.根据权利要求11所述的机器可读介质，其中，所述代理对象截取调用以访问所述可共享接口对象。
17.根据权利要求16所述的机器可读介质，其中，所述代理对象保持其它调用直到所述可共享接口对象完成当前调用的执行。
18.根据权利要求12所述的机器可读介质，还包括在多线程运行时间环境中执行所述应用程序之前，将所述单线程应用程序从压缩格式转换成未压缩格式。
19.根据权利要求18所述的机器可读介质，其中，所述压缩格式为CAP文件格式，以及所述未压缩格式为类文件格式。
20.根据权利要求11所述的机器可读介质，其中，仅允许一个应用程序在某一刻访问所述可共享接口包括把对所述单线程应用程序的调用串行化。
全文摘要
为了在下一代智能卡环境中执行传统智能卡应用程序，提供将应用程序转换成可由下一代智能卡平台执行的格式的机构。例如，在基于Java环境中，规范器工具把CAP文件翻译成Java的类文件。附加机构在下一代智能卡上重新创建专有环境，该专有环境使所述传统应用程序无须影响传统和非传统应用程序的性能而执行。例如，机构创建以前共享对象的新实例，使得传统应用程序可继续期望对那些对象进行排他性访问。此外，机构通过控制调用如何以及何时被发送到传统应用程序来管理传统应用程序和非传统应用程序之间的通信。
文档编号G06K19/077GK101013379SQ20071000061
公开日2007年8月8日 申请日期2007年1月9日 优先权日2006年1月9日
发明者坦若尔·S·拉维尚卡尔, 蒂埃里·P·维奥洛, 马修·R·希尔, 萨基卜·艾哈迈德 申请人:太阳微系统有限公司