JMS/AMQP

[quipsy-karg]

Since several years, there finally is a vendor-neutral inter-MOM protocol called AMQP. Wouldn't it make sense to replace OpenMQ by Apache Qpid or a similar open AMQP implementation? That way, Java EE applications could utilize cloud MOM services provided by OpenStack, Azure etc. without getting modified. :-)

[smillidge]

Interesting idea, how would you envisage us implementing this? Would you like to access the AMQP implementation via the JMS api something like http://qpid.apache.org/components/jms/ or JCA?

[quipsy-karg]

I think for most existing applications it would be best to provide JMS, so EJBs don't have to get modified. It would be a drop-in replacement. But in fact I did not know that JCA and JMS are mutual exclusive: Isn't it possible to have a JCA package which provides JMS?

[dmatej]

I don't think it is a drop in replacement - Glassfish + OpenMQ supports clustering and it took years to resolve all usable scenarios, deadlocks and conflicts. As you now, clustering is much less tested and there were many errors, but the JMS now works. I can't imagine how much work it could be and if it would be so much better. Maybe yes, but it should be analysed and tested in some parallel development branch.

[smillidge]

@dmatej We definitely wouldn't replace OpenMQ.

@quipsy-karg JCA and JMS aren't mutually exclusive in fact access to other JMS providers is via JCA adapters, for example ActiveMQ is accessible from JMS within Payara by using the active-mq JCA adapter. I was wondering whether you wanted to support AMQP access via a library like qpid jms api or indirectly via creating a JCA adapter for AMQP that is then accessible via GlassFish JMS.

[smillidge]

In fact I just googled this http://qpid.apache.org/components/qpid-jca/ it may already be possible to use this JCA adapter to consume messages using MDBs

Experiment anyone?

[quipsy-karg]

Just to make clear, with "drop-in replacement" I did not want to say that any APQP broker will behave exactly the same as OpenMQ did. Instead I wanted to say that an application, which just needs to use some MOM, would be fine with APQP as it does not know of the specifics of OpenMQ anyways.

[abhirockzz]

Unable to deploy qpid jca rar to Payara (the same applies to GF 4.1.1 as well) qpid-jca-rar-depl-error.txt

[smillidge]

Looks like you will need to add in a glassfish specific deployment descriptor like the Jboss one. There is a GlassFish tm locator class in the source tree in the same package as the JBoss one.

[OndroMih]

@quipsy-karg, is this issue still relevant? Since what you propose can be achieved using a custom QPID JCA adapter, is there anything that needs to be changed in Payara Server to support it?

The QPID JCA adapter supports GlassFish 3 (https://qpid.apache.org/components/qpid-jca/index.html), hopefully the same thing applies to Payara Server. If there is a problem, let us know, but best option would be to raise an issue on QPID to support also GlassFish 4 / Payara

[quipsy-karg]

As I said in the original comment, this is just an enhancement request for the Payara bundle. So yes, this idea still is open for future improvement of the product. The essence of this issue is not that somebody should be able to add AMQP to Payara explicitly, but about replacing OpenMQ by QPID by default.

[OndroMih]

You can already replace OpenMQ by any custom JCA resource - it is only a matter of disabling OpenMQ in Payara and then you can deploy and configurre any JCA resource you like. There is a blog post on how to disable OpenMQ in Payara Server: http://blog.payara.fish/disabling-openmq-in-payara-server

[OndroMih]

But if you really mean to replace OpenMQ by QPID in a standard Payara installation, it is rather a strategic decision. In that case we will acknowledge the suggestion, but the decision will not be easy to do, as it would break current stock behavior. It requires that we have a working QPID JCA adapter first. Would you be willing to test the adapter with Payara Server and help us make it working if it doesn't?

[quipsy-karg]

My proposal is about finding a strategic decision in the next months or years to make the Payara open source project really fit for the cloud age by default.

The reason is that in the cloud age, two protocols are typically used for inter-microservice-communications: REST/HTTP and AMQP. As a JAX-RS expert group member and former Jersey contributor I know that Payara is perfectly fit for REST/HTTP already as it contains Jersey. But regarding AMQP I fear that sticking with OpenMQ as the default JMS provider and asking people to manually replace it, Payara will lose ground. AMQP is the de-facto MOM protocol in the cloud age, as it is vendor-neutral and technology-neutral, while OpenMQ's protocol is rather proprietary ("closed") and more or less Java-bound.

Certainly it would be most simple to just keep OpenMQ, but to enable it to run on AMQP by default. But I doubt this would be any kind of easy or less risky than replacing it by QPID. As QPID is part of e. g. OpenStack already, and is also JMS compliant, it should not be too tough to do the change. The question is whether Payara could come with OpenMQ in 'domain1' (= backwards compatibility) while providing experimental support for QPID in domain 'payara', or possibly in a new-to-define domain 'microservice'? That way, AMQP could get introduced slowly without breaking anything, given the existing GlassFish source code allows to bind different JMS implementations to a domain.

Yes, this will be a strong effort for the Payara community, but if Payara really aims for the cloud and for microservices, support for AMQP out of the box is a must-have.

In fact, I am willing to help with that, but my time is pretty scarce. So I doubt I can do much more than setting up a virtual environment and try out whether our rather complex enterprise application will run error-free on Payara/QPID in comparison to Payara/OpenMQ.

[OndroMih]

Your reasoning certainly makes sense and we'll investigate what we can do and how much effort wuuld be needed. It would be really helpful if you manage to set up Payara with QPID adapter and give us a guide how to do it or an example working project (ideally based on docker compose or vagrant or whatever you choose, to demonstrate all the required configuration).

Once we know how to integrate Payara and QPID, we may estimate better what is necessary to support the integration out of the box, and replace Open MQ with QPID in a long run.

[quipsy-karg]

Sounds good. I will l look into this later in 2017, as I am booked out with other stuff in the next months. Just keep this ticket open meanwhile. :-)

