SOA terminologies - defined !
The intended grand vision of a universal service broker though has fallen down; the need for cataloging service is however being more and more realized as critical pieces in solving the puzzle of realizing SOA. Till early last year there had been various products offering service-cataloging features based on UDDI standards. But now we see another terminology being thrown across called repository.
Continuing with my previous post in defining the terminologies, here are two more!
Service Registry
A service registry is a searchable catalog or itemized list of meta-data on all the available services that are categorized or systematically arranged based on a predefined taxonomy.
Repository
A repository is a collection of information such as technical reference documents, reports, and policy descriptions etc. that is both current and historical about the service. This would typically be extending the data storing capabilities of the service registry and accessible with out any prior knowledge of the repository structure. Repositories are managed by the data provider and/or a registrar and are referenced in service registries through meta-data.
So putting it in simple statement registries are made of meta-data and repositories with data. But what really makes up meta-data and data? In his tip Matsumura suggests that data and meta-data are determined based on the relationship.
When referring to storing of data about services aren't we talking about managing content that is associated with service. Now there is another acronym that strikes - ECM. What about the existing ECM solutions like Sharepoint portals, Lotus Notes, Hummingbird or FileNet (already in place) as few new products are contemplating on registry-repository solutions? Looks like the new products have opted to follow their own solution called service oriented content management or content management for service and not being dependent or adapted generic content management solution. For instance, in one of the recent redbooks about WSRR says “WebSphere Service Registry and Repository is SOA and service centric in nature. It has not been designed to act as a generic content management solution and does not provide extended capabilities around information capturing, indexing or archiving.” In such cases there must be some thinking to be done both in physically hooking up ECM and repository and standard processes followed with ECM.
Comments
Bringing ECM into this article makes it more interesting. Does this mean we can relate the 3 terminologies in the following manner:
Service Registry ----> Repositories ----> ECM
Also, what is the real benefit of Repositories? What exactly is the purpose? Unless the intention is clear of its usability, it would be one more terminology in the overpopulated ocean of buzzwords.
Are we talking about using repository, we can track different set of information (interface, design, docs etc.) attached to a particular version of the Service?
Posted by: Shubhankar | January 23, 2007 01:44 PM
I intentionally did not refer repositories as 'Service repositories' as in case of 'Service registry', for reason being that existing ECM's could be employed. Having put this way it means that we can realize repositories through existing ECM solutions. So equation turns out to be like:
Service Registry --> Repositories (Custom | ECM ?)
But question here is that, what features should be thought off to enable ECMs to back service registry? Answer for which mentioned in earlier comment --
'Unless the intention is clear of its usability, it would be one more terminology ...'
Posted by: Naveen | January 24, 2007 09:27 AM