?? 183-184.html
字號:
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:Card-Side Application Programming Interfaces</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="181-183.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="185-191.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P>The SCOS toolkit or API consists of 71 general-purpose smart card functions. These functions run the gamut from simple arithmetic and file system access to security functions. Using these functions with your own assembly language code, it is relatively easy to add new commands to the Multiflex card. Nevertheless, keep in mind the preceding discussion about RAM utilization and make sure you understand how each function you call and each function it might call uses RAM.
</P>
<P>In order to activate your new command(s), you have to override some part of Multiflex command processing loop. SCOS lets you override any of the following elements of this loop:</P>
<DL>
<DD><B>•</B> <I>The card manager</I>. You would override the card manager if you wanted to take complete control of the card and have it only recognize your new commands. When you override the card manager, you are responsible for all aspects of the card’s operation including RAM initialization, transmit function activation, answer-to-reset, and command processing.
<DD><B>•</B> <I>The receive function</I>. Code that overrides the receive function would examine each command coming from the terminal and call new command processing code when a new command was detected. If an existing Multiflex command was detected, the receive function would pass it to the Multiflex card manager for processing as usual.
<DD><B>•</B> <I>The transmit function</I>. You override the transmit function when you want to alter the response of or data returned from an existing or extended command.
<DD><B>•</B> <I>The I/O interrupt function</I>. Your code gets control whenever the microprocessor throws an I/O interrupt. This feature is useful when you want to achieve tight cooperation between the host and the smart card, which is not typically the case.
</DL>
<H4 ALIGN="LEFT"><A NAME="Heading17"></A><FONT COLOR="#000077">MULTOS</FONT></H4>
<P>The MULTOS API is a card-side application programming interface on a smart card running the MULTOS multiapplication operating system. The API provides write-once-run-anywhere functionality to applications written for MULTOS-conformant smart card platforms. MULTOS provides application segregation via the use of ITSEC E6 certified firewalls. MULTOS can support both online applications, where a direct connection between the host application and the card is required, and offline applications, where such a connection is not required. MULTOS also provides a secure end-to-end application load/delete facility under card issuer control, even after the cards are in the field.
</P>
<P>The description and specifications of the MULTOS API are openly available for license from MAOSCO Ltd. The license gives the developer the right to develop one or many applications and is royalty free. All licensees receive a copy of the MULTOS Application Programmers Reference Manual, which gives details of the API, application programming language (called MEL, the MULTOS Execution Language), and a description of the MULTOS virtual machine. A small license fee (at the time of this writing approximately £100) is payable to cover the cost of production and distribution. If you want a copy, contact Nick Habgood, the CEO of MAOSCO Ltd., at <TT>Customer.Service@MULTOS.com</TT> to become a licensed MULTOS application developer.</P>
<P>Unlike the proprietary Java Card API, which is controlled exclusively by Sun Microsystems, the MULTOS specification is controlled, on behalf of the smart card industry and smart card application developers, by a consortium of companies including Motorola, Hitachi, Siemens, Gemplus, MasterCard, Mondex, DNP, and Keycorp.</P>
<H3><A NAME="Heading18"></A><FONT COLOR="#000077">The Java Card</FONT></H3>
<P>In October 1996, Schlumberger announced the implementation of an interpreter (virtual machine) for a subset of the Java programming language (Java Card) on a standard 8-bit smart card microcontroller. For the first time in the 20-year history of smart cards, it was possible for anybody to write a card-side application for a smart card and to write it in a modern high-level language.
</P>
<P>While the Java Card smart card only supports a subset of the Java language and Java programs running on a smart card that are still time and space constrained, viable smart card card-side applications—particularly non-financial applications—can be quickly and easily programmed and field tested. Providing quick time-to-market for new and innovative smart card applications was one of the driving forces behind the development of the Java Card smart card.</P>
<P>There are no 32- or 64-bit data types, no Unicode characters, no threads, no multidimensional arrays, and no garbage collection in the Java Card smart card. The best way to think of a Java program on a Java Card smart card is as a script around native function calls. It contains processing logic and it passes parameters and collects results, but rarely does a Java program on a Java Card smart card do any real computation. A Java Card smart card program is more of a data flow controller than a data processor.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="181-183.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="185-191.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -