In last week's column, I discussed the user privacy issues we
considered while designing our Favorites Web Service. Based on our initial
research into the user privacy issues, we decided to focus on three main usage
scenarios in the initial release of the Favorites Service:
A Web site, say msdn.microsoft.com, provides a button on each of
its pages that a user can click to add that page to the user's favorites stored
at the Favorites Service.
Msdn.microsoft.com provides a Web page that
displays a user's favorites, which were originally stored with the Favorites
Service by msdn.microsoft.com on the user's behalf.
Msdn.microsoft.com
provides a Web application that lets a user manage the favorites that were
originally stored with the Favorites Service by msdn.microsoft.com on the user's
behalf.
In essence, each Web site that uses the Favorites Service gets
its own private store for user favorites. Even with this limited set of
scenarios, we decided we would need to restrict access to the service to known
users—in other words, we would need to license the service.
In this column, we'll look at licensing in detail: issues to
consider when defining a business model for a Web Service, how business models
relate to licensing, the model we selected for the Favorites Service and why,
and the impact of the selected model on our design and
implementation.
Feedback on Your Comments
Before we get
started, I wanted to address a couple issues raised by readers of last week's
column.
First, with respect to user privacy, someone asked how we would
address European Union (EU) data protection regulations. For those of you
wondering "what European Union data protection regulations?," you can read about
them at http://www.europarl.eu.int/dg2/hearings/20000222/libe/framework/eplegs/en/. Since our project team works for Microsoft and we plan on hosting the
service on Microsoft-owned equipment, our deployed service must comply with
Microsoft's policy regarding the EU data directive.
Our team is currently working with Microsoft's Corporate Policy
Group to ensure that the Favorites Service deployed on our production servers
meets Microsoft policy. If we end up doing anything "extra" specifically to meet
EU requirements, we'll be sure to let you know. However, you should note that
what we need to do to comply with Microsoft policies might not be what you need
to do to comply with your own company policies. This is a great example of why
you should work with your legal advisors throughout the project lifecycle to
ensure your privacy policies comply with current laws wherever your customers,
staff, and servers are located.
Second, someone asked about dealing with the Logon component if
they wanted to aggregate the Favorites Service with some other stuff and deploy
a new service. The short answer is that the Logon component's methods are
exposed through the Favorites Web Service. A client application—or in this
scenario, the new service—calls the logon method before it can use any of the
user favorites management methods. My next column will discuss authentication
and authorization, so tune in next week for more details.
Web Service Business Models
Most Web
sites that interact directly with end users seem to have gravitated toward a few
business models. From a user's perspective, there are several options:
All features of the site are freely accessible to the user.
The user must sign up for a free account before accessing some or all
features of a site.
The user must pay for a subscription before
accessing some or all features of a site. The subscription usually provides
unlimited access to a set of features for a specified period of time.
The user must pay a per-use fee before accessing some content.
Another aspect of the business model is how the business recovers the
cost of developing and operating the site:
Development and operations costs are simply counted as part of
the cost of doing business.
Users pay a subscription fee to access the
site.
Space on the site is sold to advertisers or other sites.
As-is, these models don't really work well for Web Services. Usually a
Web Service would not be used directly by an end user. In addition, Web Services
are used programmatically, so you can't rely on advertising eyeballs for
revenue. However, the models for Web sites can help us identify some issues to
consider when defining the business model for a Web Service. The issues we
identified are Customers, Pricing, Payment Methods, Subscriptions, Notifications
and Billing, Grace Periods, Authentication, Auditing, and Customer Service.
Customers
The first question you should
ask is with which customers you want to establish business agreements. Usually a
Web Service provider will establish business agreements with application
developers that want to use the Web Service in an application. If the Web
Service stores user-specific data, the Web Service might establish agreements
with the end users instead of or in addition to any agreements with application
developers. Another possibility is that the Web Service provider establishes
business agreements with one or more Application Service Providers (ASPs) to
host the service. The ASP in turn establishes relationships with application
developers and/or end users, as appropriate.
Pricing
Once you've identified your
customers, you can start to think about the value those customers will place on
your service and how much they will be willing to pay for it. One of the things
you should consider is whether the price will be based on the number of requests
made (the pay-per-view model) or whether you will grant unlimited use for a
period of time (the lease model). Other factors include whether or not the price
is the same for all types of requests, whether or not the price is the same for
all customers, and whether or not the price is always the same for a given
customer.
Payment Methods
If you decide to charge
money for your service, you'll need to consider what mechanisms customers use to
pay for service. Web sites that interact directly with end users usually accept
credit cards. However, a company that wants to access your Web Service may not
want to use a credit card to make payments. You might need to accept payment by
check or wire transfer.
Another factor you'll need to consider is whether customers must
pay in advance, pay as they go, or can pay after the fact. If customers can pay
after the fact, you may want to place an upper limit on the outstanding charges.
You might impose a standard limit for all customers, or set a different limit
for each customer.
Subscriptions
Whether or not you charge
money for your service, you may need a way to identify who is calling the
service. In this case, each customer will need to establish an account (or
subscription) with you. How do they do this?
You should consider whether you will immediately grant an
account to anyone who asks for one, or whether there is some approval process
before an account is granted. If there's an approval process, can the customer
apply over the Web or do they need to call a customer service representative? Do
you need a staff to investigate and approve requests for new
accounts?
You should also think about what information you require before
granting an account and what optional information you will ask customers for.
This information is likely to fall into the category of personally identifiable
information that needs to be protected by your fair information practices, as
discussed last week.
Another consideration is whether you let customers select their
own account identifiers and passwords, if any, or whether you generate random
identifiers and passwords. If the customers can select their own account
identifiers, you'll need to handle the possibility of duplicate identifiers.
You'll also need to consider how customers maintain their
account information, including passwords. Do customers use your Web site or can
they call a customer service representative? What if they forget their account
identifier or password?
Notifications and Billing
If your
subscriptions have a time limit, you'll need to define the process for notifying
customers that their subscription is about to expire. The same sort of issue
occurs if you charge for your service and customers don't pay as they go. You
should think about the medium used to notify customers. For example, you might
send e-mail, make a phone call, or send an invoice. You should also think about
how many attempts you make to notify the customer and whether the same medium is
used for each attempt. How much advance notice do you provide before the
subscription expires?
If you are charging money for the service, especially charging
per-request, you should think about how often you bill customers. A customer is
not going to want to receive a bill with thousands of individual charges, one
per service request. Perhaps you'll want to aggregate charges per day, per week,
or per month, and make detailed usage reports available to those who want a
breakdown of charges.
Grace Periods
You should consider
whether to grant a grace period after a subscription has expired or payment is
past due. If so, you need to think about how long the grace period should be.
You should also think about whether there are any restrictions on the account
during the grace period. For example, perhaps the customer can only query
existing information, not store new information. Another consideration is
whether to send additional notifications to the customer during the grace
period.
Authentication
On a more technical
level, if customers need accounts to access your service, you need to consider
how you authenticate the customers when they make service requests. There are
three basic types of authentication mechanisms today: communications protocol
authentication features, application level authentication, or third-party
authentication. The most straightforward approach is to leverage the
capabilities of the communications protocol used to exchange messages with your
Web Service. For example, Microsoft Internet Information Server 5.0 supports
several authentication mechanisms for HTTP. Another option is to implement a
custom authentication mechanism in your Web Service. For example, if your Web
Service accepts SOAP messages, customer credentials could be passed in a SOAP
header or as elements in the SOAP body. Finally, you could use a third-party
service, such as Microsoft Passport, to handle authentication for
you.
Each of the available mechanisms has tradeoffs. Some mechanisms
are more secure than others. Some mechanisms are not widely supported by
developer tools for building Web Services. Some mechanisms require clients to
obtain certificates or accounts from a third-party. Some mechanisms have
significant performance overhead. You will need to weigh these tradeoffs against
your customers to figure out which mechanism is appropriate for your Web
Service. For further information about currently available authentication
options for Web Services, see the article Web Service Security.
Auditing
Another issue you'll want to
think about is the information you need to collect for auditing purposes. Think
about what information you would need on hand in case of a billing or customer
privacy dispute. If you are billing per-request, this could be quite a lot of
data. Consider the volume of data you'll collect each day and how that data is
archived. Are there standard reports you should create to help avoid or resolve
disputes?
Customer Service
Finally, consider what
kinds of customer service you need to provide. For example, you might need to
provide customer service to request and manage subscriptions. You will probably
need to provide a way for customers to report problems accessing or using your
service. You might need to provide a way to help developers write applications
that use your service.
For each kind of customer service, you'll need to think about
how that service is provided. Do customers need to use a Web site to get help?
Can they send e-mail? Can they contact you by phone? Whichever options you
decide on, what tools and infrastructure do you need to have in place in order
to provide effective support?
Business Models and Licensing
After
considering these nine issues, you should have a pretty good idea of the
business model for your Web Service. How does this relate to
licensing?
When we use the term license, we mean an agreement between a
customer and a Web Service provider regarding use of the Web Service. Unless
your business model is anonymous, free access to everyone, there's probably a
license agreement involved. For example, the act of establishing an account or
subscription may imply customer acceptance of certain terms of use. In some
cases, the customer may be required to read or sign a license agreement before
they are granted a subscription. We'll generally use the term licensing model
instead of business model when discussing Web Services that restrict access to
licensed customers.
The Favorites Licensing Model
Based on
the scenarios we selected to enable for the first release of the Favorites
Service, we had already defined who our customers were: application developers
(or more precisely, development organizations) who wanted to use the Favorites
Service. The next thing we looked at was whether customers needed to establish a
subscription before using the service. Let's consider what might happen if we
didn't require subscriptions.
Assume some application comes along that wants to start saving
favorites using the Favorites Service. We decided for user privacy reasons that
each caller effectively gets its own data store. How should the store be
identified? If the caller specifies a name for the store, there's the possibly
that two callers will specify the same name—and we have no way to distinguish
one caller from another. We could provide a CreateStore method that would return
a unique data store identifier. But what if the unique identifier is lost or
stolen? Since we have no information to tie the unique identifier to a
particular caller, we can't retrieve lost identifiers. Nor can we do much about
stolen identifiers. In fact, we can't even confirm that the person reporting a
stolen identifier has any relationship to the caller that created the data
store.
All in all, we're probably better off requiring customers to
sign up for a subscription. We can collect enough contact information to deal
with lost or stolen account identifiers or passwords. The contact information
also gives us a way to get in touch with someone if we detect a problem with the
way a particular application is using the Favorites Service.
We could have stopped at this point and decided our licensing
model would be free, life-time, unlimited use licenses granted to development
organizations who have supplied contact information (and, perhaps, read our
privacy policy or other disclaimers). However, we decided to design the system
to support a more complicated business model in order to investigate the impact
on overall system design.
In phase one, the Favorites Service is licensed to development
organizations that want to use the service from their applications. The rules
for licensing are as follows:
A licensee is granted unlimited access to the service for a
specified period of time.
The licensee must pre-pay for the service. The
rate charged is based on the length of the license and the total number of end
users for which the licensee is managing favorites.
Licensees will be
notified by e-mail one month before the license expires.
Licensees will
be notified by phone one week before the license expires.
Licensees are
granted a grace period of ten days after the license expires.
The
licensing workflow is shown in the following diagram:
Figure 1. Favorites Licensing Workflow
A customer account representative must be contacted to start the
licensing process. The licensee will be invoiced for all charges and payment
must be received before the license is validated. When the license is validated,
the licensee business contact will be sent e-mail containing all the information
needed to use the Favorites Service. New licensees may not be recognized by the
Favorites Service for up to 24 hours after validation occurs.
All new licenses are for a period of 3 months, at a rate of
$0.00/user. After the initial three month term, licenses may be renewed for 3
months, 6 months, 1 year, or 2 years. The fee charged is based on the number of
users for which the licensee is managing favorites. The functional specification
defines how this fee is calculated.
In order to compute fees for license renewals, as well as
defending ourselves in case of billing disputes, the Favorites Service logs
every call to the Web Service and its outcome (success, client error, or server
error).
Note that it is impractical for MSDN to deploy a sample service
that actually implements all the features of this licensing model. For example,
we don't have customer account representatives who can respond to requests for
new licenses or call licensees a week before their license expires. Nor do we
want to actually charge any money to use our sample service. However, we felt it
was important to design a system capable of supporting this licensing model. Our
actual implementation will have some modifications so that you can try out the
deployed service without a lot of hassle to obtain a license. We'll be sure to
point out where our design and implementation different. Hopefully it won't be
too confusing
Implementing Licensing in Favorites
As
you might imagine, supporting our licensing model added quite a bit of
complexity to the Favorites Service. It wasn't enough just to implement a COM
component and expose it as a Web Service. Suddenly we needed a way for
prospective customers to request subscriptions, a way for customers to maintain
their account information, and tools to generate notifications for subscription
renewals. We needed to collect data about every call to the service in order to
compute fees for license renewals. And we needed to implement an authentication
mechanism. The following figure provides a high level view of our system
architecture:
Figure 2. Favorite Service Licensing Architecture in Phase
One
Customers request subscriptions and changes to account
information through the Favorites Web site. The Web site validates data input,
passes the requests on to the Licensing component, and displays confirmation
messages that the requests have been received. In general, the Favorites Service
does not immediately grant subscriptions or make changes to account information.
Instead, pending requests are saved for verification by a customer account
representative. When a request is accepted, e-mail is sent to the licensee
contact to confirm the request has been completed.
The Licensing component implements the business logic for our
licensing model. Each method of the licensing component has the same basic
structure: initialize an Audit object to create an audit log entry, validate
input parameters, call stored procedures to update the appropriate databases,
send an e-mail notification if necessary, update the Audit object with the
results of the method, and save the audit log entry. Some business rules are
enforced in the stored procedures rather than the Licensing component. E-mail is
sent using the IIS SMTP service.
Our licensing model workflow is enforced using a set of status
flags stored in the Licensee and Notifications databases. For example, when a
prospective customer requests a new license, a new licensee record is written to
the Licensees database with status set to pending. Similarly, when a license
renewal notice is sent, that is recorded in the Notifications
database.
In a real-world implementation of our business model, we would
have customer account representatives verifying customer contact information
before granting new licenses or modifications to contact information. The
Favorites License Management System (FLMS) is a Web-based application that
customer account representatives could use to view pending requests and accept
or reject those requests. Since we don't have any customer account
representatives, we've only implemented support for a couple of the requests, so
you can see how it might work. Like the external customer Web site, FLMS relies
on the Licensing component to do most of the work.
In our deployed service for MSDN, we won't have any customer
account representatives, so we've implemented a process called AutoAdmin that
checks for pending requests and automatically grants them using the services of
the Licensing component. We also need a way to generate renewal notices
automatically. That is implemented in another process, Renewals, that is run
once per day.
In order to compute license fees for renewals and record
information necessary to resolve billing or customer privacy disputes, we log
the result of every request to the Favorites Web Service and Web site to the
Audit Log database using the previously mentioned Audit component. Each audit
log record contains information about the licensee making the request, the user
on whose behalf the request is made, the type of action requested, the time the
action was requested, the length of time required to handle the request, and the
outcome of the request. This information is used to compute daily usage
statistics that form the heart of our Reports Service. Once the daily usage
statistics have been computed, the raw audit log records can be
archived.
Finally, all this supporting infrastructure doesn't do us any
good whatsoever if we don't have a way to authenticate callers to our Web
Service. We have elected to implement application level authentication for the
Favorites Service. An application that wants to use the Favorites Service first
calls the Logon Service to obtain a key. It then supplies the key in each
request to the Favorites and Reports Web Services. If the key is valid, the
request is allowed to proceed. Otherwise, access is denied.
Conclusion
As you can see, the decisions
you make regarding the business model for your Web Service can have a
significant impact on the overall requirements for your system. You should try
to define the business model as early as possible to avoid surprises that would
require drastic changes to your system architecture. On the other hand, it can
be difficult to figure out what business models your customers are willing to
accept. Flexible designs that can accommodate changes in the business model are
worth pursuing.
Next week we'll continue our examination of the design issues
encountered while implementing the Favorites Service by taking a closer look at
authentication and authorization.
