Oracle Forms

Thanks Safarmer!

I just wanted to know if the applet developer companies prefer to consume more time on testing their single applet instead of writing two applets with debugging capability?
I think using one applet as a data container will cause speed problems. Comparing java card with the native cards it's slow enough and if we use another applet in order to store user data will enormously slow down the applet. Is it a common practice among applet developers to use two applet and SOI in their products?

-Thanks as always

Edited by: Bluefairy on Dec 23, 2010 3:58 AM

Hi,

I don't think it is a common practice, but we had no choice with our applet. We needed the ability to be able to update the application on the card without loosing any data. There were several private keys that only exist on the card so we could not reload the data when reinstalling. Also given the amount of data to load, it wasn't really practical to reload it all.

The second applet (data container) that I mention has very little functionality. It literally takes the data you pass to it and places it where you specify. Then when you read from it, you say I want these bytes from this location. Two slow points with any smart card aplicaiton is cryptography (no additional crypto added here) and EEPROM writes (no additional writes added since the data needs to be written somewhere).

You should remember that a poorly implemented applet in any language (native, Java, DotNet, MULTOS C/Java) will be slow. There are a few things that can be done to speed things up. Also, you may get added security at the expense of speed (applet firewall etc).

Cheers,
Shane

Also, it is an interesting alternative considering the issues involved in reloading code with data. You may save a lot of time and money on redeploying updates in this way (I now we will have).

Cheers,
Shane

This topic is very interesting to me.

In fact, I spent nearly one year studying it and unfortunately, from a point of view of a "researcher", I think that at the moment, for monolithic application, there's no way "patching" Javacard-based application. The only solution is replacing it with the new version.

However, I found this topic interesting and it could be helpful to some of you reading this article: http://portal.acm.org/citation.cfm?id=1828747
(or: http://www.msi.unilim.fr/~noubissi/wiki/uploads/Publications/noubissi4.pdf)

I spent a little more time working on javacard 3.0 connected edition with improved features hoping to implement an OSGi-cored middleware supporting dynamic update but unfortunately, my research was abandoned some months ago.

I hope that this information would be helpful to you.

Best regards,
Hai-Binh LE