Database Reference
In-Depth Information
The Enterprise Service Repository / Inventory framework
As service governance is a never-ending process that begins before a service is created
and doesn't finish until it is decommissioned, shaping and defining the service inventory
should be addressed at the beginning, before other frameworks. Nevertheless, we would
prefer to come to this point at the end of frameworks' discussion, when high demands for
it become clear and obvious. Yet, this is probably the most misunderstood and obscured
framework. Even naming can be confusing, so we need to explain the difference between
repositories and inventories first.
The service repository is the centralized store of service-related artifacts and metadata that
(possibly) include service code, test results and metrics, and services message attributes.
This store is organized as a container with clearly defined metadata taxonomy and service
ontology, supporting fast search and lookup. This container is mostly of the design-time
nature, but can be actively used on runtime as well; it is usually supplied with elaborative
human-readable interface in support of design-time discoverability, allowing artifact har-
vesting out of exiting implementations and expanding the arbitrary service taxonomy.
The service inventory is the runtime-accessible list of service artifacts mostly related to a
service contract that supports fast search and dynamic service invocations. These are sup-
ported by machine-readable APIs, which are capable of registering newly deployed ser-
vices, and search by different elements of service contract (WSDL and tModels).
Both support discoverability, that is, runtime and design-time, and therefore should not be
implemented separately. One just supports the other. The role of this framework is im-
mense; the UDDI mechanism was declared as an essential part of contemporary SOA
from the very beginning. We would risk assuming that initially slow acceptance of SOA
was also caused by immature or complex taxonomies of service inventories. Simply put,
it's rather hard to invoke and reuse something that is difficult to find or comprehend. At
the present moment, most standards related to the service taxonomy are under develop-
ment and still maturing.
Common frameworks' requirements for
GF06: ESR
are consolidated as follows:
• The Service Repository tool available with links to EBS and EBF
• An Object Harvesting mechanism for existing objects/installations (service/ob-
jects discovery in designtime)
• UDDI support for ESR, automatic registration on deployment
• Automatic service discovery in runtime (ESR unified)
Search WWH ::
Custom Search