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.