SOA Metadata Repository - SOA Registry - Metadata Repository - This all sounds very confusing
September 15, 2006 7:17 PM
Filed Under: Metadata Data Integration SOA
The notion of metadata management is becoming more critical with the loosely coupled nature of SOA. As more and more data services are created based on various information sources, metadata centric visibility tying data services to their associated information sources participating in Data Integration techniques will become critical.
First let me state my definition of these various terms:
a) Metadata Repository - A central/federated server where metadata (Models) and Meta models for various elements in an IT shop get persisted for common usage, versioning and lifecycle. These could include models of Customer Table for a database, Customer Update Service for SOA, Federated View of Customer targeted from multiple data sources.
b) SOA Metadata Repository - A natural extension of Metadata Repository where one type of Models/MetaModels being stored corresponds to SOA artifacts in the various applications.
These include the model of the Services and their relationship to existing models like databases, etc.
c) SOA Registry - A catalogue of services available for usage both in public and private scenarios. This can be driven by the models stored in the SOA Metadata Repository and the Metadata Repository could be the storage for associated WSDL, etc.
As SOA becomes more mainstream, I think that SOA metadata repository will become the same as the traditional metadata repository and will become a part of enterprise's metadata management strategy.
To clarify this let me use a concrete example. In a current enterprise IT environment, Customer information resides in a) Sales database and b) Marketing database. So for a Customer Data Integration Scenario, a report needs to be generated based on data integrated from these multiple data sources. So a data service providing integrated customer data will be leveraged by the report developer to create the report.
First step in the process would be that a Data Service Architect would define the Service Model for "Customer Information" Service
-Service
- Interface
- Operation
- GetCustomerInformation.
Once a model of the Service is defined, this is persisted in the metadata repository and published into the Service registry. The service definition could also be generated and published into the repository if WSDL or other definition mechanism are needed.
Report developer can query the service registry for "Customer Information" service based on keywords or by using a catalogue and get the service definition to start using the service definition in the report. In some cases they can directly use the service model and have access to more metadata than what can be available in a WSDL file or the service registry.
Meanwhile the data service developer can tie this service to these various Customer databases and implement integrated (federated approach) view of customer data. These relationships between service model and various databases like Customer and sales are captured in the metadata repository allowing for full visibility into loosely coupled services and their implementation data sources.
If you look at the various relationships that are captured:
Service Metadata in SOA Registry => Service Models in SOA Metadata Repository => Service Definitions (WSDL) in the SOA Metadata Repository => Service Implementation Models in SOA Metadata Repository => Database Models in Metadata Repository.
This shows how tying the data services with their associated implementation artifacts allows for both loose coupling and increased visibililty into various relationships between components in IT.
SOA Registry Service Consumption Metadata, WSDL Locations, etc
SOA Metadata Repository = Service Definitions (WSDL), Service Models, Information Models (Data, Object, BPM), Relationships between Services and Other Information Models
Eventually, I can envision there being a single entity that provides registry/repository functionality where the services can be consumed using the traditional service definition file to get the information or use the service metadata directly from common models available through the repository.
Posted by Himagiri Mukkamala on September 15, 2006 7:17 PM
