Chapter 11. Converting Legacy Applications to Web Services
IN THIS CHAPTER
Right now, I'm looking at the title of this chapter and thinking, “Wow, I can't believe that I'm calling pre-.NET applications legacy!” In the world of application development on Windows, any application written using Visual Studio 6.0 or earlier will be viewed as a legacy application within the next year or two. There already exists a feeling that we are in the middle of a large-scale paradigm shift as the industry starts to migrate over to .NET. The broad adoption of garbage collection technologies that started with Java has shown us that developers really like the idea of having the computer worry about resources. Yes, I know that garbage collection has been a computer science research project for many years. Java proved that it was ready for commercial deployment. .NET takes lessons learned from Java and many other languages and technologies to make things even better.
So, what do you do to convert your existing applications into Web Services? The most important thing to do is to recognize which applications you should not convert. For example, most developers do a good job abstracting out the data access layer. As an added bonus, the data access layer can be kept stateless with little effort. Parts that have stateless interfaces make for good candidates for Web Services.
Other good candidates include background tasks where jobs get submitted and the work gets performed sometime in the future. You can put a Web Service front end that puts the requests in a queue. The stateful backend can then handle the requests.
A good time to look at adding Web Services is at the start of a maintenance cycle. To increase scalability, you will look at breaking the systems apart. Some sub-systems may have clients hooked up to them that were not there when the application was first constructed. You may have new applications coming up that will need the backend.
In this chapter, we will look at the two common areas where most of you will have an opportunity to add Web Service capabilities to existing code:
Existing distributed applications— Your objects get activated using COM+ or a similar environment.
Existing COM objects— Use and modify existing code to work as a Web Service.
For the purposes of these two topics, we will discuss options for retrofitting existing applications with Web Service capabilities.
Besides this, we will also cover situations where you will want to migrate a Web Service or COM object to Visual Basic .NET to take advantage of the better serialization support.
This chapter will be fairly sparse on code. Chapter 10, “Microsoft SOAP SDK,” explained how to handle all the situations you can run into with the SOAP Toolkit. Here, we will focus on identifying existing resources and what to do to prepare them to be used as a Web Service.