Step 6: Identifying application patterns

Once you've selected the business patterns, start to explore the application patterns to implement this business pattern.

As you start to drill down into the Portal application patterns, you find the following diagram which summarizes the various types of functionality found in each business and integration pattern. Again, these are categorized into the mandatory (functions that are always present in this business pattern) and the optional (functions that may or may not be present).

Figure 4. The mandatory/optional Application patterns required for a portal

In comparing the mandatory and optional pattern variations for the Portal application pattern against the functions necessary for your solution, note the following requirements:

• Access integration: To be usable by the gamers, single sign-on is absolutely a requirement across these different functions. You also wish to provide personalized delivery of guild- and team-oriented information. For this scenario, you do not (yet) require Pervasive device access.
• Self-service: To reduce the overall service costs of your infrastructure, the Directly integrated single channel pattern is mandatory.
• Chat and e-mail capabilities: Both Store and Retrieve collaboration (e-mail), and Directed Collaboration (chat) help reduce customer service costs. They also allow you to provide additional functions that increase portal "stickiness" by providing team-oriented or interactive events.
• Information aggregation: You need searchable access to a variety of information sources. At the level of sophistication you want, you probably do not need Population Crawl and Discovery, although portal aggregator sites with a large number of information sources may find this functionality useful. At this stag, you are unlikely to need multi-step information aggregation, so you will use single-step aggregation, the simplest practical starting point. You will add data to the information database over time from internal sources such as interviews, articles, and news flashes, and in response to commonly asked questions or problems. In most cases, you initially envision that you'll take overt action to add these items to the information base rather than having an automated process that manages this.
• Extended enterprise: Credit card approvals and charges, as well as any outsourced components such as shipping use these very common e-commerce functions. Make a note to also check the e-commerce pattern as you move forward.

If you review the Runtime pattern choices available for the Portal application pattern, note that the same Runtime pattern is used for each of the mandatory patterns that you require. Therefore, go ahead and use this one Portal composite Runtime pattern. No need to choose between multiple conflicting choices. It includes all the components for access integration and for the other needed functions.

The Portal composite pattern also includes the Runtime components from the Self-Service pattern, so for these two pieces, the infrastructure components are provided by the Portal composite pattern. Single sign-on is provided through the application server's use of the directory.

Figure 5 shows the Portal Runtime pattern.

Figure 5. The Portal Runtime pattern

For comparison, Figure 6 shows the Runtime pattern for the Electronic Commerce pattern.

Figure 6. The Electronic Commerce application pattern, Web-Up Runtime pattern

Looking at the components of the Electronic Commerce Runtime pattern, you see some overlap with the Portal Runtime pattern in the basic structure and common components such as the Web server and firewalls. You also see components not duplicated in the Portal, such as the Commerce Application. To build up the complete Runtime architecture, overlay these two Runtime patterns.

What's next?

In this first of five articles, I've cited reasons that underscore the increasing complexity in the online games industry, especially for game providers (the focus of this series). This industry is in transition, straddling the chasm between enterprise business and the art of games.

I introduced patterns and explained their value when crafting and implementing an online games environment. I examined a typical real-world interaction to to aid you in developing a high-level business description of the development direction you intend to follow. I demonstrated how to take that description, pull out the pertinent elements, and use those elements to build a solution overview of the project.

Then using the solution overview as a base, you learned how to identify the business, integration, composite, and application patterns necessary to developing an online game infrastructure.

In the next article, I refocus on the game itself, applying a patterns-based perspective to it. I'll discuss scalability options and finish up the last two steps of the patterns-based solutions modeling by determining how to integrate the runtime patterns into a solution. You'll use the runtime model to help determine your buy, build, and outsource decisions.