Re: [soa-rm-ra] Registries and Repositories

[Danny Thornton <danny_thornton2@yahoo.com>]

I wasn't thinking of a repository for service
code/versions/history as a global database to the
entire community, but if combined with a global
registry that is where that would lead.  One analyst
firm associated the SOA repository to Governance by
essentially stating that configuration management of
the service code is a part of governing the SOA.  The
way the SOA repository was presented,  this form of
SOA repository was closely related to the registry. 
For the open source world, this might make some sense.
 I wanted to see what others had to say about the
subject. 

I associate Service Description meta-data with the
registry and meta-data data with a repository.  The
registry can also contain an orchestrated Information
Model, the Information Model in this sense being
meta-data that is a collection of facts in a specific
context (orchestration) from which conclusions can be
drawn.  The Service Description itself has an
Information Model, the Service Description Information
Model can be a part of bigger picture Information
Model.  I think Duane's slides were similar in nature
to this concept.

In my mind, the importance of a SOA repository
associated with service source code is minor compared
to the importance of the role of Service
Description/Information Model and the SOA
registry/repository.

Danny




--- 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
> 
=== message truncated ===



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com