What elements are needed to implement a remote, event driven system? - overview needed

Question

I am trying to design an event driven system where the elements of the system communicate by generating events that are responded to by other components of the system. It is intended that the components be independent of each other - or as largely independent as I can make them. The system will initially be implemented on Windows 7, and is being written in Delphi. The generated events will be generated by the Delphi code. I understand how to implement a system of the type described on a single machine.

I wish to design the system so that it can readily be deployed on different machine architectures in particular with different components running on a distributed architecture, which may well be different to Windows 7. There is no requirement for the system ever to communicate with any systems external to itself.

I have tried investigating the architecture I need to consider and have looked at the questions mentioned below. These seem to point towards utilising named pipes as a mechanism for inter-hardware communications. As a result of these investigations I have sketched out the following to describe my system - the first part of the diagram is the system as I am developing it; the second part what I have deduced I would need for possible future implementations.

This leads to the following points:

1. Can you pass events via named pipes?
2. Is this an appropriate and sensible structure to tackle this problem?
3. Are there better alternatives?
4. What have I forgotten (at this level of granularity)?

How is event driven programming implemented? How do I send a string from one instance of my Delphi program to another?

EDIT:

I had not given the points arising from "@I give crap answers" response sufficient consideration. My initial responses to his points are:

1. Synchronous v Asynchronous - mostly asynchronous
2. Events will always be in a FIFO queue.
3. Connection loss - is not terribly important - I can afford to deal with this non-rigourously.
4. Unbounded queues are a perfectly good way of dealing with events passed (if they can be) - there is no expectation of large volume of event generation.

Answer 1

For maximum deployment flexibility (operating-system independent), I recommend to take a look at popular open source message brokers which run on the Java platform. Using standard protocols. they integrate well with Delphi and other programming languages, can be used with web applications, and have a large installed user base and active community.

They are quite easy to install and configure in a few minutes, and free / commercial clients for Delphi are available.

Some examples are:

• Apache ActiveMQ

• OpenMQ

• JBoss HornetQ

I also recommend the book "Enterprise Integration Patterns" by Martin Fowler as an overview and introduction, with many simple recipes to handle specific problems.

---

Note that I am a developer of commercial Delphi clients for enterprise messaging systems, such as xmlBlaster, RabbitMQ, Amazon Simple Queue Service and the three brokers mentioned above.

Answer 2

I can only answer for your point 4 here: You have not yet decided if an event is synchronous or asynchronous. In the async case, you have to decide what to do when messages arrive. Do you have a queue? How big is the queue? Can one grab arbitrary elements in the queue or is it strictly FIFO. What happens if a message is lost (somebody axes the network cable)?

In the sync variant, the advantage is that you got delivery guarantees, but then what do you do when connections are suddenly lost?

Connection loss is going to be a problem. The more machines you have, the greater is the chance that they will occur. Decide how you will handle that.

Another trouble may be what you do if you have a large event and several small. Is the order of transfer FIFO or smallest-first? Can events be reeordered? What are the assumptions here?

---

The aside is that I hack Erlang a lot. In Erlang all the event-handling is already solved but it also means a specific model is chosen for you (async, unbounded queues, no guaranteed delivery, but detection of connection loss).