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 '16 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 – Ross Jul 21 '16 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 '16 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 '16 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)! – Ross Jul 21 '16 at 14:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.