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 modeling and administration tools; service registries and repositories; and service-level management infrastructures.
Visual service modeling and administration tools
Visual modeling 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 modeling in the Unified Modeling Language than development in Java, C# or any other declarative programming language. In a complex SOA, visual modeling 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 modeling 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 modeling 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 () 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 interprogram communication. Tool-driven controls on service binding effectively govern how services interact across the ESB.
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 [] 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 , Simple Object Access Protocol () 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 . 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.