I'm currently pondering how to best solve the following problem with Camel, and potentially ActiveMQ.
Data needs to be moved from a DB-table in Application A to a JMS Queue in Application B.
1) Create a stand-alone camel route, that fetches data from the DB-table, converts the relavent data to JMS message and sends it to the JMS queue in Application B.
Pros: Simplicity
Cons: Tight coupling between applications
2) Deploy an ActiveMQ instance, and create two separate camel routes inside the ActiveMQ instance. One route fetches data from the DB and puts is in an AMQ queue, and the second routes fetches data from the AMQ and pushes it to the JMS queue.
Pros: Loose coupling, more scalable
Cons: Additional components, More complex architecture to maintain
Which of the following two alternatives would you choose and why?
I know what I'm leaning towards, but I won't tell you yet :-)
Generally, we use apache camel to reduce the pain and complexity of enterprise integration. So if you can take data through a route from A to B in 10 or so lines of camel DSL - why not?
To me, I see more complexity in Alternative 2. Is there a reason you have in mind for using ActiveMQ?
Most often, you would use a custom ActiveMQ when you want some sort of guaranteed message delivery - but since application B has a JMS queue I doubt you really need ActiveMQ. There's a lot of headache in setting it up, maintaining it, and so forth.
With regards to coupling, I don't see that as a big issue. You are integrating between A and B, so there is bound to be some coupling. Your camel routes will need to know about the jpa / domain object format from Application A and the message format for Application B, in any case.
Performance wise, there is nothing to stop you solving performance problems in Alternative 1 via camel patterns for concurrent consumers, seda queues and the like.
Conclusion: I would go with simplicity (Alt 1), unless you have a specific and compelling reason to want to use ActiveMQ. Was that what you were thinking? ;)
Related
Spring + Apache Kafka noob here. I'm wondering if its advisable to run a single Spring Boot application that handles both producing messages as well as consuming messages.
A lot of the applications I've seen using Kafka lately usually have one separate application send/emit the message to a Kafka topic, and another one that consumes/processes the message from that topic. For larger applications, I can see a case for separate producer and consumer applications, but what about smaller ones?
For example: I'm a simple app that processes HTTP requests => send requests to a third party service, but to ensure retryability, I put the request on a Kafka queue with a service using the #Retryable annotation?
And what other considerations might come into play since it would be on the Spring framework?
Note: As your question states, what'll say is more of an advice based on my beliefs and experience rather than some absolute truth written in stone.
Your use case seems more like a proxy than an actual application with business logic. You should make sure that making this an asynchronous service makes sense - maybe it's good enough to simply hold the connection until you get a response from the 3p, and let your client handle retries if you get an error - of course, you can also retry until some timeout.
This would avoid common asynchronous issues such as making your client need to poll or have a webhook in order to get a result, or making sure a record still makes sense to be processed after a lot of time has elapsed after an outage or a high consumer lag.
If your client doesn't care about the result as long as it gets done, and you don't expect high-throughput on either side, a single Spring Boot application should be enough for handling both producer and consumer sides - while also keeping it simple.
If you do expect high throughput, I'd look into building a WebFlux based application with the reactor-kafka library - high throughput proxies are an excellent use case for reactive applications.
Another option would be having a simple serverless function that handles the http requests and produces the records, and a standard Spring Boot application to consume them.
TBH, I don't see a use case where having two full-fledged java applications to handle a proxy duty would pay off, unless maybe you have a really sound infrastructure to easily manage them that it doesn't make a difference having two applications instead of one and using more resources is not an issue.
Actually, if you expect really high traffic and a serverless function wouldn't work, or maybe you want to stick to Java-based solutions, then you could have a simple WebFlux-based application to handle the http requests and send the messages, and a standard Spring Boot or another WebFlux application to handle consumption. This way you'd be able to scale up the former in order to accommodate the high traffic, and independently scale the later in correspondence with your performance requirements.
As for the retry part, if you stick to non-reactive Spring Kafka applications, you might want to look into the non-blocking retries feature from Spring Kafka. This will enable your consumer application to process other records while waiting to retry a failed one - the #Retryable approach is deprecated in favor of DefaultErrorHandler and both will block consumption while waiting.
Note that with that you lose ordering guarantees, so use it only if the order the requests are processed is not important.
We are creating new application, which is going to use IBM's MQ as a JMS provider for a short term and switch to Tibco EMS within a year.
My question is how involving the changes would be from the Application code perspective.
So far reading from JMS documentation, my impression is it should only require minimal changes. Does anyone have experience with it and provide some input on the work involved in switching between JMS provider.
I've done POCs where I swapped out connection factories and used WMQ JMS Classes to send to various providers (TIBCO, ActiveMQ, etc), to prove out the interchangeability. I've also done full swaps from one vendors JMS to another. In theory, it should be very simple.
The biggest change will be with the connection factories. Everything JMS specific will be the same between providers. The more tightly coupled the code is to the connection factories, the more complex it will be to change the app itself. Outside of this, you may need to change vendor specific implementation of objects, such as MQQueue vs Queue.
One addition thing to keep in mid is dependent on the IBM endpoints. If you are using "target queue managers" on any producers, these will need to change. WMQ has a specific URI to reach queues on specific Queue Managers in a cluster ( "queue://target_qm/queue_name/" ). If any application uses this URI it will need to ensure it makes the proper changes here as well.
Please consider the scenario as shown in the attached image :
The Portal(producer) will send some message to the bus to which has to be processed by multiple applications(consumer) – PAYROLLAPP, HELPDESK etc.
Multiple instances of consumer applications may be running, also these instances can be added/
removed dynamically
Now, it is critical to ensure that message is processed only once, per application i.e if
PAYROLLAPP -1 processes the message, PAYROLLAPP -2 should NOT process it; of course, in the
above diagram, HELPDESK – 1 must process it. In short, in case of multiple instances, exactly one
must process the message, once
When I searched for answers, most of the stuff was about creating a 'selective consumer' - a consumer that accepts/rejects a message based on some logic - please note that no changes/additions/wrapping can be done for the applications shown in the diagram; the logic has to reside somewhere in the provider that manages the bus
Please guide about the same.
Adding more details after Petter's answer :
The items to the to the left of the left-dotted line are the 'approaches' - Pure JMS,ESB,EAI
The items to the to the right of the right-dotted line are the 'implementations'
Now, the big part - QUERIES :
Irrespective of the solution(pure JMS, ESB, EAI), does the part
below the horizontal dotted line(application-specific queues) needs
to be implemented?
How does the usage of ESB(JBoss ESB etc.), instead of ‘pure’ JMS(Active MQ etc.), help/
hamper? Does ESB provide any advantage over JMS which is ‘java-only’(?). I am hell confused
– ‘ESB or JMS’, even after referring threads like these : JMS and ESB - how they are related?.
It has one reply which says “JMS is not well suited
for the integration of REST services, File systems, S/FTP, Email, Hessian, SOAP etc. which are
better handled with an ESB that supports these types natively. For example, if you have a process
that dumps a CSV file of 500MB at midnight, and you want another system to pickup the file,
parse CSV and import into a database, this can easily be accomplished by an ESB - whereas a
solution with just JMS will be bad. Similarly, integration of REST services, with load balancing/
failover to multiple backend instances can be done better with an ESB supporting HTTP/S
natively.” It only added to my confusion !!!
Is the usage of EAI framework (Apache Camel etc.) an approach entirely different from the pure
JMS or ESB approach? If yes, how and what are the pros/cons?
I was told that ESB alone won’t help, BPM(or something else?) needs to be used to define and
store the ‘routing’ logic – is this true?
I see the point. This might be a bit tricky with "pure" JMS.
What you essentially want to do is to let the portal publish messages to a topic, but not let the PAYROLLAPPs subscribe to that topic (since all of them would get a copy of the message). So what you would need is some logic in between that distributes the message from the topic subscription to one queue per application type. From that queue, normal load balanced (the competing consumer pattern) can be implemented with JMS.
Different JMS providers have special implementations that can acomplish this task
ActiveMQ has its Virtual Destinations, WebSphere MQ has its server side subscriptions that can subscribe from a topic to a queue. In the case your JMS provider does not have any way to handle this, you might want to look at adding some routing middleware to your topology. Apache Camel is a nice, lightweight one, but there are lots of others that can setup some routing in the middle without affecting the real applications.
Update for detailed questions
The Queues below the line has to be there for sure (if your applications uses messaging). The "Some distrib. logic" box shouldn't be needed. The "Some routing logic" box could be an ESB or in this very case, be implemented in the messaging server, for instance ActiveMQ with virtual destinations (or WebSphere MQ or perhaps RabbitMQ among others).
There are a lot of buzwords in the domain of integration. Simplified (depending on who you ask - ESB can also be seen as an architectural pattern, but let's keep it simple), an ESB is a server application (or a topology of multiple servers in practice) that is a centerpiece of an integration landscape. The ESB server simply contain logic and small message flows that takes messages (files, or whatever) from one application and routes them to many applications, transform them to other formats, encrypts, converts from one transport protocol such as HTTP/SOAP to File etc.
JMS is a rather confusing and missused word. Java has to some extent dominated the enterprise messaging domain in the last years, so JMS is sometimes used pretty much as a synonym to Messaging. However, Messaging, (or message queueing, asynchronous messaging, MOM=message oriented middleware, etc.) is to be simply considered as a family of similar transport protocols that features a central relaying server. Is is not at all a Java only thing. Many successful ESBs setups I worked with actually leverage on a Messaging backbone
In your situation, I would not go too deep into the academical/philosophical differences between ESB and EAI software. They will most likely do pretty much the same things for you. Instead, look at the hard facts such as price, support, resource footprint, monitoring, tech. features, learning curve etc. Be it Camel/ServiceMix, Mule, JBoss ESB, Microsoft BizTalk, IBM Message Broker, Tibco etc.
Hah! Was it perhaps a salesman? An ESB will do just fine. A Messaging server will do in your case as well, such as ActiveMQ as has been pointed out already. BPM suits are fine for orchestrating semi-automatized business processes or if there is major business logic in the integration layer. Otherwise, avoid that added complexity.
Irrespective of the solution(pure JMS, ESB, EAI), does the part below the horizontal dotted line(application-specific queues) needs to be implemented?
The consumers need to be implemented in such a way that work with you chosen solution but you shouldn't have to worry about the creation of the queue per consumer or the distribution logic (assuming that the consumers can consume directly from the chosen tech)
How does the usage of ESB(JBoss ESB etc.), instead of ‘pure’ JMS(Active MQ etc.), help/ hamper? Does ESB provide any advantage over JMS which is ‘java-only’(?). I am hell confused – ‘ESB or JMS’, even after referring threads like these : JMS and ESB - how they are related?. It has one reply which says “JMS is not well suited for the integration of REST services, File systems, S/FTP, Email, Hessian, SOAP etc. which are better handled with an ESB that supports these types natively. For example, if you have a process that dumps a CSV file of 500MB at midnight, and you want another system to pickup the file, parse CSV and import into a database, this can easily be accomplished by an ESB - whereas a solution with just JMS will be bad. Similarly, integration of REST services, with load balancing/ failover to multiple backend instances can be done better with an ESB supporting HTTP/S natively.” It only added to my confusion !!!
My opinion is that ESB would overcomplicate this solution. It's designed (amongst other things) to assist integration with different technologies, but simpler solutions do this too - e.g - Apache Camel provides a very easy way of communicating using a huge variety of transports (including ActiveMQ).
Not all JMS implementations cater for connectivity from other languages, but ActiveMQ does using it's STOMP connector.
Is the usage of EAI framework (Apache Camel etc.) an approach entirely different from the pure JMS or ESB approach? If yes, how and what are the pros/cons?
Apache Camel and JMS are complementary technologies, as are JMS and ESB. Camel (& Spring Integration) are lightweight, simple and portable. ESB's are much more heavyweight and will normally lead to greater coupling with the ESB/application server.
I was told that ESB alone won’t help, BPM(or something else?) needs to be used to define and store the ‘routing’ logic – is this true?
It depends what your 'routing' logic is, it looks to me like you don't require routing logic, you just require guaranteed delivery to 1payroll consumer and 1 helpdesk consumer. BPM would be more useful where you want to selectively public data/invoke a service based on some characteristic of that data.
I strongly suggest reading http://activemq.apache.org/virtual-destinations.html, using these you would:
Send messages to the ActiveMQ broker, onto a VirtualTopic, e.g. VirtualTopic.X
Register the Payroll and Helpdesk consumers, as consumers on queues that ActiveMQ dynamically creates on the topic - e.g. Consumer.Payroll.VirtualTopic.X. Both Payroll consumers should be registered with the same string.
ActiveMQ will automatically retain a marker that represents what each set of consumers hasn't consumed. This means that 100% of messages will be processed by a Payroll consumer but a message will never be sent to > 1 payroll consumer.
Add/remove consumers at will.
N.B.I believe that other products, e.g. Apache QPID provide similar functionality - I'm just most aware of ActiveMQ, and have had success with this approach
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
For me JMS and ESB seem to be very related things and I'm trying to understand how exactly they are related.
I've seen a sentence that JMS can be used as a transport for ESB - then what else except the transport should be present in such an ESB? Is JMS a simple ESB or if not, then what it lacks from the real ESB?
JMS offers a set of APIs for messaging: put a message on a queue, someone else, sometime later, perhaps geographically far away takes the message off the queue and processes it. We have decoupled in time and location of the message provider and consumer. Even if the message consumer happens to be down for a time we can keep producing messages.
JMS also offers a publish/subscribe capability where the producer puts the message to a "topic" and any interested parties can subscribe to that topic, receiving messages as and when they are produced, but for the moment focus just on the queue capabilty.
We have decoupled some aspects of the relationship between provider and consumer. However some coupling remains. First, as things stand every message is processed in the same way. Suppose we want to introduce different kinds of processing for different kinds of messages:
if ( message.customer.type == Platinum )
do something special
Obviously we can write code like that, but an alternative would be to have a messaging system that can send different messages to different places we set up three queues:
Request Queue, the producer(s) puts their requests here
Platinum Queue, platinum consumer processing reads from here
Standard Queue, a standard consumer reads messages from here
And then all we need is a little bit of cleverness in the queue system itself to transfer then messsage from the Request Queue to the Platinum Queue or Standard Queue.
So this is a Content-Based Routing capability, and is something that an ESB provides. Note that the ESB uses the fundamental Queueing capabilities offered by JMS.
A second kind of couppling is that the consumer and producer must agree about the message format. In simple cases that's fine. But when you start to have many producers all putting message to the same queue you start to hit versioning problems. New message formats are introduced but you don't want to change all the existing providers.
Request Version 1 Queue Existing providers write here
Request Version 2 Queue New provider write here, New Consumer Reads here
And the ESB picks up the Version 1 Queue messages and transforms them into Version 2 messages and puts them onto the Version 2 queue.
Message transformation is another possible ESB capability.
Have a look at ESB products, see what they can do. As I work for IBM, I'm most familiar with WebSphere ESB
I would say ESB is like a facade into a number of protocals....JMS being one of them.
An addition to the above list is the latest Open Source ESB - UltraESB
JMS is not well suited for the integration of REST services, File systems, S/FTP, Email, Hessian, SOAP etc. which are better handled with an ESB that supports these types natively. For example, if you have a process that dumps a CSV file of 500MB at midnight, and you want another system to pickup the file, parse CSV and import into a database, this can easily be accomplished by an ESB - whereas a solution with just JMS will be bad. Similarly, integration of REST services, with load balancing/failover to multiple backend instances can be done better with an ESB supporting HTTP/S natively.
This Transformation does not happen automatically. You need to configure the mapping or write transformation service
Look at https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_SOA_Platform/4.2/html/SOA_ESB_Message_Transformation_Guide/ch02s03.html
Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com
ESB offers integration with a lot of different protocols in addition to JMS.
Most use JMS behind the scenes to transfer, stor and move messages. One such solution OpenESB, uses XML format messages.
There are open source ESB which you could checkout -
OpenESB
Apache Camel
MuleESB
WSO2 ESB
JMS implementation like ActiveMQ come with Camel inbuilt into them.
JMS is a protocol for communicating with an underlying messaging layer. ESB operates at a higher level, offering integration with multiple technologies and protocols, one of which would be JMS, in a uniform way that makes management of complex flows much simpler.
There are JMS message brokers , that you can easily configure with ESB. https://docs.wso2.com/display/ESB470/JMS+Transport
JMS and ESB both provide a way of communication between different applications. But the context for JMS and ESB are different. JMS is for simple need. JMS is implemented by JMS Provider. It is Java specific.
Examples of JMS Providers are: Apache Active MQ, IBM MQ, HornetQ etc.
ESB is for complex need. ESB is a component in EAI providing communication facility to various applications. It is generic & not specific to Java. JMS is one of the supported protocols.
Examples of ESB provider are: MuleESB, Apache Camel, OpenESB
Use Case: It may be an overhead to use ESB, if all our communicating applications are in Java and are using the same message format. Here JMS may be sufficient.