The proposed solution 3

Asset service

The Content Service is responsible for persistence of digital content within the network, so that games may inject content and make it available to other game clients and servers. This can provide an abstraction over the network mechanism for achieving this so that content can be manipulated independently of its delivery mechanism.

Figure 6. Content distribution

Figure 6 shows two game clients and a game server interacting via a Process Broker. The game clients are able to inject new content into the game environment and make it available to other clients and servers through the Process Broker, which makes use of a content management system exposed as a service. The content service abstracts out the detail of how the actual content is stored and retrieved, so that a content repository of choice can be used to actually store the media. The game server can check authorization and control access to the media. This then allows the game developer to offload the content management and distribution problem to the middleware infrastructure, rather than building their own system. Since the digital assets are defined as an artifact of the middleware, they can be manipulated in conjunction with other Process Broker services, under a single transaction. For example, the game client may now be able to retrieve the content in return for a payment, controlled under a single function call. The function call would result in the Process Broker executing a process that grouped an asset manipulation on the content service with a financial transaction on the payment service.

A separate DRM service can be abstracted out to deal with ownership, key exchanges etc. and allow a separate DRM clearing house to be implemented from the content service. An example implementation that could fulfill this service is the IBM EMMS middleware.

Commerce service

The commerce service provides an abstraction of a Web-based store catalog service that would typically provide an online store capability to a Web site to allow customers to browse catalogs, choose items for purchase, shopping cart facilities, and purchasing. The commerce service allows a game to integrate the content and control provided by the e-commerce store into the game environment through simple function calls and the Process Broker. Because the notion of the store is abstracted out regardless of the actual content of the store, both virtual and real purchases could be possible. For instance, an online store that allows the purchase and download of digital game content could be integrated into the game environment so that the store manifests itself as a 3D store with shelves stacked with goods, like weapons, ammo and armour. When the player picks up an item from the shelf, it is "in their shopping cart" and when they leave the store they pay for the content, which is downloaded/installed into their game client and the necessary permissions to use are amended.

Alternatively, an online store that sells physical goods, such as merchandise, pizza, etc., could be integrated in exactly the same way, but instead of a content download, the content is physically shipped to the player.

Message service

The message service is an abstraction of a message distribution hub, so that applications and data can be loosely coupled through a publish/subscribe message distribution pattern. With the Pub/Sub pattern, messages are associated with topics, which is essentially hierarchical namespace with some semantics implicitly associated with it. A message broker provides a logical cloud that represents the topic space which contains all the topics. Entities using this cloud can either produce or consume messages, and they do this by publishing a message to a topic, or subscribing to a topic. Entities are unaware of each others existence, and they are only concerned with the topic space to which they are publishing or subscribing. Each entity may actually interact with the topic space over a different mechanism, but these details are hidden from the consumers of messages. Also, the use of wildcards is permitted when referring to topic names.

So, one entity may publish messages (sometimes called events) to a topic /Sports/Tennis/Events/Wimbledon/Matches/Henman that represents the current scores for Tim Henman. Another entity may subscribe to the topic /Sports/Tennis/Events/Wimbledon/* and get all messages published about any of the players in any of the matches in the Wimbledon tournament. Figure 7, below, illustrates how a Message Distribution Service abstracting over this kind of facility could connect game environments with producers and consumers of events in completely disparate environments, such as live sporting events or Web applications.

Figure 7. Message distribution patterns

The game code could either produce events by publishing to the PubSub cloud, or listen for events by subscribing to specific topics. This way a game could take the feed of telemetry data from racing cars and the trackside sensors in a NASCAR event and use them to simulate the actual event, without needing to understand how to interface with that particular telemetry feed. Reciprocally, games with multiplayer attributes such as tournament games could publish the current in-game statistics such as current scores, player health, location etc., and other applications such as Web sites could subscribe and aggregate this data and use it however it likes. The important thing, though, is that all the applications, whether they are the games or the web apps, need to know is the relevant topic names. No integration details are required to connect them otherwise.

Other services

Clearly many other kinds of services could be defined and integrated into the middleware, and then combined with each other to provide value-add processes usable from within the game environment. The above list has been a first pass at what might be immediately of value, and the imagination of the gaming industry can help to define further service types.

Federated Trust and Identity

As has been discussed already, there are different levels of trust operating between the various parties involved in the flow of data across the middleware, resulting in different security requirements and levels of federation across the solution.

The first level of trust that must be established is between the Client Connector and the Process Broker. It is imperative that this connection is secure to protect the integrity and confidentiality of messages being exchanged between these components.