RE: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

[Marc Breissinger <marcb@webmethods.com>]

I have two basic comments.

The first is that I believe the vast majority of this discussion thread does
not belong in the TR&P list -- it should be in the RegRep list.

However, since this thread is here, I will add my $0.02.  That leads to my
second comment: I disagree with Dick's suggestion as to how the interface
should be specified.  The interface for querying of the registry should be
specified as any other ebXML process is specified: namely within the
constructs provided by the newly combined BP/CC groups (i.e., a collection
of request-response messages within a 'discovery' or 'negotiation' business
process).  That fact that it is a 'service level' process is immaterial.
The messages (i.e., message payloads) would likely have a very strong
relationship to the tpaML specification from the tpa group.  The messages
would be transported between partners via ebXML Messaging Services.  The
ebXML Messaging Service provides the wire level protocol, defines the
transport bindings, provides for authentication upon which granular levels
of security can be implemented and permits the use of encryption and digital
signatures on the "[in][out]" parameters (which are really just messages).

We don't need to fall back on some other IDL/wire protocol unless we don't
believe in what we are doing here.  If you want the ebXML RegRep interface
to be standard, *require in the BP spec* that it be carried via some
combination of supported ebXML protocols and security mechanisms.  That way,
all that need be pre-negotiated is specific physical end point to which the
initiator sends the first message.

Oh yeah - point 3: I agree with the optional part.

marc

==========================================================================
Marc Breissinger                                   voice (W): 703-460-2504
Director, Product Strategy - webMethods, Inc.      voice (C): 703-989-7689
Email:  marcb@webmethods.com                               We're hiring!!!
Email2: breissim@earthlink.net              URL: http://www.webmethods.com
==========================================================================

> -----Original Message-----
> From: Dick Brooks [mailto:dick@8760.com]
> Sent: Wednesday, August 16, 2000 6:58 PM
> To: mwsachs@us.ibm.com
> Cc: David RR Webber; ebXML Transport (E-mail); David Burdett
> Subject: RE: Trading Partner Logical Identification based on EDIFACT or
> X1 2qualifiers
>
>
> Marty,
>
> you wrote:
> > I think we both believe that a repository interface can be
> useful but its
> > use should not be mandatory.
>
> Completely agree.
>
> > However if ebXML were to define a programmatic API to the repository and
> > make it a mandatory part of the ebXML-defined repository, that would
> > benefit software providers by assuring that the same software
> > could be used
> > with all repository implementations.
>
> To build a regrep interface that meets the above assertion that "the same
> software could be used with all repository implementations.", the RegRep
> team should consider doing the following:
> - define the list of regrep functions/methods using an Interface
> Definition
> Language (such as that defined with CORBA)
> - describe each function/method [in]/[out] parameter in detail
> - define a complete set of error messages
> - describe the wire-protocol used for function/method invocation
> and return
> results (or refer to an existing standard)
>   - define the various transport level bindings for HTTP, FTP, SMTP
> - provide a granular level of security so that access to functions/methods
> can be controlled
> - permit the use of encryption and digital signatures on [in]/[out]
> parameters
>
> If the above items were presented as part of a regrep interface
> then I would
> agree with the earlier assertion.
>
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@8760.com
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
>
> InsideAgent - Empowering e-commerce solutions
>