Re: FW: Proposal: A Registry Browser GUI tool

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

Farrukh,

I'm not sure I agree with your first paragraph.  If UDDI had not specified
a particular binding (SOAP messages), there would be the potential for
interoperability nightmares if each registry operator were to pick a
different binding.  I think you actually say this in your second paragraph
("the spec still needs to say what is the required binding for
interoperability") but while a standard cannot prevent someone from using a
proprietary binding, it shouldn't encourage it.

   A perfect example of my point above is AM Stereo (anyone remember
   that?).  The US Federal Communications Commission attempted to resolve
   five incompatible proposals (bindings) and then gave up and decided to
   let the market decide.  In the New York area, the radio stations picked
   one standard but the automobile manufacturers picked a different one.
   No interoperability.  The market quickly decided that AM Stereo wasn't
   worth worrying about.

In any case, binding is needed at every level.  You appear to be discussing
the binding needed for an external interface and I was talking about the
binding needed between the messaging service and the transport level.
Note, however that the TPA also specifies the binding between the service
interface and the lower levels, which corresponds to th external interface
that you discussed.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Farrukh Najmi <Farrukh.Najmi@east.sun.com> on 09/14/2000 06:38:59 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   Rik Drummond <rvd2@worldnet.att.net>, Ebxml Transport
      <ebxml-transport@lists.ebxml.org>
Subject:  Re: FW: Proposal: A Registry Browser GUI tool




What I meant by binding was a binding specification that would allow a
service interface
to be
accesible from a specific technology or language in a standard way. Take
the UDDI
example. It positions SOAP as the
prescribed way to define and access the UDDI service. A better alternative
would have
been to specify
the interface in UML (as is the case in Registry Services spec) and then
(possibly
outside the spec) define a
standard binding to SOAP and allow others to implement other bindings (e.g.
LDAP etc).

Bindings provide flexibility but the spec still needs to say what is the
required binding
for interoperability
reasons. In the ideal world the interoperable binding could be ebXML TRP
Messaging. For
UDDI at
present the required binding for interoperability is some kinda SOAP.

Martin W Sachs/Watson/IBM wrote:

> Expaaaaaanding:
>
> "Bindings to specific technologies belong in the TPA."
>
> I am using the term "bindings" to refer to the means of specifying, for
> example, what communication protocol is used with the messaging service
for
> a given business relationship.
>
> Assume that the messaging service can be used with more than one
> communication protocol, communication security definition, etc.  What is
> needed is a means of specifying the name and parameters of the
> communication protocol to be used for a particular business relationship.
> This information cannot be specified in the message header because the
> message cannot flow without a communication protocol being in place.
> Therefore, the binding must be specified somewhere outside the messaging
> service.  The natural place is the TPA.  The transport section of the
tpaML
> specifies what communication protocol and communication security
parameters
> will be used for message exchanges under that TPA.
>
> What may be needed in the messaging service specification is some kind of
> abstract definition of how information is exchanged between the messaging
> service and the underlying transport level.
>
> Regards,
> Marty
>
>
*************************************************************************************

>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
>
*************************************************************************************

>
> Rik Drummond <rvd2@worldnet.att.net> on 09/14/2000 05:40:02 PM
>
> To:
> cc:   Ebxml Transport <ebxml-transport@lists.ebxml.org>
> Subject:  RE: FW: Proposal: A Registry Browser GUI tool
>
> you might want to expand on what you mean here... best regards, rik
>
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, September 14, 2000 4:28 PM
> To: Rik Drummond
> Cc: Ebxml Transport
> Subject: Re: FW: Proposal: A Registry Browser GUI tool
>
> Bindings to specific technologies belong in the TPA.
>
> Regards,
> Marty
>
>
****************************************************************************

>
> *********
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
>
****************************************************************************

>
> *********
>
> Rik Drummond <rvd2@worldnet.att.net> on 09/14/2000 04:34:05 PM
>
> To:   Ebxml Transport <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  FW: Proposal: A Registry Browser GUI tool
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: Thursday, September 14, 2000 3: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

--
Regards,
Farrukh