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.