RE: Proposal: A Registry Browser GUI tool

[Krishna Sankar <ksankar@cisco.com>]

Yep. You are absolutely right.(Second time I agree with you ;-), I think
this is becoming a habit )

IMHO, technology bindings should never be part of the spec. That is how we
get the interoperability.

That is the main contention I have with UDDI - they have SOAP built into the
spec.

cheers

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Thursday, September 14, 2000 1:05 PM
To: Farrukh Najmi
Cc: David RR Webber; Nicholas Kassem; ebXML poc
Subject: Re: Proposal: A Registry Browser GUI tool



In consultation with other members and having thought about the binding
issue
I have
come to think that bindings to specific technologies do not belong in the
spec at this time. I think
that an RS implementation must provide an interoperable TRP based api.

An RS implementation is free to provide any other APIs in addition to the
required TRP api as an implementation specific detail.

Farrukh Najmi wrote:

> First a correction.
>
> It is the simple layer that sits on top of the TRP layer not the other
> way around.
>
> The RS provides a technology netral interface
> to services in UML form. Binding can be defined to various technologies
> and are planned
> to be specified in the appendix of RS spec.
>
> My own RS implementation provides a Java binding that makes it completely
> obvious and simple for
> the RS client (e.g. RS Browser GUI tool) to access the RS blissfully
> ignorant of the
> underlying communication (ebXML TRP).
>
> Demonstrating the RS functionality and its interoperable interface is
> what RegRep needs to do
> for Tokyo not the simple Java binding layer. Ofcourse by that time I will
> offer the Java binding to
> RR team for acceptance in RS sppendix as just another binding to RS.
> Others are free to submit
> LDAP, SOAP, DASL whatever bindings in the same level playing field.
>
> David RR Webber wrote:
>
> > Message text written by Nicholas Kassem
> > >
> > I beg to differ. You seem to imply that ebXML TRP has some systemic
> > performance limitations precluding its' use in B2C scenarios. I don't
> > accept this assertion.
> >
> > <<<<<<<<<<<<<<<<
> >
> > No - I'm not saying that - I'm saying there's alot of overhead
> > in there that are out of place for a simple primitive interface.
> >
> > I've realized now that the TRP layer can sit on top of the
> > primitive layer.
> >
> > That way if you want to talk to the primitives via TRP - cool,
> > that will work.  But findamentally you have to be able to issue
> > the primitive calls directly too.
> >
> > Demonstrating the primitives layer is what RegRep needs to
> > do - not the TRP layer - we know that works already!
> >
> > DW.
>
> --
> Regards,
> Farrukh

--
Regards,
Farrukh