Angel \”Java\” Lopez on Blog

July 13, 2014

SharpBus in C# (1) First Steps

Filed under: .NET, C Sharp, Open Source Projects, SharpBus, Test-Driven Development — ajlopez @ 11:54 am

Last month I started to write SharpBus, a simple message processor inspired by ideas from Mule Java project. See:

As usual, I’m using TDD (Test-Driven Development), implementing small use cases and API consumption, in the simplest possible way. In fact, the project is a personal exercise of TDD. I hope that some may be useful beyond that. For now, it is an example that I want to share my workflow.

You can see the progress in:

The main ideas to implement are:

– There are Messages containing Payloads and Properties (dictionary of name / value)

– There Flows that process messages

– A Flow is composed of several elements

The elements can be chained in the flow, and can be:

– A Transformer, taking a payload or complete message, and returns a transformed version

– A Processor, taking a payload or complete message, operate on them, maybe accessing the business domain, but without transformation

– Input, a payload/message producer

– Output, a payload/message consumer, at the end od the Flow process

– A Rourter, given a payload/message, it decides with Branch to follow in the Flow. Each Branch is identified by a name.

There will also be items that can issue new posts than the current, and can issue them to different flows in the system. The message producers should be able to run threads (Threads) in principle. And there will be a set of threads (Pool of Threads) attending the incoming messages and deriving them to the respective flows.

A flow can take a message and return a response (Request / Response), or it can take a message, process it without returning an answer.

Some items need complete Message and other items operate over the Payload.

The elements in the world of Mule / Java are objects. Notably, in C #, the simplest way to implement is using lambdas. So, following TDD, the early testing and deployment has come out that way. You can see in some simple tests:

As an example of send a Payload and receive an answer, using an empty Flow:

var flow = Flow.Create();

Assert.AreEqual(1, flow.Send(1));

To send a payload and transform it:

var flow = Flow.Create()
    .Transform(x => ((int)x) + 1);

Assert.AreEqual(2, flow.Send(1));

The .Transform Transform expects a Func<object, object> which may be provided at the time with a lambda. In a classic Java 7 Mule, we should provide an object that implements an interface having a method to transform the Payload. I have to think whether it is worth having a typed Transform <T> (receiving T and returns T), or Transform <T, S> (receiving and returns T S).

I decided to build the flow by code. In the Mule environment Spring is used to set up the flow using XML. I think it is time to explore this other way, build the flow by code, and put it as the "first way", ie, as the way on which everything else could be mounted. If anyone ever needed a DSL (Domain-Specific Language) for creating flows could be implemented this way by having well designed code.

Following TDD, I still have not a case of using a Message (a complete message with content (Payload) and properties (Properties, a name / value) dictionary. All of the above is to process Payload directly.

Upcoming topics: add Message Payload with the output of messages, routing, assembling branches, etc. ..

Stay tuned!

Angel “Java” Lopez

June 27, 2014

End Of Iteration 2014w25

Previous Post
Next Post

Code Generation with AjGenesis

I published a new version of

My code generation tool, based on Node.js. Now, it can preserve files in generate tasks (if you want one of your files doesn’t overwritten). But the key change was to put models under current project directory, ajgenesis/models folder. In this way, I can put all the AjGenesis-related stuff in only one directory related to current project. So, I refactored and republished the modules and examples of:

Next steps: refactor to use the new directory, and refactor/complete the generation process in Express, Sinatra, Laravel, Django projects.


I worked on

implemented a simplified Mule-like message flow in C#, using TDD (Test-Driven Development). Now I have: input, output, transform, processors, routers, branches in flow. It was nice to see all in place, using “baby steps”, and the powerful lambdas of C#. I implemented transformer objects too. Next steps: instead of simply process a payload, start to process a complete message.


After attending a JavaScript meetup at Buenos Aires, I wrote a simple JavaScript curryfing function library:

Since then, I started to add some additional pieces, like partial application, and composition of functions.


Thanks to @fabiomaulo, I met state machine implementations in C#. So, I wrote my own version in JavaScript:

It has a fluent interface to define states, with triggers and actions. Next steps: add global triggers, and hierarchical states.


I added some functions to core and REPL. I worked on four private projects, too. More fun is comming.

Stay tuned!

Angel “Java” Lopez

June 20, 2014

End Of Iteration 2014w24

Filed under: .NET, C Sharp, Iteration, Mass, Open Source Projects, SharpBus, SharpGo, SharpMongo — ajlopez @ 6:27 pm

Previous Post
Next Post


My Go Programming Language interpreter in C#

I added typed nodes to Abstract Syntax Tree, and nodes that generate expressions instead of commands. The types will help me to determine if an expression is valid or not, according to Go type specifications.


The Mass programming language interpreter

I reimplemented binary arithmetic operations (and string concatenation) without using ObOps, but directly using compiled lambda expressions. Next steps: removing ObOps dependency from compare operations. I think that a compiled lambda is a better outcome for such expression.


My in-process, in-memory implementation in C# of a document database with a MongoDB-like interface:

I fixed source analysis issuses, and added .count method to collections and to collection objects in REPL.


I started

A simple message bus implemented in C#, inspired by Mule. Notably, the flow of message can be defined using lambdas (something missing in Mule Java up to version 7). Using TDD, using fluent interface, consuming lamdbas, is the simplest way I found to implement a message bus.


I worked fixing scripts in My parser “generator” was  converted to VisualStudio 2010I worked on four non-public projects. More fun is coming.

Stay tuned!

Angel “Java” Lopez

Create a free website or blog at