The proposed solution 2

The Client Connector

It is the responsibility of the Client Connector to present the process oriented view to the game developer through simple APIs, so that a developer may deal with high-level business function encapsulated within a single function call and rely on the middleware infrastructure to protect them from the details and complexities of the business and integration logic required to fulfill that process. It is also responsible for abstracting the personal, sensitive data belonging to the player away from the game code and client API and moving it to a place that can be administered and controlled by the owner of that data -- the player themselves. This helps to provide privacy and anonymity to the player that desires it and a level of confidence and trust between the player and the game.

Figure 3. Component architecture

Figure 3 illustrates the component architecture broken down into the Client Connector, the Process Broker and the Services. The Client Connector is a thin client that presents the APIs to the game and stores/retrieves personal player data using a secure, encrypted repository. This repository, being persistent, is used to provide any game that uses the Client Connector so that a player does not have to re-enter their data each time they buy a new game, and they do not have to configure their personal sensitive data into any game.

The Client Connector must be as efficient as possible, as it will reside within the game footprint and execution path. For PC and console games, a native, portable C version is required that runs in a non-threaded or threaded model, with memory allocation restrictions to allow a game developer to predict and proscribe its behavior, should they wish.

The Client Connector establishes a secure session with the local Process Broker, and associates the session with the player?s identity within the infrastructure. This allows separate sessions to be correlated with a unique identity for auditing purposes. It then takes the parameters from the subsequent API function calls and marshals them along with required sensitive data from the repository to the Process Broker as a request for a specific process to be executed. The Client Connector should behave in a reliable and robust fashion, so that when a game calls a function call to request the execution of a given process, the game can rely on the middleware to complete the execution once the function call has returned. Therefore, if the game crashes between the function being called and the result returning, the middleware will manage the transaction and either roll back the transaction or persist the result until reconnection, depending upon whatever is appropriate for that process and service provider.

So, by requesting processes to be executed through the Process Broker, the client effectively interacts with Web services asynchronously, using these Web services to provide value-add e-business function rather than core game logic.

The Process Broker

The Client Connector establishes a session with the nearest or most appropriate Process Broker. Therefore, clients that will potentially interact with each other may be using different Process Brokers. Logically, the Process Brokers are a single entity, but are physically rendered as a collaborative network of edge servers.

Figure 4. Distributed process execution

Figure 4 shows how a network of Process Brokers may interact to provide connectivity between clients and service providers. Each client connects locally, but is allocated a globally unique ID so that the clients may refer to each other in function calls to the middleware.

For example, the two game clients in the diagram may wish to exchange money for some reason within the game environment (a payment for a game asset, for instance) and one of the clients would initiate the request for the process to exchange money, citing their own and the other client's unique IDs as two of the parameters. The Service Provider in the diagram would, in this example, be a Payment Service Provider, and its identity would be retrieved from the relevant client's repository and located and invoked by that client's Process Broker.

The Process Brokers are required to act as neutral intermediaries to coordinate transactions between the middleware clients, whether they are player/player or player/game server interactions. In some respects, they act as a generalised escrow service, brokering the information associated with the transactions and are responsible for the reliable execution of the process and persistence of any data over long-running transactions.

The Process Brokers also contain the business and integration logic required to interact with the service providers, insulating the game developer and code from service details and the need to perform business logic at the client. This helps to maintain a flexible and reliable solution.

This logic is encapsulated within the Process Brokers as modular components that can be composed into hierarchical business processes. This means that new processes can be modelled with tooling, rather than requiring code to be written, using existing logic and new function made available to the client connector.

Service Providers

Wherever possible, existing standards specifying Service Provider function will be used. For instance, the PayCircle initiative is one standard that is attempting to define how a Payment Service Provider should present their interfaces with Web services. However, in the case where these standards either do not exist, or have little or no adoption, alternatives must be sought. These can either be generic interface definitions that attempt to canonicalize likely function for a given service type (such as Payment service, Asset service, Security service, etc.) or specific integration logic for a specific Service Provider.

The choice will be influenced by selection of business partners in the value chain, emerging standards and pragmatics of a solution. IBM will continue to work with standards bodies to define the core Web services infrastructure specifications, and with business partners as required.

The initial function provided by the middleware categorizes the Service Providers into a set of types. These types represent a generic interface for that kind of service, and the combination of types can be used to fulfil complex business processes, such as a trade of digital assets protected by a rights management system in return for money.

The following sections detail the service types that have been defined in the initial architecture.

Payment Service

The Payment Service represents a Service Provider that can be used to capture a financial transaction and result in a payment being made between two parties. The support for a peer to peer charging model needs to be supported by this service to allow players to exchange funds, and also the traditional consumer/merchant model to allow a charge to be made on behalf of another service provider.

Figure 5. Payment Services

Examples of organizations that could fulfill this role are Telcos and mobile operators, pre-pay card systems, ISPs and utility companies, credit/debit card services etc. The actual payment fulfillment is abstracted from the service interface, so multiple payment models can be supported.

The Payment Service should be the preferred means of paying for all game experiences by the player, whether it is subscriptions, content, or premium services, so that all charges can be consolidated to a single payment channel for the player.