0

I work at a small to medium enterprise that are in the business of handling the processing of transactions for the selling and purchasing of "online, electronic products". Things such as prepaid mobile airtime, mobile data, electricity and even water and gas metering.

We are a Microsoft shop and all our skills and architecture is in the Microsoft stack. We integrate to other airtime and electricity suppliers and vendors, and others integrate to us. This is done via web services with a mix of legacy .asmx web services and the newer stuff is in WCF services. We have an established data layer that talks to SQL servers and our business logic is in a huge collection of class libraries (c#).

We have a bunch of old console apps and some WinForms apps running on servers that sit and process MSMQ queues or poll SQL database tables for specific transactions to process. We are starting to rewrite these processing apps into Windows Services as this will be easier to manage via an automated deployment process such as Octopus.

Then I joined the team as the only web developer and introduced them to Microsoft's Web API framework. I've been asked if it is a good idea to use Web API as the service layer going forward instead of WCF? My gut feeling is, no, as it is more geared towards a RESTful interface which leans itself towards front-end software. Our processing apps typically go from one service call to another to the backend and so forth. Doing that via Web API is probably not going to the best fit, right?

Is it then good practice to use WCF for the processing back-end apps (Windows Services), but use Web API for the front-ends we have? We have one large WinForms app which also uses some of the WCF services and even here Web API seems a bit clunky to implement. Web API really seems more appropriate for pure web front-ends, am I on the right path here?

1

Yes, you're on the right path, in my opinion (as long as WCF in your statements are the services developed on protocols other than HTTP + JSON like Web API because WCF can also be used for building Web API).

My reason is simply the various protocols that WCF supports make the communication between processes in the whole system better than only using HTTP which is good in communication via internet but is not good in intranet, localhost contexts (where TCP, NamedPipes are better choices).

Moreover, if I'm not wrong, WCF supports MSMQ (and service bus, maybe) which can be a useful stuff for an eventsource to dispatch events to subscription sub-systems that makes the system more reactive without having to use polling services.

  • Good point on the MSMQ as we definitely make use of that quite a bit for internal processing. I'm not sure exactly how it is implemented at the moment but WCF would definitely be a nice fit here. – Neville Jul 24 '17 at 22:01

Your Answer

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

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