> On May 23, 2006, at 6:27 PM, Stefan Tilkov wrote:
>> 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 ...
>
> Perhaps, but the REST API hasn't been standardized, therefore other
> runtime products (XML gateways, SOA management systems, enterprise
> systems management systems, ESBs, platforms, etc) don't know how to
> use it unless the vendors negotiate directly with Systinet to learn
> the semantics of the API.
In any useful UDDI deployment, I'll have my own tModels with their
own semantics. How is this different?
> Meanwhile, vendors like AmberPoint, Actional, Sonic ESB,
> Reactivity, CA, HP, SOA Software, etc, can all implement generic
> registry integration functionality based on the UDDI protocol that
> seamlessly interoperates with Systinet 2, Infravio X-Registry,
> Software AG CentraSite, Sun Registry, Flashline, etc, etc.
>
Anne: *Can* they or *do* they implement this kind of integration? How
is the "generic registry integration" more useful than a generic HTTP
resource integration?
This is not intended as a rhetorical question; I'm really curious to
learn about real-world scenarios where the UDDI standard has added
more value than a plain HTTP GET would have.
Thanks,
Stefan
> That's the value of the standard UDDI protocols.
> Anne
>
> On 5/23/06, Stefan Tilkov <[EMAIL PROTECTED] > wrote: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.
> >
> >
>
>
>
>
>
>
> ------------------------ 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.
>
>
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.
