Tutorials SOA DevelopmentThe next category of products in the space of policy-driven infrastructure is the service management platform. Unlike the typical systems management product, which normally observes system behavior in the background, products in the service management space take a more active role. In addition to collecting metrics about service invocations, they can also intercept requests and enforce policies associated with those invocations.
Service management products from the major vendors in the space will include both gateways and agents, as well as agents for other gateways, such as ESBs or XML appliances, as if this space wasn't confusing enough. A key difference between service management platforms, ESBs, and XML appliances is typically in the policy domains supported. For all of these products, the policy domains usually include ones focused on individual requests, such as security, but where the service management platforms really shine is in policies that apply across multiple requests, or policies that are consumer-based, rather than service-based. For example, service management platforms will typically be able to enforce a policy that mandates notifications whenever the average response time for a specific time period exceeds a particular threshold. Taking this concept a step further, a service management platform should also be able to apply different thresholds for different consumers. Beyond policy enforcement, service management platforms also include advanced capabilities in collecting metrics on service traffic, along with sophisticated dashboards, reports, and analytics capabilities on those metrics. In contrast, a service management platform may not have as sophisticated routing capabilities of an ESB or the raw performance or threat protection capabilities of an XML appliance.
The final category that must be included is frameworks, specifically service invocation and exposure frameworks. As mentioned earlier, a gateway is not required to implement policy-driven infrastructure. A service invocation framework can be used to intercept outgoing requests and perform policy enforcement and decision-making, and a service exposure framework can be used to intercept incoming requests and perform policy enforcement and decision-making. For example, in the domain of security policies, a service exposure framework such as .NET and Windows Communication Foundation or Java EE and JAX-WS, allow security policies to be specified in an external file from the actual service implementation code.
Man y of these frameworks have also extended the normal WSDL (Web Services Description Language) to specify policies for using the service, such as what type of security credentials are required. These policies are normally specified using the WS-Policy framework, but beyond security (WS-SecurityPolicy), and reliable messaging (WS-ReliableMessagingPolicy), additional standards for specifying policies have not been created. By including these policies within a WSDL document, a consumer can ensure the messages they send are compliant with what the provider expects.
The primary drawback to utilizing frameworks, and also common to an exclusively agent-based approach, is that it limits the domains of policies that can be enforced. In this chapter, the key focus was service versioning. This is an area where a framework-based approach may be insufficient. The reason is that by the time we reach the policy enforcement point, we are already executing a particular version of the service. At that point, it is too late to redirect the request to a different version, unless the versioning logic is coded into the service itself. Agents may have a bit more flexibility in this area, but if the versions aren't running in the same application server or application server cluster, there may still be challenges.
External Service Consumer Perimeter XML Appliance (PEP, PDP) Service Registry/ Repository (PIP) Enterprise Service Bus (PEP, PDP) Internal Service Consumer Service Invocation Framework (PEP, PDP) Outgoing Service Management Agent (PEP, PDP) ESB Management Console, XML Appliance Console, ServiceManagement Console (PMP) Service Management Agent (PEP, PDP) Incoming Service Management Agent (PEP, PDP) Service Exposure Framework (PEP, PDP) Service Provider
While not required, it is possible to combine all of these elements into a single view. XML appliances, with their advanced security capabilities, excel at the perimeter, ESBs with their mediation and routing capabilities can act as a centralized broker, and Web Service Management agents can be leveraged throughout. Combined with the core Web Services and XML support provided by a framework yields the following conceptual view. Policy enforcement and decision points are labeled with PEP/PDP, policy information points are labeled with PIP, and policy management points are labeled with PMP.
