|
|
Many organizations realize that their current business practices do not fit neatly into a Web services paradigm, and they may need to devise a new pricing model. The elements of the pricing may need to take into account factors such as resources used, number of users, and whatever the market will bear. A typical business-pricing model takes into account supply and demand. Because Web services offerings have not yet reached critical mass, users will need to anticipate which will come first-supply or demand-and plan accordingly. Because most Web services available via the Internet are free, their real value cannot be accurately measured.
To date, the focus on moving to a Web services model has focused primarily on integration within companies. Many large organizations realize the value of using Web services for this. Interoperability between heterogeneous platforms and the applications that run on them, such as mainframes (COBOL), Unix (C++), and Windows (Java), provides an immediate benefit. The primary objective is to reuse existing functionality across lines of business. This translates into reduced IT expenditures, in the form of less duplicated code and increased maintainability.
One of the trends in the industry is toward outsourcing services, sometimes referred to as e-sourcing. E-sourcing is the mechanism to deliver software-based services over the network containing both business and IT features. This automated, pay-as-you-go model is capable of serving multiple consumers and provides capacity on demand.
The older model of being able to give away services in exchange for advertising revenue is no longer relevant, because Web services no longer depend on browsers to render their displays. Web services further complicate accounting in that transactions can cross multiple services. Accounting and metering in a service-oriented architecture is vastly different from current, browser-based scenarios. For one thing, Web services take a higher-level approach than tracking users by IP address, simplistic hit counting, or recording storage use.
In Chapter 15, we discussed the use of digital certificates for signing and non-repudiation. This is especially important for billing purposes. Having a digital signature on hand will prevent inaccurate charges to the service requestor. This may mandate that your service use a digitally signed SOAP message.
The centralization of the digital certificate function should be delegated to an accounting Web service, similar to the trust model discussed in Chapter 15. Its sole responsibility is to act as a resource governor for all Web services. The accounting Web service should appropriately handle the three basic approaches to accounting for Web services use: subscriptions, leasing, and per transaction. It should also handle the following functions if you are going to charge for your service:
Adding, modifying, suspending, and deleting service requestor accounts on both an ad hoc and as contractual basis
Recording user start and stop times for the requested service
Providing reporting capabilities, such as total resource use by user, usage statistics by service, and so on
Providing a feed to accounts-receivable (billing) and tax-calculation systems
Using a common billing interface that allows an organization to adjust its rating models dynamically
Defining this service and having all your other services use it from the beginning is important to organizations that charge for their services. In the next section, we will look at the flow of this service.
Figure 16.1 outlines the flow of our accounting service. Let us walk through the flow, starting with the client after it has discovered the service it wants to use.
The client connects to the service provider and executes the service.
The requested service binds to the accounting service.
The accounting service checks to see if the requested service requires accounting.
If the service requires accounting, the accounting service checks to see if the user is allowed to use the service at the requested time or has exceeded maximum usage.
If the above checks pass, the accounting service creates a start-time record using the ID the client used to bind to the initial service.
The accounting service lets the requested service know it is okay to execute the requested service. It returns a unique transaction token to the requested service to prevent overlapping messages.
When the requested service is finished executing, it calls the accounting service with a stop event, passing in the related token. The accounting service closes the transaction and creates the appropriate billing records.
The ability to dynamically charge for services based on usage provides many organizations with additional pricing capabilities. To further extend the above approach, you could separate accounting from metering. The accounting service could simply become the gatekeeper. The metering service could become a distinct Web service that exists either locally or remotely. The metering service could create the billing records and become outsourced. Furthermore, the metering service could be extended to support existing metering paradigms, such call detail records (CDR) or the IPDR framework. (For more information on IPDR, visit www.ipdr.org.)
|
|
