Licensing 来源: 时间:2002-09-12 11:38 作者:AMTeam.org Licensing
February 21, 2001 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. 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 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 All features of the site are freely accessible to the user.
Development and operations costs are simply counted as part of
the cost of doing business. Customers Pricing Payment Methods 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 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 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 Authentication 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 Customer 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 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 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. 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 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 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. |
关键词:
|
相关文章 |