SOA governance: Preventing rogue services

Service-oriented architecture is the shape of distributed computing in the Internet Age. At the heart, SOA is a set of practical approaches for designing shareable, reusable services. It lets enterprise IT groups treat a decentralized, multiplatform environment as a unified computing fabric. But SOA also is a mess waiting to happen.

By encouraging widespread reuse of scattered software components, SOA threatens to transform the enterprise network into a complex, sprawling unmanageable mesh. Left ungoverned, SOA could allow anyone anywhere to deploy a new service at any time, and invoke and orchestrate that service - and thousands of others - into ever more convoluted messaging patterns. In such an environment, coordinated application planning and optimization become fiendishly difficult. In addition, rogue services could spring up everywhere, passing themselves off as legitimate nodes and wreaking havoc on the delicate trust that underlies production SOA.

SOA governance refers to the industry's efforts to establish practices and tools for managing this mesh and enforcing consistent security, performance and other policies across the service life cycle. SOA governance tools let organizations continuously model, map, monitor and take control of their distributed environments. Effective governance ensures that the enterprise SOA complies with all applicable regulatory, competitive, operational and other baseline requirements.

Vendors of SOA governance tools are forming industry associations to popularize approaches for design-time and run-time governance. Last month, many pure-play vendors of SOA governance tools formed SOA Link, an alliance under which they pledge to improve interoperability among their products. Founding partners include AmberPoint, Composite Software, Forum Systems, Infravio, Intalio, Iona, JBoss, Layer 7 Technologies, LogicBlaze, NetIQ, ParaSoft, Reactivity, SOA Software, SymphonySoft, webMethods and WS02.

Organizational process changes are critical to SOA governance, says Miko Matsumura, vice president of marketing and technology standards at Infravio, an SOA governance tool vendor. "SOA governance depends on IT governance processes, under which SOA projects are built to adhere to business policies," Matsumura says. In addition, he says, SOA project governance requires governing boards in which there is a "clear conversational basis between business and IT personnel, focusing on business considerations."

Enterprise IT groups, especially at large companies with distributed development teams, also should implement internal centers of excellence. These would spread SOA governance best practices and application design patterns among developers, Matsumura says.

From a technological standpoint, SOA governance demands a comprehensive management infrastructure that spans the service life cycle from planning through design, development, deployment, operation and optimization. SOA governance vendors will often characterize their tools as appropriate for design-time vs deploy-time vs run-time usage (or all three).

Across the complete SOA life cycle, governance tools assist enterprise IT in planning, developing, deploying, monitoring, optimizing and controlling their distributed, heterogeneous application environments. SOA governance infrastructure also helps organizations ensure the continued performance, reliability, availability and security of end-to-end business interactions within their SOAs.

The principal technological components of the SOA governance infrastructure are visual service modelling and administration tools; service registries and repositories; and service-level management infrastructures.

Page Break

Visual service modelling and administration tools

Visual modelling is at the forefront of SOA governance, across all service life-cycle stages. An SOA development tool vendor is more likely to boast of its ability to support visual modelling in the Unified Modelling Language than development in Java, C# or any other declarative programming language. In a complex SOA, visual modelling is the most effective approach for specifying, implementing and maintaining the end-to-end orchestration logic, policies and rules upon which governance depends.

Every SOA platform and tool vendor provides visual modelling tools for SOA governance. Every SOA consultancy deploys visual tools to support their various planning, development and other professional services.

As a governance approach, visual modelling isn't restricted to SOA design time. Enterprise architects may feed run-time metrics from visually oriented SOA monitoring tools into their SOA application models to assess how best to tweak, modify and optimize an operational SOA. Some call this governance phase the SOA change time.

Service registries and repositories

Service registries are primarily used in SOA design time, though they often have run-time functions too. Registries support development, publishing and management of the service contracts, policies and metadata that drive SOA governance. As such, they provide a master control point - or policy enforcement point (PEP) - where services can be registered and discovered in an SOA.

