Angel \”Java\” Lopez on Blog

November 30, 2011

Social Online Games Programming (Part 5) New Azure Toolkit

Previous Post
Next Post

Two weeks ago, a new version of Windows Azure Toolkit for Social Games was released. See @ntotten posts:

Windows Azure Toolkit for Social Games Version 1.1.1
Windows Azure Toolkit for Social Games Version 1.1

The new version implements two simple HTML5 games: tic-tac-toe and four-in-a-row, backed up by ASP.NET MVC views, WCF Web API services, ACS federated security, and Azure Storage. You can play them online at:

I think this is a more clear example than the previous one (Tankster) that was great but a bit overwhelming ;-). Let’s dive into some implementation details of this new example.

Totten wrote:

The biggest change we have made in this release is to separate the core toolkit from the Tankster game. After we released the Tankster sample game we received a lot of feedback asking for a simpler game that developers could use to learn. To meet this need we developed two simple games, Tic-Tac-Toe and Four in a Row, and included in the toolkit. The Tankster game is now available separately as a sample built on top of the toolkit.

While the new games included in the toolkit are much simpler than Tankster, they still show the same core concepts. You can easily use these samples as a starting point to build out any number of types of games. Additionally, you will find that many of the core components of the game such as the leaderboard services, game command services can be used without any modification to the server side or client side code.

In my previous post, I mentioned a minor but important change in game action processing: any game logic was removed from server code. Adopting this approach, you can write new games without changing the ASP.NET MVC code. You still can add server side code if you want (to have more control over the actions, to avoid player cheating, etc..) but it is interesting to have a base code with game-agnostic code.

Opening the solution in Visual Studio, you will find Javascript files used by the two games. You can write a new game, reusing these files:

The games are implemented as areas:

You could add new games and publish them as NuGet packages.

Visually, the client Javascript code is organized as:

Each game X (TicTacToe, FourInARow, yours) has:

XGame: the game logic

XBoard: to draw board on canvas and to detect click events on it

XViewModel: containing the player and other data to be used at view rendering (the example uses knockout.js, an MVC in Javascript)

XController: to process new events and to coordinate the above elements

The generic part:

UserService: methods related to users: login, get friends, etc.

GameService:  play moves, receives new moves, other actions.

ServerInterface: Ajax calls (using GET, POST, JSONP, Azure storage…) that are used by the implemention of User and Game Service.

Topics for next posts: analyze the Javascript code, the use of Canvas, Javascript tests using QUnit, communication with server using Ajax, change the Game Service (Javascript) to use a Node.js server.

Keep tuned!

Angel “Java” Lopez

July 21, 2011

Social Online Games Programming (Part 2) Tankster and Windows Azure Toolkit For Social Games

Previous post
Next post

Yesterday, July 20th, Microsoft released a preview version of Windows Azure Toolkit for Social Games, and published a beta version (with code) of a first demo game.

You can download the code from Codeplex:

You can play the game at:

The current solution main projects:

Tankster.GamePlay is a Web Role. The only worker role is Tankster.WorkerRole. Tankster.Core is a class library. There are interesting code at Tankster.Common: Azure utilities to access repositories, a job engine; all its code is game-agnostic.

These are my first short comments about the code and implemented features (remember, is a beta! Some of these features/implementations could change in the next release):

– Client technology: HTML5, Javascript, EaselJs (for canvas programming).
– Server technology: ASP.NET MVC 3, some Razor test views (interesting topic: how to test the game without the REAL game), WCF Web API (another interesting topic to discuss: alternative technologies to received the game activity)
– There is a client game model and entities in Javascript. See src/model, src/game.

– There is a server game model (see Tankster.Core class library project)

– You can play in single player mode, but you can choose multi-player online. Then, the game uses ACS Portal to login using Federated Authentication:

– The client code resides in a single page: index.html (with lot of referenced javascript files)
– Client code sends JSON data (commands) to WCF Web API endpoints, using Ajax/JQuery. There are services published, exposing a REST-like interface


– Most of the game activity is send to game/command service. The service updates the game status residing in a blob at Azure Storage. Code excerpt:

// Add gameAction
var gameAction = new GameAction
    Id = Guid.NewGuid(),
    Type = commandType,
    CommandData = commandData,
    UserId = this.CurrentUserId,
    Timestamp = DateTime.UtcNow
// Cleanup game actions lists
for (int i = 0; i < game.GameActions.Count(); i++)
    if (game.GameActions[i].Timestamp < DateTime.UtcNow.AddSeconds(-10))

