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?