![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The need for a web services pricing model
As web services evolve in the industry, business models for commercial web service providers will become an object of increasing concern and discussion. Web services as published today are basically free and therefore not measured in terms of their value. But as soon as services of higher value, such as payment-processing, become available, the need will arise for a model to efficiently measure web services invoked by service requesters. Because these services are not browser-dependent, advertisement revenue is more or less obsolete in this context and must be substituted with an alternative model.
An overview of web services and its architecture
Web services, a collection of functions packaged as a single entity and published for use by other programs, introduces the displacement of manually initiated transactions using a browser by program initiated transactions. They can be described, published, discovered, and invoked dynamically in a distributed environment, which means web services are built entirely on Internet standards.
The architectural concept behind web services is the service-oriented architecture (SOA). It describes three fundamental roles:
- Service providers
- A service broker
- A service requestor
These roles, as shown in Figure 1, interact through find,
bind, and publish/unpublish operations.
Figure 1: Web services components
The service provider provides the service and publishes them through a registry. The service broker provides support for publishing and locating services. And the service requestor finds required services via the service broker and binds the services via the service provider.
The challenge to creating a web services pricing model
The progress of current web service initiatives is enormous, and faces many technical challenges, among them:
- Reliability and security
- Transactions and scalability
- Accountability and testing, etc.
The solution outlined in this article focuses on the problem area of accounting for web services, looking in particular at business management for service providers, and how they can efficiently charge the service requestors for their service.
The meter and accounting model
The meter and accounting model, designed especially for web services, takes a higher level approach than measuring traffic between IP-addresses, counting the number of e-mails sent, or recording the use of storage for a particular user. Although it is designed to support service providers which use Web services technology, each provider may run different kinds of web services on their individual systems. What we are looking at, in general, are:
- Simple services, like stock quote services or temperature services with no quality of service guarantee and available at no charge
- Services that clients use in business transactions, in which the quality of service plays a high role of importance and the service is probably not offered free-of-charge
For the latter kinds of services, the service provider needs to audit the service as it is used and bill for it. This is typically done on a periodic basis, and is where the meter and accounting model comes in.
The model operates on a base assumption that web services with a high degree of value are contracted via Service Level Agreements (SLA's) or their equivalent, which implies that both parties agree to the contract. The contract lays the foundation for metering the services to be used, by covering all the attributes of the service customs and how they shall be employed by provider and requestor. The contract can also include environmental prerequisites for the use of the web service.
Once the requestor (or client) has contracted (or registered) with the provider, that requestor is said to be known to the provider and to the service meter. This is achieved via electronically signed contracts and certificates for the use of the web service.
The contract provides details concerning:
- The type of contract: long term, ad hoc, restricted time, unlimited time, etc.
- Start dates and expiration dates of the contract
- The time model to be used: everyday, Monday to Friday, etc.
- The amount model, which defines limits to the amount of service to be provided
- Security: Signatures or certificates for encryption and authentication
The meter and accounting service stores the relationship between the requestor and provider as detailed in the contract buy the internal use of certificates. This is especially important for billing purposes, in order to prevent inaccurate charges to the service requestor. The service requestor must use a signed SOAP message with the use of a contracted service.
Note that the use of contracts does not preclude relationships between web services published dynamically differently; it merely requires that an appropriate usage model be employed.
The functionality of the meter can serve a number of possible business models, such as:
- The pay-per-click/fee-for-use model
- The subscription model
- The lease model
For a discussion about different revenue models see the Resources section.
The meter and accounting web service basically acts as a resource-counter for Web Services. It provides input for:
- Billing according to the service provider's rating models (e.g. Common Billing Interface)
- Payment and tax processing
-
Defining functions and accounting figures like the following:
- record user begin time for service xyz
- record user end time for service xyz
- report total resource usage for a specific user
- report used service statistic per requesto
- create Service Requestor (SR) accounts (ad hoc account & contract)
- create Service Provider (SP) accounts
- answer queries if user id is allowed for requested Service ID (contract element)
- create IPDR.org conform XML usage records
The meter service makes it possible to retrieve usage-data in standard form as XML files. This data can be used in a batch-like model, that is, by a billing product which supports processing standards conform input.
Network Data Management - Usage (NDM-U)
for IP-Based Services
The IPDR organization has specified which technical information for
the interchange of usage data among service elements participating in the
delivery of IP-based services is sufficient. They have developed a framework
that qualifies IP network and service elements and support systems and
describes the relationship between the systems. The framework provides
a template specifying the type of IP resource and service usage information
that needs to be exchanged.
Elements that are common to all IPDR services are declared in a single
Master IPDR Schema document. Service-specific schema specify the data types
required to define IPDR elements specific to each service.
In the pilot implementation shown in this article we have developed
a web service specific schema according to our meter and accounting model.
The following steps are performed in the process illustrated by the diagram above:
- The SOAP Bind request for the service provider-hosted web service
- The service provider filter checks authentication of the service requestor using the supplied signature and a gives a SOAP Fault response in case of none authentication
- The SOAP request is sent to the meter service provider, requesting it to count the web service and the meter service provider validates the service provider's request against the contract details and starts counting
- The service provider executes the service
- The web service is completed
- A SOAP request message is sent to the resource counter to stop counting
- A SOAP response message is sent to the service requestor indicating that the service is completed, returns the result
For simplicity's sake, we have omitted minor interactions (that is, error situations and the certification authority needed to validate signatures).
We have implemented a prototype to show the usage of the meter. The code was integrated into the Gourmet2Go demo application from the IBM Web Services ToolKit (available from IBM Alphaworks; see Resources).
Figure 5 shows the data, gathered during several sessions by users which have been using the Gourmet2Go demo and the registered services. The services have been assigned different types of usage models for demonstration purposes, as we discussed earlier.
Valuable web services that shall be included in enterprise business transactions demand models on how service providers can charge for the service's usage. In this article we have shown a possible solution for this issue.
A service provider using this service to meter the usage of web services, first registers the available web services in the meter service. Service requestors that have chosen to use one of the service providers services (e.g. after exploring the UDDI registry), subscribe and contract the usage. Part of this contract is the selection a predefined usage model and the agreement on the certificate standard, like X509.v3. This is needed by the requestor to sign the SOAP messages and by the provider to meter the correct requestor. Typically, on a periodic basis, the provider uses the meter service to generate billing data in order to charge the contracted requestors.
Our proposed model is implemented as a web service itself. A service provider can integrate a similar model directly into their service provider platform, but will suffer the drawback of loosing some of the benefits of web services that can evolve dynamically.
-
Read about the Web
service architecture.
-
Read Web
services architect, Part 2: Models for dynamic e-business, for a discussion
about the value proposition of web services and revenue models.
-
Find the IBM
Web Services ToolKit at the IBM alphaWorks page.
-
Here you find all the details about the IPDR.org
initiative.
-
Take this great tutorial on Digitial
signatures for SOAP.
-
The white paper: Dynamic
e-business and with DB2 and web services shows how DB2 supports Web
services with DB2 XML Extender.
Wolfgang Eibach has held various positions in development and architecture at the IBM Boeblingen Lab. His professional experience as a software architect includes large host-based software systems, OO technologies, MQSeries, Workflow and Banking Applications.
Dietmar Kuebler is a software architect working at the IBM Boeblingen Lab. He has held various positions in development, technical marketing and project management, with a wide experience in architecture and software development in multiple environments. His areas of technical expertise include OO technologies, Java, WebSphere and middleware technologies.
Dietmar and Wolfgang are currently working on Web service initiatives
in the IBM Boeblingen Lab.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
