activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Design Guidance
Date Tue, 18 Apr 2006 21:33:16 GMT
On 4/18/06, Will Hartung <> wrote:
> >> 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.

So the only possible technology is some web service API plus a SOAP
over HTTP stack right?

If so you could look at WS-Notification

> > 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.

Note that the C# client supports pluggable transports so it should be
possible to use any transport/marshalling layer inside it. Plus it
should be possible to integrate ActiveMQ.Net into WCF to further hide
the C# client.

> > 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.

The weakness is in the consumption side; its hard to do RESTful
consumption really well - so we're not 100% pure REST (we use GET to
consume by default) - or you can use GET to browse queues then a POST
to delete messages (but we have no message locking to do pure RESTful
load balancing).

> > 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.

We've a JMS bridge in both ActiveMQ and ServiceMix; we're just missing
support for Oracle AQ; though we could treat it as a JMS provider



View raw message