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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

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

Subject: Re: How is this supposed to work?


You are right that the response is sent to the URI that is looked up in the TPA
based on DUNS number.

You are also right that in track 1 we are using asynch protocol. The spec
defines both asyn and synch versions of methods on the ObjectQueryManager. This
means that the actions should specify the async version of the method (so use
getRootClassificationNodesAsynch and not getRootClassificationNodes).

There are two header fields that relate a request to its response. The
conversationId field shoudl be the same in teh response as the conversationId
set by the request. The refToMessageId in teh response should have the messageIf
of the request message. That is how request/response matching takes place AFAIK.



Yoshi Russell wrote:

> <snip>
> It seems to me that this track 1 is being implemented with an asynchronous
> protocol.  This means that the registry receives the
> GetRootClassificationNodesRequest and responds to a URI that corresponds to
> the DUNS number in the request header asynchronously instead of just sending
> a response document back to a waiting client.
> Is this right? If so, how is the client supposed to match the messages up?
> That is on the what part of the header must remain in tact in order for
> matching to occur?
> <snip>
> JP


org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
fn:Farrukh S. Najmi

[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