Embrace change

Yesterday I've introduced the new architecture of the Tideland EAS - formerly known as "Events and Services", now the "Erlang/OTP Application Server". One of the new concepts is the definition of agents for the control of business processes. Those agents are typical callback modules working like finite state machines. The state change is done by internal code, by the returning from services calls, or by the arguments of an external continuation after reaching a waypoint.
 
So here's one example of how to use the agent API from a view or a connector. First the agent will be started, then the reply will be handled asynchronously. Both, the agent and the reply call have a timeout. The first one defines the timespan in which the agent should complete its work, the second one is just for the reply call. 

start_agent(Args) -> 
  % my_agent is the name of the callback module. 
  easagt:start(my_agent, Args, {5, hours}). 
 process_agent(Aid) -> 
  case easagt:reply(Aid, {5, seconds}) of 
   {waypoint, foo, Info} -> 
     ContinuationArgs = handle_foo(Info), 
     easagt:continue(Aid, ContinuationArgs), 
     process_agent(Aid); 
   {waypoint, bar, Info} -> 
     ContinuationArgs = handle_bar(Info), 
     easagt:continue(Aid, ContinuationArgs), 
     process_agent(Aid); 
   {finished, error, Reason} -> 
     {error, Reason}; 
   {finished, ok, Reply} -> 
     {ok, Reply}; 
   {error, timeout} -> 
     {error, timeout} 
  end. 

This is a very simplified code fragment, but it shows how a running agent can stop working when reaching a waypoint where external action - or interaction - is needed. The last shown error is the timeout of the reply call, the inner one can also be a timeout, in this case caused by the agent. If the timeouts aren't passed as integers representing milliseconds the time library of the CEL calculates them based on the tuples.
 
The control of state changes inside an agent is done through the result of the current processing.

process(foo, Args, StateData) -> 
  % Do something ... 
  {next, bar, NewArgs, NewStateData}. 
 process(bar, Args, StateData) -> 
  % Do something else ... 
  {call, [{svc_a, req_a, ArgsA}, {svc_b, req_b, ArgsB}], baz, NewStateData}. 
 process(baz, ServiceCallResults, StateData) -> 
  % Do something with the service call results ... 
  {waypoint, baz, Info, yadda, NewStateData}. 
 process(yadda, ContinuationArgs, StateData) -> 
  % Do something with the continuation args ... 
  {stop, ok, Result}. 

It's easy to see how one or more services can be called, the processing will continue when all services replied or after an optional timeout, or the control can be passed to an external waypoint. Additionally simple service calls can directly be done inside the callback functions. 

{ok, Reply} = eassvc:call(svc_x, req_x, ArgsX, Timeout) 

This API isn't stable yet, but it shows the direction. I'll write more about it here.

Loading mentions Retweet

It's time for a change, a deeper change. A change based on the experiences made during the development and testing of the EAS like it works today. The original idea behind the EAS has been an event-driven architecture where services subscribe to different types of events - therefore the name EAS, events and services. Additionally the platform contains a generic complex event processing. This system now works fine, only the timeout mechanism for replies and time based event processing is missing. So far so good.

 But there's still one problem. The idea has been that business process are a flow of events. Each step can raise one or more events that will be handled then. It's a simple idea, but it's hard to handle. The managing of the control flow is hard, especially when a change is needed. That's not worth it. So the idea of changing the design came up. There are still services, which handle requests asynchronously. Additionally there are agents, each one is a kind of state machine representing a business process. The third part is the complex event processing, still based on subscriptions.

Due to the experiences with the EAS the prototype for this new design will be available soon. The persistence of requests, replies, and aggregations together with the dispatching mechanism like it is implemented today supports the scalability using of large number of nodes in parallel. So the new approach can fulfill the requirements together with an easier API for the later implementation of services, business processes, and event processings.
 
