Thanks. I read the referenced document. Unfortunately I'm not very familiar with the interfaces that are referenced in that document, so I'd like to as some possibly quite dumb questions:
- Would the message correlator be exposed to a user of the API, or would it be hidden (or maybe both styles of interaction would be supported)? Ultimately, I understand that the caller has to have some way of correlating a response with a request. I know that some APIs achieve this by requiring that a new instance of a consumer object be created for each outstanding request. I guess I think that is wasteful :-). - On a similar note, who generates the correlation ID, or again could either of the parties (producer/message exchange) generate it? - One of the main reasons to use an asynchronous API (for me, anyway) is scalability - in essence this means reducing the number of threads required to handle outstanding responses while maintaining a high level of throughput. This essentially means using some kind of queueing implementation and leaving the issue of thread use up to the producers/consumers. > -----Original Message----- > From: Jaime Meritt [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 31, 2003 9:44 AM > To: [EMAIL PROTECTED] > Subject: RE: Antw: Asynchronous interface > > > Inline... > > Thanks, > Jaime > > > -----Original Message----- > > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 31, 2003 9:31 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Antw: Asynchronous interface > > > > There's a difference between an asynchronous API and an > asynchronous > > transport. You should be able to make asynchronous calls over HTTP, > > too. > > > > This is true. We (Dave, James, and I) sent a proposal to the > list awhile ago describing a truly asynchronous API that was > transport independent thus enabling asynch HTTP/JMS/etc. > James has been working on asynchronous invocation within the > framework using the IME packages and implementation. Our API > built upon James' IME layer to expose a user facing API for > asynch interaction with web services. Please take a look at: > xml-axis\proposals\async_sonic\AxisAsyncClientAPI.htm for > more information. > > When we initially sent it out there was little feedback from > the group. Perhaps now is a good time to go over the proposal > and offer some suggestions/comments. > > Thanks, > Jaime > > > For a description of what I man, see the WASP documentation on > > asynchronous > > API: > > > http://www.systinet.com/doc/wasp_jserver/basic> s/webServiceInvocation.h > > tml# > > ba > > sics.webServiceInvocation.asynchronous > > > > > -----Original Message----- > > > From: Markus Frommherz [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, January 31, 2003 9:15 AM > > > To: [EMAIL PROTECTED] > > > Subject: Antw: Asynchronous interface > > > > > > > > > You might consider to check the advanced JMS (Java Message > > > Service) support in the 1.1 (cvs or nightly). Some folks > reported to > > > get it running. If you think of > > > the onMessage-method, (experimentally) provided in the jwsdp from > > > sun, this got not into a J2EE standard because of > redundancy with JMS. > > > Therefore JMS+Axis will be the future for enterprise messaging. > > > > > > HTH > > > Mark > > > > > > >>> [EMAIL PROTECTED] 31.01.2003 15.03 Uhr >>> > > > I've just read back through the archive of this mailing > list and I > > > notice that there was talk at the end of october of providing an > > > asynchronous method invocation mechanism in Axis. I would be > > > interested to hear how this is progressing. > > > > > > Thanks - Paul Andrews. > > > > > > > > > > >
