Re: The use of ebXML Message Services for ebXML Registry

[Tim McGrath <tmcgrath@tedis.com.au>]

it appears that the situation was not clarified.  my guess is that we wanted to say the TRP messaging was
"mandatory" but not "exclusive".  that is, you can have many messaging mechanisms but you must have at least
the TRP one.  this avoids the bootstrap problem david was referring to.  the down side to this is that you
cannot implement a Registry without TRP messaging - the Registry is not independent.  May personal opinion is
that this is a small price to pay to get interoperability. after all, this initiative is ebXML -so why not
ask that TRP messaging be used?

let me suggest that, as the TA spec now reads:
"The ebXML Messaging Service MAY serve as the transport mechanism for all communication into and out of the
Registry. "

the RegRep specs needs to be more specific by stating something like.
"The ebXML Messaging Service MAY serve as the transport mechanism for all communication into and out of the
Registry.  To ensure interoperability, ebXML Messaging Services SHALL be be provided as the transport
mechanism for communication into and out of the Registry"

Farrukh Najmi - JavaSoft East wrote:

> Duanne,
>
> I thought the reolution was to fix that ebXML TRP was not the only way for client/registry
> communication. Unless something has changed since Vancouver, ebXML TRP is still *required*
> by the ebXML Registry specifications.
>
> Note that teh change in TRP to use SOAP has no impact on registry. It used TRP messaging before and still
> continues to do so. This stability is why we speced it so.
>
> --
>
> Regards,
> Farrukh
>
>
> "duane" <duane@xmlglobal.com> wrote:
> >Date: Fri, 16 Feb 2001 11:30:32 -0800
> >Yesd - this was resolved.  It is not required to use ebXML trp for
> >Registry communications
> >
> >Duane
> >
> >> "Munter, Joel D" wrote:
> >>
> >> Was this question/issue ever resolved?
> >> Joel
> >>
> >> -----Original Message-----
> >> From: Tim McGrath [mailto:tmcgrath@tedis.com.au]
> >> Sent: Thursday, January 25, 2001 11:14 PM
> >> To: Bob Sutor; Bill Smith; Ray Walker; knaujok@home.com; 'ebXML
> >> Coordination'
> >> Subject: The use of ebXML Message Services for ebXML Registry
> >>
> >> During the recent Quality Review of the Registry Services
> >> specification, an issue arose which we would like to bring to the
> >> attention of the Executive (possibly for tabling to the Steering
> >> Committee).
> >>
> >> We would like clarification on the position of ebXML with respect to
> >> the exclusive use of TRP Message Services for all Registry Services
> >> communications.
> >>
> >> This has been stated in both the TA and the Registry Services
> >> specifications:
> >>
> >>      Technical Architecture v1.0 (lines 874-875) states:
> >>      "The ebXML Messaging Service serves as the transport
> >>      mechanism for all communications into and out of the
> >>      Registry."
> >>
> >>      Registry Services v0.83 (lines 243-244) states:
> >>      "All interactions between the clients of the ebXML Registry
> >>      and the ebXML Registry will be conducted using ebXML
> >>      Messaging Service."
> >>
> >> This requirement does not appear in the ebXML Requirements document.
> >> The QR team would like to know if the intention of ebXML is for
> >> "exclusive" or just "mandatory" support for ebXML Message Services?
> >> .
> >>
> >>
> >> --
> >> regards
> >> tim mcgrath
> >> TEDIS   fremantle  western australia 6160
> >> phone: +618 93352228  fax: +618 93352142
> >>
> >
> >------------------------------------------------------------------
> >To unsubscribe from this elist send a message with the single word
> >"unsubscribe" in the body to: ebxml-coord-request@lists.ebxml.org

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

begin:vcard 
n:McGrath;Tim
tel;pager:+61(0)299633829
tel;cell:+61 (0)438352228
tel;fax:+61(0)893352142
tel;work:+61(0)893352228
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:tmcgrath@tedis.com.au 
x-mozilla-cpt:;-23520
fn:tim mcgrath
end:vcard