Shimmin On Software: Insight Into SOA Registries
As Service Oriented Architectures proliferate, vendors will realize they have to develop a master metadata management system to handle the different registeries.
Every SOA vendor has one and only one registry and repository. This databank of information keeps track of loosely coupled Web services and information about those services. Once deployed, a registry/repository is considered the single arbiter, the keeper of the corporate conch (metadata, as it were) for all service-oriented architecture assets.
That sounds good. But in reality, these solutions are more like a church suggestion box. Sure, people feed in bits of useful information, but by and large, most keep their thoughts to themselves.
- Strengthen Organizational Agility with the Latest Advances in Case Management
- Accelerate Agility Now: WebSphere Application Server v8.5.5 Overview
- Altair Speeds Complex Simulation and Workload Management with the Intel' Xeon Phi Coprocessor
- How Virtualization is Key to Managing Risk
This admittedly heretical analogy hints at two problems with registries and repositories, hereafter referred to as registries, hinting at perhaps a third problem.
First, registries, though bountiful, are immensely underutilized. Many novice SOA practitioners populate a registry manually, inserting WSDLs (Web Service Definition Language, formal descriptions of a Web service) that they think will, and more important, "should" be re-used. Registries populated in this manner contain precious little beyond the location of the services in question. Obviously, this is a best practices issue exacerbated by human nature.
And here is where the second problem comes into play, disguised as a solution to the first problem. Technology strives to overcome such human failings through automation. In the case of SOA registries, tools used to design and create Web services are beginning to publish information about those services into a central registry.
The same holds true for tools used to orchestrate those services and their transactions. And the same holds true for tools used to manage those services once deployed.
Soon, more advanced customers employing a well-integrated and broad SOA suite will be able to employ this sort of automation across the entire development life cycle: model, assemble, deploy, and manage. At each step in the process, different users create various assets and artifacts, some of which are sent on to the central registry. In this way, a representation of each service lives in the registry as metadata and changes in accordance with each step in the development life cycle.
For example, a business analyst working with a business process modeling notation tool will design a basic process workflow and an associated number of assets, such as use case documents, UML models, key performance indicators, and others, to that workflow. This user then hands off as much of this information as possible to an IT architect or developer, who will add significantly more metadata to the mix, including source code, service level agreements, data models, transformations, and the like.
At each step in the process, as much of this data as possible will be passed on to the next user in the line via federation and synchronization between independent tools and a central repository.
This data exchange will continue until it reaches the SOA governance and administration users, who use as much of this information as possible to monitor running processes and enact change based upon measures such as key performance indicators and SLAs.