Re: How is this supposed to work?

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

JP,

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.

--

Regards,
Farrukh

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

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard