Skip to Main Content

E-Business Suite

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

How to decide the Item Class Structure

3669639Apr 21 2019 — edited Feb 8 2021

Hi,

My client is requesting us to recommend and help them to decide the item class structure as they are not able to decide the same.

I am suggesting few points which can be food for thought for them to decide what kind of item class hierarchy would be suitable for them:

  1. Item class can be decided on the basis on grouping items when NIR process flow is required
  2. Data quality and matching is required
  3. Item number and description need to follow any particular sequence
  4. Item Class can be created for specials
  5. Item class can be created based on organization structure
  6. Item class can be created based on regions where the business operates

Please let me know if you have any pointers or suggestion which can be helpful to decide the item class structure. If you can suggest any hierarchy that you may have followed in your past implementations then it would be of great help.

Thanks

Ekansh

Comments

safarmer
Answer
Hi,

You are correct in your assumption that you have to remove the old applet and then load a new one.

If the data is important, you could have two applets on the card. One would be a data container and the other would have the application logic. You would access the data through Shareable Object Interfaces (SOI). You need to secure this though as it could mean that if your card is compromised, there is a means for any applet to access your data. In a single applet solution you do not have this problem as the firewall protects the data.

Cheers,
Shane
Marked as Answer by Bluefairy · Sep 27 2020
Bluefairy
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
safarmer
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
safarmer
safarmer wrote:
I don't think it is a common practice
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
Jean-Damien LEBUI
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
1 - 5

Post Details

Added on Apr 21 2019
0 comments
102 views