I'm evaluating options for my team's middleware. We really have a frankenstein'd setup. We're using Apache ServiceMix(Karaf/ActiveMQ/CXF), Websphere 8.5, ActiveMQ where we don't really need it, and all of our applications are not really coded to failover to another node if the primary goes down. We realized the issues of our setup and now want to improve.
We currently host bundles (not sure if they're all OSGI compliant) in a Karaf Container, which are used via ActiveMQ after being sent JMS messages via Apache Camel from Websphere.
My current idea is to kill off ActiveMQ, make all the camel routes towards HTTP (instead of JMS queues), and convert our data bundles/services to serve via HTTP through Apache CXF (replacing websphere for some things) and not ActiveMQ Queues/JMS. However, we have Websphere licenses, and I do know that it supports bundles in some way, I'm just not as familiar as to how it does (same nature as karaf)?
The main question is in the title, and I hope it's not too generic.
WebSphere 8.5 is a full OSGi container supporting Blueprint just as Karaf does.
You can, in theory, run your camel bundles or whatnot just as fine in WAS8.5. However, Apache Karaf is a lot more aligned towards running ActiveMQ/CXF/Camel stuff than WebSphere will ever be. Installation in Karaf is a few commands, where installation and configuration struggle in WAS85 for the Camel feauters and basic camel routes is .. well, a headace when I tried it last time. Others seems to have the same struggle.
I have rather good experience of running Camel apps inside WebSphere Application Server, but that was by embedding Camel in a standard WebApp, not using the OSGi stuff. So, embedded web apps is my recommendation for running Camel inside WebSphere.
For the "replace AMQ/JMS with HTTP" part. You are aware of that you are replacing pears with apples, right? JMS has a lot of features HTTP does not have (and some overhead compared to HTTP). For the sake of completeness, WebSphere also has a JMS provider built in. So if you have a large HA secured WebSphere infrastructure, the WebSphere (SIBus) provider might be a good choice. Otherwise, ActiveMQ rocks :-)
Related
Has anyone succeeded in creating a bridge between IBM MQSeries (MQS) and ActiveMQ Artemis 7.x (AMQ 7) so that the later can send messages to and receive from the first? Currently I have no problem bridging between MQS 7.5 and AMQ 6.3 by deploying a camel route and MQS libraries on the broker itself. However, the same way doesn't work anymore as each route deployment requires a broker reconfiguration and restart.
Thanks in advance for any feedback.
A few examples ship with ActiveMQ Artemis which might be helpful:
The "inter-broker-bridge" example in the examples/features/sub-modules/ directory. This example demonstrates how to deploy an instance of org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl to the broker using Spring in a web application.
The "camel" example in the examples/features/standard/ directory. This example demonstrates how to deploy a Camel route to the broker using Spring in a web application.
I can't speak to whether or not either of these can be updated at runtime as I've not actually attempted that. Both of these options should be able to move messages in either direction (i.e. from Artemis to MQS or from MQS to Artemis).
Another option would simply be to run Camel standalone and deploy your routes there. This would give you more flexibility as it would allow you to specifically choose the hardware where the routes run as well as how many resources the Camel JVM consumes. Running Camel routes directly on the broker, while convenient, isn't a great fit because the broker is a broker and not an application server.
To be clear, ActiveMQ Artemis and IBM MQSeries are not directly compatible with each other and are not expected to be. This true for most (if not all) JMS broker implementations. The role of components like the ActiveMQ Artemis JMS bridge and integration platforms like Camel are to solve the compatibility problem by using a common API to speak to both brokers - JMS in this case. Any broker which implements JMS can be integrated using these methods.
I have a functioning application using Spring Boot, Rabbit MQ & MySQL DB locally. I'm curious, how I can upload this app to the AWS Environment and get it working seamlessly.
The only part where I'm lost is how to get RabbitMQ in the cloud? Any suggestions?
I see three options for your needs :
Use AmazonMQ managed service. This uses ActiveMQ under the hood, and supports the AMQP protocol (so you can continue to use the RabbitMQ client). Here's an article on how to do it : https://aws.amazon.com/blogs/compute/migrating-from-rabbitmq-to-amazon-mq/.
Use a third-party managed service (such as CloudAMQP). This is similar to the first option, but you can choose a RabbitMQ provider if you wish.
Install RabbitMQ on an EC2 instance and manage it yourself. This is the most flexible option, but it will require more effort on your part and it will probably cost more. I would recommend this option only if you have special requirements that are not met by using a hosted service.
In all cases, I would also recommend to use a messaging library such as Spring Messaging or Apache Camel to isolate your code from your messaging implementation. This will reduce the boilerplate code you need for messaging and allows you to focus on your application logic.
I understand JMS spec allows me to write MDBs. Then I can deploy them on an appserver like websphere or jboss (and they have inbuilt implementation of JMS provider which is Java EE compliant). The question is when to use a full fledged product like IBM WebSphere MQ or ACtiveMQ instead of using App server's inbuilt JMS provider.
This appears to be a good reference to what you are asking, specific to IBM products but can be generalized to using an application server integrated messaging system vs a standalone messaging system - http://www.ibm.com/developerworks/websphere/library/techarticles/1109_wallis/1109_wallis.html
A built in JMS provider, such as WebSphere SI Bus, possibly others, are built for JMS messaging.
WebSphere MQ (MQSeries), ActiveMQ etc. have clients for multiple languages and are built for applications other than Application Server hosted applications to connect to it (C++, Java SE, Python, etc).
Say you want a local messaging server on the same physical server (or network?) as a non JavaEE application, you don't want to install a Java EE App Server, but want a stand alone messaging server instead (WebSphere MQ, Active MQ).
That said, ActiveMQ, for instance, is the messaging system inside Apache Geronimo. So there is overlapping here.
Then there is a whole discussion about management, clustering and security. Java EE messaging systems are pretty much optimized to follow the cluster layout of Java EE. In other deployment scenarios, the clustering might be optimal in other ways, such as cluster for different security zones. Also security models and management tools might be different in stand alone messagaing servers.
our needs for a queuing solution are fairly simple, a producer needs to put things in a persistent queue and these need to be handled by a consumer. The queuing systems needs to be integrated within a Spring application and distributed on multiple tomcat hosts.
When reading through questions i see a lot of people that warn about using ActiveMQ with Spring for example so i am wondering what the alternatives are when taking simplicity, scalability and performance in mind when combined with a Spring based application.
If you are already using Sping, then integrating ActiveMQ with it is fairly easy. The simplest solution would be to run ActiceMQ standalone and have your Tomcat applications simply communicate with it using Spring JMS (or AMQ client APIs)...
Another option is to use Apache Camel. It has great ActiveMQ support, can work with an external or embedded broker, adds many messaging/routing features and can be deployed standlone, in ActiveMQ or in Tomcat easily...good luck
We're looking at the choice between implementing an enterprise integration solution in either:
Spring/Spring Integration/JMS/Spring Web MVC
Websphere Application Server/MDB/Spring
What are the pros/cons?
Especially interested in what WAS/MDB solution is functionally better at.
Cheers
Paul
If the only thing you need in your entire project from the Java EE Specification is to get messages from a JMS provider, I suggest you to not use WebSphere App Server. Go with Tomcat+Basic Spring JMS Template. Simple, free, lightweight.
Websphere will bring a level of complexity you don't need. Stay away from heavy weight app server. But if you need more fancy Transaction management ( XA between JMS and a DB) then get a real Java EE App Server.