You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@xml.apache.org by Wouter Cloetens <wc...@raleigh.ibm.com> on 2000/08/10 09:43:35 UTC
RE: SOAP & JMS (was: Re: Service class access to servlet containe r)
On Thu, 10 Aug 2000 11:06:37 -0400, Glen Daniels wrote:
>You wouldn't want to tie your SOAP/JMS transport to any particular
>implementation - that's the whole point of a standard JMS API! :)
Absolutely.
>JMS Connections should be set up out-of-band, either by passing them
>manually down into the transport when you create it, or by implementing a
>"JMSProvider" interface which you can supply to the transport and let it do
>the work for you.
I implemented it as a base JMS transport class, which you can subclass to do your
MoM-specific things. You can either call a static method, to which you pass a Properties
object containing configuration info, which will an instance of the MoM-specific JMS
transport object (the class name of that class is a property), or you can pass it a JMS
ConnectionFactory which you've created yourself.
>We should probably support both explicit naming of a
>pre-existing reply queue for request-response interactions, and also dynamic
>temporary-queue generation to receive replies.
I only have support for tempdyn queues in my MQSeries implementation, but your can
override that. I also have support for publish/subscribe. A subscriber can configure a
SOAPEventListener to be invoked with a SOAPEvent (containing a Call object)
asynchronously.
>This is on my list to implement at some point as well, but IIRC someone else
>was already working on something like it?
That would be me, but I'm not the only one who said he was doing something like it. :-)
>--Glen
>
>> -----Original Message-----
>> From: Paul Fink [mailto:pfink@wamnet.com]
>> Sent: Thursday, August 10, 2000 10:25 AM
>> To: SOAP
>> Subject: SOAP & JMS (was: Re: Service class access to servlet
>> container)
>>
>>
>> I think it would be good to take one of the open source JMS
>> versions and create a SOAP/JMS implementation.
>>
>> Trouble is I haven't figured out what that means, ..., yet.
>>
>> ZOAP is suppose to be something like this but I'm not sure
>> its real. see ZOAP at www.jbosss.org.
>>
>> ----- Original Message -----
>> From: "Wouter Cloetens" <wc...@raleigh.ibm.com>
>> To: <so...@xml.apache.org>
>> Sent: Wednesday, August 09, 2000 6:53 AM
>> Subject: Re: Service class access to servlet container
>>
>>
>> > On Wed, 9 Aug 2000 17:01:07 -0500, Paul Fink wrote:
>> >
>> > >I think that the solution that will evolve will be a combination
>> > >of SOAP & EJB. My own solution is SOAP + JMS + EJB,
>> > > (well actually XML-RPC ;>})
>> >
>> > What a coincidence. I'm almost done with a first reusable
>> version of a JMS
>> (MQSeries)
>> > SOAP transport implementation. I've had an MQSeries-HTTP
>> SOAP bridge for
>> ages, but
>> > a JMS to EJB SOAP front-end (rather than a servlet) is the
>> next step. :-)
>> > Initially, I guess I'll only support stateless
>> transactions. Applications
>> that need to maintain
>> > state via remote object references will just have to use IIOP.
>> >
>> > >and I have found other reference to folks doing the same.
>> >
>> > Looks like there are a lot of great minds out there
>> thinking alike. ;-)
>> >
>> > bfn, Wouter
>> > --
>> > http://www.workspot.net/~zombie/soap/
>> > My opinions are irrelevant. They will be assimilated by my employer.
>> >
>>
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.