Pavel Thanks for your response.
I think I can cut the JMS aspect out and just use the base java calls within my API Wrapper. If I just use the get with wait, and keep looping I can then notify the listeners (i.e. the end application) with the message. Get with wait is quite light-weight? Although this doe not fit my API model application initiated receive, it doesn't break it too much to fit to the java model. I saw the wrapper as a static class so not a pooled resource - not that I'm a J2EE or application server expect. Regards Neil -----Original Message----- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 18:20 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, To me it sounds as you will have to make your "API wrapper" your own JMS provider. You will most probably have to implement ConnectionConsumer and Session interfaces from there because this is how J2EE-compliant app servers support MDBs (they supply the implementation of ServerSession and ServerSessionPool and push messages through to Sessions they get from ServerSessions). I am not sure if any of them actually will be able to get messages for MDBs via any other interface. As for the asynchronous model of getting messages, you will probably have to create a special thread on a client side to call onMessage() methods on every registered listener (J2EE compliant app server does it with ServerSession's start() method) and that thread will push all messages through the listeners. This is how, I believe, any JMS Session is implemented (yes, I remember you want to keep JMS out of the loop I just refer to it as an example for implementing your wrapper. Pure MQ API only provides synchronous MQGET to receive messages). Hope this will help, Pavel "Taylor, Neil" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] EQUEST.COM> cc: Sent by: MQSeries Subject: Re: MQ wrapper to new Java App Server World? List <[EMAIL PROTECTED] C.AT> 02/09/2004 11:23 AM Please respond to MQSeries List Thanks Pavel I am trying to keep mqseries and JMS out of the loop. My email below is not as clear as it could be - we have designed the API wrapper already, on the assumption of a receive call being made by the end-application. So we have a "receive" API call that we would expect an application to call, but Java's model is not to do this, but rather register with a listener and be notified of events. Thereby breaking the model. If anybody has experience in this area then please let me know. Regards Neil -----Original Message----- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 15:32 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, I have never tried it with MQ JMS provider, but looking in the doucmentation, it does include its own implementation of ConnectionConsumer (which is exactly the facility intended for an application server to push messages into its MessageListeners, which MDBs are). So I would recommend you to configure your appServer to use MQ as an external JMS provider (see MQ "Using Java" book for MQ part of the deal) and see if it works. Hope this will help, Pavel "Taylor, Neil" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] EQUEST.COM> cc: Sent by: MQSeries Subject: MQ wrapper to new Java App Server World? List <[EMAIL PROTECTED] C.AT> 02/09/2004 05:23 AM Please respond to MQSeries List Hi I was wondering if anyone had experience of building an MQ wrapper, that was then to be implemented in the Java/ EJB world. Where Message Driven Beans are the norm and expect to be event driven. How has this changed the model? For instance we have a receive API call that we use to abstract the MQGet functionality. However, this assumes a polling by the application calling the API. But with the MDB the expected mode is of message arrival "waking" the application and "giving" it the message directly. Hence the MQ Wrapper is bypassed. Any views? Regards Neil -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
