Simple JNDI serving is straightforward, distributed transaction management is hard
There is a fairly comprehensive tutorial on JNDI provided by Oracle. Although it appears dated (JDK 1.1.2 anyone?) the JNDI specification has not changed a lot in the intervening time and is still relevant. Carefully reading through the examples will provide you with enough information to be able to construct a standalone application capable of serving up internal objects in response to JNDI requests.
Are you sure you need distributed transactions?
Your second question is to do with handling distributed transactions. There are several ways to interpret a distributed transaction based on the level of collaboration between applications.
In the simple case you'd have a workflow like this:
- Application A sends a work package to Application B over HTTP
- Application B attempts to commit this to the database. If successful a 200 OK is returned, otherwise some error code is used.
- Application A knows how to react to a failure appropriately.
Clearly you wouldn't need JNDI to implement this kind of workflow, other than perhaps to have your application (Application C) take the role of providing Application B with the database connection pool (Tip: use C3P0 for that).
In the complex case you'd have a workflow more like this:
- Application A registers the start of a distributed transaction with Application C, and then works with the database to do some work.
- Application A completes part of the overall transaction and hands over to Application B to finish it. Application A notifies Application C of the status.
- Application B registers its part of the transaction with Application C and attempts to complete its work. If it fails, Application C knows how to orchestrate the rollback (perhaps using nested transaction management).
If you're looking for a workflow like the complex case, then I'd say you should be considering an application container to manage it. If not, then you may not even need JNDI.