[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Registries and Repositories
| Let's try another twist on this. Let's say the registry contains a subset of the service description necessary for a consumer to differentiate between different services and decide which was best to satisfy its needs. As with the "complete" description, the subset in the registry is likely to comprise links to external resources rather than having copies of the resources itself. This may be sufficient because, for example, if a consumer can see that the provider will abide by a certain policy (where the policy is indicated by the link), having the details of the policy (e.g. the resource obtained by dereferencing the link) may not be necessary. The subset in the registry should also point to the "rest" of the service description. The identified subset may depend on the particular registry (e.g. its data model or the consumers it is most likely to support) and a different subset may be chosen for different registries. This last statement assumes that multiple registries exist and a service may be registered in more than one. This brings up the question of identifying when two descriptions point to the same service, but that is probably necessary because I can't see effectively policing the idea of only being registered in one place. As for repositories, sometimes the concept of an associated registry and repository makes sense and sometime it doesn't. For example, I can see a policy registry and an associated repository holding the actual normative (and maybe executable) description. When the policy artifact is entered into the repository, the registry entry is created. If policy consumers "register" interest in a policy (i.e. in a pub/sub sense), they can be notified if the policy changes. For a service, it is less clear what would be stored in a repository. Yes, we could use the repository to hold a configuration managed copy, but there is no way to ensure that that is at the target when you interact through the supplied service interface. Then there is the matter of the underlying capability and how its CM affects (or is reflected in) the CM of the service that accesses it. More likely, the service description has a CM component (or elements that together enable a CM function) that identifies (points to?) executable resources and the service CM in some way references that resource's CM artifacts. Now we can ensure some level of connectivity between the artifact and its function, something other than just careful bookkeeping of well-meaning and overworked librarians. I think I could even come up with how federation would work in this scenario, something I have yet to see done convincingly for UDDI. I'd be interested to see how this lines up (or completely runs afoul) of the more in-depth rep/reg work done by others. But be quick about this -- I'm adding some registry slides to my MITRE SOA course. Ken On Dec 4, 2006, at 1:25 PM, Duane Nickull wrote:
------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]