I'm newbie in Apache Camel, so please forgive me for the stupid question.
I am browsing examples of sending messages using multicast and I don't understand it.
I know that (in the network layer) multicast source sends datagram to specified address from range 224.0.0.0 to 239.255.255.255, to subscribers, but multicast source "does not know" how many subscribers are, only one datagram is sent for anyone of subscribers .
I do not understand either the example from the documentation (https://camel.apache.org/components/latest/eips/multicast-eip.html#_multicast_example) or from here (https://www.javarticles.com/2015/05/apache-camel-multicast-examples.html).
Why (if I understood correctly) the subscribers of the message are explicitly specified ("direct: a", "direct: b", "direct: c")?
After all, in one moment there may be 3 of them, in another time 10 of them, and so on. I don't think I need to change the code and define e.g. "direct:10", am I right?
Does the Apache Camel multicast mean something different than the one from the network layer?
Yes its not the same. Multicast EIP is a way of sending a message to N recipients at the same time (where the number of recipient is fixed/known ahead of time).
yes, you correctly understand that there is difference between network layer multicast and apache camel multicast.
The use case for camel multicast is when you want to send same message to the multiple endpoints. So in example from docs:
from("direct:a").multicast().to("direct:x", "direct:y", "direct:z");
The same message from "direct:a" will be send to all three endpoints. And the number of "destination" endpoints is defined for each route and could be different for different routes.
Note that in case of:
from("direct:a").to("direct:x").to("direct:y")
You are chaining processing of the messages. The result from the "direct:a" will be send to "direct:x" and the result from "direct:x" will be send to "direct:y", so "direct:y" could get different message as "direct:x".
Related
I have an AMQ queue I'm connecting to. The publisher is sending JMS TextMessage. The messages are of different types: foo-updated, bar-updated, baz-updated etc, all on the single queue.
The payload/message body is JSON for all types, and their schemas have significant overlap (but no direct type information).
The publishing team said "search the string/text of the message for foo, and if it's there, it's a foo-updated message".
That sounds wrong.
There may be header information in the JMS message I can use (I'm exploring that), but assuming I can influence (but not necessarily change anything), what's the best way to handle this ?
If you have influence over using JMS topics, you should use that. Just like REST URLs you could use topics to indicate resources and actions on those: foo/create, foo/update, bar/update
Then the JMS Broker can help you to efficiently route different messages to difference consumers. E.g. one consumer subscribing to foo/* another to */update
If you are stuck with a queue, the publisher should add additional information as header properties, for example type=foo and action=update. Then your consumer can specify JMS selectors like "action = 'update'" to receive only some of the messages.
Otherwise you are actually stuck with looking into the content :-(
Use JMS Message Selectors
See: Message Selectors
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'd like to understand what exactly is the difference between the two Enterprise Integration Patterns
Content-Based Router
Message Router
The definition at camel documentation is suggestive that Content-Based router is a special case of Message Router. They why list them separately?
Actually "Message Router" is one of the "Basic Messaging Concepts". List of such basic messaging concepts is:
Channel - Messaging applications transmit data through a Message Channel, a virtual pipe that connects a sender to a receiver.
Message - A Message is an atomic packet of data that can be transmitted on a channel.
Multi-step delivery - Set of actions often need to be performed on the message after it is sent by its original sender but before it is received by its final receiver.
Routing - In a large enterprise with numerous applications and channels to connect them, a message may have to go through several channels to reach its final destination. The route a message must follow may be so complex that the original sender does not know what channel will get the message to the final receiver. Instead, the original sender sends the message to a Message Router.
Transformation - Various applications may not agree on the format for the same conceptual data; the sender formats the message one way, yet the receiver expects it to be formatted another way.
Endpoint - An application does not have some built-in capability to interface with a messaging system. Rather, it must contain a layer of code that knows both how the application works and how the messaging system works, bridging the two so that they work together.
"Content Based Router" is one of the "Message Routers" and there are a lot of different other Message Routers available like "Message Filter", "Splitter", "Aggregator", "Recipient list" etc.
I suggest reading a book that used by camel so all such points will be more clear:
https://www.amazon.com/o/asin/0321200683/ref=nosim/enterpriseint-20
As far as I understand the patterns Message Router only applies when the input and output is a queue or topic of a messaging system.
Content-based Router is not limited to messaging. I think you can say that inside a Message Router you have a Content-based router that decides which way to go.
In camel the decision is made using the choice() element.
If my assumption is correct then the documentation of the Message-Router at camel is wrong as it does not reflect the queues. I will check with the camel dev list and correct the wiki page if we agree on this.
I am developing an sms gateway using jsmpp library.
This is my scenario.
I bind to the SMSC(telecoms company) on 2 connections and receive messages on 2 shortcodes, say 30002 and 30003 , assigned to me by the SMSC.
Then, third party binders(companies involved in bulk sms push) who normally should bind directly to the SMSC bind to my gateway via SMPP connections to my SMPP server(which serves as an SMSC of sorts to them)
The third party binder sends messages to the SMPP server and I capture this messages, queue them and send them to the main SMSC(telecoms company).
The telecoms company then responds with delivery reports and messages from the bulk message reports and other data which I forward to the third party binders.
This scenario has worked well for when I have only 1 third party binder.
But now we want to handle a more general case where we have many third party binders.
Since I have only 2 short codes available on which the SMSC forwards messages to me, how do I know which of the third party binders owns the SMSC response?
I have the unsavoury and inefficient option of forwarding the responses to all connected third parties.
The only other option apart from the above is to get a different short code from the SMSC for each third party binder, which is not cost efficient for my scenario.
First of all, you can pretty easily forward all DLRs to the correct third parties. In order to do so, you will have to store some extra data in a database of your choice (if you only have 1 application node and low traffic, even SQLite will suffice; otherwise look towards some NoSQL solution):
Every time you receive a submit_sm_resp packet from telecom SMSC, start storing a pair (key-value, actually) message_id -> third_party_id.
Every time you receive a deliver_sm packet from SMSC, retrieve the message_id from the packet, then look for this message_id in your DB to find which third party to forward it to.
Consider removing the message_id -> third_party_id pair after you have successfully forwarded the final DLR for that message_id.
The situation is a lot worse with the MO messages. The only possible (but nonetheless very bad) way of using a single shortcode for multiple clients (third parties) is having a fragile combination of TTLs and timeouts on you data. It also only makes sense when every MO that you expect is a reply to a previous MT message.
Separate incoming MTs that need reply from the receiver using TLV or extra SMPP links. Let us call those MTs Questions.
Handle Questions something like this:
Handle MO messages (Answers) like this:
UPD. Text elaboration
In order to know the correct third party for MO message (not delivery report) you need some additional info about who the message is addressed to. This info might originate from either the third party or the subscriber (one who has initiated the MO message in the first place). My diagrams formally describe the case where the third party gives you this information.
A third party sends you an MT message that they expect to be Answered by the recipient.
You make a note in the database, that if the recipient sends you an MO message in the next N minutes, then this Answer should be forwarded to the aforementioned third party.
I apologise that my answer is not specific to jsmpp but I have little knowledge of this library, however, I also believe it should be fairly easy to implement an algorithm once you understood it regardless of your instrument.
so I have been following this tutorial: http://www.rabbitmq.com/tutorials/tutorial-six-java.html, but I cant get it to work with a direct exchange.
Can someone help me out please by modifying the code so that it works with a direct exchange.
My objective: the user can chose which machine to send to, When they choose i want to bind to that machine and just send it to that machine. But it doesn't seem to be working when i change the queue declare to exchange declare. Any help would be greatly appriciated!!!
Thanks
In RabbitMQ you publish messages to exchanges, so the code you are seeing in the tutorial: channel.basicPublish("", "rpc_queue", props, message.getBytes());, means: send a message to the exchange "", using routing key "rpc_queue". That's the default or anon exchange discussed in tutorial one.
So if you want to send a message to a direct exchange, just change the empty exchange name for your exchange name.
Now, why do you want to do it that way? Why can't you instead of declaring an "rpc_queue", you declare a queue per machine, and address them by their names, in basicPublish?
I'm writing an application server that will receive SIP and DNS messages from the network.
When I receive a message from the network, I understand from the documentation that at first, I get a ChannelBuffer. I would like to determine which kind of message has been received (SIP or DNS) and to decode it.
To determine the message type, I can dedicate port to each type of message, but I would be interested to know if there exist another solution for that. My question is more about how to decode the ChannelBuffer.
Is there a ChannelHandler provided by Netty to decode SIP or DNS messages? If not, what would be the right place in the type hierarchy to write my custom ChannelHandler?
To illustrate my question, let's take as example the HttpRequestDecoder, the hierarchy is:
java.lang.Object
org.jboss.netty.channel.SimpleChannelUpstreamHandler
org.jboss.netty.handler.codec.frame.FrameDecoder
org.jboss.netty.handler.codec.replay.ReplayingDecoder<HttpMessageDecoder.State>
org.jboss.netty.handler.codec.http.HttpMessageDecoder
org.jboss.netty.handler.codec.http.HttpRequestDecoder
Also, do I need to use two different ChannelHandler for decoding and encoding, or is there a possibility to use a single ChannelHandler for both?
Thanks
If you really have a requirement for port unification (an example here), i.e. receiving different protocols on the same port, then you would have to detect the protocol in a handler and take appropriate actions. Could be as simple as inserting different handlers in the pipe line.
However, I find it very improbable that SIP and DNS would share the same port, hence no need to complicate matters.
I haven't seen a SIP decoder/encoder for Netty, but depending on what you want to do with the message, the HTTP decoder is a a very good starting point (and could be made simpler since chunking is not supported in SIP).
I would strongly recommend not to try to combine DNS and SIP decoding in one handler (or any other combination for that matter). Keep the handlers as simple and coherent as possible. Combine handlers instead, if needed.