Re: [Springframework-developer] Spring remoting with Jini?

[Steven D. <ste...@gm...>]

Just for my understanding, are you talking about Jini integration for
Spring or remoting for Spring?

Currently there is no remoting support for JMS since - like Jini -
this is an asynchronous service. Calling a remote method and receiving
a result or exception asynchronously for me lies somewhere between
undoable and very difficult.

Steven

On Thu, 10 Mar 2005 16:27:08 +1300, Ben Piper <Ben...@pe...> wrote:
> Seth said:
>=20
> >As an avid Jini fan (and past user) I can say it should be a great
> >match, and quite easy to do.  I'd be glad to help if you need it.
> >I've often thought about combining Spring and Jini, so I'm glad you
> >brought it up. :)
>=20
> It's nice to know that others have also considered this.  Perhaps I can
> get your thoughts on what I've contemplated thus far:
>=20
> The current implementations of remoting seem to follow a common model of
> intercepting method invocations at the client end and turning them into
> remote service calls.  To follow this model with Jini implies that you
> load a Jini Configuration at some initialisation point, discover the
> service, grab the service proxy, then invoke the intercepted
> MethodInvocation on it.  I'm a little shaky on the Spring stuff... but I
> guess you'd have a JiniProxyFactoryBean to do some initialisation in
> afterPropertiesSet (I imagine you'd set up a LookupCache for the service
> interface in question?).
>=20
> On the remote end, I'm even more uncertain.  I like to think of Jini in
> terms of Rio (a sub-project that makes Jini more accessible to those of
> us in the enterprise application space), as I came upon the two
> simultaneously.  So, you would have a Cybernode 'container' (which is
> itself a service) that can export services as provisioned to it by a
> Provision Monitor.  The question in my mind is where Spring comes into
> the picture.  I see no reason why one couldn't have a JiniRemoteExporter
> of sorts... such that when Spring initialises the bean, the service
> interface is exported... however in the case of Rio, it's actually when
> a service is provisioned to a Cybernode that it's exported.
>=20
> So, within a Cybernode container (or any JVM), I may want to load a
> Spring ApplicationContext, but I might not necessarily want that to
> drive the exporting of services... and that's certainly configurable
> (but you probably wouldn't want to be providing a service within the
> Cybernode container without the Cybernode service itself knowing that
> it's exported it).
>=20
> The context in which I'm looking at this is that a couple of colleagues
> are piloting a fully Spring managed architecture for a web application,
> from MVC to integration with Hibernate, transaction management and all
> that.  What we're just starting to look at now is physically (or
> logically) breaking up the web and application tiers with remoting, for
> which Jini seems an excellent middleware fit, particularly given other
> requirements that we have.
>=20
> I'd be very keen to receive any comments and ideas that you might have.
>=20
>=20
> Abel said:
>=20
> >Ben I'm currently working on JavaSpaces and Spring integration (as a
> side >project) nothing related to remote invocations though.  What I'm
> doing is >putting together something that resembles the JMS stuff in
> Spring but for >JavaSpaces.  The goal is to make the Jini related stuff
> transparent from >the user.
>=20
> So by 'JMS stuff' I take it you mean the org.springframework.jms
> package? Have you been compiling any core support classes for general
> Jini operations, e.g. service discovery/lookup, configuration
> management, etc.? It'd be great to have a common integration point with
> Spring for the core Jini stuff, and use that as a platform for
> JavaSpaces, remoting, and whatever else.  At the moment I'm trying to
> write some fairly case-specific Jini remoting stuff to prove to myself
> that I'm not barking up the wrong tree, but I'm not yet comfortable
> enough with Jini and Spring to be sure what the best way forward is.  I
> have a good application for it though, so I hope to make some progress.
> I'm also interested in JavaSpaces integration for areas outside of
> remote service invocation, although it's not something I'm focusing on
> right now.
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&opclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>