First, can you give me a very quick summary of Governance?
First let’s quickly define terms. It’s important to understand the difference between a “registry” and a “repository”, even though the two are frequently referred to as synonyms or blended together in a single piece of software.
A web service registry helps a person or helps software find a particular service based on a various kinds of selection criteria. The registry is just a software program that’s akin to a dating service only without the eventual restraining orders. Services are advertised along with a description of their features. A URL
(like http://www.PracticeSafeTech/services/orderBooks.wsdl) is returned by the registry. Developers might use the registry to find a service they need when programming an application or the application itself may use the registry at runtime to find a service. A registry maintains pointers to the services but does not have the power to alter the service itself.
A web service repository, on the other hand, is the tool a company uses to manage each service’s “lifecycle”, from cradle to grave . The repository is used to associate a number of attributes with every service - especially the service’s current state, who depends on it and what other services a given service needs for itself. So a service that is malfunctioning might have its state set to “broken” in the repository. You can’t get that kind of information from the service itself (especially since it’s broken), so a service’s status is stored in the repository.
So what's a repository used for?
Repository software allows you to quickly understand the state of a company’s web services. It typically allows you to retrieve lists of services based on:
- What applications the services are associated with
- Who uses the services
- Who owns a service
- What business objects a service uses
- What the current service state is (“in development”, “in production”, etc.)
- What the last modified date is
- What services are awaiting approval, repair, or some other action
- And a number of other selection criteria based on properties of the service
So very quickly, what's "Governance" then?
Now let’s quickly review governance. “Governance” is the disciplined approach you use to manage the services in your organization. Governance is sometimes described somewhat abstractly as the set of policies you use to manage your services. But in practice, what that really boils down to is formalizing the answers to these questions:
- When do you enter services in your repository?
- When do you push each service through various states (like “in development”, “under repair”, “pending approval”, etc.)?
- Who do you authorize to make changes to the service metadata?
- What work flows do you establish for people of different roles who use the repository to push services through their various states?
So what's the idea behind governance policies?
If you know the answers to those questions, you know your governance policies. Those governance policies have these goals:
- To keep services from unexpectedly changing or breaking.
- To keep the interfaces (rather than the implementation) of a service from unexpectedly changing.
- To ensure that people know about services they may be interested in.
- To avoid overlapping functionality.
- To keep all hell from breaking loose. To ensure that corporate fist fights are reduced to mere screaming and shouting matches.
Ultimately governance is about enforcing policies that help to coordinate shared material.
So how to registries and repositories work together then?
Since the registry is the piece of software that establishes visibility to services and the repository is the software that tracks the service state and some metadata, the combination of the two creates a logical choice as an enforcer of governance policies. For example, suppose a web service is in a “needs repair” state in the repository. The registry might then take that service off line so it can no longer be found. Any law or policy that has no enforcement ends up getting ignored, so the registry and repository join forces to enforce governance policies.
What kinds of files to registries and repositories help manage?
In the old days , registries were used only to serve out web service interface files (WSDL files). Now-a-days they track any files that might be shared in the organization that, if unexpectedly changed, would cause problems for somebody else’s application. Registries and repositories now track XML Schemas (XSD), XML Stylesheet Transformation (XSLT) documents, Business Process flows (BPEL), WS-Policy descriptions, general XML documents, or just about any shared business object, service, schema, or document that’s needed during development or runtime.
Since applications depend on services that, in turn, depend on other services or applications, a very complex web of interrelationships can result. In such cases, the impact of changes to services can be difficult to determine. Repository software often provides mechanisms to understand interrelationships and to perform “impact assessments”.
In just a few seconds, tell me what UDDI is
You may encounter the term "UDDI" in literature that deals with governance. Universal Description Discovery and Integration (UDDI) is a client API and server runtime that implements a registry. Technically UDDI can support a wide range of documents, but it is normally used to serve out only WSDL documents.
The grand vision for UDDI was originally for inter-corporate use. Companies were going to scan the world for services they needed that provided the highest quality for the lowest price. Applications would dynamically bind to the best service and fantastic new market efficiencies would be realized. For example, a book store might create a set of web services according to a standard set of interface definitions. Those services would then be posted in a global UDDI repository for book sellers. This would open up that seller’s inventory to the entire world. Any software system that needed to buy one of the vendor’s books could examine that seller’s inventory via the vendor’s inventory services (found via the global UDDI repository) and then purchase the books also via a few of the vendor’s web service calls. Amazon.com, for example, was going to be replaced by a set of global UDDI servers. Obviously this has not happened yet because of a number of problems outlined below in the “How well does it work?” section.
OK then, what's WS-Inspection?
Often mentioned in conjunction with UDDI, WS-Inspection language is an XML format that a web service provider uses to describe its own services. Since service consumers may be looking for a given service based on widely varying selection criteria, the WS-Inspection format (an XML file, of course) is designed to support very diverse queries. WS-Inspection is often confused with UDDI itself, but it does not perform the same function. WS-Inspection describes only a small set of services and is provided directly from each service provider. UDDI, on the other hand, describes everyone’s services (not just one provider’s) and is acts as a central directory service. If you asked every server in your company for their WS-Inspection documents, you could assemble your company’s UDDI directory from that set of queries.
What are the common mistakes that companies continually make?
So how well does governance software really work? What are the most common mistakes companies make with their governance software and policies? Are there any alternatives to governance software? For a few bucks you can get some very valuable information, but also avoid death by boredom. Click the “order” button below and get the remaining sections on the governance chapter you've just read. Don't miss out, for example, on the "Common Mistakes", "Alternatives", or "Future of the Technology" sections. Get those sections for all the other technologies we cover as well. You'd be surprised at what really brings down governance projects. Our analysis is thorough and we don't simply state the obvious. Order today!