Enterprise Integration Zone is brought to you in partnership with:

As VP of Technology Evangelism at WSO2, Chris Haddad raises awareness of Platform as a Service, Cloud Architecture, Service Oriented Architecture, API Management, and Enterprise Integration. Prior to joining WSO2, Haddad’s experience includes building software development teams, contributing to open source, crafting technology roadmaps, leading Gartner research teams, and delivering Software as a Service and Web applications. Chris is a DZone MVB and is not an employee of DZone and has posted 108 posts at DZone. You can read more from them at their website. View Full User Profile

Application Services Governance Requires More Than an SOA Registry

04.13.2013
| 1801 views |
  • submit to reddit
All SOA infrastructure products should participate in managing, storing, deciding, or enforcing policy.  More than a SOA Governance registry is required.  Application Services Governance Platforms provides advanced policy management capabilities across design-time, run-time, security, and lifecycle management focus areas.

Key WSO2 application services governance platform components participating in policy enforcement, decision, and storage include:

WSO2 Governance Registry serves as a policy store for any type of runtime policies including security policies, lifecycle management workflow policies, API policies, service description, service contracts, service consumption, service usage, service lifecycle management, service level agreements (SLAs) and XACML authorization policies. The WSO2 stack has built-in support for a number of standards, including WS-Policy, XACML 3.0 and SCXML.

WSO2 API Manager delivers an application services governance experience tuned for self-service, on-demand access, and safe API usage.  API governance management encompasses service level policies, usage policies, version policies, subscription policies, and access control policies.

WSO2 App Factory governs and manages application lifecycle policies, infrastructure access policies, and application versioning policies. WSO2 App Factory solves first-mile issues when developing and testing services

WSO2 Identity Server serves as a policy decision point and policy manager for sophisticated security policies encoded in XACML.

WSO2 Business Process Server is a general-purpose workflow engine used by WSO2 Application Services Governance Platform products to execute governance workflow, present task lists, and manage approvals.

WSO2 Complex Event Processor can be configured as a policy decision point, which uses time-based policy pattern matching to evaluate run-time service, message, REST resource, and event traffic.

WSO2 ESB (and all WSO2 products) serve as well-integrated policy enforcement points that may delegate policy decisions to external decision points or internally cache and process policy assertions.

WSO2 Stratos and WSO2 Carbon middleware components (i.e. WSO2 Elastic Load Balancer) deliver sophisticated run-time policy enforcement for tenant partitioning, service level management, application provisioning, tenant access, and resource management.

Policy Management Capabilities

The WSO2 Application Services Governance Platform provides advanced policy management capabilities across design-time, run-time, security, and lifecycle management focus areas.

Design-time policy management

The WSO2 Governance Registry ensures all standard design-time policies, and provides a highly flexible policy management framework, where teams can add new policies and policy validations as extensions using common plug-points. For example, teams can extend basic authentication policies and validate that a minimum level of WS-Security is used on all services. The WSO2 Application Services Governance platform supports all design-time policy management activities listed in this document.

Run-time policy management

Run-time policy management is implemented using a fit-for-purpose combination of WSO2 Enterprise Service Bus, WSO2 API Manager gateway component, WSO2 Cloud Gateway, WSO2 Mobile Gateway Solution, WSO2 Elastic Load Balancer, and/or WSO2 Stratos Cloud Platform.

WSO2 API Manager clients commonly manage and govern API run-time interactions according to specified API service tier policies (e.g. rate limits), subscriptions, and access policies.  In an ESB or API gateway serving as a policy enforcement point, specific service subscribers can be rate limited, traffic can be throttled, malicious messages discarded.  Additional run-time policy mitigation is possible, and in fact, any flow can be defined (e.g., log, send back a fault to the client, start diagnostic process, send event to management components, or fire off a BPEL workflow process with human activity interactions).  Cloud controllers adjust topology and traffic to rectify service level policy breaches. For example, start a new elastic instance to handle more loads.

Additionally, the WSO2 Application Services Governance platform supports a diverse number of run-time policy management activities.

Security Policy Management and Enforcement

The WSO2 application services governance platform supports open Web protocols and popular enterprise protocols including OAuth, SAML2, WS-Trust STS, Kerberos, and Active Directory. The WSO2 applications service governance platform can be interfaced with third-party security policy enforcement systems, including Microsoft Windows Identity Foundation for .NET applications.

Service and Application Lifecycle Management

WSO2 App Factory enables teams to govern and manage application lifecycle promotion and versioning.  Development teams may define custom gates, checklist items, and promotion/demotion rules to govern and manage application lifecycle processes.

The WSO2 Governance Registry, WSO2 API Manager, and WSO2 App Factory implement a very simple, powerful, flexible model for lifecycle states and stages.

The default WSO2 Governance Registry configuration presents a streamlined lifecycle management process that may be modified to match client governance policies.  The management interface presents mandatory and optional checklist items.

The default WSO2 API Manager’s lifecycle management process defines ‘created’, ‘published’, ‘deprecated’, ‘retired’, and ‘block’ states.  Team members in the ‘API Creator’ role may define an API and place it in the initial ‘created’ stage.  Team members in the ‘API Publisher’ role may transition APIs across subsequent lifecycle stages.

WSO2 App Factory  provides service implementation project-level governance and management. WSO2 App Factory automatically executes application service (service or API) integration tests, compliance tests, and performance tests.  Teams may assess test results before promoting service implementations.

Lifecycle Management Model

As the lifecycle management model is based on the WSO2 Business Process Server and a robust workflow execution engine, the model is completely flexible and can be extended in Java, script languages, or BPEL.  Many clients use the “default” (out of the box) model with minimal customization.

The default model is based on the W3C standard State Chart XML (SCXML), which is an XML model of a state machine. Each lifecycle stage is defined as a state and transitions between these are defined as actions that users can take. Each transition has a set of “checklist” pre-conditions that can be tested, together with role-based security to ensure that only the correct role can “check” an item off. In addition, code can be used to calculate checkbox states or form preconditions. Code can be triggered on transition as well. SCXML has a graphical view, which will become part of the tooling around lifecycles.

The result is that the governance teams can quickly and easily create effective lifecycle policies. The WSO2 Application Services Governance Platform presents fit-for-purpose governance environment (WSO2 Governance Registry for services, WSO2 API Manager for APIs, or WSO2 App Factory for applications) offering users a simple-to-use UI that allows users to promote or demote assets in the lifecycle. The SCXML model also supports “branching lifecycles” where assets can go down different paths (e.g. passing external services through an extra security assessment).  Lifecycle stage transitions may trigger run-time enforcement actions.  For example, changing an API stage to ‘Deprecated’ will prevent future subscriptions.  Changing an API stage to ‘Blocked’ will deny API calls.  In WSO2 App Factory, changing service implementation stage will automatically deploy or un-deploy service implementation artifacts from run-time cloud environments (i.e. Dev, Test, Production).

Published at DZone with permission of Chris Haddad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)