In-Depth

Heard on the street: Tales of .NET

• By Rich Seeley
• September 29, 2003

The Microsoft roadmap to Web services on .NET is leading the development of real-world business applications using XML technology. But the journey is not without surprises, both pleasant and unpleasant. Developers interviewed for this article were pleasantly surprised at how easy it is for most programmers to use Microsoft’s Visual Studio .NET tools. And despite XML’s verbosity, performance and scalability on the Microsoft platform are surprisingly good. But there are some bumps in the road, including sketchy security standards as well as interface and synchronization issues. And while Microsoft makes it easy for even business users to build simple Web services, some developers say it is crucial to have a thorough knowledge of the W3C XML standard, especially XML Schema, to avoid pitfalls as Web services applications proliferate.

Application Development Trends talked to developers who recently completed Web services applications on the .NET platform using the Visual Studio for .NET tools. The developers interviewed found few serious issues with the .NET platform or tools.

“It’s ridiculously easy to create Web services using Microsoft Visual Studio tools,” said Micah Dylan, senior consultant at Extreme Logic Inc. in Santa Monica, Calif.

His experience includes building a Web service application for ProcessClaims, a Manhattan Beach, Calif.-based insurance industry vendor that links auto insurance companies, body shops and other vendors involved in handling auto accident repairs.

Bob Lamoureux, chief architect at Thomson Financial in Boston is impressed with the latest enhancements Microsoft has made to .NET.

“The functionality of the framework has been simplified,” he said. “Quite a few things that were easy before are beyond easy now.”

Lamoureux recently completed work on a Web services application for Thomson Financial’s Investment Management Group that automatically updates Excel spreadsheets with the key financial data analysts and investors are tracking.

He credits Microsoft for simplifying .NET technologies in the two years since the initial release of the product.

“For example,” he said, “things in the directory services world that just one release ago were maybe wrapped up in 13 or 14 API functions and pretty efficient, are now down to two. So you have two wrapper classes around an entire directory. That’s a really efficient interface.”

In addition, he said, “Microsoft allows you to go in and tweak things through these application administration tools to fine-tune things much better than you could before.”

As Microsoft has enhanced its .NET technology, Lamoureux said the overall framework flexibility helped smooth implementation and migration, which turned out to be critical in the Thomson Web services project.

“In the old days [2001], if you had two versions of the framework you had to choose one or the other; they couldn’t run side-by-side. .NET now allows you to have side-by-side execution. That gives us a nice migration path as we go up this learning curve,” he noted. This proved important for teams working on the initial Thomson project.

“We had a federated development environment here at Thomson,” Lamoureux said. “We had the workspace engine team working out of London and we had the core services team working out of Boston. They worked for the entire first half of the year and then our first release date came up in June.

“They both delivered their projects and realized, much to their dismay, that one team had built it entirely around the 1.0 .NET framework and the other team entirely around 1.1. Somebody just forgot to ask the question,” he noted. “The good news was that we were able to install the server and have both frameworks running side-by-side with minimal issues.”

Performance and scalability

In the experience of the developers interviewed for this article, Web services on .NET exceeded expectations for performance and scalability.

Frank Barbato, chief systems architect at Lydian Trust Company in Palm Beach, Fla., recently completed work on a .NET-based Web services application linking the bank’s auto loan process to credit and fraud-checking services. He did not find common criticisms of Web services performance to be true.

“One common misconception people have about Web services is that they believe they will be really slow because of all this marshalling of huge amounts of chatty XML data going across the wires,” Barbato said. “It turns out that the speed is excellent. It’s much higher than we had imagined. That’s one pleasant surprise. Web services are actually pretty fast.”

In his view, the key to speedy Web services processing is not about the speed of one individual transaction, but rather maintaining acceptable speed as the application scales up.

“It’s not necessarily important that you get your answer back in one millisecond,” he said. “It’s more important that you get a thousand answers back in the same amount of time.”

In Barbato’s view, the key test of performance and scalability is when the application, which processes an individual request in five milliseconds, can maintain that same five-millisecond speed when it receives a thousand requests at once.

The team at Lydian Trust does not discount the importance of hardware in the performance and scalability equation.

“You have to make sure you have a fairly strong network infrastructure,” explained Lydian CTO John Studdard, who led the Web services development effort at the bank. “Because now these transactions that would have happened on a single box are executing asynchronously, and it involves a lot of network traffic. So network infrastructure has to be a consideration as well.”

The Lydian network is a Cisco switch environment with HP/Compaq Reliant servers; it uses the EMC storage management system, Studdard explained.

Bumps in the road

Still, Web services development with Microsoft’s .NET roadmap is not quite a Sunday drive -- all of the developers encountered significant bumps in the road, including sketchy security standards as well as interface and synchronization issues.

“Most of the challenges revolve around weaknesses or lack of standards for Web services as they are today,” said Lydian’s Barbato. “Security is one of them. You have to make up your own standards or devise a schema that allows you to plug standards in as they become available.”

The Lydian team had to address weaknesses in Web services standards in a number of areas with a concept they call “Core Services.”

“It basically means you extend a Web service with a set of interfaces that are referenced in .NET that you must support,” Barbato explained. “We dictated the standards internally across our enterprise, and provided standard interfaces that would be used to address all the shortcomings that we’re aware of. That allows us, as standards become available later, to plug in these standards and still have things go against the interfaces.”

One shortcoming Barbato found in the .NET technology is the samples and examples Microsoft provides for .NET development. He said this is especially true with applications, such as Lydian’s, that reach beyond the enterprise to connect with business partners.

“The Microsoft way of doing things is that you get some pretty basic examples and people will tend to follow those examples,” he said. “But, unfortunately, they’re not complex or advanced enough to really guarantee interoperability or efficiency if they’re going to be called from outside the enterprise.”

As easy as Microsoft appears to be making Web service development, Barbato and the other developers interviewed all stressed the need to understand the nitty-gritty of XML standards, especially schema.

“Web services work best when you design them from the XML perspective, as opposed to the Microsoft samples and examples that have you grab a dataset and return it,” Barbato said. “Magically, they’ve done a great job of making everything seamless, but you end up at the other end with some default XML serialization that may not be the best thing for portability or interoperability.”

He argues that this is a training issue for programmers before they begin working with .NET. “All you’re going to get in the Microsoft examples is the addition [of a] Web service: two integers are added together and one is returned, which is pretty useless,” he noted. “It’s important to help developers to understand that they have to care about the XML first, and think about issues such as serialization, which is counterintuitive to what the samples say and how people develop Web services today.”

Serialization was the biggest bump in the road that the Lydian team encountered, according to Barbato. This is where he believes it is crucial for developers to understand the basics of the W3C XML standards. This is an important issue for Web services that go beyond the firewall because in Barbato’s experience, not all vendors are Microsoft-centric.

“Serialization is the magic that allows Web services to work, whether it’s from the client side, the proxy calling up to the Web service or the Web service returning data back,” he explained. “In the end, what you return goes through an automatic -- per the .NET runtime -- serialization process. This default serialization works great, but you get some unexpected results sometimes. Or you’ll get a result you may not want or that the user at the other end may not understand, for example, if you query a dataset and it returns a dataset. That’s great if the person on the other end is using .NET and can get that and fine-tune it and use it. But the caller on the other end isn’t always Microsoft-centric.”

Some tips on best practices

The ease of use built into Microsoft .NET tools can trip up developers when they encounter complex serialization issues because the XML type and the .NET type do not always match up in Barbato’s experience.

“It gets more complex than it sounds because Microsoft does such a great job of making it so easy for you,” he said. “But to really make something that is broad-based and will scale, you have to understand serialization.”

Training in XML to deal with issues such as serialization leads the list of best practices. Creating Web services that achieve the golden mean between doing too much and doing too little is important to both Thomson’s Lamoureux and Extreme Logic’s Dylan.

Lamoureux is an advocate of what he refers to as “clean interfaces.”

“If you shoot too high, you have an interface that basically is the kitchen sink. It does it all. It’s what I lovingly refer to as the ‘do this’ operation and all the parameters define the operation,” he explained. “At a lower level, you create an interface to do everything. Set the minute hand. Set the second hand. Set the hour hand. Set the date. Setting the clock is a bad interface. So striking a balance between interfaces so you can have an efficient transfer across a network without a lot of chatter, without having one big heavy blog that goes back and forth, is a challenge because there’s no real standard for that.”

Extreme Logic’s Dylan makes a distinction between what he refers to as “fine-grained Web services,” which are of the setting-the-clock variety, and Web services that have greater functionality.

“From an architectural perspective, it’s important that people don’t think of Web services as a DCOM over the Internet,” Dylan said. “The tendency is to create fine-grained Web services where you have lots of Web services that do one or two small things. That’s really not what they’re for. It’s important to create large-grained interfaces that call a Web service and do a lot of work. It shouldn’t be that you have to call 10 different Web services. You need to think about how to make your interface large-grained to do big jobs.”

In terms of best practices, Lamoureux advocates getting the entire development team on one programming language from those available in the Microsoft world -- basically, Visual Basic or C#.

“Either be a VB shop or a C# shop, or any other language, but those are the two primary ones,” he said. “Coming out of the box with the team bifurcated between those two languages tends to be a little problematic. The infrastructure supports it, but as a development organization it becomes a little unwieldy.”

“We had to dig in and just learn how to do it,” Lydian’s Barbato said.

Please see the following related story “Web services fans in chorus: ‘The WS-I Basic Profile is here!’” by Jack Vaughan, or click here to go to Web extra: .NET.