my guess would be that in any server-side application you have to trade performance and bandwidth for "enterprise"-capabilities like fail-over, data consistency over the cluster, message transaction management, scalability and modularity.

so you would either have the first and your system would have reduced or no "enterprise" features.
or you have the latter, reduce performance and bandwidth, and your game would no longer work.

having read most of the dozen-or-so specs constituting J2EE I never read a phrase like "This feature should be implemented to run slow".

if someone would like to make his very own, balanced trade, the choice is given to him by modern J2EE servers. they offer all kinds of optimisations, caches, tweaks and different transaction strategies.

i don't believe anyone stating he can give you unlimited speed and unlimited scalability and unlimited data replication at the same time before he has not put the system under production load (be it J2EE or proprietary). but you don't need /unlimited/ speed and scalability in a production environment, just as much as is needed ;-). and that's what where the deal starts.

"proprietary" engines may be optimized for more-or-less-general gaming needs. but i doubt they can right now be as good as established, well-known J2EE engines when it comes to "enterprise" features, can they?

Today's Slashdot pointed me to an IBM alphaworks project called 'BIG' (Business Integration for Games) which allows an online game to make use of a Webshere based online billing service.
It's not yet (and maybe will never be) a product, but it shows that there are notions of seeing certain games as 'enterprise' systems.

Slashdot post:
http://games.slashdot.org/article.pl?sid=04/02/23/084232

BIG project:
http://www.alphaworks.ibm.com/tech/big/

White Paper:
http://www-106.ibm.com/developerworks/webservices/library/ws-intgame/

Re-reading this thread I have difficulties coming to the same conclusion, while at the same time agreeing to most of the thing said here.
But you are right, I don't know if J2EE is appropriate for a game. I cannot prove it. I'd have to write one, I guess. But I can in my weird mind think of games where J2EE was worth evaluating.

One question concerning "grexengine", described on the web site as "approximately equivalent to J2EE". Assuming you are right and J2EE/enterprise architecture was _potentially_ appropriate for <5% of all online games and let's roughly assume that online games have an overall game market share of, say, 50% (??more, less??). Then how much of the game market is your company targeting with grexengine? Is it a niche product?


... as is with most IT technology. The more detail, the more devil.

Come on, this is the old OpenGL vs. Java thing with new clothes. J2EE is build upon J2SE. So it is trivial to say that a pure J2SE implementation would be favourable over a J2EE implementation without needing J2EE specific features.

By the way, J2EE is not just EJBs. It's JSP and Servlets, too.

When somebody needed to implement a massive multi-player text-adventure in two weeks which does fail-over or clustering and stores large amounts of data on the server(s) and could be tolerated to use HTTP instead of sockets he really gets some bad advice from this thread for not using/evaluating J2EE. Because it maybe is his only chance to do the job on time.

People might call "It's not a game, it's an enterprise application!" because it's not using graphics or not trying to do real time communication. But maybe new types of games are of that kind.

So again, do use J2EE _only_ when you really need J2EE specific features whether it's a game or "a real enterprise app". If not, _do_not_ use it.

It's fascinating to follow the expertise on this forum around those networking and online topics. On the other hand, isn't "the engine" often confused with "the game"? (Which really is the best fun case for a software engineer ;-) )


There are enterprise apps where latency issues cause transactions to role back. With regard to TCP/IP latency, you are probably right.


Not agreed. Myst et al. are games where latency is NOT critical (There really where latencies when I originally played it! - Not reducing the fun I had.).
Online chess is a game where latency is NOT critical. Is this board restricted to any game flavor?

Keeping distributed systems in sync (source code, databases, game clients...) comes with the penalty either of (a) complex sync logic or (b) reduced performance (but only when lacking server CPU or bandwith!).

Don't use J2EE for peer-to-peer or fat-client scenarios since they are not strict client/server.


The original question was: "Can Jboss and EJB be used for server side online gaming ?" -- Strictly saying No does not seem to be the right answer to me because J2EE is already heavily used for server-side online apps like Online Banking, webbased Bug Repositories, Online Shops -- all kinds of online information systems. What more do you need to know? If a MMORPG is an online information system, I would not rule it out beforehand.

I am not a professional game developer and I am not a game developer at all. I can't prove anything. The target use case has not been given together with the question. If Thierry needs online, real-time audio chat, it does not sound like a server-based application to me. The audio is send to the peers directly, isn't it?


Performance is always the killer argument. -- Even for saying Java is not ready for game development, or for anything at all :-)
J2EE is not designed for real-time applications, as isn't TCP/IP, nor Java. All this stuff which is done to achieve that are workarounds (IMHO).

Well, I disagree with the general statement made here, that

"J2EE is not made for game apps."

A J2EE server is a framework and is not designed for specific apps but for specific architectures.
These are:
- client/server-based
- transaction-driven
- complex (like (much) more than 10 db tables)
- a significant number of business classes
- a team of developers larger than, say, 5
- distributed (clustered)
- integrative (integrates with another already existing service)
- session-based (multi-user environment)
- secure.

Of course, this is only a buzzword list but it can help sort out really fast if J2EE is matching the needs of a specific game app.
To me, this would probably meet for large multi-user RPGs and other apps where the computational overhead is on the server.

I turned away from J2EE a few years ago but right now, with the current JBoss Releases (3.2.x) (together with xdoclet) I am more than surprised how easy you can build up and deploy "enterprise applications". (It was like switching from Java 1.1 to Java 1.2.)

Performance. A J2EE server is like an Oracle DB. You can do very bad things that kill performance. So many switches... It took me really some time to become familiar with the J2EE patterns (do's and dont's). It's a world of its own. And I can recommend to try CMP (container managed persistence) instead of those other persistence frameworks.

RMI/remote calls. Method calls within the J2EE container are no longer remote calls. That was yesterday.

The simple fact that there is no profound J2EE know-how on a game development team rules out the use of that technology!

And: Yes, J2EE is well suited for a Chat app. Why not?