activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Hartung <wi...@msoft.com>
Subject Re: Design Guidance
Date Tue, 18 Apr 2006 15:31:52 GMT

>> 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
(willh@msoft.com)



--
View this message in context: http://www.nabble.com/Design-Guidance-t1447633.html#a3970484
Sent from the ActiveMQ - User forum at Nabble.com.


Mime
View raw message