[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Registries and Repositories
Luckily in our midst we have an expert in this area (kathryn). Not only does she chair the Registry TC at OASIS, but she is also in charge of a large registry at Boeing called Central. D On 12/5/06 8:54 PM, "Francis McCabe" <frankmccabe@mac.com> wrote: > 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 >> >> >> >> > -- ********************************************************** Sr. Technical Evangelist - Adobe Systems, Inc. * Chair - OASIS SOA Reference Model Technical Committee * Blog: http://technoracle.blogspot.com * Music: http://www.mix2r.com/audio/by/artist/duane_nickull* **********************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]