> -----Original Message----- > From: Nader Aeinehchi [mailto:[EMAIL PROTECTED] > Sent: Monday, April 26, 2004 5:09 PM > To: Avalon Developers List > Subject: Re: Question: Inter JVM communication? > > Hello > > Now that I know Merlin does not provide such a functionality, allow me to > ask some questions and make some comments: > > =================================================================== > > (a) component instance identity management > > 1. Although many systems, like EJB containers and FIPA agent systems, > make > "component instance identity management", I am not quite sure that it is a > requirement.
> 2. Another question is whether all types of components in one JVM should > be > accessible by another JVM? Probably not? There will be service facades that will need to be exposed. Some components that are part of a subsystem exposing a distributed façade may not and at times for security should not expose access. > In Service Oriented Architecture (like Jini and WebServices), only > interesting components are turned into "services". Thus, the challenge > becomes to expose and locate services. > Here, I believe Jini's Registrar or Web Services' UDDI could benefited. > I concur. Actually we can use a UDDI like mechanism backed by Eve when she's ready. That way it's replicated and the directory can be accessed outside of Java. > =================================================================== > > > (b) a remoting facility > Right. > > 3. As soon as remote Services come into picture, reliability of the remote > container becomes important to consider. In most cases, remote > communication goes through network although multiple containers may run in > the same physical machine. In any case, the over-simplification of the > remote system that e.g. EJB and Corba do, should be seriously re- > considered. > Jini builds upon the concept of "leasing". The service provider is > required > to re-register itself within the Registrar after the lease period, > otherwise > it would be removed from the registrar and thus not available for service > consumers. Having found the service provider, the consumer leases for the > service for a given period. That's a very interesting mechanism. Does that do away with things like stale handles now that we know a handle is useless after the lease period is up? I'm working with Alan Cabrera (from Geronimo) on Snickers and we're developing an ASN.1 runtime for BER at the moment and a build time stub compiler. We intend to use a PER or BER provider within Geronimo's protocol stack. We can use the same technology within such a facility. Another thing is how do we make this generic enough so other containers can use it as well. It would be nice of the same code worked for Geronimo as well as for Merlin, Fortress and Apache external containers. This would give it more value but if we can't get components to interoperate its ludicrous to think we can get a component clustering solution to work out of the box for separate containers. There might be some level of code sharing and if we achieve that then I'm happy. Just thinking out loud here. > =================================================================== > 4. Remote event/message system should be developed. > > Jini provides some interesting "distributed events" mechanism that "tries" > to deliver an event to a remote listener within the lease period. During > this period, if the listener is not available, the event is sent to an > Event > Mailbox such that the listener can retrieve the event in a later time. > All in all, Jini's distributed event mechanism looks interesting and > requires further analysis. This sounds very interesting indeed - so much so it could distract me away from Eve. I really need to sit down and actually try to use Jini. > =================================================================== > 5. Another consideration is event system versus message system. On should sit on top of the other no? > =================================================================== > 6. > > a. If I may make a recommendation, Jini's Registrar, Lookup, Discovery and > Lease mechanism should adopted for the following purpose: > > > 1. How does Component A in JVM1 find ServiceB in JVM2? Ok if you say so. It does sound like a sensible and robust service location mechanism that is proven. > b. Currently, I am analyzing several event/message systems and hope to > come > back with some results. Excellent. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
