Skip to Main Content
Forums

Java Development Tools

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!

Validate Attribute value at entity level validation against Runtime DB Query

Sanjeev-OFMAug 30 2022

Hello Friends,
We are having one requirement where we need to do additional validation against a query text. I'm explaining it with the scenario.
Scenario:
We have to validate entity based view object one String attribute value (which is a combination of 8 multiple values separated via "." Value example-- "001.100.101.00012.ABC123,24343,12019,ak200") against with query text where starting 4 parameter value of String attribute need to pass in query text where clause( select count(*) from table name where param1='001' and param2='100' and param3='101' and param4='00012') and if query text count>0 than allow to save the record and if there is no record with provided combination in query text than need to show error message.

Kindly help with suggestion how we can validate it using the declarative approach.
Thanks
Sanjeev

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
1 person found this helpful
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 person found this helpful
1 - 5

Post Details

Added on Aug 30 2022
#adf, #application-development-in-java, #jdeveloper-and-adf
15 comments
519 views