When the Colorado Department of Agriculture (CDA) needed to collate and distribute time-sensitive information, it turned to Web services technology. Web services make applications available online using XML-based protocols, automating processes that might otherwise be unwieldy. In 1999, the CDA began working with software firm Compuware to develop a Web services solution to disseminate data about a wasting disease that was rapidly spreading among the local elk population.

The XML-based solution was created using Microsoft's Visual Studio.Net and dot-Net Web services framework. The application collects and then distributes data regarding the impact of the disease, but the lessons learned from its development could be useful to many companies.

John Picanso, chief information officer of the CDA, explains that using Web services as a solution was seen as unproven but worth trying as an alternative to the previous method, a Mac OS-based application, linked to a proprietary database.

The legacy Macintosh system was inefficient and slow, according to Picanso. "We had a bottleneck where we could no longer disseminate data electronically," he says. "This was a vital part of our business that we were trying to save." Now the CDA can integrate this data with its Microsoft SQL Server database, so it can be served to anyone involved in the project via a browser.

Although the idea of Web services was in its infancy, the modular nature of the Web services model - based on components rather than monolithic applications - encouraged the CDA to try it.

"We had to jump in and get the application ready and deployed," he says. "Everyone in the enterprise had to be able to communicate at the same level and have access to all the same information. Because it was a relatively small application, we thought we would just try it out."

The solution uses a number of the main Web services technologies, including the Soap programming protocol and WSDL (Web Services Description Language) for tagging services, according to Manish Sharma, lead architect at Compuware.

"The technology was so new in 1999 it was hard to comprehend," says Picanso. "It was even harder getting a [development] team, coders or the architects ramped up about it. There is a great deal of confusion from both vendors and enterprises, and we struggle with J2EE, dot-Net and XML on a daily basis. No one really understands what it means, how you get there, whether to implement or the implications of your choice of technology. We would have struggled with dot-Net without Compuware."

Picanso admits he was taking a risk. "If you make the wrong decision and end up pulling the plug on your legacy system you'll end up in trouble," he says. "I put a lot of faith in Compuware but they delivered."

Picanso says that the system has worked well so far. "The toolset was very stable, everyone got to know the environment we were dealing with, and we have had very good support from the users."

Compuware's Sharma says there were many problems to overcome but agrees that the system has surpassed initial expectations. "One of the main challenges that we foresaw was integrating the dot-Net-enabled applications with the existing DNA-style applications [based on earlier Microsoft technologies]. Because of our experience with, and understanding of, both the old and new technologies, we were able to overcome this challenge."

Have your say: contact IT Week