First, I scanned Dave, James, and Paul approach of extending jms in axis (nightly build). Looks impressing. Did'nt tried it, but could run already. I'll consider migrating, if it is offically accepted. IMHO no clean (open) solution yet avalaible. Secondly, you allmost exactly described the functionality that the xml-rpc guys I mentioned, delivered. Their Client uses a threadpool. If their number goes over a fixed limit, newer requests are stored. Sorry, but my english is not good enough to follow: <<if an <<asynchronous interface were supported directly by Axis, <<it would use a <<queueing mechanism and leave the issue of threading up to the ultimate <<producer/consumer themselves. Does that mean, axis stores the messages, until the client decides to consume?. As far as I understand it, that could be done with the DJP-approach.
>>> [EMAIL PROTECTED] 31.01.2003 19.17 Uhr >>> Yes. I can see how that would work. I'm not convinced that it's a satisfactory solution in my case for scalability reasons: It requires a thread for each outstanding request/response pair. I guess you could use an internal thread pool to manage that but my hope is that if an asynchronous interface were supported directly by Axis, it would use a queueing mechanism and leave the issue of threading up to the ultimate producer/consumer themselves. > -----Original Message----- > From: Markus Frommherz [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 31, 2003 11:02 AM > To: [EMAIL PROTECTED] > Subject: RE: Antw: Asynchronous interface > > > I beg your pardon. Next try: > You want a convenient way to fire soap and consume async > (consumer-producer)? If you run out of time, you might > consider doing yourself: You will need an > XmlRpcClient-class, that gets your parameters, > passes that data plus a pointer to your consumer to a > workerclass. That XmlRpcClient starts() the worker. > Workerclass (implements Runnable) actually fills the call, > fires the call. when receiving, it calls the consumer back. > With a look at apache cvs, I even managed it myself for a > simple (dom)->(dom) service. > > In short: > There is an async client implementation from apache xml-rpc > (older project for xml-rpc) you might take a look at these > these files: > package: > http://cvs.apache.org/viewcvs.cgi/xml-rpc/src/java/org/apache/xmlrpc > Interface > http://cvs.apache.org/viewcvs.cgi/xml-rpc/src/java/org/apache/ > xmlrpc/AsyncCallback.java > Client > http://cvs.apache.org/viewcvs.cgi/xml-rpc/src/java/org/apache/ xmlrpc/XmlRpcClientLite.java cheers, markus >>> [EMAIL PROTECTED] 31.01.2003 15.30 Uhr >>> There's a difference between an asynchronous API and an asynchronous transport. You should be able to make asynchronous calls over HTTP, too. For a description of what I man, see the WASP documentation on asynchronous API: http://www.systinet.com/doc/wasp_jserver/basics/webServiceInvocation.htm l#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. > > >