[OndroMih]

Thanks, @quipsy-karg. ActiveMQ also implements AMQP and we know that it works well with Payara Server. We'll also have to find out if there are no license conflicts in using either QPID or ActiveMQ, since both are Apache projects licensed under Apache v2.

[pdudits]

@OndrejM, on the other hand ActiveMQ doesn't implement JMS 2, so one needs to look in direction of Apache Artemis to get full Java EE 7 compliance.

Disclaimer: I use ActiveMQ, and I didn't try to use JMSContext with activemq-rar yet.

[OndroMih]

I don't know much about QPID, but it seems that there's only support for JMS 1.1 too.

[mikecroft]

Hi @quipsy-karg have you seen the new cloud connectors repository? The aim there is to, effectively, fulfill your earlier point:

finding a strategic decision in the next months or years to make the Payara open source project really fit for the cloud age by default.

The effect is that, rather than replacing the broker in Payara, we provide options for users who wish to connect to modern message brokers which may be outside the traditional Java ecosystem. We don't support AMQP yet (PRs always welcome ;) ) but it certainly could be in this way.

What are your thoughts on this approach as an alternative to switching the broker, given that it will allow you to use MDBs with modern messaging providers?

[quipsy-karg]

Cool project!

Anyways, to question still is open, whether it makes sense to replace the default broker shipped with Payara. Looking at what cloud services mostly do, APQP simply is the sole really open standard here. Certainly it is great to be able to manually add other providers to your app, but using the sole standard protocol should be the default – at least for Payara Microprofile.

-Markus

Von: Mike Croft [mailto:notifications@github.com] Gesendet: Mittwoch, 5. Juli 2017 10:18 An: payara/Payara Cc: Markus Karg; Mention Betreff: Re: [payara/Payara] JMS/AMQP (#553)

Hi @quipsy-karghttps://github.com/quipsy-karg have you seen the new cloud connectorshttps://github.com/payara/Cloud-Connectors repository? The aim there is to, effectively, fulfill your earlier point:

finding a strategic decision in the next months or years to make the Payara open source project really fit for the cloud age by default.

The effect is that, rather than replacing the broker in Payara, we provide options for users who wish to connect to modern message brokers which may be outside the traditional Java ecosystem. We don't support AMQP yet (PRs always welcome ;) ) but it certainly could be in this way.

What are your thoughts on this approach as an alternative to switching the broker, given that it will allow you to use MDBs with modern messaging providers?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/payara/Payara/issues/553#issuecomment-313034878, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADhBk264H-THKBfZyM9SNxbs_XOU0XG9ks5sK0a-gaJpZM4Gvr6g.

[mikecroft]

For Payara Micro and MicroProfile, we don't ship any broker and have only introduced support for JMS (and our JCA cloud connectors) in 172. I don't think we want to ship a broker with either because we'd rather not dictate what people use (for the same reason that you opened this issue!)

AMQP might be the sole open standard, but it's not universal. If we packaged QPid, then we aren't improving the situation, just changing a protocol. We would still be simply providing a broker that only a limited subset of people may use (even if that may be a majority). There's no telling how things will go in the future, so this allows us to make sure we can be as flexible as possible.

[mkarg]

You are right with all you say, but in one aspect I need to correct you: Replacing the protocol from native protocols to APQP effectively brings the freedom that publisher and subscriber do not need to agree upon one broker product. Also the application is unaware of the broker product. That's effectively the sense of APQP. That's why it is superior to any other provider, and why I asked to bundle it as a replacement for the completely proprietary current product.

[mikecroft]

I'm still not sure I follow the need for a broker to be packaged in to Payara Micro? Also, Apache QPid only supports JMS and AMQP, whereas ActiveMQ Artemis supports those plus MQTT, STOMP, OpenWire. If we chose Artemis, what would we do when another protocol is popular, would we replace the broker again? We need to support people who are happy working with what they already use as well as those who want to use something more modern, like SQS, and the right way to do that is by not enforcing a product on people.

[mkarg]

I do not say that we should add another provider to Payara Micro. What I suggest is:

• Payara Server (the Java EE compatible product) should provide APQP instead of a native protocol.
• The Payara Providers Collection should provide APQP besides the current protocols.

[OndroMih]

Unfortunately, we’re not able to fit this feature request into our current roadmap. I’m closing this issue. I hope you understand.