Thanks for thinking along. I had reached that same conclusion with regard to using AQ exposed as JMS to hook into a JEE server. The only drawback for my particular scenario is that this requires additional work in the application server – where I was hoping for a way to configure the JMS Queue to publish onto in the  database and completely stay out of the app server.

However, I concluded earlier on that it will not be possible to create a single, generic solution in PL/SQL and JSP that support any JMS server; it turns out that every JMS implementation (JBoss, GlassFish, WebSphere, WebLogic) requires its own, special client implementation – using dedicated libraries. So instead of being able to create a single JSP with a single set of associated JARs, we will have to create and load a JSP+ JARs for every JMS implementation that needs to be supported.

The best approach seems to be now configure an Advanced Queue in the database expose itself as a JMS Queue that Java Clients then can register to. The following approach:
* during installation of the application, create an Advanced Queue and expose it as JMS Queue (or Topic)
* have the database application publishe to this AQ
* create a MDB (Message Driven Bean) that registers to the AQ based JMS Queue and publish onwards to any desired target JMS Queue or Topic. This MDB can be configured through a properties file or through JMX to target it to the correct target JMS Queue. By adopting this approach, your database implementation stays clean – no complex JSP and JAR installation, no complex configuration of security settings and privileges for the JSP, no special support for every type of JMS implementation that you want/need to support and the full flexibility and decoupling of JMS is still available: your customer sets up the target queue that you should publish to [from the database, directly or indirectly] and the MDB is configured to listen to the AQ based JMS and publish to the ‘real’ JMS Queue. The only complexity introduced is a (standard) Java class (MDB) that should be deployed on the application server used by the customer to run their JMS environment
With WebLogic we could adopt the approach you suggest, with the Foreign JMS Provider. I am not sure how that works out on other application servers that need to be supported.

Lucas