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