Angel “Java” Lopez on Blog

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 AjMessagesWCF-0.1.1.zip

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:

<application>/<node>/<action>

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"
Value="App2/Node1/Process"/>
        </Handler>
      </Handler>
      <Action Name="Process"
Handler="Pipeline1"/>
    </Node>
    <Node Name="Node2"/>
  </Application>  



 

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"
    Address=http://localhost:50000/AjMessages
    Activate="true">
      

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

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:

unload
fork

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:

help

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
http://www.ajlopez.com/en

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" ?>
<AjMessages>
  <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>
        <Handler Name="PrintMessageHandler"/>
        <Handler Name="ConfigureHandler"/>
      </Handler>
      <Action Name="Configure" Handler="ConfigurePipeline"/>
    </Node>
  </Application> 

  

... 

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

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

Angel “Java” Lopez
http://www.ajlopez.com/en

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 HostingWorkflow1.zip.

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
http://www.ajlopez.com/

I’ve received a message from www.theserverside.net:

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 SearchVB.com, has aggregated links to some of the sites’ relevant content on WCF.

More info at:

http://www.theserverside.net/tt/articles/showarticle.tss?id=WCFSpecial