So, should you use web services in your own applications?

A very simple question - should you use web services in your own application? Most professional developers are bought into the idea these days of exposing functionality in their applications via web services, for greater interoperability, but the question often arises, should they use those same web services within their own applications?

As a general rule, I think, yes. One of the guidelines I use would be (in line with one of the core tenets of Service Oriented Architectures), is, are you exposing some autonomous unit of functionality? Is it something that would be of use, in some standalone capacity? If so, then it’s a good candidate for a web service. Sure, there will be low level parts of the system where web services are not appropriate, where some other mechanism, may be a better choice. But, by and large I would start with the premise that web services are good, and offer you lots of benefits, especially from an architectural perspective.

Systems, if they are successful and used a lot, tend to grow and morph over time, and so it makes sense to build in hooks to help allow that growth.

• You want to offer a web portal that display information? An ASP.NET 2.0 or SharePoint 2.0 webpart that uses a web service call would works really well.
• You want a mobile version of your application that runs on a PDA that works on-line and off-line? A Windows Form application that makes a web service work great in this scenario.
• You want to integrate some of your application functionality in Microsoft Office 2003 (perhaps Word or Excel)? The Information Bridge Framework or Visual Studio Tools for Office makes it possible via web service calls.
• You need to let a Java client or J2EE server integrate with your system? Web services offer interoperability across hardware and software platforms.

So why wouldn’t you use web services? The main reason I have seen is the perception they are slow. I think it is a misconception, and any latency is far out weighed by the benefits they offer.

This whole issue was brought home to me when I met an ISV that had built a three tier application using EJB. Everything but Microsoft in the stack, including an HTML forms designer that produced code that made RMI calls to their middle tier beans. There had around 400 methods exposed via RMI, which would eventually rise to nearer 1,000 once the system was complete. They had ignored all interoperability options, and in the process, let the technology define their architecture. They had built a system that would only work in this closed environment, and had also conveniently skipped over the issue of transactions, which was closely tied in with the EJB container they used. So, surprise, surprise, when they started working with customer who used Microsoft tools, they had no viable option out the box, and are now desperately trying Java bridges and other tools to reverse engineer some degree of interop. I hope it works, but it could have been avoided so easily.