[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Registries and Repositories
I got the feeling that Danny's repository was to act as a kind of global database -- not directly part of service descriptions, but a common information resource shared by the entire community. If that were the case, then I can see two arguments: a. It is out of scope for a pure SOA play b. It could be incredibly useful for an organization to organize itself in that way. Frank On Dec 5, 2006, at 7:32 PM, Ken Laskey wrote: > 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: > >> Service Registries act as pointers to metadata that describe the >> service. >> They fulfill many aspects of the SOA metamodel including the >> visibility (by >> making the service endpoints findable to the consumer), pointing at >> artifacts that contain the metadata for things like the service >> policy, the >> service description and other things. Holding the code that makes >> the >> service run is not something one would normally employ a registry/ >> repository >> for. >> >> The repository is not as simple as it at first seems. Many people >> have a >> perception that a repository is one "thing" when in fact, the >> artifacts >> might be de-centralized. For example, the registry might hold a >> static copy >> of a WSDL in resident memory via an internal repository, but it >> might point >> at an extrinsic artifact for the service policy which resides on a >> different >> system. While this is nice in terms of a dynamic system that can >> facilitate >> some aspects of late binding (simple changes like ports, URL's, SOAP >> versions etc.), it also introduces a problem of synchronization >> between the >> registry and the repository. The registry might not be notified >> if an >> extrinsic objects changes state. This could be solved using a >> mechanism >> like WS-Eventing. >> >> I have many sets of slides available for download at >> www.nickull.net on the >> subject (including ISO 11179, UDDI and ebXML Registry) if anyone >> wants to >> read up on the topic. >> >> Duane >> >> >> On 12/4/06 8:09 AM, "Chiusano, Joseph" <chiusano_joseph@bah.com> >> wrote: >> >>> More thoughts: >>> >>> So the registry would store metadata that describes service >>> artifacts, >>> which are stored in a repository. Service artifacts can also be >>> considered types of IT artifacts. >>> >>> Joe >>> >>> Joseph Chiusano >>> Associate >>> >>> Booz | Allen | Hamilton >>> ______________________-- >>> >>> 700 13th St. NW, Suite 1100 >>> Washington, DC 20005 >>> O: 202-508-6514 >>> C: 202-251-0731 >>> Visit us online@ http://www.boozallen.com >>> >>> -----Original Message----- >>> From: Chiusano, Joseph [mailto:chiusano_joseph@bah.com] >>> Sent: Monday, December 04, 2006 10:41 AM >>> To: Danny Thornton; Francis McCabe >>> Cc: soa-rm-ra@lists.oasis-open.org >>> Subject: RE: [soa-rm-ra] Registries and Repositories >>> >>> To me, a service description is one example of a service artifact. A >>> service policy in text form (for human consumption) would be another >>> example. If I recall correctly, a service policy in electronic form >>> would be part of the service description according to our RM (if >>> I am >>> not correct, then that would be another example of a service >>> artifact). >>> >>> Joe >>> >>> Joseph Chiusano >>> Associate >>> >>> Booz | Allen | Hamilton >>> ______________________-- >>> >>> 700 13th St. NW, Suite 1100 >>> Washington, DC 20005 >>> O: 202-508-6514 >>> C: 202-251-0731 >>> Visit us online@ http://www.boozallen.com >>> >>> -----Original Message----- >>> From: Danny Thornton [mailto:danny_thornton2@yahoo.com] >>> Sent: Monday, December 04, 2006 10:16 AM >>> To: Chiusano, Joseph; Francis McCabe >>> Cc: soa-rm-ra@lists.oasis-open.org >>> Subject: RE: [soa-rm-ra] Registries and Repositories >>> >>> So let's expand on what a service artifact is and what a service >>> description artifact is. This will help provide a better distinction >>> between the registry and the repository. >>> >>> Danny >>> >>> >>> --- "Chiusano, Joseph" <chiusano_joseph@bah.com> >>> wrote: >>> >>>> Suggestion: The repository is the storage location for service >>>> artifacts. >>>> >>>> Joseph Chiusano >>>> Associate >>>> >>>> Booz | Allen | Hamilton >>>> ______________________-- >>>> >>>> 700 13th St. NW, Suite 1100 >>>> Washington, DC 20005 >>>> O: 202-508-6514 >>>> C: 202-251-0731 >>>> Visit us online@ http://www.boozallen.com >>>> >>>> -----Original Message----- >>>> From: Francis McCabe [mailto:frankmccabe@mac.com] >>>> Sent: Monday, December 04, 2006 1:00 AM >>>> To: Danny Thornton >>>> Cc: soa-rm-ra@lists.oasis-open.org >>>> Subject: Re: [soa-rm-ra] Registries and Repositories >>>> >>>> We can certainly discuss this. >>>> However, I am not sure that I see everything here. >>>> For one thing, I do not see how services can be stored... >>>> >>>> Frank >>>> >>>> On Dec 3, 2006, at 9:31 PM, Danny Thornton wrote: >>>> >>>>> I would like to add a Registry/Repository >>>> discussion to the agenda for >>>> >>>>> this Wednesday RM providing we have time. This >>>> relates to the >>>>> Visibility section of the RA. >>>>> >>>>> >>>> >>> http://wiki.oasis-open.org/soa-rm/TheArchitecture/ServiceView/ >>>>> Visibility >>>>> >>>>> The RA currently defines the registry as >>>> containing links to Service >>>>> Description artifacts and the repository is >>>> defined as storing those >>>>> artifacts. >>>>> >>>>> Another view of the repository is that the >>>> repository is the storage >>>>> location for the services, the system of record of >>>> the services. One >>>>> of the things stored in the repository is the >>>> configuration management >>>> >>>>> of the SOA service code. In this view, the SOA >>>> repository becomes >>>>> somewhat internal to the organization. The >>>> majority of the Service >>>>> Description and its artifacts reside in the >>>> service registry. >>>>> >>>>> Other thoughts on this? >>>>> >>>>> Danny >>>>> >>>>> __________________________________________________ >>>>> Do You Yahoo!? >>>>> Tired of spam? Yahoo! Mail has the best spam >>>> protection around >>>>> http://mail.yahoo.com >>>> >>> >>> >>> >>> >>> ____________________________________________________________________ >>> ____ >>> ____________ >>> Cheap talk? >>> Check out Yahoo! Messenger's low PC-to-Phone call rates. >>> http://voice.yahoo.com >> >> -- >> ****************************************************** >> Sr. Technical Evangelist - Adobe Systems, Inc. * >> Chair - OASIS SOA Reference Model Technical Committee* >> Blog: http://technoracle.blogspot.com * >> ****************************************************** >> > > ---------------------------------------------------------------------- > -------------------- > 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]