Hi all,

I've been making services for my company as dynamic mbeans that make themselves 
accessible to clients via a HARMI stub bound to the JNDI tree.

I was thinking that, in order to make life simpler, as well as give us better control 
of method interception (as in mbean invoke() trapping), I'd like to have the clients 
just get a handle on the remote mbean server and generate a dynamic proxy for the 
interface to the service.

The only problem here is that some of my services are on only specific hosts, so if I 
happen to be talking to one of the mbean servers that doesn't have the service 
registered, it will fail.

So I guess my question is, is there a HAMBeanServer type mechanism looming about?  One 
that when you call
server.invoke(ObjName,Method,Param[],Sig[]) 
it will actually invoke on a service that has the mbean avaliable?

And better yet, a server with the service deplyed and STARTED (in the service mbean 
sense)

I thought about making my own HARMI mbean server thingie that did just that, but since 
there's no way to directly call a method on one node in the cluster, that becomes 
difficult.  
I suppose I could do it by keeping a cache of remote mbean references for every node 
in the cluster.  
And when a request comes in for service 'X', he could just cluster call looking for 
who has the service up and started, then call that guys mbean server, sort of a proxy 
service.

I was just wondering if this was already solved somewhere.  As I've seen that JBoss 
cache seems to have solved my other big problem I spent quite some time solving of 
highly transactional shared state.  
Fyi, if you didn't know, DistributedState can not really be trusted due to the way it 
transfers state.  
When you stick 1GB (many small items) of data in dstate, it has to double the size to 
serialize it in to a byte[] to send out for a state transfer when a node joins.  
During that serialization, and modifications to dstate will cause concurrent mod 
exceptions, just making the sync fail and leaving you with an unbalanced cache.  And 
in our case, we do 10->100 writes to the cache per second.  So it just doesn't work.

Ok, got a bit off track there..

So back to my question, has this issue been resolved?  Or was that solution to just 
bind each service via a HARMI stub to the JNDI tree?

We've chosen to make all our services mbeans and use CMP/Hibernate for data access.   
Session beans seem to be the norm from reading the forums, but I'm really picky about 
look-and-feel in APIs.  I don't think clients should have to 'create' their services 
to use them.  It's much more clear to tell people to lookup a service and just use it, 
rather than jump through the hoops that session beans impose.



View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3839258#3839258

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3839258


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to