Registries may include configuration, compliance and constraint profiles on services and associated software artifacts. Any repository, database, catalog or other node that facilitates registration, discovery and retrieval of service contracts, metadata and policies may be regarded as a registry.

The principal service registry vendors fall into two camps. On the one hand are pure-play vendors, which provide service, policy and metadata registries and repositories. Flashline, Infravio, LogicLibrary, SOA Software and Systinet (a division of Mercury Interactive) are some examples. On the other hand are SOA platform vendors, which include registries as a component of integrated product suites that often include application servers, portals, database management systems, business intelligence tools, integration middleware and other functional components. SOA platform vendors with registries include BEA Systems, IBM, Microsoft, Novell, Oracle, SAP, Sun and webMethods. The Universal Description, Discovery and Integration (UDDI) standard defines one of the principal registry environments for SOA, though by no means the only.

Most pure-play and platform vendors also provide SOA development, integration and management tools. SOA vendors that don't have their own registries often integrate with one or more third-party registries through UDDI V3 and other open standards. For example, HP has a broad range of SOA development, policy definition and run-time governance tools, but integrates principally with Systinet's UDDI registry. And enterprise service bus (ESB) middleware vendors, such as Fiorano Software, Sonic Software and Tibco Software, integrate with third-party UDDI and other registries and repositories.

Most commercial service registry products support the following SOA governance functions:

• Service registration: Application developers, also known as service providers, publish their functionality to registries. They publish their services' contracts, which include such descriptive attributes as service identities, locations, methods, bindings, configurations, schemas and policies. One of the most effective approaches for SOA governance is to restrict what sorts of new services may be published to the master registry, by whom, with whose approvals and under what conditions. Increasingly, developers are integrating registries with workflow features that govern how services are approved, designed, developed, published, versioned and retired. In addition, many registries include prescriptive service templates that may be required to develop services that will be published to the registry.

• Service location: service consumers - in other words, application developers - query the registry to find services that match their functional requirements. The registry lets the service consumer retrieve service contracts. Controls on who may access the registry and what service attributes are exposed through the registry are other effective means of SOA governance, and are usually supported in registry products.

• Service binding: Service consumers use the retrieved service contracts to develop code that will bind, invoke and interact with registered services. Developers often use integrated development environments for the automatic binding of newly created services to the various protocols, schemas and other interfaces required for inter-program communication. Tool-driven controls on service binding effectively govern how services interact across the ESB.

Page Break

One of the emerging best practices in design-time SOA governance is profile management within the registry to indicate a service's current life-cycle stage and the associated policies for that stage. Atul Saini, CTO of Fiorano Software, describes how service profiling might work in the development stage:

"One might want to run a service on a particular machine with a set of input parameters. The machine name and parameters become part of the development profile attached to the service. Once the service has been developed, it can be promoted to the quality-assurance stage and run on a different machine with different parameters. This second machine/parameter set becomes a new profile. In this way, multiple profiles can be created for a given service, and the service can be moved between various stages in its life cycle by simply associating different profiles with the service at any time," Siani says.

Profile management often presumes that a development organization has a structured procedure for promoting services to the next stage. Some SOA development tools include embedded workflow environments that help organizations address this aspect of design-time governance. For example, LogicLibrary's Logidex tool "helps development organizations configure checkpoints, roles and multistep workflows into the SOA development process", says Brent Carlson, the company's CTO and co-founder.

"You can automate the review and validation steps involved in promoting a service to the next stage - such as validating a [Web Services Description Language] definition against the organization's particular set of WS-* standards - and, if the definition is found to be nonconformant, kick it back to the developer for correction before the service can be published to the registry," he says.

Service-level management infrastructures

