Getting to Know Us

 

Mary Kirtland
Microsoft Corporation

January 3, 2001

Welcome to At Your Service, a new column devoted to Web Services.

Web Services provide information and services to applications through well-defined programmatic interfaces built on standard Internet protocols. They are a key part of Microsoft .NET. Naturally, we at MSDN thought we ought to understand how to build them. Not just how to push the buttons in Visual Studio, but how to build scalable, highly available, secure, reliable Web Services.

Our team has gained valuable experience building Web applications such as Duwamish Online. What's different about building Web Services? What problems do you run in to when other developers want to use your Web Services in their applications—applications hosted on different operating systems, written in different languages, and using different implementations of key specifications, such as SOAP?

We figure the only way to find out is to build some services ourselves. So over the next several months, the Web Services guidance team will be building, deploying, and operating some sample Web Services. Our objective: to illustrate the issues you need to consider when designing, implementing, deploying, and operating your own Web Services. (We'll look at consuming Web Services, too!) We hope to release one Web Service every three months.

Three months is a long time to make you wait for new information though. So in the grand tradition of the Duwamish Diary, we'll be using this column to follow each sample project from conception through design, implementation, and deployment. At least once every two weeks, we'll post a diary entry so you can follow along with us. As we complete each project, we'll post our specs, sources, and other project artifacts here on MSDN. And you'll always be able to access all this information from our new Web Services Developer Center.

Meet the Team

The Web Services guidance team currently consists of six people:

• I, Mary Kirtland, am the chief cook and bottleneck—I mean, architect and program manager—for the team. I do most everything but code, test, or operate our sample services. Some of you may know me from my days as a program manager with the OLE/COM/DCOM/MTS/COM+/whatever-you-want-to-call-it team. Then I disappeared into the cone of silence surrounding .NET. About a year ago, I figured out that I enjoy writing about how to use technologies to build apps a lot more than I enjoy building the technologies themselves. So in April, I moved over to MSDN to work on what has become the Web Services guidance team. Much of my time is devoted to writing this column and content for the Web Services resource page. The rest is spent trying to keep the project specs up to date and keeping track of new technologies we'll want to cover down the road.
• Matt Powell and Scott Seely make up our development team. Matt joined the team in October from Developer Support. Matt wrote the ISAPI listener in the SOAP Toolkit for Visual Studio 6.0, coauthored Running Microsoft Information Server 4.0 for Microsoft Press, and has written several articles for MSDN Magazine and its predecessors, MSJ and MIND.
  Scott joined Microsoft and our team in December after spending the past five years out in the real world building real apps with Microsoft products. In his copious spare time, he has written articles for Windows Developer's Journal as well as a book titled Windows Shell Programming. When he's not working on our sample service, he's working on a book about SOAP.
  You can expect to see Matt and Scott writing articles about the dev side of things in the months to come.
• Our test team consists of Jan McCollum and Jim Francisco. Jan joined us in October as our test lead and has been hard at work coming up with a test plan for our first project. Jim joined us in December and is working on unit tests and test automation. Jim has worked on the Windows 98 Networking test team and the Microsoft Host Integration Server build/release test team. He came to our team after a stint in the dot-com world developing deployment and administration tools for n-tier Web applications. We'll try to get them to write some articles about testing Web Services when we're a little farther along.
• Bronwyn Calsyn is our operations manager. Bronwyn started in November and has been busy trying to figure out what equipment we need to deploy our sample services live on the Internet, along with the operations procedures we need to keep things running smoothly. We'll try to get her to write some articles about the deployment and operations side of things, too.

Introducing the Favorites Service

Our first project is the Favorites Service. As avid users of the Web, we recognize that one of the problems end users face is locating pages they've previously visited—particularly at dynamic sites such as MSDN Online, or news sites where articles aren't accessible from the front page for more than a few days. While you can use browser favorites to keep track of favorite pages, browser favorites are local to a specific machine. But what if you use multiple machines or devices? Wouldn't it be nice if the favorites could be stored on a server somewhere, easily accessed from whichever machine you happened to be using?

This is exactly what the Favorites Service does. It enables Web sites to store links to an end user's favorite Web pages. Now, you might think this doesn't sound like a very complicated service. And from a business logic perspective, it's not. That means we won't have to spend a lot of time explaining the business logic and you won't have a lot of application-specific code to wade through to find techniques you can use in your own Web Services. But we have encountered a number of interesting issues with the service—issues that many other developers we've spoken to are also running in to.

Our first few columns will focus on the issues we've encountered during the design phase of the project. Some of the topics we're considering:

• Protecting user privacy. Should any application in the world be able to query or edit every end user's favorites, regardless of which application saved the favorites in the first place?
• Licensing. If every application can't access all end user's favorites, how do we control access to the service? Should we charge money for the service? Which business models make sense?
• Authentication and authorization. If we're going to restrict access to the service, how do we authenticate client applications and decide what they are authorized to do? How do we identify end users anyway?
• Estimating performance requirements. How do we figure out what kind of load our service will be subjected to? Can we use the same methods we'd use to estimate load on a Web site? How do we determine what kind of response times and availability our clients will demand?
• Licensee requirements from development, test, and operations. If we're restricting access to the service, maybe charging money based on usage, how do client application developers and testers try out apps that rely on our service? How can they avoid affecting production data stores? What kinds of tools do our clients' test and operations staffs need to help troubleshoot whether a problem is in their applications or our service? What kind of documentation should we provide?
• Globalization. What do we need to do to ensure that client applications around the world can use our Web Service?
• Manageability. What kind of information does our operations staff need in order to manage our Web Service? How do we collect that information and present it to management tools?

If there are other topics you'd like to see covered, please e-mail us at wsgmsdn@microsoft.com. Note that at this time we cannot respond through the user comments on this page. We do, however, read the comments regularly. If we can figure out what your comments have to do with our content, we'll see what we can do to address your issue in a future column.

Next week we'll look at the issues we encountered in defining the vision for the Favorites Service project. See you then!