1

We've got a spaghetti mess of an application that I've been tasked with rebuilding. I really want to make the new code much more flexible, and also more distributed.

On a basic level the application collects data from hardware, performs some control actions, displays the data, and lets the user send settings to hardware.

There was no separation, the code was hardware specific, no data access layer/disconnect between data, backend, control, and eventually UI. It was a horrible mess when we had a hardware change, and everything had to be reworked. It was also a single application on a single computer, yet we need it to be more modular. Maybe one server collects data and makes local control decisions etc, and when it has a link uploads that to a central database.

I'm trying to come up with some architecture/design patterns that will help with this and I've seen Event Aggregator come up a lot. However, it seems mostly aimed at the UI side of things, whereas I'm thinking of a cross-service/application messaging.

Does this sound like a sensible design? Does it sound like any design patterns out there? I don't want to re-invent the wheel.

The main principle of event agragators, that the source and consumer of the events know nothing of each other seems like it could be difficult to achieve when they don't share an application.

enter image description here

1 Answer 1

Reset to default
1

I think you are on the right track with Event Aggregator.

Consider the alternative which is Observer pattern and you realize that there are multiple sources of hardware events that one must have handling logic to observe on and make decisions. Martin Fowler does a better job than I do about explaining the advantages of Event Aggregator here.

Also consider all of the important Quality Attributes of your system and allow those most important attributes to drive your architectural decisions here.

  • Modularity
  • Interoperability
  • Composability
  • Maintainability

A message driven architecture utilizing Event Aggregator pattern can address the consolidation of messages being created from components and do a number of things with this.

  • One option is that if this data must be persisted, it makes sense to transform the message into a common data format and persist in a data store/file/database. Another Service component can read data from the database for reporting and status
  • Another option is that the aggregator component can instead publish a message to a Topic in a common format and multiple recipient components subscribing to that Topic will receive the message and choose to potentially store data in their own store or do something else with the data entirely in real time. Information on Topics http://activemq.apache.org/how-does-a-queue-compare-to-a-topic.html

I see the Hardware abstraction software components sending unprocessed data messages to a Remote Queue. These messages all transmit to a Local Queue that the Aggregator component will listen on for incoming messages. It can then transform the data into a common format and either publish a message to a topic or save the data in a database. This Aggregator could also optionally handle sending messages in the opposite order via different messsage queues to various Hardware abstraction components for configuration changes. You could also have a separate Aggregator component and process to handle this use case.

Now you can build services against your database for read data requests, and against a message queue for incoming configuration changes.

This gives you separation of concerns, easier modularity when standing up software components, ease of maintainability and abstraction from hardware changes, and greater flexibility on the GUI side to have multiple types of user interfaces (Desktop application, web application, mobile, etc...).

4
  • Would something like ZeroMQ work to subscribe/publish these messages?
    – Joe
    Commented Sep 14, 2016 at 16:00
  • @Joe Theoretically yes, however it is a very lightweight client and doesn't support things like transactional processing (Rollback, Retries, Backouts, etc...) and persistent queues (avoiding downtime message loss). This question really comes down to, "How serious is the situation if I were to lose a message or fail to process it?" If the answer is "Not much" or you have some margin of error then ZeroMQ is appropriate.
    – maple_shaft ♦
    Commented Sep 14, 2016 at 16:10
  • Ah, I see you were linking ActiveMQ, I missed that - I see how that could be more appropriate. Thanks!
    – Joe
    Commented Sep 15, 2016 at 8:31
  • @Joe No problem. Architecture is a discipline of itself. The most important takeaway I stress to people is to determine non-functional requirements from your quality attributes. Where some requirements are quantitative and concrete, others are qualitative and subjective. The most important part of my job when writing architecture documentation is defining Rationale. It is hard to convince the business and stakeholders of an approach without it. You might want to consider documenting this.
    – maple_shaft ♦
    Commented Sep 15, 2016 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.