OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Trading Partner Logical Identification based on EDIFACT or X12qualifiers


I agree that there is  a bootstrapping question with respect to registry
queries.

Note that the TPA you refer to is a TPA between the party who is making the
query and the registry.  This TPA governs registry accesses.  So, at the
time the party is making a query about something in the registry, the user
already has a TPA with the registry and knows how to set the TPAInfo
fields.  The bootstrapping issue is, of course, that if the party which is
trying to initiate a relationship with the registry has to query the
registry to get a TPA which governs registry queries, we indeed have bad
circularity.

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
*************************************************************************************



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 08/17/2000 10:42:54 AM

To:   "'marcb@webmethods.com'" <marcb@webmethods.com>,
      "'ebXML-Transport@lists.ebxml.org'" <ebXML-Transport@lists.ebxml.org>
cc:
Subject:  RE: Trading Partner Logical Identification based on EDIFACT or X1
      2qualifiers





-----Original Message-----
>From: Marc Breissinger [mailto:marcb@webmethods.com]
>

>I have two basic comments.

>The first is [... ]
> 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.

I think there is something special about the registry queries that
needs to be kept in mind, which is that these are "bootstrapping"
the subsequent BP messaging. So, since ebxml messages have to have
headers, and they have to contain a TPAInfo, we need to know the
TPAInfo values before we make the request to obtain them...
So treating the request as a standard ebXML message does border
precariously on a bad circularity, unless the TPAInfo is made
optional for these headers of these messages. Or so it seems to me.
There are probably other ways to make certain that the ebXML
message specs allow for the discovery messages to avoid these
technicalities. I also notice that the To value field might
need some special comment.

Aside from this "gotcha" I agree with Nick and others who want
to avoid specificing some RPC call just for the "setup" messages.

>all that need be pre-negotiated is specific physical end point to which
the
>initiator sends the first message.

And all the stuff to fill out the header to conform to the ebXML specs...





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC