As some of you know, I've attended Citrix iForum, Citrix's server-based computing show, for the past several years. I like the show. The technical content improves each year—not that I always get as much time for breakout sessions as I'd like—and the show gives me a chance to talk to people who are interested in server-based computing: product managers, systems engineers, customers, vendors, and analysts.
Server-based computing is expanding into the .NET space. Last week, at one of this year's iForum's evening events, I chatted for a while with Jim McGrath, Citrix's senior product marketing manager for Web products. Because of Jim's close work on Citrix NFuse Elite access portal server, I figured he'd be a good guy to talk to about how the Web services portion of .NET figures in Citrix's plans for the future.
I began by asking Jim about Citrix's plans for Web services. He rolled his eyes. "I'll tell you what. When I ask two customers what Web services are and they say the same thing, I'll know it's time. Until then. . ." Then he shrugged. We talked a bit more and worked out that Jim didn't view the situation as he originally implied; Citrix is closely linked to Microsoft, and Microsoft is strongly interested in developing a working .NET architecture. (Also, as Citrix's chief technology officer—CTO—Bob Kruger pointed out, you really can't develop software according to what users want right now—you need to anticipate what they'll want in the future.) However, Jim isn't alone in his sense that people aren't really sure what Web services are. While at Windows & .NET Magazine LIVE! in Orlando, Florida, 2 weeks ago (I've had a busy couple of weeks), I fell into conversation with one of the XML-track presenters, and he said pretty much the same thing: Although Web services are a subset of .NET, the two are not synonymous, and getting people to understand that can be difficult.
I'm happier with a concept if I can see it in practical application, and I don't think I'm alone. It would be easier to understand Web services if we could grasp them not just as technology (as we've been doing by looking at Universal Description, Discovery, and Integration—UDDI—in this column) but also at the application level. What does a Web service application look like?
One example is the medical Web service Clinical Context Object Workgroup (CCOW), which performs a kind of next-generation OLE by taking user input at one point and populating related applications with the same information. If you're not familiar with CCOW, however, you can see other Web services in action if you're using Windows XP. Suppose someone sends you a .pdf file, but you don't have Adobe Systems' Adobe Acrobat Reader installed. When you try to open the file, it has no current file associations. In this situation in Windows 2000, the File Types dialog box would open, and you'd choose an application to associate with the .pdf file from a list of applications already installed. (If you didn't have Acrobat Reader currently installed, you wouldn't be able to open the .pdf file.) When asked to open a file of an unrecognized type, XP opens a dialog box that offers you the choice of either opening the familiar File Types dialog box or taking a new option: looking online for an appropriate application to associate with the .pdf file. Click the button to browse online, and you'll see a collection of applications that support .pdf files, from which you can install Acrobat Reader.
That's a simple example of a Web service, but it's an illustration that works. In Dot-Tech Perspectives, I started reporting about current .NET implementations in July but have devoted the last six columns to UDDI 3.0. Next issue, I'll resume looking at some ways you're using .NET today.
