Assuming you have a single DB, you're making the center of the "hub" the DB. It becomes the same architecture.
Remember, the first rule of optimization: Don't do it. The second is: Don't do it yet.
Quoting Genmen: "Assuming you have a single DB, you're making the center of the "hub" the DB. It becomes the same architecture."
I agree with you on this - it is moving the bottleneck to the DB but... all this talk about creating complex scalable applications by using an architecture that allows you to throw more machines into different parts of the cluster... it isn't ALL hogwash (maybe you think it is?)... Let's *assume* that I can set up a number of synchronized dbs (I'm not a db expert), isn't my argument still valid? Won't a homegrown solution for inserting records into a db through a servlet pool on multiple machines out-perform most (if not all) JMS implementations?
In terms of performance, many JMS implementations don't use relational DBs but use local storage. Some do "buddy replication" over the network, and require no disks for "persistence". These probably would out-perform your solution.
Anyway, by the time you finished your custom solution, it's likely JBoss Messaging 1.2 with full clustering would be out.
Yeah No point reinventing the wheel also.