Swift has very advanced federation features.
What I hope for is to have at least some minimal federation features kinda like MQSeries has.
Like I said in an earlier post:
The main thing we need is a router process. When the server got a message that needs to go to some other node in the federation, it dumps the message in the router's queue.
The router process picks up the message looks at routing configuration and dumps the message to the right queue that a channel is working on. A channel is nothing more than a process that moves messages from one node in the federation to another node.
Most of the work will NOT be in the JBossMQ core. It will be in the router and channel processes.
Ofcourse all those processes would just be MBeans running in the JBoss server.
I'm not familiar with the MQSeries federation support, but I like the idea of a router process. In order for federation to be supported the idea of how the JBossMQ core is used would have to change a bit. Correct me if I'm wrong but the router would now have to be the access point into the JBossMQ core. It would then proxy the messages to relevant destinations. Modules could then be developed for the router which would add some of the advanced features found in Swift.
I don't think that every feature needs to be present in jboss at once, but that incremental development is good and we should have a goal to strive for. IMHO the type of router support available in Swift should be close to that goal (along with suggestions from the user base and developers).
Hi, sorry if I am a pain in the ass, but what good are the routing for.
1. Clustering and HA I understand. That is good, access to a destination becomes transparent.
2. Routing for true PTP I understand (such as jabber or mail).
But why route JMS? Is it through firewalls or what? Why can't the client send directly to the destination he want't to reach. OK, I can see your answer comming: configurability. A client has a connection to is motherserver, but it is not shure for all future that the mother server will handle all destinations. Fine: do the JNDI trick - just put up NNS or other tricks in JNDI to get the client directed to the correct instance.
So, explain to me ;-)
By the way, I think it will be pretty easy to plug in a router sender in the new architectur (wich I hope to commit to morrow).
Here are my opinions on the matter, of course other are free to comment as well. I believe that routing in JMS yields similar gains as routing in P2P.
1. Configurability. No matter how the end result is implemented I think many would agree that the less configuration that has to be maintained the better. Especially if you have a large group of clients and somewhat dynamic server resources.
2. Stability. Dynamically routed networks are generally easier to transparently heal than static P2P.
3. Fun stuff. The feature adds. Routing based on load, based on system capability, based on importance are easier implemented on the servers than having to be maintained on each client.
4. Network topology. In some settings there may be a difference in network topology. A firewall, or other situation may prevent the transparent redirection of clients. Or the routers may be able to communicate with each other faster than client->router communication. Take the situation where a few routers are dual homed on a 100MB and 1G network. Many clients could communicate with the routers via their std. 100MB interfaces and the company could configure a few routers to communicate via GigE. Some routers may also be able to transparently act as bridges say to a Swift or MQSeries resource.
Now having routers still doesn't fix every problem. There is still a single point of failure, namely the connection to your mother router. Now if routers were light weight enough you could run a small router on each client. But this goes against part of pro 3. I think it might be nice to have a hybrid approach. Have a typical routed network, but do some JNDI magic as well so that if the mother router goes down a client can connect to another mother. Sure one could just keep a small list of available mother routers on each client, but I'm trying to keep the client config to a minimum.
Those are my thoughts. What do other people think? What features would they like to see in JMS Federation (since the term itself could mean a lot of things)?
One question that comes up is what wire-protocol should we use between routers? One thought I had that would make this all fit very tightly into the current JMX based model would be to require that the RMI management adaptor be present for JMS Federation support, then simply do all routing via that adaptor. So a router that wants to connect to another router would simply create a RMI connection to the remote MBean Server, and request the JMSRoutingMBean.
a lot of god reason, and I won't debate you on them. You have an itch, and you scratch it. Open source...
More generally I do however think that JBossMQ would be in more need of a cluster/HA solution right now and that the parts of the routing stuff that speeks to me most are the ha stuff. To install JBossMQ in enterprise solution is not that easy today, since you can't argue againt the "single point of failure" you will have with it.
I would also perhaps question the p2p argument when it commes to JMS, but that since I really do not view it as the best way to create p2p networks. For instance - and it is stated clear on JMS at SUN - it is designed for intranet solutions. Yes, you can use it to traverse firewalls and such, but only by using provider specific features.
Again, I will not argue agains someone willing to take the time to create routing support into JBoss, since it might come handy if we want to make JBossMQ into a more generall messaging solution (JAXM, XML, JavaSpace personality, Jabber). But that on my large wishlist ;-)
I guess I was using p2p to mean more point 2 point rather than implying a lot of personal communication. Anyway, I realize that what I'm proposing is rather grand and that it would be great of jboss had some form of JMS Federation now (whether it be routing or not).
Now I'm not familiar with HA (what does this mean?). Peter, what from of clustering would you suggest for JMS resources? How would this fit into the clustering already used within jboss?
I'm still in the learning phase when it comes to JMX, but my feeling would be that the routers should intercommunicate via whatever mechanism they're natively using. So a JMS router would use JMS to communicate between other routers.
Now correct me if I'm wrong, but all that would need to be done to achieve this would be to develop a JMS adapter to the MBean Server. From what I understand this should be a fairly simple task.
Of course the more I talk, the more this may be *my* fairly simple task. ;)
I guess you're right. One router could look up a QueueConnectionFactory on another router, then create a QueueConnection and start exchanging messages that way...
That's kind of what I figure. We'll have to ship with a default sys Queue or something that would have to exist in order for these features to work. In all it should be doable. I think. Juha and Marc's JMX book just arrived... ;)
After more thought, I think I still like the JMX idea better. If we used JMS we'd have support some sort of protocol language within the messages. It could be XML based or Object based, but never the less, we've have to have a message listener on one side listening for messages and processing the results. With JMX and the RMI adaptor, we'd just create a connection to a remote MBeanServer and start calling methods...
I don't have a problem with using JMX, the more I read about it the more I think it's a pretty nice architecture. One of the beauties of JMX is that you can write your MBean once and then use any number of protocol adapters and connectors to access the MBean over the network.
Now you're right, functionally no matter what adapter we use we'll still be able to access the MBean. There just seems pureness to using a JMS connector when communicating between JMS servers. Sure the connector will have to set up a message listener, but this is symantically similar to setting up an RMIRegistry which your RMI adapter would have to use. In addition, with a JMS connector communication could be asynchronous and distributed via Topics, traits that could potentially be very useful.
As for the protocol language, this would be very simple. The connector itself doesn't have to understand the nature of the messages being sent to the server. It just needs to encapsulate the method call being invoked on the MBeanServer. This encapsulation can be XML, Object or whatever based, but it will still be the encapsulation of a single method call.
In the end it will feel to the user that we're just using JMX and the JMS adapter to create a connection to a remote MBeanServer and start calling methods. It also gives us added leverage in that if someone needed to, they could also develop out of band utilities which would use JMS, but that wouldn't need to use JMX or our JMX adapter (client side anyway).
I'm currently picking out a third-party JMS system to integrate with JBoss in order to get message routing; I think I can shed a little light here.
A major benefit of store-and-forward message routing is that it lets you send a message to a queue on another server, even if that server isn't reachable.
In our configuration, we have about a dozen servers spread around a WAN. In the course of using a web application on one of these servers, a user could request that data managed by another server be processed. Processing could take hours, so it's asynchronous anyway.
With message routing, the message is first stored on the local app server. The JMS system takes care of forwarding it to the remote server, even if it happens to be inaccessible or down when the request is generated. Also, queues and topics are reachable from anywhere on the network.
I'm not sure if this is what you meant by "true PTP," but it is just about exactly like mail: the JMS routers act like sendmail+IMAP, letting local clients send messages whether or not the rest of the world is connected and providing a global address space.
I did consider jury-rigging routing at the application level, using the JMS API, but this has a few major drawbacks. First, if you set the JMSReplyTo header in the original message, its value is meaningless once the message has been delivered to the remote system. Also, the message identity is lost: the message received by the queue processor is not the same message sent by the web app, having a different message ID and timestamp.
To avoid those problems, routing has to be part of the JMS provider itself.
P.S. I'm leaning toward SwiftMQ. Any success stories out there with JBoss and SwiftMQ? The MDB integration etc. is certainly encouraging.
Yah, what your talking about is what is so very cool about SwiftMQ. It, in my opinion, does it better then anyone else.