Best way to access JNDI configured DataSource from outside container

Question

I'm not sure if this is the right forum category, but it seemed like a good place to start.
I have a DB2 database on an OS/390 mainframe that is configured as a JNDI datasource in WebSphere (WSAD) 5.1.x. I can get connections and do database transactions within my web-application just fine.
Part of my project needs a cron managed stand-alone application to do some database clean up work. It essentially needs to query one database, and then based on the results stick some data into the DB2 database. Easy enough right?
The issue here is that our Security department will not under any circumstances give us the passwords and users for either database. They give these only to the server admins who configure WSAD. We also can't use a properties file. The server admins either won't touch any properties file (it is considered "code" and they don't want to be responsible for problems) or they won't have access to the contents of the ears or jars we give them. This basically leaves us with our JNDI datasource as the only datasource we could access (because the admins will have it configured with a username and password). There is also no way to infer a valid username/password from the owner of the web-app since it will live on an NT box and the NT user won't have mainframe rights.
There is also no possibility of bending these rules no matter how stupid or cumbersome they are.
So my question is, what is the best method in which to gain access to this JNDI DataSource or a Connection from this DataSource? Can I even get a DataSource from a JNDI lookup? Is JMS/RMI or some other acronymn that I don't know about the only way to acomplish this?
We're using Struts MVC -> Spring -> Hibernate in the webapp, if that helps.
Thanks in advance.

Answer 1

You seem to be asking: "how can a standalone app get a valid DB2 connection by leveraging the live objects in a WSAD application"?
While this is pretty far from my area of expertise, I don't think you can. While both JMS and RMI (and other technologies) can export some types of Java objects, they have to be objects that implement the java.io.Serializable interface. Connections cannot be serialized because these objects (normally) encapsulate a live TCP/IP connection. I don't see any fundamental reason a DataSource object couldn't be serialized other than security, but that very reason means that no reasonable implementation is going to be serializable; if it were serializable, you could almost certainly extract the value of the username and password from the serialized object. In other words, what you're really trying to do is get around security and Java's security is probably robust enough to prevent it.
If the DB credentials only live in the WSAD world, that's where the database work has to be done. However, there's no reason the work can't be driven by a servlet or JSP that is in turn invoked from a cron-driven script or application. Personally, I do such "event notifier" scripts in Perl; Java is a bit heavy for "start up, post to URL, shutdown", but if you have more work going on you could certainly use Java. If actually doing the work in the WSAD application is not acceptable, then you're probably stuck.