– The game status is polled by javascript clients from blob storage. In this way, the ASP.NET MVC web role has less workload.

– The blob resides in the same domain, so no cross-domain JSON call is needed. But the game is prepared to use cross-domain Ajax call, replacing the XmlHttpRequest object by a Flash component.

– The Skirmish game mode (five players in a game) is made queuing the new players in a Game Queue, managed at worker role.

– The Statistics are processed at worker role: some game actions are sent to Azure queue, so the statistics process doesn’t disturb the client game.

– User status, Game status, Skirmish Game Queue status are blobs.

– Statistics data uses SQL Azure.

– There only worker role use a Job Engine to process many tasks, example:

// Game Queue for Skirmish game
    .SetupContext((message, context) =>
         context.Add("userId", message.UserId);
        new SkirmishGameQueueCommand(userRepository,
            gameRepository, workerContext))

There are a lot of points to comment and discuss, feed for upcoming posts. Surely, the solution will evolve and new versions will be published (this week? next week?). But it is interesting to have a published game online AND the code to analyzes it.

Keep tuned!

Angel “Java” Lopez

April 22, 2009

Introducing AjProcessor (Part 1)

Filed under: .NET, AjMessages, Grid Computing, Windows Communication Foundation — ajlopez @ 7:05 pm

Last month, I was working in AjProcessor code, as part of my code katas Google project:

The idea is the evolution of some exploratory coding with AjMessages and other examples. I want to have an application, based in message passing, that can be run in a grid of heterogeneus machines. The application could 
be partitioned in steps, and each step could run in the same host machine, or on a another machine. The deployment in machines should be transparent to the writing of the application code.

Some of those goals were reached with AjMessages, but this time, I want a more clear kick off, based on the lesson learnt of my previous attempts.

First, I want to write down some basic ideas, to explain the motivation of the initial code written for AjProcessor. The basic idea, is to have message processors. A message processor is a code that receives a message, and process it.


The message has a payload (an arbitrary object, string, anything), and additional properties, with key/value.

Another essential brick in this lego-like application, is the element that publish messages. That is, there is a publisher:


An outgoing message could be received by any other code. The same message can be processed by more than one processor:


It’s like the publish/subscribe pattern. Another pattern to take into account, is a router-like component. Depending on the message (property, content), it could be send to different targets.


Frequently, a component will implement both roles, message processor and message publisher. In order to call plain old .NET objects, it would be nice to have a processor that receives a message, take some part of the message (i.e. the payload), and send it as a parameter to one its methods. The return value could feed a new message.


The components can be arranged as a chain, implementing a pipeline to process a message:


A more complex arrangement could receive a message, and forward it to different pipelines, according to some property or content in incoming message.


(this concept could be mapped to an application in AjMessage, but without the idea of distributed processing). A more interesting idea is to run that kind of pipeline routers in many machines


AjProcessor infrastructure is in charge of the serialization/routing/deserialization of messages between host machine. It could be WCF or anything else. The basic idea is to have a pluggable transport.

Well, these are the seed ideas behind the project. In an upcoming post, I’ll explain some of the current code (only few interfaces and classes, now).

Angel “Java” Lopez

March 4, 2009

Windows Communication Foundation configuration madness

Filed under: .NET, Software Development, Windows Communication Foundation — ajlopez @ 10:09 am

Windows Communication Foundation was created to support the creation of distributed applicacions, trying to give us a library of communication tools, so we can reuse it, without writing the service gateways and service interfaces from scratch. Technologies like web services, evolved, and there are many versions and details to take into account if you want to have secure, relaible and interoperable communication.

The concept of a Service Model, is a great advance. But today, I have to raise my hand, only to point to something makes WCF a convoluted solution. I’m referring to WCF configuration.

If you want to use any WCF feature, beyond the simplest one, quickly you’ll be fighting with the configuration options of this beast. What is the sympton? If you miss some minimal part, your channel doesn’t work. If you miss some configuration option when creating a certificate, if you forget to do one step in a dozen or more of “to do list”, your call will not work. And you have to manage a lot of concepts, like certificates, tokens, issuers, chain of trust, behaviors, bindings, endpoints, identities, custom bindings, factories,  service hosts, channel factories, security options, enumeration types, extensions methods, and …. I could continue for hours.

A minimal example. I just browsing the web, and I found the article

WCF (Windows Communication Foundation) Example

I read there:

Being able to switch the transport layer from TCP (Secure SSL) into HTTP with some simple code, that’s amazing!

Yes, but

