>> To be blunt, that simply isn't going to happen. Just close your eyes and >> think of England, it's not in the cards.
> Why is it never gonna happen? Design mostly, the web service is the interface. The fact that ActiveMQ (or any other solution) is behind the scenes providing the updates is simply a detail. > I'm still at a bit of a loss to completely understand what you are > trying to do. Is there some requirement explicitly disallowing a .Net > client library (which does everything you need already)? > Or is the idea to use some kind of RESTful API to ActiveMQ to avoid > using client libraries? Essentially, keeping the client as agnostic as practical. > We have REST support so you can just use HTTP POST/GET; you can also > browse the available messages on a queue as an XML document (or RSS > feed). Would that help? I'll have to look. I thought the REST support was for publishing, not necessarily subscribing. > You could bridge from ActiveMQ to Oracle Queues; but I don't see what > value Oracle Queues brings to the table. I'm actually more interested in going the other way, from Oracle to ActiveMQ. The idea being that not all changes will necessarily come from the app server, some may source from the database. If the stored procedures can post to an Oracle Queue, and then that Queue can be forwarded to an ActiveMQ Topic, that would satisfy that requirement quite nicely. Thanx! Regards, Will Hartung ([EMAIL PROTECTED]) -- View this message in context: http://www.nabble.com/Design-Guidance-t1447633.html#a3970484 Sent from the ActiveMQ - User forum at Nabble.com.
