When Are XML Web Services Appropriate?
Building or consuming XML Web services may not be appropriate for every situation. Obviously, if you are building simple desktop applications for computers that have slow Internet connections, or even no connection at all, then XML Web services are not for you. Also, if you are looking to build services that will be exposed and used by the development community at large, you may wish to wait and see if the world adopts the XML Web services development model before you build any large-scale services.
If, however, you are building applications for a committed user baseusers who are on board and awaiting the service, not just potential users who may or may not be persuaded to buy inand your application can benefit from functionality that you cannot provide otherwise due to time or knowledge constraints, then XML Web services might be the perfect solution for you.
Ultimately, only you can really judge if an XML Web service is the correct path for your applications, but there can be no denying that this technology has many uses. XML Web services allow developers to harness the core talents of other programmers, talents that may lie outside their own areas of expertise. They also allow small development teams to make use of the efforts of large development houses, including Microsoft itself, and use services that would take years to be developed in house.
Web classes are appropriate in so many situations that it would be impossible to list all the possible scenarios for creating or consuming them. Some situations lend themselves extremely well to the XML Web services model and, even with Visual Studios .NET and other platforms still in beta, are starting to show up in production as this is being written. Most of these new XML Web services fall into one of the following rather broad categories: intranet applications development, exposure of current customer services, and preexisting Web applications.
Using Web Services in Your Intranet Applications
Intranet applications offer perhaps the most obvious scenarios for building XML Web services. First of all, your user base is already connected to your Web servers. Second, by virtue of having an intranet, your company has an expressed need to share information and services.
What makes an intranet a perfect venue for XML Web services is that you already have to build the functionality in some programming language. The overhead involved in writing your functionality into an XML Web service is not much greater, and in many cases even less, than what is required to build the functionality in some other format.
Now, once the XML Web service is completed and being used by your intranet applications as was originally intended, it will be easier to reuse the functionality in other intranet applications, desktop applications, and even Internet applications.
Imagine that your company has an intranet application that tracks employee sick days, vacation time, and benefits. Currently, supervisors navigate to files on specific employees, cut and paste information out of the Web application, and use it to generate reports and populate other applications.
Now your company asks you to enhance this intranet site by automating the report processes and exposing your data to other application developers. You could just give these other developers permission to directly hit your database and to place their ASP code on the server with yours, or you could build all of the benefits functionality into an XML Web service and expose it that way.
Now a developer in your company who decides to build a new desktop reporting tool can simply communicate with your Web service to get the needed data. Likewise, when other developers need to build ASP projects that share your functionality but don't have access rights to the server that your application is on, they merely need to be able to browse it and send HTTP requests to it.
Customer ServiceRelated Web Services
If you are building applications for a company that offers any kind of goods or services, and you need to share information with partners, clients, or potential customers, then XML Web services may be for you.
If you are already building applications to post item quantities and costs, product descriptions, stock evaluations, or even football handicaps to Web sites, then you can leverage your efforts into something much more robust. Simply build the functionality that you are already planning to deliver via standard ASP, CGI, custom DLLs, or whatever into a Web service. Your Web site can still use the service, but now the same development can be used again and again in a host of other applications. These applications need not be Web applications, or even be developed by your company. Depending on the arrangement that you have with your customer, these XML Web services could be used in the customer's own development initiatives as a free service or accompanied by some billing model.
Even if you don't share information via the Internet already, XML Web services could be created that securely expose up-to-the-minute information on your business. Then either your company or a third party can roll out applications that make doing business faster and more efficient.
Porting Preexisting Web Applications to XML Web Services
While I would never suggest that anyone rewrite a program just to take advantage of a new technology when a need does not clearly exist, switching to a new technology when upgrading or building new applications may make sense.
In the case of XML Web services, porting your current Web apps out of standard ASP, CGI, or any other technology may make sense when it comes time to add new features or improve on old ones. If the possibility exists that a Web service built to handle one application could be used in future ones, why not plan ahead and save the additional redesigns down the road? As was previously mentioned, writing XML Web services in Visual Studio .NET is as easy, if not easier, than almost any method you may be using currently to design Internet-based applications.