Would Jboss and EJB be usefull ?

[cknoll]

brainlounge: Good links, and underscores a good point that is possibly being missed in this thread (but also may not have been the perspective of the poster) which is: EJB can play a role in online game development outside what the gamer actually sees. Perhpas J2EE is not the correct technology to maintain the state of players and NPCs as they move across the universe, but what about some of the other aspects of a MMOG? Billing is a great example: If you have EJBs to handle the ‘business rules’ of account creation, then it would be a very trivial matter to include a third party billing Bean that you could fold into the transaction that involves account creation…if the BillingBean throws an exception, you can rollback the account creation performed in your AccountManagerBean. (for example).

In addition, one aspect of MMOG that EJBs would be a very good fit for would be inventory management: How many dup bugs would be eliminated if the inventory and transaction mechanisms used was based on something with a proven track record vs. something homegrown?

Square hole with a square peg indeed.

-Chris

[blahblahblahh]

In addition, one aspect of MMOG that EJBs would be a very good fit for would be inventory management: How many dup bugs would be eliminated if the inventory and transaction mechanisms used was based on something with a proven track record vs. something homegrown?

Or people developing MMOG’s could just do their due-diligence and buy real software for their backend instead of paying interns to hack it together

Really, eliminating dupe bugs has no need for bean solutions - TP systems are extremely well researched and understood (I have a 3 inch thick book on my shelf above my desk entitled “Transaction Processing” which is more than 10 years old, yet 80% of it is still perfectly valid today) - and little inherent advantage (beans and J2EE are slow, for instance).

If you’re just going to look at functionailty offered by J2EE (which is what you’re starting to do again) then it’s a very bad fit because it just can’t cope at runtime :(.

[brainlounge]

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?