On May 23, 2006, at 5:07 PM, Anne Thomas Manes wrote:

> Mark, why do assume that UDDI = centralized?
>
> UDDI is a protocol for accessing a registry. All registries and 
> repositories should support the UDDI protocol.
>

I wonder ... should they? What value does UDDI add? Where is the 
ecosystem that relies on the UDDI model and API? Where are the tools 
and what value do they provide?

I have advocated UDDI in the past, but I have stopped believing in it.

> In response to Jan's question, a registry which is nothing more 
> than an implementation of the UDDI specification isn't particularly 
> useful. A registry/repository should support significantly more 
> governance and lifecycle management functionality. ( e.g., take a 
> look at Systinet 2 and Infravio X-Registry).
>

Which sort of underlines my point -- UDDI alone does not solve any 
problem, so you currently need to do something more or less proprietary.

Systinet 2, BTW, provides a pure REST interface that is much more 
useful than any UDDI-based, tModel-ridden API could ever dream of 
being ...

Stefan

> Anne
>
> On 5/23/06, Mark Baker <[EMAIL PROTECTED]> wrote: Anne - all that you 
> describe there is trivially-decentralizable, so I
> maintain, if you do it with UDDI you've got a new problem to deal
> with.
>
> On 5/22/06, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> > Don't pidgeon-hole registry and repository into a system used 
> only for
> > discovery.
> >
> > Registries provide a conduit for multiple runtime systems to share
> > management and control information (e.g., policies, SLAs, 
> heuristics, etc).
> > Repositories support metadata management, policy management, 
> contract
> > management, dependency management, impact analysis, and lots of 
> other
> > SDLC/governance activities.
> >
> > Anne
> >
> > On 5/22/06, Mark Baker <[EMAIL PROTECTED] > wrote:
> > >
> > > > This is where a UDDI Registry/Repository comes into its own,
> > >
> > > Ouch!
> > >
> > > No, the problem is that if you change implementations and stuff
> > > breaks, then you're not loosely coupled.  "Become more loosely
> > > coupled" is the answer to that problem.
> > >
> > > If you centralize trivially-decentralizable functionality like
> > > discovery to solve a loose coupling problem, then you've now 
> got two
> > > problems.
> > >
> > > Mark.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Get to your groups with one click. Know instantly when new email 
> arrives
> http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/NhFolB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> SPONSORED LINKS
> Computer software Computer aided design software Computer job
> Soa Service-oriented architecture
>
> YAHOO! GROUPS LINKS
>
>  Visit your group "service-orientated-architecture" on the web.
>
>  To unsubscribe from this group, send an email to:
>  [EMAIL PROTECTED]
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>






SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




Reply via email to