Using WCF in a new project... is it feasible?

Question

The company that I work for develops a C++ application to manage service businesses (dispatching, GPS tracking, CRM, etc). The problem is that the system is a little too limited. Being a relatively small company, we'd like to broaden the horizons and add some more modern features such as a web interface and plugins for various other applications, like Outlook, that would enable them to interact with data in our application.

Currently, I'm developing a web interface in ASP.NET MVC and have been for the last two months. However, this implementation is suffering from the same kind of limits that the C++ application has, so I would like to take things a step further. It's just that I'm not sure if this is a wise decision, or how I should go about convincing management that the greatly increased development time will mean greater possibilities in the future.

What I would like to do is implement some sort of massive API using WCF that would allow access via both web and desktop applications. My web interface could then be just that... and interface to this API using a framework such as Qooxdoo or ExtJS. But other interfaces could be added, such as an iPhone application, an Adobe AIR application, an iGoogle Widget, an Outlook plugin, etc.

Here's the thing, though... at the moment, I'm just a lot of talk. I have a good knowledge of C# and .NET technologies like WPF, WinForms, ASP.NET MVC, etc. But, I've never used WCF in my life. I'm pretty sure I can pick it up, but is it possible to grasp something so extensive as WCF when my employer wants to see fast results?

One way that I believe I can show results is to release the API incrementally. For example, the first "Community Technology Preview" would include simple dispatching functionality, he next CTP would include sales and marketing features, and so on. I don't really think customers would pick it up very quickly, but it would allow us to internally develop applications such as a web interface and plugins.

One problem I see with that is spending so much time developing the API that the development of applications that actually USE the API would be extremely slow. I mean, I could show a URL to my boss that returns a list of customers in JSON format, but what can that really do for us if the customers can't do anything with it?

I guess what I'm trying to ask is: how feasible is it to drop development on a limited web application that's almost finished and begin work on a WCF-based API to power future projects?

Answer 1

If you're already deeply familiar with C#, I believe you can pick up WCF and implement a simple proof-of-concept WCF service in a matter of days. Just pick up a good WCF book from the bookstore and learn the basics. You can also try using Microsoft's Web Service Software Factory to quickly build a WCF service following best practices.

If you want something even easier and faster, ASMX web services are even easier to create than WCF services. Just make sure your API is using serializable objects, slap a [WebService] attribute on your class, [WebMethod] attribute on your methods, create an ASMX file, and voila, you have a web service! It really is that easy.

Answer 2

You make it sound like your web development will have to be totally flushed in order to generate your WPF stuff. Depending on how you developed it, is that really the case?

Before embarking on your project, I think you need to do a lot of homework on WCF and get comfortable writing smaller, simpler apps in it first. Grok it before foisting your version 1.0 API design on your clients, or it shall truly be a plague on all your houses!

One more thing... This is a really good time to start really doing TDD for your APIs. Partner with someone who wants to interact with your application and learn their use cases and drive your API design accordingly. Writing a one-sided interface without a consumer is probably not the best idea IMO.

Answer 3

Well, why not have both? You can finish up on the web-based project and then develop the WCF part, exposing the service endpoints so that you can have different applications connect to it remotely.

Then, if you really want, you can refactor the web-based app to make the calls to the WCF endpoints (or, if possible, to the implementation behind them, as you don't really need to add that network latency).

Answer 4

Well I've built a number of WCF applications and it's not terribly difficult to get into (has irritating pitfalls, but that's what trial and errors for!)

That said, given what you've outlined there, I'd recommend against it if you have something that's getting close to finishing, and your boss is after fast results. If it's a possibility, why not finish the application you're working on, and then write a document on what you could accomplish with a WCF API on top of what you already have with the web application and send that to your boss / manager?

It's not a great solution since your current web app wouldn't be running against it, but it seems better (to me) to get something out there first, since setting up the start of a good API isn't something I personally enjoy doing with deadlines closing in and high expectations..