Why not using JMS for our games?

Hey guys,

I recently discovered the JMS specification, and I am really wondering what we are doing here … just re-inventering the wheel?
Why not making our network libs to implement or use the JMS spec ?

Java already have a huge advance in networking, why don’t we simply use it ?

Ina word: Performance

Its like saying “who do we need JOGL if we already have AWT canvas for graphics drawing”…

Games may well use JMS for occasional messages but not in a game loop changing frequent messages.

But JMS is not an implementation, it is just a specification.
Why should it be considered not performant ?

I was thinking that rather than to have a network lib war, we could be a little more organized and have a JMS implementation war. This way, all the games could use the same API (JMS) and switch between the different implementations without having to modify the source code of the game.

Because it is not an API that was designed with minimizing latencies in mind. The abstraction has to be buitl around the qualities you want or it wont deliver those qualities. Its loike trying to put a metric nut on an english screw. You waill spend an INCRDIBLE amount of effort trying to pang it into somplace it was never desigend to go.

JMS is designed for enterprise apps where the issues are average transactional throughput and fault-tolerance and NOT worst case latency.

Agreed. In my real-life I supported enterprise middleware for about six years and various messaging products ( focused on IBM MQ ) were a key part of that. Absolutely great if you want guaranteed delivery and several other transactional features, but they are not the right solution for most game needs.

Now if you were building a PBM-style turn based game JMS may be a perfect mechanism to get your clients moves back to the server. But for anything close to real-time it’s a matter of “right tool for the job” and I don’t JMS is it.