Ooopss typo , RPC*. ----- Original Message ----- From: tlk <tlk@nb.sympatico.ca> To: <me@enhydra.org> Sent: Wednesday, September 05, 2001 1:20 PM Subject: ME: Re: RE: Re: RMI and J2ME > I Agree, > > SOAP , RCP-XML over JMS is much more foreseeable. > > > ----- Original Message ----- > From: Keith Bigelow <keith.bigelow@lutris.com> > To: <me@enhydra.org> > Sent: Wednesday, September 05, 2001 1:19 PM > Subject: ME: RE: Re: RMI and J2ME > > > > so to paraphrase, > > > > "SOAP over JMS is more compelling than RMI" > > > > Yes? > > kb > > > > -----Original Message----- > > From: me-admin@enhydra.org [mailto:me-admin@enhydra.org]On Behalf Of > > john d. beatty > > Sent: Wednesday, September 05, 2001 9:03 AM > > To: me@enhydra.org > > Subject: ME: Re: RMI and J2ME > > > > > > From: "Keith Bigelow" <keith.bigelow@lutris.com> > > > Hey all, > > > > > > I was asked about RMI today, and whether the ME project should pursue a > > kRMI > > > solution on top of MIDp. > > > > > > There are already open source implementations out there that we could > talk > > > to about joining our project, but I'm not certain that we want to invest > > > here. > > > > > > Off the top of my head, these were my early thoughts: > > > > > > REASONS NOT TO IMPLEMENT RMI on MIDp > > > - RMI implementations will likely be large if they are useful, and MIDp > > RAM > > > is too small already > > > - RMI exists in Pjava, so for the larger devices [WinCE, Palm, etc.], > > there > > > is a solution already > > > - RMI exists in some third party KVMs already [kada, esmertec, etc.] > > > - RMI may exist in PDAp (Stefan, can you confirm/deny this without > getting > > > in trouble?) > > > - kSOAP gives us some of the benefits of RMI, but none of the Java-only > > > limitations > > > > > > REASONS TO IMPLEMENT RMI > > > - RMI is the first thing every developer howls about as 'missing' on > > > J2ME/MIDp > > > - It's easier to load a class than to replace a KVM on these devices > > > - We might be able to do the 80/20 rule and get 80% of the functionality > > for > > > 20% of the coding > > > > To assess the technical issues first, a complete RMI implementation > includes > > things like dynamic download of stub code, distributed garbage collection, > > exporting unicast remote objects/protocol listener, the client-side > > activation protocol, and RMI registry support. Ouch. Because MIDP only > > supports outbound HTTP (right now, anyways), we would have to tunnel RMI > > over HTTP. Not unheard of, but not pretty, either. Minimal RMI support > > would probably be client-side RMI; no dynamically downloaded stubs; no > > client-side activation. I'm not an RMI expert by any means, but getting > > this down to MIDP level is daunting at best. > > > > I also have questions about the usefulness of RMI on MIDP-based devices. > Use > > of distributed objects using RMI has proven most useful for server-side > > applications within an enterprise rather than a common glue across the > > Internet. For the common glue across the Internet, the web services model > > shows more promise because of the better interoperability. > > > > Another important point IMO is that asynchronous messaging shows more > > promise that synchronous RPCs for distributed applications because of high > > latencies, unreliable connections, etc. This is especially the case in the > > wireless world. Thus, I would be much more interested in a JMS > > implementation than an RMI implementation. > > > > john > > > > _______________________________________________ > > ME mailing list > > ME@enhydra.org > > http://www.enhydra.org/mailman/listinfo.cgi/me > > > > _______________________________________________ > > ME mailing list > > ME@enhydra.org > > http://www.enhydra.org/mailman/listinfo.cgi/me > > > > _______________________________________________ > ME mailing list > ME@enhydra.org > http://www.enhydra.org/mailman/listinfo.cgi/me |