Level: Introductory Mike Polan (polan@ca.ibm.com), WebSphere Hosting Architect, IBM Electronic Commerce division
01 Jan 2002 Provisioning Web services is a keystone to operating pay-per-use Web services between businesses. It is a complex mixture of service authentication, enrollment, metering, billing, and managing operations that control the behavior of a Web service during use, whether within your own company or between business partners. This paper examines the Web Services Hosting Technology (WSHT) package released through alphaWorks that handles this major task.
Introduction
Web services architecture simplifies the creation of distributed applications by leveraging the pervasive nature of the Internet. Organizations can now have cheap, open pipelines to their customers and partners. This allows the creation and integration of automated processes between business entities, as well as the creation of hosted services that can be used as parts of distributed business processes.
For example, a business may implement a purchasing system. In addition to tracking orders and managing the workflow needed for internal approvals, this system could automatically discover, solicit bids, and place orders through external suppliers. It could discover and arrange financing and shipping for orders, and track order status. By leveraging Web services, the purchasing system remains within the realm of control of the organization managing the process, yet can delegate to external organizations for the services needed to complete the process. While much work remains to realize this goal, the infrastructure is beginning to emerge. The Internet provides the connectivity; the Web services architecture provides the mechanisms for exchanging data. Standards bodies will continue to refine service interface specifications to further reduce integration effort. Service providers or businesses that publish Web services for internal or external use will need management functions to provision and control these services. Dan Gisolfi described the requirements identified by the IT department of the fictional "Trumpet" company in his Web services architect column (see Resources). An alphaWorks package, "Web Services Hosting Technology" (WSHT V1.0) demonstrates how the concerns of the Trumpet IT department can be partially addressed. This paper discusses using WSHT in that environment, and how the remaining requirements might be addressed in the future.
Hosting scenarios
The key areas of focus of WSHT on Web services provisioning are as follows:
- Tooling to allow the publishing of Web services into a catalog referenced by the subscription system.
- A subscription and provisioning system for Web services.
- Metering and billing of Web services relative to the contract associated with subscriptions.
- A management system for the subscriptions, provisioning, metering, and billing components.
We begin by looking at the two key scenarios:
- The hosting of Web services built and running on a local application server within the corporate intranet.
- The hosting of Web services built and running on an application server outside of the corporate intranet.
The distinction between the two scenarios is that the first is a simple hosting scenario, while the second could be described as a brokering or wholesaling scenario. For further information on this distinction, you should read "Applying Web services to the application service provider environment" (see Resources).
The goal in both cases is to allow the management of Web services in a fashion that separates the problem domain of the service itself from that of the subscription, provisioning, and management system; in many cases, the author of the service will not need to consider the needs of the provisioning system when composing the service.
The development and deployment aspect would involve of the following steps:
- A developer uses a Web services toolkit and unit test environment to create and test the Web service.
- The developer provides the provisioning hooks to allow a provisioning system to programmatically enroll a new user of the service (if needed).
- The service provider creates a rating package for the rating and billing engine (using tools provided by those applications).
- The Web service is deployed onto the service provider's production server.
- The Web service definition (WSDL) is deployed to UDDI or some other WSDL registry.
- The service provider creates an offer (an offer contains one or more WSDL registry listed services which are associated with the rating package).
- The service provider deploys the offer to an online catalog referencing the services catalog and the rating package.
The enrollment and subscription aspect:
- A potential subscriber (consumer) discovers the Web service(s) either via the registry referencing the catalog or vice versa.
- The new subscriber enrolls (establishes an account) with the service provider if not already a member.
- The subscriber selects to subscribe to the new Web service.
- The service is automatically provisioned for the new subscriber.
- The subscriber downloads the assets necessary to work with the Web service, composes, and deploys a client application.
And the usage aspect:
- The client application uses the Web service, usage is metered and reported by the Web services provisioning infrastructure.
- Usage events are passed to the rating engine, which generates invoice lines for the billing system.
- Both the service provider and the subscriber access the billing system for the current usage charges.
- The service provider uses the management UI to control access to the Web service.
Each of these aspects involves the provisioning system at some level. The development and deployment aspect requires building an interface to the provisioning system; the enrollment and subscription builds the provisioning system; and the usage aspect makes use of the provisioning system. Thus, the enrollment and provisioning system, and the systems that support it, is the key to successfully hosting enterprise-level Web services.
Web Services Hosting requirements
To support Web services hosting on an enterprise scale, you will need a number of important components. This section builds on the requirements identified for hosting Web services that were introduced in "Metering and accounting for Web services"(see Resources).
Catalog of services
To manage Web services for hosting, the services may need to be associated with an offer or deal. An offer links Web services to an appropriate rating package used for determining usage fees (billing). The offer and associated services are published to a catalog and are then available for discovery and subscription by the consumer.
A rating package is a set of rules that associates subscription and usage meter events with a fee. The rating engine evaluates these events against the identified rating package, feeding invoice lines into a billing system. A billing system associates the invoice lines with the proper account, as well as a number of other functions such as tracking invoices and accepting payments.
Once defined, a publishing step makes the assets necessary for the consumption of a Web service available to the consumer. The offer information associated with the services is published to the catalog service and is referenced by the subscription service. Enrollment and subscription
Enrollment is the process of making the hosting system aware of the subscriber identity. This identity is needed to later associate the use of a Web service with the consumer of that service. Often the enrollment and subscription steps are combined.
Subscription is the act of adding a user to the list of consumers of a given Web service. The consumer selects the desired service by choosing an offer containing the desired service(s) and identifying the terms of use in a contract. Subscription may require payment of a setup fee. Once subscribed, any assets necessary for the operation (consumption) of the service are made available to the consumer.
Provisioning
Provisioning is the act of preparing the system for the use of a service by a consumer. It involves preparing both technical and business aspects for supporting the consumers activities.
Web service provisioning
Services may be anonymous or provisioned. Anonymous services operate without requiring the identity of the consumer at run time. An example of an anonymous service would be the retrieval of a stock price. The authentication, authorization, and metering of a Web service is delegated to the hosting system, so anonymous services typically need no additional provisioning.
A provisioned service is one that requires association of a user account and/or other information with the service. For example, the retrieval of an account balance from a user portfolio would be a provisioned service, as the account balance to retrieve must be determined. Additional access control is required for fine-grained protection of the assets associated with that service.
Each provisioned service needs some extensions to automate the enrollment and subscription process. Typically these are APIs built into the service, and need only to be mapped to the provisioning system functions through a service agent. The provisioning system will then drive these functions through the agent at subscription time.
Supporting systems
A number of systems, present in any distributed system design, are useful as well when hosing Web services, and must be provisioned, as shown in Table 1.
Table 1. Provisioning support systems
| System | Description | | Member | A common repository to allow the sharing of user profile information between services. The member repository is populated during the enrollment step. Ideally profile management is self-service, the management functions being provisioned like any other service as part of an offer. | | Authentication | This establishes the identity of the invoker of a service at run time. The authentication system is typically provisioned during enrollment. | | Authorization | This system stores and reports on policies and permissions to determine authorized access to a service and prevent unauthorized access to components or services. The authorization system would be provisioned at subscription time, and consulted at service run time. | | License management | This system assists the service provider in ensuring access to services are properly controlled under the terms of the license agreements for that service. License agreements may be to the service provider and the end user, or between the service provider and the supplier of the service. The license management system would be provisioned at the time the service was installed, and consulted at service run time. | | Rating system | The rating system is used to determine the fees to be applied to meter events as they occur. The rating system consists of a rating engine, and a rating package for each consumer agreement (rating packages can be shared). The rating package would be created (or referenced) at service subscription time. The rating engine would typically process meter events (to determine fees) post service execution, although some implementation may require processing at service run time. |
Contracts
A contract can be used to hold the information that links the consumer of a Web service to that service, to the terms of the service (including the rating package), and to the billing account. Authentication and identity systems provide the context used to discover the appropriate contract when the service is invoked, along with the invoked service itself. The contract context is used for metering information, by the Service Level Agreement (SLA) and by the Quality of Service (QoS) management systems. The hosting system creates and associate consumers, the services, SLA, QoS, and the billing account upon subscription.
In a hosted environment, attempts to invoke hosted Web services will be denied if a valid contract to use those services does not exist.
Metering, rating, and billing
The accounting process for provisioning has several subfactors of metering, logging, rating, and billing. Metering
Use of the Web service by the consumer must be metered if you need usage-based billing. The system also collects enrollment, subscription and provisioning events, and can use this information to determine subscription fees.
Usage metering without imposing additional design requirements on the service itself is accomplished by the instrumentation of the Web services run time. Web services authors may further instrument their services to provide additional metering events. Logging
Meter events are written to a common log for later processing by the rating engine. Metering and meter event logging may occur both at the server and the client sides of the Web service, allowing later reconciliation. Rating
The rating engine translates meter events into invoice items passed to the billing system using the assigned rating package. The rating engine determines charges based on usage and subscription (time-based). Often the rating engine is part of a larger billing system. Billing
The billing system accepts invoice information from the rating engine and associates it with the correct user account. The billing system provides information to allow the retrieval and payment of billing information by the consumer, reconciliation in the case of disputes, and the correct disbursement of payments to the provider’s suppliers (who in turn may be service providers offering wholesale services to the original provider).
Run time for Web services Hosting
At run time, the various supporting systems again come into play as shown in Table 2.
Table 2: Hosting support systems at run time
| System | Run-time procedures | | Member | Services may need to retrieve member information from this common repository. | | Authentication | Establish and validate the identity of the invoker of a service. | | Authorization | Ensure users access only those services to which they are entitled. | | Metering | The Web services infrastructure will record usage events to the logging system. | | Logging | A common logging system will capture audit and meter records for later processing. | | License management | Ensure the components of the system and services are used in a manner consistent with the terms of any license agreements that apply. |
When a service is invoked, the Web services infrastructure will attempt to discover a contract to apply to this invocation. The contract would contain references to the information under which the service would be processed. At a minimum, the existence of a contract would serve as an authorization check; without a valid contract, the service cannot be invoked. The contract may also identify the rating package that should be used when processing meter events generated by this invocation, and may identify QoS and SLA parameters to be used when dispatching the service.
Management
The employment of self-serve profile management functions would lower the cost of operations of the service provider, and would empower consumers to manage their organization and personal data. Management functions of the authentication and authorization systems are typically provided by those systems themselves.
Catalog publishing tools would be used to manage service and offering information in the catalog, while the hosting system would provide contract and subscription management.
Typically the billing system provides custom management function. The billing system may also provide subscriber interface components that would be integrated into an end user portal.
Web Services Hosting Technology
Web Services Hosting Technology (WSHT) is a new package released on alphaWorks that implements all the major functions of provisioning. The following is an overview of WSHT and how it works.
Components and function
The major components of WSHT are the portal, the offer catalog, the enrollment and subscription system, the run-time extensions, and the rating, billing, and accounting system.
WSHT portal
The WSHT package addresses many of the requirements for hosting Web services. It is not intended for production, so the enrollment, subscription, and administrative functions have been combined into a single portal for convenience. The portal provides access to:
- Catalog build and management functions.
- User and subscription management.
- Billing account status.
- Enrollment functions.
- Subscription functions.
- Entitlement lists.
- A Web services test interface.
Offering creation and offer catalog
WSHT provides a tool for creating and managing subscription elements known as offers. An offer associated one or more Web service from a UDDI registry with a rating package used for billing. Offers are presented to enrolled users in a simple catalog as part of the enrollment and subscription operation.
Enrollment and subscription
A simple enrollment system is provided based on the WSTK Identity service. To enroll, a user simply selects a unique user id and provides a password.
A subscription interface allows the enrolled user to select from a list of available offers. Acceptance of the terms of the offer results in the creation of a contract used upon service invocation.
Run-time extensions
The basic Web services run time is extended in the WSHT environment. The run time has been instrumented to record audit and meter records. The basic WSTK identity service is used for authorization (if a user exists and the password matches they are authorized to use the system). The WSTK contract service is used to establish whether the user of a service has a valid contract in place, the contract identifier is then referenced on the meter records.
Rating, billing, and accounting
A lightweight rating engine periodically processes meter records found in the audit and meter log, passing invoice records to a lightweight billing system. The billing system associates invoice records to subscriber accounts. A user interface is provided to allow the viewing of consolidated subscriber bills.
Operating WSHT
Operating WSHT is a two step process; first, to establish the service with the provisioning system; and second to bind the service consumer client to the provisioning system.
WSHT publish, enrollment, and subscription
Figure 1 shows how the service developer publishes the service definition to a UDDI registry. The service provider matches the service to a rating package as an offer, and creates a catalog entry. The consumer enrolls with the service provider, selects the service desired from the catalog, and subscribes to the service. The client assets are downloaded by the consumer and used in the development of the client application invoking the service.
Figure 1. Establishing a service with the provisioning system.
WSHT run time
At run time (see Figure 2), the client application binds to the service and invokes it using an appropriate mechanism for reporting the identity established in the enrollment phase (see Figure 1). The Web services server invokes the identity handler to verify the consumer identity, and then the contract handler to verify a contract exists. The metering handler is then called to record the service invocation start, and later, its completion. The rating engine processes events found in the event long, determines the charges and creates invoice items in the billing system. The consumer uses the service portal to view usage charges.
Figure 2. Run-time client application binding and services interaction
WSHT configurations
There are two configurations for WSHT to support different implementations of Web services protocols: simple and gateway.
Simple
The simple configuration assumes the use of the handler system in the Apache SOAP 3.0 (Axis) protocol implementation, for establishing the identity of the user of a service. The service client inserts the user id and password into the request. The Web Services ToolKit 3.0 server (see Resources) retrieves the identity and uses it to discover the applicable contract under which the service will be invoked.
Gateway
The Web Services Gateway (WSGW) can be used for more complex scenarios, such as:
- Support for non-Axis clients.
- Support for non-Axis hosted services. In particular, the gateway can be used in the "wholesale"scenario, where a service provider is a broker or portal for external services.
- Support for WSIF-invoked internal services, including RMI-IIOP
The WSGW is instrumented for hosting by the addition of interceptors which function in the same fashion as the Axis handlers described above. The gateway will allow the establishment of consumer identity without reliance on the Axis client handlers. For example, WSHT will support HTTP authentication when using the WSGW.
Conclusion
WSHT demonstrates how the Web Services ToolKit and the Web Services Gateway can be used to provide the core functions needed to operate a pay-for-use Web service hosting system. Contracts can be used to link services and consumer identities to rating packages. The rating packages convert usage meter records into invoice records and associated with a consumer account. Most importantly, any service, local or remote, can be provisioned and managed by the WSHT hosting support without requiring changes to the Web service itself. Architectures such as this one will simplify the acceptance of Web services into service provider environments.
Resources
About the author  | | | Mike Polan is a WebSphere Architect currently focused on application and service provisioning, in particular Web services provisioning development. He was a development manager for WebSphere Commerce Suite and lead development teams on VisualAge C++ and VisualAge Java. He can be reached at polan@ca.ibm.com.
|
Rate this page
| 
