I am currently looking into re-architecture of some of my organization applications. Other questions aside, the one that I am currently trying to figure out the best approach for currently is the application communication. Here’s the current thinking:
- Client Application (UI client) – handles user interaction
- Admin Application (Background service) – handles business logic
- Hardware layer – actual hardware and its controllers
For the vast majority of the interactions there will be a clear Client-Server relationship between the Client and Admin. Client makes a request and gets a response.
There are a few situations however that are handled by Admin pushing notifications to a port on a Client – the reason for that is that we want immediate feedback if a state of specific hardware devices change, without continuously polling the Admin by Client. This does not seem ideal – in my mind, there should normally be a pretty clear Client-Server relationship between applications and having this sort of 2 way communication leads to unnecessary complexity.
I don’t have much knowledge around cross-application communication, but it does seem like WCF is the way to go. The biggest question here is whether this outlined 2 way communication is a good architectural pattern to get into.
Some of the things I’m thinking about:
- Moving the problematic logic to the Client. This seems like a bad approach as it will bloat the light Client with Business logic
- WCF Duplex communication Call-back contract – having trouble conceptually understanding this, but it does sound promising. It seems to provide a sort of single request, multiple responses model that I’m after
- Keeping things as they are and leaving the Admin to push it’s hardware changes to a Client port. Without being able to give a clear reason, this just feels dirty. Does not feel like the right way to do things.
Does anyone have any thoughts/advice? Is 2 way communication really as bad as I think?
Thanks! 🙂
5