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 |