Often, commercial registry products integrate with one or more service-level management (SLM) products, from the same or third-party vendors. SLM tools are principally employed in SOA run time. They enable policy-driven monitoring, optimization and control of the SOA in accordance with service-level agreements (SLA). Hence, they can be used to govern the flow of ESB traffic among registered services, endpoints and users.

SLM tools - or Web services management infrastructure - differ from traditional network, system and application management tools in their focus on application-layer message inspection and its triggering of automated policy rules based on headers, payloads, senders and other message attributes. SLM environments enable end-to-end service-level monitoring through centralized correlation of traffic-triggered events and metrics.

SLM environments enforce governance policies on ESB message traffic through run-time components called agents. The agent is the principal PEP for run-time SOA governance (just as the registry is the principal PEP for design-time SOA governance). An agent is any functional component that intercepts, inspects, filters, transforms, routes or accelerates processing of production XML, Simple Object Access Protocol (SOAP) and other content interchanges between services.

An agent may be deployed as an intermediary node (such as in a proxy server or specialized hardware appliance) or within an application server (typically integrated with that server's SOAP engine, or embedded in a co-processor board).

SLM environments let IT administrators determine, for example, whether end-to-end latencies and response times on SOAP traffic have exceeded predefined QoS thresholds. Many allow dynamic rerouting of SOAP messages to improve QoS. Some tools also can serve as application-layer firewalls.

The SLM environment should let organizations detect rogue services in their SOA and take appropriate actions, says Dan Foody, CTO of Sonic Software. "A rogue service is one that never went through the necessary approval process [during design time]. You need an infrastructure that can automatically detect rogue services, validate and register them, and then push them through the approval process. Until approved, a rogue service may be quarantined or subjected to tighter-than-normal security."

An SLM console is the principal run-time monitoring and administration node for SOA governance. SLM consoles also support real-time visualization and control of the end-to-end behavior of an SOA in run-time. Enterprises can deploy consoles in centralized or decentralized configurations and can access them through browsers, SOAP interfaces, vendor-proprietary GUIs or other means.

Enterprise IT can integrate SLM consoles into broader management suites that also handle application, system or network management. Enterprises usually deploy SLM consoles in conjunction with registries or repositories of administrator-defined SLAs and other policies. Increasingly, SLM consoles connect to distributed agents through Web Services Distributed Management, a set of Organization for the Advancement of Structured Information Standards standards.

SLM pure plays include Actional (a unit of Progress Software), AmberPoint, Reactivity and SOA Software (which recently acquired another pure play, Blue Titan). Platform vendors with SLM tools or embedded functionality include BEA, HP, IBM Tivoli, Oracle and webMethods. Tibco has announced plans to include SLM and a UDDI registry in its Project Matrix SOA/ESB offerings later this year.

SOA platform vendors will continue to add comprehensive SLM features to their product architectures, as well as such ESB features as dynamic content-based routing and distributed transactions.

To address scalability and performance, more vendors will begin packaging SLM agents as hardware appliances. IBM's DataPower Technology group is a pioneer in the SLM appliance market. Other vendors, such as Cisco with its Application-Oriented Networking (AON) product family, will provide intermediary appliances that operate as PEPs for run-time SOA governance. Appliances enable run-time governance tools to "allocate [million instructions per second] flexibly through an SOA based on changing workloads," says Bill Ruh, managing director of Cisco's AON services team.

But fundamentally, SOA governance comes down to corporate culture, not technological plumbing. Enterprises also will need to sustain an IT governance culture that encourages maximum service reuse, through a full slate of SOA-focused training, incentives, visual development tools and best practices. Corporate-standard policies and design patterns must be embedded in development tools, and instilled through an all-pervading IT ethos. And the IT culture always must be driven by the business governance environment, leveraging reusable services to maximize return, agility, visibility and accountability.

A well-governed SOA provides a platform to harness the organization's full resources for competitive advantage. The alternative is a mess of myriad, scattered, poorly integrated services operating at cross-purposes.

James Kobielus is a principal analyst at Current Analysis