In-Depth

.NET finds a home on the range

• By Tony Baer
• August 1, 2002

When does it make sense to take a chance with beta technology? For the Colorado Department of Agriculture (CDA), the opportunity came when it was time to develop a new application to track wild elk herds in the Rockies. In this case, the technology was Web services, and the opportunity was the need to develop an application that could also be deployed outside the department to other state agencies. Until recently, the data had been stored through a Macintosh HyperCard application and Microsoft Excel spreadsheet.

The elk herd application was in many ways typical of the application environment that CIO John Picanso had discovered when he first joined the department back in 1998. ''We had an inventory of roughly 80 separate applications, most of which were written in Visual Basic, but none of which were integrated,'' he noted. ''One of the first decisions was to start integrating the data and reuse the code to capitalize on all the work that we had already done.''

Consequently, deciding on the path to a new Web services architecture came after a virtual gauntlet of decisions ruled out conventional options. It began with the easiest decision: deciding to expose data as XML.

The next piece of the puzzle was determining how to open the data up to users outside the department. Admittedly, the path of least resistance would have been to develop a standard intranet architecture that presented the data on a standard HTML Web page. ''We ruled that out because we wanted to enable other [state] agencies to consume data in the way they wanted it, whether it was in a spreadsheet, a database or another application,'' said Manish Sharma, principal consultant at Compuware Professional Services, which worked with CDA to develop the application.

Because the department was already a Microsoft shop, the next logical choice would have been to develop a DCOM application. But again, because the user base would be outside the department, firewalls, along with the reality that other departments might not have Microsoft platforms, eliminated the DCOM option.

At that point, the team decided to embrace a Web services architecture. Although it was extremely new, the team was pretty confident about adopting SOAP. ''We didn't consider using SOAP a risk because we felt the standard would be here to stay,'' said Sharma. And with the decision to adopt Web services, the team decided to test out the new VB.NET language because of its Web services support.

The development team, which included Sharma and a couple of internal VB developers who were trained on the new .NET tools, used several pieces of the emerging Microsoft .NET framework, including ADO.NET for data representation, and ASP.NET for consuming the Web services and generating SOAP messages. Although the application was written using .NET technology, it interacted with existing COM+ components.

In developing the application, Sharma compared .NET development to older approaches. For instance, in designing the back end, Sharma compared several methods for generating XML data formats. Of the options -- using conventional DOM objects, custom XML schema and ADO.NET's data sets -- the ADO.NET approach performed just as well as the alternatives and proved far simpler to develop and maintain. A minor drawback, Sharma noted, was that ADO.NET's data sets use function arguments that might not always be understood by third-party tools.

For the front end, the development team initially decided to use ASP.NET over more conventional approaches, such as generating HTML pages using pre-.NET ASP technology or deploying traditional VB Windows clients. Since the application has gone live, however, a few conventional HTML pages have been added to reduce network traffic for several general-purpose pages that do not have the same degree of interactivity as the ASP.NET pages.

As for the new .NET technology, CDA's Picanso gives it a realistic few thumbs up. For instance, his staff of VB developers is approaching the object-oriented design practices required by the .NET framework cautiously. On the other hand, they took to XML ''like ducks to water,'' something, he notes, that required a new approach to data modeling. ''People need to think about how to make their XML schemas generic enough for outside consumption,'' he added.

In driving the transition to .NET, Picanso realizes that developers might prefer returning to their old tried-and-true methods. He admits that he does not know how well VB developers will adapt to VB.NET. But CDA is not looking back. ''We're examining an application where they might rather go back to their comfort zone, but I'm not letting them go there,'' he said.

See main story, ''Early .NET returns: So far, so good.''