I did have some problems, though. The tcpBinding.Security.Mode = SecurityMode.None; is very crucial on both sides. I’m not sure what it does, but it does not turn off the security completely as I have read in my references. There is still SSL encryption, but on a lower level. It is possible to add certificates to the connection, which also makes the connection more secure.

That’s the problem. If you play exploring the different properties and methods of binding and endpoints, you’ll enter a maze without visible exit. Notice that the author is not sure about one of the configuration he is using. And this is only one option: you have dozens more to set, if you want to fine tune your service.

Yes, there is declarative configuration. You can use the WCF configuration wizard:

Ok, can you see the three tabgs, at right? They have more options to fill and understand! Can you see the tree at left? It’s only the top of the iceberg. If you expand the bindings, you’ll enter a new Narnia world:

More properties to fill, and one more tabs! You begin to feel uneasy. If you have courage, create and expand  anything in the advanced branch:

The tree is becoming a amazonic forest. I could take snapshops of each branch this wizard exposes, to publish a complete volume. Most of these options ARE REQUIRED if you want to secure your service, use tokens issued by other systems, define the authentication of the client and service, and more. And my point is: if you fail in filling and defining a minimal part of this stuff, your system is a sand castle, a tower of cards in delicated equilibrium. This is the butterfly effect: a fly of a butterfly in one configuration file, could create an storm in your system. You must pay attention to too many details. It’s common to have to pay attention to details in software development. But I guess in this case, it’s too much: it’s insane to any single human mind.

In other systems, you have lot of options, too (remember the count of properties of any form control?). But you don’t need to master all (or halft) of the details. That is not the case with WCF configuration. This state of affairs sucks. And if you like to write down directly the XML configuration, you have to fight with something like this:


There are few uglier thing I met in my 30 years of software development (I could enumerate: EJB configuration, Cocoon ideas, Job Control Language in the old IBM mainframes…).

I have a theory. Enrico Fermi asked: if the extraterrestials exist, where are they? The story is: they exist. They began to study our planet (remember first “flying soucers”? They was seen at Mount Rainer at forties, near Seattle… yes, they were researching the origin of all this…). For decades, they read our literature, watch our film productions, made controlled experiments with some human beings. But when they began to study WCF and EJB configuration, our planet was doomed: they declared it under quarantine, we will be out of contact, isolated from the rest of the galaxy for the next ten thousand years. The humankind is a crazy civilization, there is no hope for our future.

Ok, I must stop whining. WCF has a great service model: now, it can manage JSON, XML, and it’s prepared to be flexible and extensible. But sometimes, we must stop the ball, and balance the flexibility with the accompaning complexity. This post is the result of days of fightings with WCF, WCF examples, documentations and guidelines.

Angel “Java” Lopez

October 18, 2007

AjMessages: a message processor

Filed under: .NET, AjMessages, Windows Communication Foundation — ajlopez @ 10:33 am

Following ideas from Fabriq project, I wrote last week an example of a server application that can receive and process OneWay Windows Communication Foundation (WCF) messages. The server can host applications, and each application is composed by nodes, that have actions. The example code can be download from

The message

The message to exchange is a WCF message (the original Fabriq was written before the WCF era). The main information that AjMessages uses is the Headers.Action property. This string has the name of the application, node, and action to invoke.

The action

It’s a string with format:


An application is a set of nodes. A server can host some or all nodes of an application. But the same node can run in different servers. In this way, the internal process of the server can forward a message to other server: the action is not a physical address, but a logical one. Each server knows the address and nodes in other servers, and then, it can decide to forward a message to another server.

The application

A configuration XML file define the applications to run. An application has:

  • Nodes: a collection of actions to process.
  • Handlers: objects to process a message. A handler can be a composite of other handlers.
  • Actions: named entry points to a handler

An example application definition:

  <Application Name="App1"> 
    <Node Name="Node1"> 
      <Handler Name="PrintMessageHandler" 
Type="AjMessages.PrintMessageHandler, AjMessages"/> 
      <Handler Name="PostHandler" 
Type="AjMessages.PostHandler, AjMessages"/> 
      <Handler Name="DecrementHandler" 
Type="AjMessages.Console01.DecrementHandler, AjMessages.Console01"/> 
      <Handler Name="Pipeline1"> 
        <Handler Name="DecrementHandler"/> 
        <Handler Name="PostHandler"> 
          <Property Name="Action" 
      <Action Name="Process" 
    <Node Name="Node2"/> 


The handler

A handler must implements an interface:

    public interface IHandler 
        void Process(Context ctx); 

