What about scale?

I mentioned earlier that the game is likely to be a high-volume, highly dynamic part of your environment. As such, you're unlikely to fit everything on the single server as indicated previously. The Stand-Alone Single Channel pattern description gives some help here in the form of Non-Functional Requirements custom pattern designs.

Non-Functional Requirements patterns focus on the specific design process considerations for high availability and high-performance solutions. Specifically, the focus is software and node configuration scenarios within the demilitarized zone (DMZ), or external network, and the implementation procedures for using these designs.

High performance is the non-functional requirement I'll address. A number of options are provided -- look at the Basic Runtime pattern in Figure 3.

Figure 3. Non-Functional Requirements, high performance: Basic Runtime pattern

Again, you need to replace the concept of a Web application server with the concept of a more general application server. Generically though, this is probably a reasonable approach to take.

Steps 7 and 8: Integrating runtime patterns into a solution

You're now at the last step of this stage of patterns-based solution modeling. You've identified a number of runtime patterns, each of which apply to part of your infrastructure. Now, overlay all of them into an overall runtime pattern for your scenario. At the same time, add placeholders for functions that you know you need but are not called out by the patterns you've reviewed.

Figure 4. Overlay of Runtime patterns (surrounded by green boxes)

Figure 4 places all these functions together on a single diagram. It adds a couple of additional functions (such as the Customer Relationship Management component) and firewalls to protect functionally separate parts of the architecture. You established the most common linkages or operational flows between each function. You also gave each part of the architecture a name for easier discussion of the overall architecture.

Zoning out: walking through the model

Take a moment to understand this model.

You have a group of gamers, represented on the left side of Figure 4 by the box titled "IP-based user." In this current scenario, you expect that your users are PC-based gamers. As noted previously, when they connect to your site they will probably connect to the game using a browser-based mechanism through HTTP, but also connect directly to the game using a sockets-based, game-specific connection.

The first time the gamer arrives at the site, you will ask him to register. If the gamer arrives as a result of having purchased a game hosted on this site, he may have a registration key, an automatic registration from inside the installed game, or some other mechanism that enables him to register. If he has not purchased and installed a game, you still might require them to register before you give access to premium content. As part of the registration process, you may also allow gamers to hang out in a lobby area -- similar to a crowd milling around outside a theater -- prior to entering the entertainment event. To encapsulate the infrastructure required to support registration and the lobby, I call this part of the infrastructure the lobby zone.

The core reason people come to the game infrastructure is to play the game. Given that sometimes the game population can grow into the thousands (potentially millions), a significant amount of infrastructure might be needed to support them -- server farms, scalability mechanisms that stop a single server from becoming overloaded, fail-over for 24/7 games, and so on. As a way of grouping and identifying this section of the infrastructure, I call this the game zone.

In addition to playing the game, other activities might cause gamers to hang out, spend more time (and more money) at the game site, and become more committed to the game. This propensity can be encouraged by providing appropriate functions and activities at the game site. In essence, these activities pay off for the gamers by making them feel part of a community of people who have the same hobby -- the game. Therefore, I call these the community functions and the part of the infrastructure that supports these activities, the community zone.

This simple categorization gives the first level of structure that you can use to understand and describe what you have. Still, some required functions are missing from this diagram:

• You will need a set of management functions. This includes those functions required to keep the whole infrastructure running, such as monitoring and maintenance. Often, these functions have agents that are distributed across all components, but a centralized point also provides oversight.
• If your applications require significant storage, it may make sense to use an emerging best practice -- consolidation of all storage in your infrastructure into a storage zone.
• You need a development environment that can support the development and testing of components before you bring them into the environment. Fence this set of hardware, software, and activities off from the production infrastructure in a development zone.
• To support your enterprise, you will have other systems, such as finance, payroll, and legal systems. Securely protect these from the remainder of your infrastructure in an enterprise zone.

This is a significant set of issues so I'll leave further elaboration of these zones to another time.