One additional thing that helped a lot during the redesign has been my first usage of the Fundamental Modeling Concepts (FMC / http://www.fmc-modeling.org/). It really helps to design and document software-intensive systems in a simple, clear, and esthetic way. Beside static views like above dynamic ones are supported too. So I'll test it more.

Loading mentions Retweet

I thought a bit about my idea for a next generation Tideland EAS and now made a decision. It is really an appealing idea building a new integration platform for event-driven solutions based on technologies like JSON, HTTP, and JavaScript for the service subscription. But that's not my goal. I've got real applications in mind, currently three different ones. And the EAS is just intended to be the backend framework which allows to implement them as event-driven solutions which work reliable in a 24/7 environment. So I'll continue the development as planed. Additionally I've started writing a small article about my motivation for event-driven architectures on http://www.tideland.biz which will be published soon.

Loading mentions Retweet

When I started the development of the Tideland EAS I had a small pure Erlang event-driven architecture in, just as the middleware for my apps. But sometimes ideas assume in an independent existence. OK, the old concept would also benefit from the reliability and scalability of Erlang/OTP, but not as much as it is in the possibilities of this platform.
 
So, while reading about and evaluating CouchDB, my concept changes. I'm currently thinking about reimplementing it as a real middleware for event-driven architectures. This draft gives a better insight:

The black steps (1) to (3) show the subscription process where a service provider sends a JavaScript filtering the subscribed events. The EAS will store some administrative data, like the ID of the subscription and the service provider, and sends the JavaScript to CouchDB as the database server. CouchDB uses the script to create a view for the subscription.
 
The red steps (1) to (6) show the event processing. A raised event sent to the EAS will be stored inside the CouchDB event table and will so also be visible in all matching views. In case of a polling service the new events will be retrieved and sent to the service. It now can process the event and send the reply or new continuing events back to the EAS. Finally - if wanted by the event source - a reply will be sent back.
 
There are still several open aspects I've got to think about. But I think it looks promising. I'll test the concept with a quick prototype.

Loading mentions Retweet

During the last days I've had to stop my development on the Tideland EAS due to the migration of my root server to two new ones. Now my own projects as well as my customers do have a better environment.
 
But after that I've been able to continue the work on my small event-driven middleware for Erlang based solutions. The completion of a test business process helped to make the API for service developers more simple and consistent. Additionally the configuration and the error handling have been improved. Now there's only the configuration - and usage - of functions for the preprocessing of events and postprocessing the results is missing for a beta release. They are intended to allow the transformation of data from one format into another if e.g. two service interfaces doesn't fit.
 
After this extension the functional part for release 1.0.0 is complete. But I still have to add some functionality for reliability and scalability. So the dispatcher shall notify others if a service registers or unregisters. And in case of a restart through the supervisor they shall retrieve the registered services from other nodes. The same is needed for the configuration. So still some work to do, but that's exactly Erlangs playground. *smile*

Loading mentions Retweet

Even after more than 25 years of software development I sometimes forget some of the best practices. This time the principles KISS and YAGNI during the development of my platform for EDA, the Tideland Events and Services. I discovered it during the development of test services and test cases. Due to the adding of a too high flexibility the API got unhandy. So I started to change it and discovered that the internal architecture tries to cover by far too much cases - independent of their likeliness.
 
So now it's time for a larger refactoring with the goal to strip everything down to the original intention. Beside the fact that the API and the usage will get easier the code will also decrease. That's a good result for the future maintainability.

Loading mentions Retweet

But that doesn't mean that I've stopped everything. Beside the continuing of our renovation - only the rear corridor and some smaller tasks are left - I've continued my development and started the preparing a conference session. And both are about very similar topics. I'm now working with distributed solutions since many years, but mostly typical N-tier applications with horizontal scaling using multiple web or application servers, EAI, or SOA. Now my focus switches to concurrent distributed solutions and EDA.

Today we more and more get networked using system with more and more processors or cores. IT systems are woven into our work and into our private life. So while in earlier times it has been enough to write an application which behaves almost autistic and concentrates on doing things one after each other developers today have to handle more complex scenarios. Their systems have to be able to parallelize work to use the new infrastructure, react on different kinds of stimmulations and events, analyze them if they are related, and process them the regular way as well as perform autonomous actions based on the analyze results. The typical flow inside an application is changing and gets more and more natural.

While this may lead to extreme powerful solutions the developer needs an infrastructure to develope and operate them. Especially the dynamic behaviour resulting out of the event evaluation is hard to control and even harder to debug. So my Tideland Events and Services tries to provide an infrastructure for event-driven applications based on Erlang. It contains - or will contain -

• services for the processing of events,
• channels for the distribution of events to subscribed services,
• aspects for the pre and post processing of events,
• automatic service and channel discovery in a network of nodes,
• restoring of service states in case of a service restart, and
• contexts as an environment for related events.

Loading mentions Retweet

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

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

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

Loading mentions Retweet