To achieve high availability and reach our goal of being linearly scaleable, the P2P Games system was divided into several functional layers. Each layer performs a specific task, and is completely independent of the other layers. Each of these layers is not specific to each other, and could be replaced easily, without code changes in the others. Quite actually, any of the layers to be described could be removed and utilized for other enterprise software systems: stock trading, portal services access, GIS gathering and presentation, etc.

Each section shown below will be described in detail in the following sections.

Service Providers through Inversion of Control
Before we continue, a new software design pattern should be described. This slightly different approach is useful when approaching common design problems having multiple services and/or solutions. Instead of looking at a problem as having one solution, and proceeding with a design for that solution, the problem is approached from its constituent tasks. It is the definition of those tasks that is of primary importance. Once the tasks are defined, solution providers may be designed to fill that task.

Consider the following example: baking a cake. Once a recipe is procured, instructions can be followed from top to bottom. The inputs are the ingredients, and the output (hopefully) will be a wonderfully delicious cake. In our daily lives, we accomplish this for many tasks, following individual instructions to the letter to produce our desired output.

However, what if input may be slightly different each time, and the output is required to be slightly different each time. What if we run a bakery with lots of employees, and they are all idiots?

Instead of following a recipe from top to bottom, we break the list into four sections:

1. Gather ingredients.
2. Mix.
3. Bake.
4. Frost.

Each of these four recipe sections could have hundreds of solutions. For instance, one may travel to the store to get eggs. Or eggs could be gathered from the local farmer. Or, some new, healthful substitute may be used for eggs. Either way, the ingredients are provided by one of our idiotic employees, and there could be multiple solutions.

In software design, this slight difference in approach is known as Inversion of Control (IoC), and is a subset of Aspect Oriented Programming. Once a problem is defined into smaller tasks, individual services may be written to fulfill that task. Each service is independent of the rest, and the system as a whole doesn’t necessarily care which type of task is provided for them.

Consider another example: translating speeches by representatives at the United Nations. When a delegate speaks to the international assembly, they do not bring along a fleet of translators so their words may be understood by all listeners. Translators are provided as a service, and the delegate need not worry about how or into what languages they are being translated.

Application Layers
Four sections of the P2P Games system will be outlined in this paper. These include Communications, Client Games Presentation, Web Interfaces, and the Data Persistence. It will be demonstrated how each of these layers utilize the theories and goals stated above. The Inversion of Control pattern is used often to provide power and flexibility to the system.

Client Communication Layer
The P2P Games Client Communication Layer utilizes the Inversion of Control pattern to allow for thousands of client applications to communicate with P2P Games Servers. Each Internet Client application connects through the Client Interface to send and receive commands and data. These commands include chat messages, game data, and personal settings used for Client presentation.

For most Internet applications, the method by which these data messages are translated (also known as serialization) depends upon the underlying technologies utilized. Client applications utilizing Microsoft’s ActiveX, Sun’s Java, and Macromedia Flash all utilize proprietary data formats to send information back and forth from client to server. If a system is designed to utilize Microsoft ActiveX on the client, the server is usually hard-coded to communicate using a fixed Microsoft standard.

As shown above, a system that caters to Microsoft ActiveX, normally utilizes a Microsoft Server application using a proprietary Microsoft communication format. Sun’s Java, Macromedia's Flash, and other Internet technologies also provide standardized formats. It is not the purpose of this example to blame a particular technology or company for this shortfall of design. Rather, this example illustrates how a single solution to a problem can create an inflexible architecture.

Other systems utilize an open data format, such as XML, for Internet communication. Since XML is an open, text-based technology, the communication itself is standardized, so any client application may utilize it. This allows for multiple Client application types to be utilized on the same system.
This approach also has a major drawback. Some applications are better at utilizing XML than others. While Microsoft technologies consume XML documents quickly, the Macromedia Flash plug-in utilizes an interpreter at runtime to parse XML, causing poor client performance.

Instead of approaching this communication problem from a single technology solution standpoint, and applying the Inversion of Control pattern, it is possible to imagine a system where any client technology can be utilized to communicate using any format desired. As such, a Microsoft ActiveX control could utilize Microsoft’s binary data format, a Java application could utilize Java binary serialization, and Macromedia movies could use another type of communication standard. Even unreleased future technologies could be plugged into the existing system once the proper communication standard is defined.
As the model above shows, the P2P Games Client Manager injects the appropriate communication service into the Client Interface for communications translation. Any viable client technology may be used to connect to the gaming system provided the appropriate communication service is made available. In other words, a User in Australia could connect to the P2P Games system using an installed Microsoft application, and play a poker game against a German using a no-install Macromedia Flash movie, and an American using a Sun Java Applet, with no one player knowing the difference.

Furthermore, the rest of the P2P Games system is not bound to the communication type of the client. Once the data is translated into the appropriate “simple” server objects, processing may continue. The P2P Games system is extremely powerful in that it remains flexible to respond to any client application type. Once the client software is written, and the appropriate service translator provided, any player utilizing that technology may be seamlessly integrated into any game.