New article about Erlang available

The subscribers of the German iX magazine already got it on Tuesday, today it's available in trade: my 30th article! It's an almost 5 pages introduction into the history, the basic principles, and the areas of application of Erlang. So enjoy it, any comments are welcome.

Erlang development progress

After a short break - I've finished my article about Erlang for the German iX magazine - my Erlang development continued. I've spent most of my time into the improvement of the Tidleland CEL Lightweight Message Bus (CELLMB) which is now working really smooth. First approaches have been too complex but now it's simple and fast. I've don't really implemented a bus, Erlang already has a very good communication infrastructure. So I only use this. The major component is a supervisor managing and monitoring the services. Those are locally registered processes based on gen_server and with own service-depending callbacks. So e.g. the statement

{ok, Reply} = cellmb:request(Ctx, configuration, read, {my_app, my_group, path, to, my, var})

leads to the call of

my_cfg:read(Ctx, {my_app, my_group, path, to, my, var}, State).

Management and lifecycle are implemented in cellmb and cellmbsvc, so the writing and usage of own services is really simple. The next advantage is the semi-automatic distribution of messages. So imagine the following situation: due to a mix of load-balancing, a higher availability through redundancy, and the access of local resources the node alpha provides the services one and two, the node beta the services two and three, the node gamma the services three and four, and the node delta the services four and one. Each service is located on two nodes but each node doesn't provide all services. In other configurations there also may be a different distribution of services, e.g. non-overlapping or some services on all nodes. Clients of the CELLMB don't have to care. So if a client on node alpha publishes the message

{ok, Reply} = cellmb:request(Ctx, three, do_something, Args)

the system will discover which node provides service three - here the nodes beta and gamma - and establishes a proxy service to one of them. The message will then be resend through the proxy, like all following messages. If a connection is broken during the operation the system tries to establish a new one or - in case of a failure - throw an exception. So there are still some features missing, like a simple SOAP client interface, the migration of services between nodes during runtime, and pro- and post-processing of messages matching a defined pattern. The latter is intended for a kind of aspects. I'll add those features later when - or if - I need them.

Currently I'm implementing the first common services. The status will be documented in our wiki. Most of the standard implementations will use Mnesia for the persistency. My first trials have been really promising.