Thanks for the reply. To be precise, the components that are going to potentially be remote are a script engine and a persistence layer (for now). It is mostly for the persistence layer at this point because the script engine is fairly lightweight. The objective would be to have the client send a graph of business objects to the persistence mechanism that would reside on another machine. Right now that 'send' happens in the same. I need it to be synchronous, otherwise I would probably just use JMS. I just wanted the client to be unaware of what or where the operation was taking place. As for the transfer size, that can vary depending on the object graph, but it isn't large (maybe, maybe a hundred rows in a DB equivalent).
I can certainly write my own proxies for this to do SOAP or RMI but I wanted to make sure that there wasn't something there already. I'm not so much concerned with the client, but didn't know what was available for the server. I'll definitely look into the altRMI stuff. Sounds pretty interesting. Thanks for the help, Robert -----Original Message----- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 23, 2002 10:39 PM To: Avalon Developers List Subject: Re: remoting components On Sat, 23 Feb 2002 07:13, Robert wrote: > I'm fairly new to the list, but have been watching with interest (I like > the ServiceManager stuff), and I'm slowly moving our product to use > Avalon's stuff as much as possible. kool. > Anyway, I've been digging around a bit and still can't quite find what > I'm looking for. What I want to be able to do is 'run' my components > remotely and then look them up from some client. By this I mean I would > like to have a central location for them, such as a JNDI tree or > something similar and have my clients, mostly installed Swing apps on an > intranet or webapps, lookup Components from this central repository. What type of access do you need? Is it synchronous, async. It is to transfer large quantities of data or is small bits. Mainly I would suggest you use existing technologies (JMS, RMI, AltRMI, Sockets, SOAP, CORBA whatever) to do the remoting while you write the server side component using AValon iitnerfaces and infrastructure. However it is difficult to recomend anything without knowing more about your use case ;) > Is this something that Phoenix should be able to do? I'm a tad leary of > that just because my boss doesn't want a 'full' server (I know it's a > microkernel, but have to convince others of such). Phoenix could do it if you needed it but ... > Should I build my own remote component implementation that will do the > communicating via RMI or SOAP or whatever? is probably the best way depending on what you want to do exactly. I believe there has already been some work so that various Phoenix blocks are exposed via AltRMI (RMI-like infrastructure), SOAP and JMX. However you could easily write your own layer that exp[orted objects via whichever technology is most desirable. -- Cheers, Pete Frank Zappa observed: "It's not getting any smarter out there.You have to come to terms with stupidity, and make it work for you." -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
