Service owners can specify the consumption level that each app is allowed. Policies can then be put in place to instruct IBM DataPower to enforce these limits.
There are several resources on the internet describing how to control service consumption:
- SOA Policy, Service Gateway, and SLA Management
This IBMÂ® RedbooksÂ® publication teaches you how to automate your runtime policy by using a centralized policy management system. The SOA Policy Solution provides a centralized policy administration, enforcement, and monitoring for runtime policies that enable traffic management for service level agreement enforcement, service mediation, and other customized policies. Policies can be defined once and reused among multiple services, thus enabling a standardized, consistent approach to a runtime policy that saves time and money for implementation and maintenance of non-functional requirements for the enterprise and assists with faster time to market.
Business users can use the SOA Policy Solution to help create the service level agreements for their business services to deliver on promises for business performance. IT Architects can use the SOA Policy Solution to architect the policy solution patterns that standardize the runtime policy usage at their organization. Developers select specific policy patterns to implement the non-functional requirements that are associated with their projects. Operations groups provide information about operation needs and create standardized monitoring policy for operational action at run time.
- Using WebSphere Service Registry and Repository V8 and DataPower V5 for service level mediation policy enforcement
This article shows you how to create a web service proxy in WebSphere DataPower for a web service registered and governed in WebSphere Service Registry and Repository. It also shows you how to attach a service-level mediation policy to the service in WebSphere Service Registry and Repository and then enforce it in DataPower.
This article shows you how to control consumption of a service, and reject requests from applications who have not registered as a consumer in WSRR.
- Using DataPower with WSRR and REST services, Part 1: Registering, exposing, and invoking a REST service with a sample client
This article shows you how to use new capabilities in DataPower V6 and WSRR V184.108.40.206 to dynamically look up endpoint URLs of REST services that are registered in WSRR. Policies authored and stored in WSRR and enforced by DataPower have also been enriched with new capabilities.
Much like the previous article, this shows how to control consumption of REST over HTTP services using DataPower.
- Combining IBM Integration Bus with WSRR
Combining IBM Integration Bus with WSRR (WebSphere Service Registry and Repository) enables message flows running in IBM Integration Bus to access the metadata associated with services registered in WSRR. This enables dynamic connectivity between service consumers and service providers.
Part 5 of the article series shows how to check for requests to an IIB-based service, and reject requests from applications who have not registered as a consumer in WSRR.
In this video series, WSRR developer Steve Willoughby demonstrates the policy authoring, attachment, promotion and WebSphere DataPower V5.0 integration with WebSphere Service Registry and Repository.