Wednesday 21 October 2009

NetworkMonitor: my new view of the structure

During the last few weeks I have been reading a lot about software architecture and how other people do things. I found out that it is very easy to create a publish/subscribe system that makes it easy to send messages from one place of the system to somewhere else. I see it as an ideal method to communicate between Bounded Contexts.
With this knowledge I was thinking about how I can structure NetworkMonitor in a loosely coupled way.
  • Scheduler
  • Command runner
  • Host/Service state

Scheduler

The scheduler has the important task to keep a list of scheduled items, this can domain specific things like running commands to check the state of host/services, but also application things like do a log rotation.. The Scheduler can be very generic so that it supports a lot of different items.

Command runner

The command runner will do the actual actions for getting the state of hosts/services. It will run the command and wait for the response, the response will be parsed and the state of the host or service will be set.

Host/Service state

The state of hosts or services can be very simple, but when the state changes to an unexpected state, several things should be done. The Host/Service state has the responsibility to schedule new commands based on the current state, and will be used to show the user the state information.

The missing link

The three subsystems are very different from each other, but they should still communicate with each other. The problem here is how do they communicate.
Before we can answer that we should know where each part is in the system.
I see three possibilities:
  • They are all in the same application
  • They are in different applications on the same computer
  • They are on different places in the network/world
When we choose for only the first option, it will be easy. We can use simple event (like windows messaging or .net events), but this won't work when we need to support the other solutions.
The other two solutions need some kind of messaging system over the network/memory. The same method we can use when we have all the systems in the same application.
What I am thinking about is a Publish/Subscribe pattern.
In short the pattern has one class where all publishers post messages to, and everyone that want to respond on a message, adds(subscribes) itself as listener to that same class. When a message is send, the class will go over every listener and post the message.
How this is done over a network I am not sure yet, but I think it should be possible.

That it for this moment.. I've got a lot of ideas and will try to implement them. But first I have to do some work...

No comments:

Post a Comment

Note: only a member of this blog may post a comment.