Application Authorization - Expert Oracle and Java Security - page 225

each connection string used by the application. This declaration of connsHash uses generics to require
that the keys be Strings and the values be RAW , with the <String, RAW> syntax.
HashMaps can be created without generics; that is, without specifying the object type of the key and
value, but each time you retrieve a key or value, you would need to cast it to the appropriate type.
Additionally, by specifying the object types, we are assured that our application will only place objects of
that type in our key and value fields. Otherwise, HashMaps can hold a variety of Object types all at once.
An Inner Class to Represent the Application
Our applications will identify themselves to this application authentication process by passing an object
that implements a specific interface: the RevLvlClassIntfc interface. An interface is like a class, but it is
hollow—it has no guts. An interface can specify a list of methods, and all classes that implement that
interface will need to implement those methods; that is, they will need to have methods with the same
signature (same name, arguments and return types). Hopefully, they will also provide the guts or
functional code to accomplish whatever's required.
The RevLvlClassIntfc interface is in the orajavsec package, just like OracleJavaSecure . Also like
OracleJavaSecure , the interface needs to exist in the Oracle database as well as on the client.
RevLvlClassIntfc needs to be loaded into Oracle, as the first line of Listing 10-19 suggests, and needs to
be distributed to developers along with OracleJavaSecure.class , most likely in the same jar file.
Listing 10-19. Revision Level Class Interface
//CREATE OR REPLACE AND RESOLVE JAVA SOURCE NAMED appsec."orajavsec/RevLvlClassIntfc" AS
package orajavsec;
public interface RevLvlClassIntfc {
//private static final long serialVersionUID = 2011010100L;
//private String innerClassRevLvl = " 20110101a";
public String getRevLvl();
}
 Note You can find this code in the file named Chapter10/orajavsec/RevLvlClassIntfc.java.
There is one method in the interface, getRevLvl() . This returns a revision level, innerClassRevLvl
that we can use to support multiple versions of an application. For instance, if you are moving your
application data to new Oracle tables or a new Oracle database, you could update innerClassRevLvl in
your inner class and use our processes to register the updated application and generate a new set of
connection strings associated with it. Both the old application/version and the new one would be able to
get their respective connections simultaneously. Also, to force everyone to move to a new version of an
application and to disable the old version, we can delete the old version of our inner class from the
application registry, or just delete the associated connection strings list.
We will ask the implementers of this interface (the developers) to also provide a static long named
serialVersionUID that is used in object serialization (packaging for storage in the database and for
transmission across the network.) We will discuss this more shortly.