Re: [Springframework-developer] JMS remoting provider available

[<jue...@we...>]

James,
=20
That's cool stuff! In particular as it reuses the existing =
RemoteInvocation support so nicely. However, I still vote to put it into =
the sandbox for the 1.1.x timeframe. Mainly because there is no time to =
polish it, and it's worth to be publically introduced in a 1.x release.
=20
Also, for the server side, we don't ship facilities to host the =
MessageListener (JmsServiceExporter) yet. I see that this is in the =
works :-) but we're still lacking recommendations on how to deploy JMS =
remoting end-to-end. One more reason to keep it in the sandbox for the =
time being.
=20
Finally, I'd prefer jms.remoting as package rather than remoting.jms - =
for a comparison, our transaction manager implementations reside in jdbc =
respectively orm.hibernate etc too, rather than in the transaction =
package. EJB remoting resides in the ejb package too, despite reusing =
facilities from the remoting package.
=20
So if you don't object to the sandbox and the changed package name, I'll =
move it over to the sandbox into the jms.remoting directory... We need =
to clarify that before the 1.1.2 release, which is scheduled to happen =
this Sunday.
=20
Cheers,
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von jas...@ma...
Gesendet: Mo 18.10.2004 12:23
An: spr...@li...
Betreff: [Springframework-developer] JMS remoting provider available



I've hacked together a JMS provider of the remoting layer in Spring,
which works like the HTTP, JAX-RPC & Caucho implementations but which
uses JMS for the underlying networking code.

By using JMS we can now load balance requests for a service across
multiple service endpoints; so we can easily implement a cluster of
servers complete with load balancing and auto fail-over. Currently this
assumes a state-less service model. We may wish to implement something
a little more clever for stateful services (and how to fail-over in a
cluster of stateful services), but this is a first cut which should be
quite useful for clusters of stateless services - we could layer on top
some kind of stateful mechanism. Some JMS providers have features like
'exclusive queues' or 'message groups' which can be used to provide
stateful-like routing of messages similar to those used in EJB
containers for stateful session beans.


The code is pretty straightforward; just 3 classes, so I took the
cheeky approach of checking it straight into the main code branch
rather than leaving it spend time in the sandbox first; we can easily
move it into the sandbox if need be.

Where possible the makes use of the existing JmsTemplate code. To
simplify the implementation code I used the QueueRequestor, but we
could tidy that up later and use explicit send() / receive() instead to
be able to support configurable timeouts and timeToLive values on a
remote request etc.

Any feedback or thoughts are most welcome

James
-------
http://radio.weblogs.com/0112098/



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give =
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer