When you're trying to build a massively multiplayer online gaming platform (MMOG), probably the most important part of the system is scalability. After all, if it doesn't scale, it's simply a multiplayer online gaming platform - without the "massive". While it almost seems embarrassing to point this out, it's extremely interesting to note that there have recently been a lot of discussion about scalability of online systems - in particular, the Web 2.0 applications. I won't point to these discussions, but suffice it to say that I find it terribly amusing to hear the various forms of the argument that you can worry about scalability later - i.e. it's not something that has to be designed in from the start. (Arguments of the form "don't worry about scalability because no one is going to use your application anyway" are perfectly fine, however). As the history of MMOG has shown, the application's architecture has a huge impact on the ability to scale. As many gaming platforms have discovered, scalability isn't something you can simply "add on" after you "get things right". Anyone who thinks that this doesn't apply to other network application architectures amuse me to no end, given as if they actually produce something of value, it will fall over when it hits the natural scalability limit of their crappy architecture.

In any event, there's a couple of basic problems with MMOG that limit scalability. The first has to do with what is known as "Area Of Interest". The idea here is familiar enough to anyone who has done any distributed communication in that the gaming platform doesn't want to find itself in an N² connection topology. In MMOG, the entities (gamer avatars, NPC, etc) have to communicate with other entities in the game. If you can't find a way to limit the communication to the entities in the area of interest - i.e. the other entities that the entity in question is limited to communicating with - then you have a huge scalability issue due to sending messages to entities that simply don't care about the communication because it can't possibly affect them. This not only wastes bandwidth and precious OS network resources but causes a host of other issues having to do with the time ordering of distributed events and filtering our events that aren't relevant. It's a mess.

The initial spec actually has two separate parts: an api/framework, and an implementation with a new distribution format. Unfortunately, these are presented in a way that seriously blurs the distinction. Worse, the new distribution format (".jam" files) often takes center stage. The emPHAsis is on the wrong syLLAble. The api/framework layer must be the primary focus of the JSR 277 specification, providing a coherent compile/runtime model that enables multiple implementations. Specific implementations, while required to surface framework/api issues, should be documented in appendices or even separate specs. If the EDR spec had been written from this perspective, we probably would have avoided most of the current animosity. We can and should fix this in the next draft release. Implementations can then be seen on equal footing. More importantly, they can be left to compete on their own merits. Not everyone wants or needs OSGi, and the new .jam implementation may be right for them. But we know that there will be LOTS of bundles around when SE 7 ships, vastly outnumbering .jam files, so we need an OSGi implementation. ASAP. Built by OSGi insiders. Without it, we cannot have confidence that the api/framework abstractions are right or complete. With it, we not only gain spec validation but have a ready-made solution for using bundles on SE 7.