The context has a property Message, that points to the WCF message in process, and some other methods to use: a Server property that reference to the current server object, and a Post method, to send a new message. The idea is to put in the context all the needed external functionality to the handler, so this is decoupled of the server and message in process.

This is a departure of the original implementation in Fabriq, where the handler receives a message, not a context.

The host

A host is a logical unit that runs inside a server. A server is informed, via configuration, the hosts that are available in other servers, and which ones are local. An example:

  <Host Name="Host1" 

<Application Name="AjMessages"> 
      <Node Name="Administration"/> 
    <Application Name="App1"> 
      <Node Name="Node1"/> 
      <Node Name="Node2"/> 

Dynamic configuration

One of the key features implemented is a handler that reconfigure in runtime the running server. It receives a new XML configuration, and merges it with the current information. Then, using these handler, an application can send a message to a AjMessages server, and load, stop, update hosts, applications and nodes.

The solution

The class library AjMessages project contains the implementation of the example. The other projects are manual test to run that shows how to use the example.

Inside Configuration folder there are classes defined to load configuration data from an XML structure.

Handlers folder contains some predefined handlers to use, an important one is the ConfigurationHandler that permits to reconfigure dynamically the server while it’s running.

Ports folder has implementations of endpoints to receive and send message from an to other AjMessages servers.

PipelineHandler.cs is the composite handler, that contain other handlers.

LocalHost.cs is the implementation of a host running in the current server. It mantains a list of active nodes.

RemoteHost.cs mantains the info associated to a host running in other servers. Using this information, the local server knows how to forward a message, inspecting the remote hosts that have an active node.

Running the example

There is a console project AjMessages.Console01 that can be used as a manual test.

You can run the example, and enter the commands:

load ConfigurationServer1.xml
load ConfigurationHost1.xml
load ConfigurationHost2.xml
send App1/Node1/Process 20

The first command creates the server, using the configuration file. The second and third command reconfigure the server to install and run two hosts, with its applications and nodes. The last command send an integer message using App1/Node1/Process as action.

After that, you enter:


These launch another server console program. In the first one, enter:

load ConfigurationServer1.xml
load ConfigurationHost1.xml
load ConfigurationRemoteHost2.xml

and in the other server, enter:

load ConfigurationServer2.xml
load ConfigurationHost2.xml
load ConfigurationRemoteHost1.xml

In anyone, enter:

send App1/Node1/Process 20

and you’ll both servers exchanging messages.

In any moment, you can enter:


to obtain a list of commands to use.

Next steps

In a future installment of the example, I’ll rewrite the application to use a custom Message, capable of be transported via WCF, or DSS (Decentralized System Services), so the example could be hosted in different technologies. I must refactor some classes, for example, Server, that has many responsabilities.

Comments, suggestions, welcome!

Angel “Java” Lopez

October 15, 2007

Remember Fabriq

Filed under: .NET, Windows Communication Foundation — ajlopez @ 12:15 am

The last weeks I studied the code of Fabriq project. You can download the code from Arvindra Shemi’s blog post:

FABRIQ has gone public!

More information about the project at:

Arvindra Shemi Fabriq Articles
Clemens Vasters Fabriq Articles

An image from the docs:

According to the project documentation:

FABRIQ is an infrastructure for constructing networks of nodes processing and relaying messages. These nodes are hosted in machines running into a serviced application.

You can have multiple machines running the same or different applications. The “network” is the application, “node” is a collection of “actions”, and each action process a message. More doc:

These nodes can be hosted in any distribution on several machines according to a defined configuration, so there may be machines running a single node or several nodes, this association are made by specifying the host-name or machine identification associated with each node in the network.

Each of these machines is running a serviced application responsible for starting and stopping its Host and Nodes which are the application main components. The host is responsible for handling the configuration, loading and unloading nodes and receives the messages and delivers them to the appropriate Node.

An interesting article that goes to the guts:

Positioning FABRIQ – What? Why? Apple or Orange?

Technically oriented articles:

FABRIQ Terminology
A simple FABRIQ config file
FABRIQ Message Handlers and Pipelines
FABRIQ Networks and Nodes
Configuring FABRIQ Networks and Nodes

I think that all these features can be reimplemented using current technologies (the published project use .NET 1.x, COM hosting), as Windows Communication Foundation, or the new distributed services of Microsoft Robotics (DSS).

In the first case, the Message to exchange and process could be the System.ServiceModel.Channel.Message class from WCF. But another idea is to have a custom Message class, that could be serializable via differents transports: WCF, DSS, Remoting, Web Services, or anything else.

