[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Trading Partner Logical Identification based on EDIFACT orX12qualifiers
Dick wrote "Mandating the use of a regrep API: ...- it should be optional
for those ebXMLers who are willing to take the risk and find it useful"
I totally agree with Dick.
Piming Kuo
Technical Specialist - Applied Technology
Worldspan
Dick Brooks
<dick@8760.com> To: David RR Webber <Gnosis_@compuserve.com>
cc: gvh@progress.com, David Burdett
08/16/2000 <david.burdett@commerceone.com>, "ebXML
11:12 AM Transport (E-mail)"
Please respond <ebXML-Transport@lists.ebxml.org>
to dick Subject: RE: Trading Partner Logical
Identification based on EDIFACT or X12qualifiers
David,
I'm afraid we'll simply have to agree to disagree. The requirement that ALL
ebXML implementers must provide a programmatic interface to their
repository
is unacceptable. I see no problem making this optional for those who see
value in it, but it shouldn't be mandatory.
My existing B2B products contain a database of trading partner information
that the system administrators are responsible for managing. Trading
Partners have no access to this database and that is the safest solution,
in
my opinion. If you want to make your products trading partner database
accessible over the Internet through API's then go for it. But don't make
me
do the same, it should be my CHOICE, not MANDATED!
Also, I never said it was too much work to provide an API (those were your
words), my position is this:
Mandating the use of a regrep API:
- introduces an unnecessary security risk
- is inefficient because it adds an unnecessary remote access to each
interchange
- it's questionable whether or not it adds any real value in terms of
interoperability
- it should be optional for those ebXMLers who are willing to take the
risk and find it useful
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
> -----Original Message-----
> From: David RR Webber [mailto:Gnosis_@compuserve.com]
> Sent: Wednesday, August 16, 2000 10:20 AM
> To: INTERNET:dick@8760.com
> Cc: gvh@progress.com; David Burdett; ebXML Transport (E-mail)
> Subject: Re: Trading Partner Logical Identification based on EDIFACT or
> X12qualifiers
>
>
> Dick you contradict yourself here! On the one hand you have machine
> requirements to interchange headers, then say its too much work to
> do the repository as well. Frankly I'm not impressed. My two
> cents worth
> is if you can handle all that MIME and SMTP stuff - you can surely do a
> simple http query/response! AND going forward we want to move to a
> clean second generation XML/http layer anyway - MIME is a current
> generation solution.
>
> PLUS - and this is a big PLUS - what the heck is this? I'm sorry but the
> whole point of ebXML is to NOT sink into the EDI mire again. EDI took
> so blasted long to set up precisely because there was no MANDATED
> machine API interrogation. Word Docs, FAX's, that's not acceptable,
> its just trying to justify consultant time tinkering with stuff
> they should
> never
> have to touch.
>
> Plug-N-Play for EDI - is that too radical?
>
> I say we make the Repository functionality mandatory, and show
> lightweight alternatives for when people are using it in-house to go
> between two servers on their own systems (that has to be the
> least case use model). A 'Repository' can then be as simple as an
> ebXML-TRP.ini file in a sub-directory that contains the interchange
> formats.
>
> DW.
>
> Message text written by INTERNET:dick@8760.com
> >
> Let's not confuse WHAT information has to be provided to make ebXML work
> with
> HOW the information is provided. I think we all agree that ebXML parties
> must
> agree on WHAT information is needed but HOW this information is obtained
> and
> stored will depend on many factors. Do we agree?
>
> >
> > If that's the case, and we're not careful to establish over-the-wire
> > interoperability between ebXML messaging service implementations,
remind
> > me again why we're bothering to do ebXML?
> >
>
> ebXML is defining an over-the-wire specification within the TR&P specs
> (headers
> and packaging). This should (hopefully) ensure interoperability. ebXML is
> also
> defining WHAT information trading partners need in order to conduct
> E-Commerce
> using ebXML. The point of this discussion is whether or not a ebXML host
> MUST
> provide a regrep API to ensure interoperability. I contend that a
> repository
> API IS NOT a requirement for interoperability because the information
> needed to
> exchange ebXML messages can be provided through several means
> (e-mail, word
> docs, fax, et al). A regrep API might make the process more efficient in
> some
> cases, but it shouldn't be a mandatory requirement.
>
> > Or are you suggesting that Amazon doesn't need to be ebXML-compliant,
> > but ebXML providers need to interoperate with whatever they have? That
> > seems way outside the scope of ebXML, and into the land of vendor
> > support for multiple eBusiness protocols/frameworks.
> >
>
> My main point is this; some parts of ebXML are absolutely mandatory to
> ensure
> interoperability between trading partners, standard headers and
packaging,
> are
> two classic examples. I DON'T believe a "repository interface (API)" is
> needed
> to ensure interoperability. There are many ways to convey the information
> about
> HOW two parties engage in ebXML compliant E-Commerce without making this
> information available via a programmatic interface. Would a standard
> programmatic interface be useful - of course - in some cases, but not
all.
> The
> Amazon example is one case where a programmatic interface to an ebXML
> repository
> is unnecessary.
>
> Dick
> <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC