[quote]I have yet to work on a project that necessitates EJB.
All projects Ive witnessed going down the eJb track,
never return…!!!
Id always go for JDO unless:
-1) your are a sadomasachistical techiee
-2) you want to explore with J2ee flexible architecture
-3) your serverside app is really distributed, integrated over various systems
[/quote]
Yeah, I think it’s suffering from the universal-hammer-syndrome I mentioned above; EJB is really tempting if you’re writing a network-server with a large number of (potential) users, and you don’t know / don’t like writing network handlers etc. J2EE does SO MUCH WORK for free - but it’s non-configurable, non-extensible, and so it’s like running down a tunnel - you CANNOT get J2EE to work for situations other than the ones it was designed for without MASSES of work.
As for reasons for using it… can I add:
being able to put on your CV that you developed a “major J2EE/EJB project”, and hopefully get a higher paid job somewhere else on a similar failing project that you know will never reach completion
If you’re going to consider JDO, I would suggest first taking a look at Hibernate 2.0. Its easier to work with, and is more supported by developers than JDO (at the moment). This may change when JDO 2.0 specification comes out.
JBoss isn’t known for performance, so I imagine that would be a problem and I am hard pressed to see a need for EJB on a game. My experience with EJB has typically been pretty bad. The only exception would be MDB (Message Driven Beans) which work wonders. One thought though about MDB and JMS in general. If you have data that HAS to be updated in the database but isn’t terribly time sensitive or can be delayed a little bit, why not throw it in a queue?
I mean think about it, you are running along the ground in your multi-player, tile-based world and suddenly get disconnected. You lose 20 minutes of game data in one shot. Crap! If the game were to set up to request a position save every 1 minute or some such and that request sits in a queue until serviced, you could easily tune the load on your database by increasing or decreasing the number of MDBs listening on that queue.
This is just one example, but queueing can be VERY useful for places where time isn’t so important but it HAS to work.
I have used a similiar technique for several enterprise projects I have worked on where data had to be written to the database and we didn’t want to consume all the processor of the server with it at one time. So we trickled out the updates based on CPU load. You would dump it in the queue and as CPU became available, we would then do some work.
Let’s just be blunt about it - JBoss is slow - even its MDB performance is slow, painfully unusable for a game slow. I’d been down that path not once but twice and both times I turned away swearing never to go that road again. EJB is a round peg square hole type of thing - completely useless for gaming. Jboss would be nice and some of the protocols they support now are nice, but Jboss as a collective is way more overhead than the average game can absorb on the server side. Unfortunately.
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?
[quote]Well, I disagree with the general statement made here, that
“J2EE is not made for game apps.”
…
To me, this would probably meet for large multi-user RPGs and other apps where the computational overhead is on the server.
[/quote]
I would be fascinated to know how you would solve the single biggest (one could almost say the “defining”) technical problem of MMORPGs: Every single action by every single player potentially needs to be communicated to every single other player in less than a few tenths of a second, and has to be extensively pre-processed beforehand (e.g. to ensure the client is not sent any more data than it absolutely needs, to prevent cheating via hacked clients).
I have some friends still working at IBM on enterprise arch, and they assure me that IBM at least is moving it’s servers in that direction (i.e. capable of huge interdependency between the actions of all clients without loss of performance), but none of them are from a games industry background, and I’m not convinced they fully appreciate the extent of the problems.
Shrug. The buzzword list you provided for J2EE was almost entirely devoid of use-cases, and as a systems architect I’d say it was almost entirely useless to evaluate an architecture for any particular project…it just doesn’t contain any of the really important details that allow you to evaluate an arch for your particular needs!
Sure, it’s very easy to be vague and say “well, J2EE kind of does the same sorts of things as a multiplayer server with large numbers of players” but by the same token QNX = Linux = Win NT (they’re all OS’s that are POSIX compliant, except perhaps QNX [I know there *is* a major RT OS that is POSIX compliant, but perhaps not QNX?]).
This certainly doesn’t prevent you from being right, it’s just I’ve seen no evidence that would support your disagreement with the statement you quoted. I also know there are other good architectures you can use for MMOG development that are considerably different from J2EE and I cannot possibly believe you could ever code MMOGs as rapidly or effectively in J2EE as in these.
Fundamentally, performance is AFAICS the deal-breaker for J2EE. The things that you need to scale up and the performance criteria that must be obeyed for Walmart’s datamining apps are pretty much 100% unrelated to those for a game. J2EE was designed specifically for (things like) the former; I’ve never heard any suggestion that the latter was even considered?
[quote]I would be fascinated to know how you would solve the single biggest (one could almost say the “defining”) technical problem of MMORPGs: Every single action by every single player potentially needs to be communicated to every single other player in less than a few tenths of a second, and has to be extensively pre-processed beforehand (e.g. to ensure the client is not sent any more data than it absolutely needs, to prevent cheating via hacked clients).
[/quote]
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.
[quote]Shrug. The buzzword list you provided for J2EE was almost entirely devoid of use-cases, and as a systems architect I’d say it was almost entirely useless to evaluate an architecture for any particular project…it just doesn’t contain any of the really important details that allow you to evaluate an arch for your particular needs!
[/quote]
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?
[quote]Fundamentally, performance is AFAICS the deal-breaker for J2EE. The things that you need to scale up and the performance criteria that must be obeyed for Walmart’s datamining apps are pretty much 100% unrelated to those for a game. J2EE was designed specifically for (things like) the former; I’ve never heard any suggestion that the latter was even considered?
[/quote]
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).
I can tell you with certainty that JBoss is not performant enough at the moment to be useful for performance intensive gaming applications where you need the server to process 10’s of thousands of messages in few seconds. Performance wise JBoss isn’t there yet. JBoss != J2EE. Jboss is an application server implementation. EJB is wildly overkill for anything related to gaming. If you’re considering EJB, you might as well just code your networking layer entirely in RMI and be done with it.
The J2EE APIs that are generally useful for gaming applications are: JMS, JSP 2.0, and to some extent JNDI.
If you are building a Flash game that generates all of its content based on server calls - JSP (and possibly EJB) are for you. If you need to pass a lot of messages around quickly - JMS may be for you, if you can deal with the overhead that comes with the implementation… and not all implementations are suited for gaming. Jboss is unfortunately one of them. JNDI is generally useful for just about everything - including gaming, if you have a need for it.
I’ve been writing code in Java since 96-96 and have done the J2EE track and certified as a Enterprise Architect. I can tell you with certainty that if you are building a game with J2EE - you have done a poor job at architecture. Even if we get past the performance of application servers, what you’ve just ended up with is an architecture full of a lot of services, features, and overhead that give you absolutely nothing.
There is mistake number 1. Games != Enterprise Applications. Your requirements are entirely different. Takes maybe a day of spec’ing out the system in UML to see quickly that J2EE is just the wrong direction to go.
Mistake #2. Performance of a J2EE application server is relative to how its used and not equivalent to that of a games ‘server’ kernel. Any average multiuser game is simply passing around packets that are ending up on a server. The only mechanism of J2EE that even makes sense in this approach is JMS. However, JMS is for asynchronous messaging and in 80% of cases a game is more interested in synchronous messaging.
In-VM RMI calls have been removed as an optimization - yes, but the calls between clients and an application server are STILL RMI or JMS based if you’re anywhere near J2EE compliant. By law, EJBs do not open sockets nor native resources because that would screw with the ejb lifecycle, particularly passivation and load balancing across multiple containers. As such, the primary mechanisms you’d want to use to communicate (UDP and TCP) are all but forbidden to you by definition in the specification. Ergo, the specification is telling you outright - round peg, square hole.
Very true. This is one case where J2EE is the obvious choice. The reliability and scalability provided by JMS make it the ideal platform for a chat application. Throw in a cluster of MQSeries servers and you’re done - one week tops.
J2EE is NOT a magic bullet for everything. That’s what gets projects into many of the problems they have now. Same with XML. People use it as a magic bullet to solve every problem. I see this same clear lack of requirements gathering with people sending XML to MIDP class devices because XML is universal - cool, so now you’re sending large docs across an extremely narrow pipe to a device with very limited CPU for parsing XML, and costing yoru customer a crap load of money in the process. Any design you put on paper will quickly tell you which technologies are well suited and which ones are not well suited.
For most conventional games - J2EE is not well suited, will cost you more money to develop, and give you a lot of ‘functionality’ that you will end up trying to ‘turn off’ to get things running quickly.
But why bother write ANYTHING when IRC is freely available? Im always astounded that games feel they have tow rite their own chat and then up doing it badly.
And frankly, I think its a heck of a lot faster to write a chat server in J2SE then EJBs and performance is likely to be better without all that unused structure around it. It would be interesting to do a “race” between a very knowledgeable J2SE progrmamer and a similar EJB programmer and see what they came up with.
J2EE was desigend for enterprise apps. Its good for enterprise apps. But it can easily become the hammer thats starts you thinking every problem is a nail.
In enterprise apps throughput is everything, latency is almost a non-issue. In games, worst case latency performance IS the critical measure.
[quote]In re chat…
It would be interesting to do a “race” between a very knowledgeable J2SE progrmamer and a similar EJB programmer and see what they came up with.
[/quote]
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 )
[quote]In re chat…
In enterprise apps throughput is everything, latency is almost a non-issue. In games, worst case latency performance IS the critical measure.
[/quote]
There are enterprise apps where latency issues cause transactions to role back. With regard to TCP/IP latency, you are probably right.
[quote]In re chat…
In games, worst case latency performance IS the critical measure.
[/quote]
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?
This is perfectly true. It is also rather incredible (literally) … I can imagine this happening (sort of) but I would find it hard to believe it ever happening, for purely practical reasons. E.g. it would take many months just to produce enough (textual) content for a single adventure (MUD), and probably require many people working on that time scale to satisfy enough people to make clustering and failover a requirement - so it’s very unlikely that the engine for running this would have to be delivered in two weeks.
Hmm. I’m not sure I understand your first sentence here, but you seem to be implying that the vocal posters here have obvious particular narrow fields of expertise, and are overly critical (and suspicious) of anything outside of that. If so, you need to read more carefully - many of us have very wide experience (e.g. there seem to be a lot of people here with a commercial J2EE background), if not - sorry for misunderstanding you!
The posts on this topic seem to have mostly followed:
More specifically, in the light of your initial statement
[quote]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.
[/quote]
part of the problem is that J2EE is NOT made for MMOG architectures. It’s even less suited to “normal” game architectures, where most of J2EE is useless.
The other part is that the J2EE implementations are also NOT made for MMOG apps. They suck - the performance is dismal (given the problem domain).
Therefore, most of us with direct experience feel that J2EE is not suited to game apps; we understand that it is first and foremost an architecture, but it doesn’t work on either that level or the practical level.
??? Myst is a single-player game; of course latency (of a J2EE implementation) is not an issue!
But we’re talking specifically about online games, which to my mind means multiplayer, no?
Indeed. However, the posts in this thread have pretty much said “for most games, J2EE is a bad choice”; you seemed to start by suggesting that J2ee was more widely appropriate than this. In fact, the percentage of online games for which J2EE is appropriate is, IMHO, somewhere under 5%, probably much less.
Perhaps you could post specific examples of games where J2EE is an appropriate choice, which could be useful to readers of the thread? Although vague examples wouldn’t help, unfortunately, since with choosing J2EE “the devil’s in the detail”.
No, use J2EE only when you both need j2EE features AND your game (app) actually follows the basic assumptions in J2EE - that is a long list which includes:
[]particular traffic patterns
[]separate ranges of tolerable latency for each of: per-method, per-bean, AND per-user-request
[]potential re-usability of code (N.B. business logic potentially has 99% or so reusability, games exhibit much less for quite complex reasons)
[]existence of many 3rd-party component vendors, creating a huge marketplace of purchasable components
[*]…etc
But why bother write ANYTHING when IRC is freely available?
[/quote]
Integrating IRC into a Java application is actually a LOT more work than staging a clusterable JMS solution. I could stage a JMS solution in a day right now, no question - and be able to pass arbitrary application specific object across the architecture, secure it, and break it up into topics with little to no effort. Easy as pie with JMS. If you’ve written more than 200 lines of code for the client and the server, you did it wrong
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.
There’s one point that seems to have gotten lost here, which is learning curve. EJbs are very complex and have a steep learning curve.
In the text-adventure example i think the programmer new to EJBs would spend most of his first two weeks getting his tool chain up and running and understanding how EJBs want to be built.
(My background for this guess is having actually written “the worlds smallest EJB execution environment” as part of an experimental project at Sun-- about 100K. )
Sun REALLY needs to work with folks to simplify J2EE overall. Many many lines of code to do even simple things. If it weren’t for XDoclet, I would probably still be figuring out that EJBs for gaming (even on the backend) are not performant enough for prime time Even MDBs (which was extremely disappointing) just don’t cut it for the latencies that one has to deal with for the average online game.
I’m not quite sure I understand your assumptions, so I’ll be verbose in replying…
Describing the grexengine relative to J2EE is a convenient starting point to give people a handle on it.
[]Both are based first-and-foremost around a particular architecture
[]Both fit into the category of “service-based” architectures
[]Despite any failures of J2EE :), chunks of it were clearly designed to be very easy for people to program against. E.g. Servlets are incredibly simple, at first, and seem to try and remove the need for most HTTP-specific knowledge. The GE is aimed at developers with no distributed-systems expertise, so there’s a lot of emphasis on making all the services and the main architecture very simple to understand and use, AND requiring as few lines of code to achieve things as possible (and it takes a lot of effort and head-scratching to achieve that without producing “dumbed-down” interfaces that lack power/flexibility).
[]Some versions of the GE actually have many elements in common with J2EE - e.g. TP, clustering, etc.
The biggest difference is that the architectures are completely different as soon as you step below viewing them as “basically service-based”. The second biggest difference is probably that the GE is explicitly designed to be customized by the customers at every point - whereas with J2EE implementations, you aren’t supposed (historically often weren’t given any means of doing it) to fiddle with large sections of the system; you just had to accept that there was a container doing what you wanted it to. If it was slightly doing the wrong thing, or in the wrong way, you weren’t allowed to go and tweak it. Over time, more implementations have given you more tweaking options AFAICS, although IIRC none of this is mandated by the J2EE spec? With the GE, the opposite is true; everything can be customized, and this is mandated by the architecture (in fact, it accounts for a major part of the architecutre itself).
Finally, on to market shares. The main GE is targetted at MMOG’s, defined as games with approx 10k to 500k simultaneous players today (scaling up to millions in the future, if necessary; it’s not clear yet how many non-trivial games will grow to that size, if any).
The recently completed GE-Lite is aimed at much smaller games (typically 0.5k to 50k) and uses the exact same architecture, so you could swap back and forth between the two without recompiling your own code. In particular, the GE-Lite is for games that probably don’t think of themselves as MMOG’s (except when their marketing droid wants to use some buzzwords); for instance it currently doesn’t include any of the “shared virtual world” systems like the geographic ones. Most games in this segment don’t have a world-map with people running around on it. It’s also for games that are starting with modest playerbases and want cheap technology to get started with.
MMOG’s have a market share of something like 5%-20% of the games market (I’m basing that estimate on knowledge of how many US homes purchase games, and how many players each of the US-played MMOG’s currently has, then adding some more to take account of the MMOG’s that are not really played in the US but have many more players).
So, the two GE-based products together are probably not serving a niche market, although each alone is arguably in a niche.
Hope that helps. (fx: wishes something like this were on the website and I didn’t have to type all that out ;))
There is a lot of very interesting dialog in this thread. I know the common consensus has been that EJB is not a game oriented technology, but a critical assumption has been made. J2EE may not be suitable for real time applications, but it looks perfect for turn-based games such as board games, text adventures, and turn-based strategy games. I am working on speccing out a complex web-based turn-based strategy game and can see applicable uses for almost the entire J2EE spec. JSP/Servlet for my presentation layer, EJB for my application logic and database abstraction, and possibly even JMS for talking to alternative I/O like SMS messaging. So, be careful when completely ruling J2EE out of the game world. Square pegs work wonders in square holes.
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.
)