3

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. Design sketch

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.
Community
  • 1
  • 1
Chris Walton
  • 2,513
  • 3
  • 25
  • 39
  • @S.Lott As stated in the question I am developing it initially for Windows 7. Future implementations could well involve making the UI element web based, running against a Linux server hosted backend. I do wish to design it in such a way that I do not build obstacles to future developments of this sort. – Chris Walton Jan 27 '11 at 00:36
  • Sorry. The tags usually include the operating system. I was unsure why the OS was omitted from the tags. – S.Lott Jan 27 '11 at 00:56
  • What are the volumes of events? How many per second? How much data is associated with each event? How much history is going to be kept? – S.Lott Jan 27 '11 at 00:57
  • @S. Lott I did not add a tag for the OS because I want to incorporate as much deployment flexibility as possible into my system. – Chris Walton Jan 27 '11 at 01:01
  • 1
    When talking to different architectures, you may face challenges wrt what the other architectures expect from pipes. WhenI used named pipes (2002?), I was talking to a RS/400 or some such and while my Delphi pipe client and test server communicated ok (running on different machines), I could not establish a connection with the RS/400. It kept waiting for additional bytes/characters on the pipe. A simple pipe client put together in VB6 (yikes) worked in a single attempt... Things may have changed, but it's something to bear in mind using pipes instead of TCP/IP based communication. – Marjan Venema Jan 27 '11 at 07:29
  • @S. Lott volumes of O(10^2) per second; data sizes not yet fixed but typically likely to be O(2^9) per event; no event history to be kept, though changes arising from the events will be stored. – Chris Walton Jan 27 '11 at 20:11
  • @Marjan - valuable points to bear in mind. I may need to look at TCP/IP (does this automatically imply sockets?) as a primary mechanism. – Chris Walton Jan 27 '11 at 20:14
  • @Chris: yes, TCP/IP means sockets... – Marjan Venema Jan 27 '11 at 20:28

4 Answers4

3

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:

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.

mjn
  • 36,362
  • 28
  • 176
  • 378
  • Am I right in thinking that you are assuming that all these message brokers will handle events - it may seem basic, but this is one of the points I was not clear on. – Chris Walton Jan 27 '11 at 12:57
  • 1
    Message brokers are mostly used transfer simple data types or key/value maps to keep performance, but can also transfer serialized objects - if the events are serializable or can be expressed with simple datatypes, the broker can handle them. – mjn Jan 27 '11 at 19:38
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).

I GIVE CRAP ANSWERS
  • 18,739
  • 3
  • 42
  • 47
1

I suggest to look at RabbitMQ, http://www.rabbitmq.com/. It has the server and client. Just need some wrapper codes in delphi and you are ready to build your business logic

Cheers

APZ28
  • 997
  • 5
  • 4
  • You can use the components [mentioned](http://stackoverflow.com/questions/4811734/what-elements-are-needed-to-implement-a-remote-event-driven-system-overview-n/4813453#4813453) by that [mjn](http://stackoverflow.com/users/80901/mjn) for that. They are good. – Jeroen Wiert Pluimers Jan 27 '11 at 09:52
0

This is probably just an application for a message queue.

http://msdn.microsoft.com/en-us/library/ms632590(v=vs.85).aspx

S.Lott
  • 384,516
  • 81
  • 508
  • 779