RE: [Springframework-developer] Fwd: application integration: intra-VM remoting

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I will look into the HttpInvokerProxyFactoryBean a bit...

thx

andre

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Steven Devijver
Sent: 12 January 2005 13:24
To: spr...@li...
Subject: Re: [Springframework-developer] Fwd: application integration:
intra-VM remoting

Andre,

The two classes I've send are the proof-of-concept. You would need to
create a proxy factory bean and a service exporter. I use
HttpInvokerProxyFactoryBean and HttpInvokerServiceExporter as
examples. I'm planning to release this as a separate project. Since
you need to deploy this jar in a special way it cannot be part of the
Spring sandbox.

Take a look here, it will be easier for you to copy the code:

http://forum.springframework.org/viewtopic.php?t=3D2907

Steven=20

On Wed, 12 Jan 2005 13:12:33 -0000, Andre Vermeulen
<ave...@su...> wrote:
> Hi Steven
>=20
> A very interesting idea...
>=20
> I was thinking about this exact thing a few weeks back. But didn't =
have a clue to go about... neither the time for r&d.
> If nothing else I might be able to help  you test.
>=20
> Send your proof-of-concept on I would be very interested.
>=20
> regards
>=20
> andre
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Steven Devijver
> Sent: 12 January 2005 12:48
> To: spr...@li...
> Subject: [Springframework-developer] Fwd: application integration:
> intra-VM remoting
>=20
> I've created a proof-of-concept implementation that allows intra-VM
> method invocations.
> I will probably release this code in a seperate jar but for now I
> would like your feedback. What's missing from is the proxy factory for
> clients and the exporter for the host.
>=20
> This interface needs to be implemented by the exporter:
>=20
> /**
>  * This interface needs to be implemented by exporter classes that
> want to participate in intra-VM method
>  * invocation in the same thread as the caller of the invoked method.
> This allows
>  * for an EJB-style integration pattern by calling objects that live
> in the same VM but
>  * are managed by a separate container. The typical use case would be
> a caller that lives in a
>  * web application (WAR) and calls a service object that lives in the
> same VM but inside another
>  * web application.
>  *
>  * @author Steven Devijver
>  * @since 12-01-2005
>  */
> public interface InvocationHandler {
>=20
>         /**
>          * The interface of the service that is called. This interface =
is shipped
>          * by the application that hosts the service to other =
applications that want
>          * to call the service as a client. The interface class =
functions a an end
>          * point marked.
>          *
>          * @return the service interface
>          */
>         public Class getServiceInterface();
>=20
>         /**
>          * This method is called by an invocation mediator to pass =
method invocations.
>          *
>          * @param invocation the method invocation
>          * @return the result of the method invocation
>          */
>         public Object handleInvocation(Object invocation);
> }
>=20
> This is the mediator that passes method invocations to
> InvocationHandler interfaces:
>=20
> /**
>  * <p>This class offers a number of static methods to register and
>  * unregister InvocationHandler instances and pass method
>  * invocations to these instance based on end point interfaces.
>  *
>  * <p>In a servlet container setup where applications each living in a
>  * separate web application (WAR) environment this class needs to be =
loaded
>  * by the class loader that is shared by the web applications. The =
best location
>  * to put the jar file would be in the lib directory of the servlet =
engine.
>  *
>  * @author Steven Devijver
>  * @since 12-01-2005
>  */
> public class IntraVMInvocationMediator {
>=20
>         private static Map invocationHandlers =3D new Hashtable();
>=20
>         private IntraVMInvocationMediator() {
>                 super();
>         }
>=20
>         /**
>          * Register a InvocationHandler instance with the mediator.
>          *
>          * @param invocationHandler the InvocationHandler instance
>          */
>         public static void register(InvocationHandler =
invocationHandler) {
>                 =
invocationHandlers.put(invocationHandler.getServiceInterface(), new
> WeakReference(invocationHandler));
>         }
>=20
>         /**
>          * Unregister a InvocationHandler instance with the mediator.
>          *
>          * @param invocationHandler the InvocationHandler instance
>          */
>         public static void unregister(InvocationHandler =
invocationHandler) {
>                 =
invocationHandlers.remove(invocationHandler.getServiceInterface());
>         }
>=20
>         /**
>          * Pass a method invocation to a InvocationHandler instance =
based on the
>          * name of the service interface end point.
>          *
>          * @param serviceInterface the service interface end point
>          * @param invocation the method invocation
>          * @return the result of the method invocation
>          */
>         public static Object invoke(Class serviceInterface, Object =
invocation) {
>                 Map tmpMap =3D new HashMap(invocationHandlers);
>=20
>                 for (Iterator iter =3D tmpMap.keySet().iterator(); =
iter.hasNext();) {
>                         Class tmpClass =3D (Class)iter.next();
>                         if =
(tmpClass.getName().equals(serviceInterface.getName())) {
>                                 WeakReference weakReference =3D =
(WeakReference)tmpMap.get(tmpClass);
>                                 InvocationHandler invocationHandler =
=3D
> (InvocationHandler)weakReference.get();
>                                 if (invocationHandler !=3D null) {
>                                         return =
invocationHandler.handleInvocation(invocation);
>                                 } else {
>                                         throw new =
RuntimeException("End point with interface [" +
> serviceInterface.getName() + "] is not available!");
>                                 }
>                         }
>                 }
>=20
>                 throw new RuntimeException("End point with interface =
[" +
> serviceInterface.getName() + "] is not available!");
>         }
> }
>=20
> Steven
>=20
> ---------- Forwarded message ----------
> From: Steven Devijver <ste...@gm...>
> Date: Tue, 11 Jan 2005 13:32:50 +0100
> Subject: application integration: intra-VM remoting
> To: spr...@li...
>=20
> Hi,
>=20
> Consider an organization that has a number of applications each using
> Spring. Each application is deployed as a separate war in the same
> servlet container.
>=20
> An application can expose specific services which allow integration
> with other applications. Messaging is one solution for integration but
> if you can use global transactions direct method calls in the same
> thread is also a suitable integration pattern.
>=20
> I don't want to re-configure the service beans belonging to one
> application plus all its dependencies in each application that wants
> to call said application. Instead I want to do a call through a client
> library EJB style. Using Spring each application could provide the
> persistent classes, interfaces of exposed services and a Spring config
> file with a client setup to access these services. The service than
> would live in one place: the servlet context of the application it
> belongs to.
>=20
> But I don't want to use the remoting strategies currently included
> with Spring: HTTP invoker, Hessian, Burlap, RMI. For a number of
> reasons this is not suitable:
>=20
> - communication overhead in creating connections and serialization
> while in the same VM.
> - calls do not happen in the same thread -> no global transactions.
>=20
> So all I can think of is to do remoting through an intra-VM mechanism.
> I haven't got a clue on how to set up such a mechanism but I know it's
> a typical use case for EJB applications (local home interfaces).
>=20
> Steven
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer