You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Peter Hansson <pe...@yahoo.com.INVALID> on 2016/02/29 22:21:12 UTC
Recommendation for vendor independent strategy
Hi there
We've developed a "thingy" that integrates with various messaging architectures. So far - at the sites where we have deployed - we've had IBM MQ, Tibco Message Service and even a Wildlfy installation (HornetQ) at the other end. We've developed in Java and used JMS so we use exactly the same code against any of these and haven't actually cared to much about these messaging architectures at the other end of our software.
Now we have customer that uses ActiveMQ and this is new to us.
We have (without it being deliberate) developed against JMS 2.0 because we use async send. Frankly we haven't paid attention to this. It just so happens that the middleware we've met so far have been JMS 2.0 compliant so this has not been an issue.
So, we are in need of a client jar for ActiveMQ 5.x that supports JMS 2.0. Is such a thing available? If so from where? I've been looking at some JIRA tickets but I've failed to figure out the exact status of JMS2.0 together with ActiveMQ, Apollo, Artemis and what have you. I'm confused.
I believe the customer in question is running some fairly recent version of ActiveMQ, I believe it was 5.10.x.
I don't think we have an appetite to rewrite our code just to land this customer. The business case is probably not strong enough.
Perhaps I should emphasize that we're really only concerned with the client side of things. The actual messaging infrastructure (I believe you guys call them brokers?) is not our headache. As for the JMS 2.0 feature we use we couldn't care less if this is something which is faked in the client lib or if it's a native feature on the server side.
Any recommendation on how to proceed ?
Peter
Re: Recommendation for vendor independent strategy
Posted by artnaseef <ar...@artnaseef.com>.
It may be possible to build a facade, if you don't need all of the features
of the 2.0 spec.
For example, ActiveMQ has an async send features that producers can use,
which may meet your needs.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Recommendation-for-vendor-independent-strategy-tp4708598p4708617.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Recommendation for vendor independent strategy
Posted by "John D. Ament" <jo...@apache.org>.
Even then, JMS 2.0 is a client library. Its not the protocol
implementation to your backing queue. On the flip side, there are many
AMQP implementations, it may be a better approach to connecting in a vendor
agnostic way.
John
On Mon, Feb 29, 2016 at 8:39 PM Tim Bain <tb...@alumni.duke.edu> wrote:
> I'm not aware of a plan to implement JMS 2.0 in ActiveMQ 5.x. I believe
> Artemis implements JMS 2.0, but you'd have to convince your potential
> customer to switch to it and it's not a simple drop-in replacement so they
> might not be willing to do that just to use your "thingy."
>
> I'm not aware of anyone who's "faked" a JMS 2.0 client JAR, but maybe
> someone else is.
>
> Tim
> On Feb 29, 2016 2:21 PM, "Peter Hansson" <peterhansson_se@yahoo.com
> .invalid>
> wrote:
>
> > Hi there
> > We've developed a "thingy" that integrates with various messaging
> > architectures. So far - at the sites where we have deployed - we've had
> IBM
> > MQ, Tibco Message Service and even a Wildlfy installation (HornetQ) at
> the
> > other end. We've developed in Java and used JMS so we use exactly the
> same
> > code against any of these and haven't actually cared to much about these
> > messaging architectures at the other end of our software.
> > Now we have customer that uses ActiveMQ and this is new to us.
> > We have (without it being deliberate) developed against JMS 2.0 because
> we
> > use async send. Frankly we haven't paid attention to this. It just so
> > happens that the middleware we've met so far have been JMS 2.0 compliant
> so
> > this has not been an issue.
> >
> > So, we are in need of a client jar for ActiveMQ 5.x that supports JMS
> > 2.0. Is such a thing available? If so from where? I've been looking at
> > some JIRA tickets but I've failed to figure out the exact status of
> JMS2.0
> > together with ActiveMQ, Apollo, Artemis and what have you. I'm confused.
> > I believe the customer in question is running some fairly recent version
> > of ActiveMQ, I believe it was 5.10.x.
> > I don't think we have an appetite to rewrite our code just to land this
> > customer. The business case is probably not strong enough.
> > Perhaps I should emphasize that we're really only concerned with the
> > client side of things. The actual messaging infrastructure (I believe you
> > guys call them brokers?) is not our headache. As for the JMS 2.0 feature
> we
> > use we couldn't care less if this is something which is faked in the
> client
> > lib or if it's a native feature on the server side.
> >
> > Any recommendation on how to proceed ?
> >
> > Peter
> >
> >
> >
>
Re: Recommendation for vendor independent strategy
Posted by Tim Bain <tb...@alumni.duke.edu>.
I'm not aware of a plan to implement JMS 2.0 in ActiveMQ 5.x. I believe
Artemis implements JMS 2.0, but you'd have to convince your potential
customer to switch to it and it's not a simple drop-in replacement so they
might not be willing to do that just to use your "thingy."
I'm not aware of anyone who's "faked" a JMS 2.0 client JAR, but maybe
someone else is.
Tim
On Feb 29, 2016 2:21 PM, "Peter Hansson" <pe...@yahoo.com.invalid>
wrote:
> Hi there
> We've developed a "thingy" that integrates with various messaging
> architectures. So far - at the sites where we have deployed - we've had IBM
> MQ, Tibco Message Service and even a Wildlfy installation (HornetQ) at the
> other end. We've developed in Java and used JMS so we use exactly the same
> code against any of these and haven't actually cared to much about these
> messaging architectures at the other end of our software.
> Now we have customer that uses ActiveMQ and this is new to us.
> We have (without it being deliberate) developed against JMS 2.0 because we
> use async send. Frankly we haven't paid attention to this. It just so
> happens that the middleware we've met so far have been JMS 2.0 compliant so
> this has not been an issue.
>
> So, we are in need of a client jar for ActiveMQ 5.x that supports JMS
> 2.0. Is such a thing available? If so from where? I've been looking at
> some JIRA tickets but I've failed to figure out the exact status of JMS2.0
> together with ActiveMQ, Apollo, Artemis and what have you. I'm confused.
> I believe the customer in question is running some fairly recent version
> of ActiveMQ, I believe it was 5.10.x.
> I don't think we have an appetite to rewrite our code just to land this
> customer. The business case is probably not strong enough.
> Perhaps I should emphasize that we're really only concerned with the
> client side of things. The actual messaging infrastructure (I believe you
> guys call them brokers?) is not our headache. As for the JMS 2.0 feature we
> use we couldn't care less if this is something which is faked in the client
> lib or if it's a native feature on the server side.
>
> Any recommendation on how to proceed ?
>
> Peter
>
>
>