I’m working on rewrite from scratch the full idea, with dynamic configuration, load balancing, in WCF or in other base technologies. I borrowed some ideas from my old project AjServer:

Hacia el AjServer (Spanish)

An extract from a configuration file:

<?xml version="1.0" encoding="utf-8" ?> 
  <Application Name="AjMessages"> 
    <Node Name="Administration"> 
      <Handler Name="ConfigureHandler"  

Type="AjMessages.ConfigureHandler, AjMessages"/> 
      <Handler Name="PrintHandler"  

Type="AjMessages.PrintHandler, AjMessages"/> 
      <Handler Name="PrintMessageHandler"  

Type="AjMessages.PrintMessageHandler, AjMessages"/> 
      <Handler Name="ConfigurePipeline"> 
        <Handler Name="PrintHandler"> 
          <Property Name="Text"  

Value="Reconfiguring server..."/> 
        <Handler Name="PrintMessageHandler"/> 
        <Handler Name="ConfigureHandler"/> 
      <Action Name="Configure" Handler="ConfigurePipeline"/> 



  <Host Name="Host1" Address="http://localhost:50000/AjMessages"> 
    <Application Name="AjMessages"> 
      <Node Name="Administration"/> 
    <Application Name="App1"> 
      <Node Name="Node1"/> 
      <Node Name="Node2"/> 

I have a running version, with WCF and without WCF. I hope to post about my advances these days.

Angel “Java” Lopez

September 6, 2007

Windows Workflow hosted as a WCF Service

I wrote an example about using two new features of Windows Worflow Foundation shipped in .NET 3.5: the workflow can be hosted and exposed as a Windows Communication Foundation Service, and the use of Receive Activity. I used Visual Studio 2008 Beta 2, as the IDE. This post it’s not a detailed step by step. It pretends to highlight some procedures and concepts.

The code can be downloaded from

It’s a minimalist example: a workflow instance is created, it waits for an external events, then it continues, writing a line to the console. Simpler, impossible.

The example contains a solution with:

– A console program that hosts and expose a sequential workflow.

– A client console program

– An interface, used by both programs

– A Sequential Workflow Library, with a Receive Activity, and a Code Activity.

This is the appearance of the final workflow design:

The workflow process an order, for a fictitious restaurant. First, I created a class library project, to define the common interface:

This interface define two methods: one to cook the order, and other to cancel it. The example only uses the cooked method (we’re optimistic), and nothing more. But in a more evolved example, we can include a create order method, and some decision branch in the workflow.

Note the using of System.ServiceModel, to mark with WCF attributes the interface and its methods.

In the Sequential Workflow Library, I initially dragged a Receive Activity:

It’s a new activity, that is in the revamped toolbox:

When you add the Receive Activity, it must be completed with a Service Operation Info (more about another important property in a following paragraph):

You can clicked on the ellipsis, to use a dialog:

Notably, you can create a contract, without write the interface. But, in this example, I choose to import the interface that I’d previously defined. Then, using the Import… button, you can select the interface, from the referenced assemblies (the workflow library project reference the class library project containing the interface definition) :

Pressing the OK button, you can select the method to use to invoke the Receive Activity:

The receive activity waits until an OrderCooked method invocation is received. This is a new way to manage the incoming events on a workflow. The interface contract will be exposed as a WCF service.

I added a code activity, after the receive activity, and wrote a simple code to write a message:

A host console program creates a Workflow Runtime, hosted under WCF:

Note the use of the new WorkflowServiceHost class, and the adding of a service endpoint to expose the order interface.

The client console program programmatically creates a WCF channel that use the interface, only to create a workflow instance, and make it advance, sending an OrderCooked method invocation:

You must notice that the program never create a workflow instance. Where is the instance created? Remember the Receive Activity: it has a property CanCreateInstance, and I set it to True:

In order to test the solution, I modify its properties, to launch the client and the host project at the same time:

And voila! Client outcome:

and Host outcome:

It’s not the ultimate workflow demo, but I hope that it will be useful to show these new features from .NET 3.5.

Thanks to Southworks and the Tamesis team, for the support to write this post.

Angel “Java” Lopez

March 6, 2007

Windows Communication Foundation Special on

Filed under: .NET, Windows Communication Foundation — ajlopez @ 5:43 pm

I’ve received a message from

Windows Communication Foundation (WCF) is poised as an architecture ready to enable interoperable services. For many people it will be the way they connect their existing .NET applications. To help you, TheServerSide.NET, together with sister site, has aggregated links to some of the sites’ relevant content on WCF.

More info at:

Blog at