avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Nash <miken...@jglobalonline.com>
Subject Re: Avalon and Messaging
Date Wed, 15 May 2002 14:21:39 GMT
Stephen, Pete:

> >I have a suggestion, depending on how fine grained your services are and 
> >whether they are sync or async. For each service you define an interface. 

The services I was thinking about would be fairly coarse-grained, e.g. basically business
logic, access to database persistance, that kind of thing.

> >Lets assume that calls to this service can be done asynchronously (sp?), ie 
> >you make the call but you don't need to wait for a return value. 

Wouldn't this same approach work even in a synchronous environment? If we're talking about
invoking some kind of business logic a response is likely required - maybe a seperate message
back in the other direction...

> You then 
> >write a component/block that implements the interface. Same as normal avalon 
> >component at this stage.
> >
> >Then you write a JDK1.3 InvocationHandler. This will transalte the method call 
> >into a ObjectMessage (or whatever) and transmit it using JMS. This could 
> >easily be done using reflection.
> >
> >Then you build a proxy that uses InvocationHandler (and talks using JMS) if 
> >you wanted to reference remote object. Something like
> >
> >InvocationHandler myInvocationHandler = 
> >       new MyInvocationHandler( "myQueueName" );
> >myService = (MyService)Proxy.newProxyInstance( 
> >                                   new Class[] { MyService.class }, 
> >                                   myInvocationHandler );
> >

Yes, I see how this would work - and be transparent to the caller! Very nice. The invoke method
of the InvokationHandler interface can return an Object, though - if necessary this could
be the response, could it not? (E.g. for invokations that are synchronous, the invokation
handler would send the message, wait for the response, then return it to the caller as the
return Object. Where it's not necessary, it can just hand back null)

> And if will drill one layer deeper, we could perhaps come up with some 
> interfaces and base/abstract classes enabling pluggable async transport 
> solutions (e.g. JMS or CORBA Messaging).

Absolutely. The transport would be unknown to the caller, and in fact could be just a straight
method call when it's local. I wasn't familiar with the new Dynamic Proxy API in 1.3, thanks
for the pointer! 

Anyone see a problem with this approach? Otherwise I'll start experimenting!


Michael Nash
JGlobal Ltd.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message