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! :)

  • Using WCF is better than using a port (because its better to use higher level abstractions unless you need to go low level). Personally I would use a REST API for the server and use pub/sub message broker to publish status events to the client.
    – Chamindu
    Jul 20, 2016 at 4:51
  • That's also what I was thinking. In terms of REST API though - would hosting a REST API in IIS no add additional overhead? This is a simple 1 client - 1 server relationship from that point. I am not sure on what is the pub/sub concept
    – Web Dev
    Jul 21, 2016 at 2:10
  • If you can use NancyFx (github.com/NancyFx/Nancy/wiki/Self-Hosting-Nancy) or OWin (github.com/danesparza/OWIN-WebAPI-Service) you can self host the API in your windows service.
    – Chamindu
    Jul 21, 2016 at 3:18
  • pub/sub - publisher, subscriber. Look at the ZeroMQ Guide for a lot of detailed information, its a message broker that you can use to send messages bi-directionally.
    – gbjbaanb
    Jul 21, 2016 at 11:59
  • Ohh interesting! Interesting! I was just doing some more research while waiting for any potential replies and came across SignalR which seems like a good WCF alternative as it is much easier to setup and requires less code to maintain. OWIN and SignalR seem to be somewhat related right? That Owin WebAPI Service seems to look almost exactly like my current SignalR code. Any thought on SignalR and whether that will be good for the job (sounds like it so far)!
    – Web Dev
    Jul 21, 2016 at 14:51


Your Answer

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

Browse other questions tagged or ask your own question.