RE: Proposal: A Registry Browser GUI tool

[Rik Drummond <rvd2@worldnet.att.net>]

we with rr have always assumed we would use the trp protocols to access the
rr at least as one of the options. the other option is ldap ua.... for the
prototype i think that trp would be best.... rik

-----Original Message-----
From: dick@8760.com [mailto:dick@8760.com]
Sent: Thursday, September 14, 2000 7:37 AM
To: Nicholas Kassem; David RR Webber
Cc: ebXML poc
Subject: Re: Proposal: A Registry Browser GUI tool


Responses inline:

----- Original Message -----
From: Nicholas Kassem <nick.kassem@eng.sun.com>
To: David RR Webber <Gnosis_@compuserve.com>
Cc: ebXML poc <ebxml-poc@lists.ebxml.org>
Sent: Thursday, September 14, 2000 12:45 AM
Subject: Re: Proposal: A Registry Browser GUI tool


> Please see my comments.
>
> Nick
>
> At 08:55 PM 9/13/2000 -0400, David RR Webber wrote:
> >Message text written by Farrukh Najmi
> > >
> >My thought was that the tool would use ebXML TRP Messaging for exactly
that
> >reason.
> >
> >Nicholas Kassem wrote:
> >
> > > Getting back to the original question. I think having a regrep client
> >(i.e.
> > > tool) would be very nice particularly if it used ebXML TRP. I think
this
> > > could solve another problem we have, namely that there is talk in some
> > > quarters that ebXML TRP is not suitable for B2C. I don't subscribe to
> >this
> > > notion and it would be very good if we could dispel this myth.
Thoughts ?
> > >
> > > Nick
> > ><
> >
> >OK - I view this somewhat differently.  TRP are using http / MIME based
> >interchanges.  I see that RegRep can follow that same approach - but
> >quiessentially the interaction model is different here, and therefore
> >the envelope structures and dialogues are too.
>
> Interesting - yes clearly we see this differently. How a regrep client
> accesses the regrep service should be no different than any other
> ebXML  Business Process. The regrep client is simply a specialized BP with
> specific QoS (from the underlying MS) requirements. I believe this is what
> was stated in the very early days of ebXML.
>

Nick is correct, the MS was designed to support RPC like behavior where a
party
sends an ebXML Message containing a "REQUEST" which results in an immediate
synchronous or asynchronous "RESPONSE". A scenario related to regrep would
appear as follows:

ebXML message REQUEST: I want your trading partner profile
ebXML message RESPONSE: OK; here it is

In the above scenario the ebXML header document in the REQUEST message
identifies the service (a.k.a. procedure) being invoked, in this case it
would
be a regrep service (e.g.  TPINFO) and the payload contains the "call
parameters" (e.g. DUNS Number of trading partner profile being requested).
The
RESPONSE contains an ebXML message indicating a SUCCESS status in the ebXML
header document, the payload  contains the requested information (trading
partner profile) in XML (tpaML).

Dick Brooks
http://www.8760.com/