colamo.org basic architecture blueprint (11-21-05) by Carsten Brunke

 

1. Intention of this draft

This document on the topic of colamo.org delivers a raw description of the state of the discussion process between the maintainers of the project. The launch of the colamo.org community states the beginning of the second step of our adventure to build a

While the part of communication between the colamo.org server and the e4l backend became quite clear by now (and will be documented better whilst development) as SWAP evolves, we haven't decided finally about the technological base of the server yet. We assume it to be a J2EE application server like Tomcat or JBoss, running Enterprise Java Beans on it. Perhaps there are other promising concepts out there you wish to advocate for? Please do so. Same for the part shown in figure 2. The concept of "cop" is thought of as an equivalent of RMI, adopted to the needs of a mobile scenario. Which means need for small memory footprint, convincing security implementation, handling of low quality connections and reduced complexity.

 

The idea of colamo.org basically shows up as a distributed software model where the application is executed on the mobile device, asking the server for data and data processing, whilst all connection handling runs in background. As HTTP is the least common denominator provided by J2ME, connection handling will be a tricky task.

 

However, some work is done. e4l has been opened to colamo.org-clients by the implementation of SWAP. SWAP has been documented - well, at least the first steps were taken. Java has been evaluated as the platform of our choice. Tender bonds have been knitted to www.j2mepolish.org (see below). The community website has been launched, including a Subversion code/revision control system and a public mailing list. The community has been announced at the Linux World Expo in Frankfurt/Main (and we were very pleased with the response). A coding session took place in Plochingen near Stuttgart where we proved the idea of letting a mobile client with J2ME on it (a SonyEricsson k700i cell phone, actually) talking via http-streaming to an e4l-Server - it worked well, which is why we're convinced that an OSS community will be able to bring the whole thing to life.

 

4. What can you do for colamo.org?

There are more than enough duties to be arranged. In the first place we have to find answers to architectural questions. We're looking forward to an according discussion process on the mailinglist. Furthermore, there are tasks like security, SWAP, COP, client design, tools, device dependencies, documentation, quality control and so on. Please let us all know in which part you're interested, so you can get involved.

 

There are two OSS communities, colamo.org is or has to be linked to. www.exchange4linux.org has already been mentioned. A second one is www.j2mepolish.org. With "J2ME Polish" there's a project out there which adresses two problems colamo.org runs into. The first one is device dependence. Polish is based on a database which contains all those small and sometimes huge differences between devices including bugs, divergent standards interpretation, feature sets, requirements of the virtual machines etc.. The second answer Polish provides is one to the wish to produce a sort of rich client for the mobiles. In other words: Polish allows to generate clients a more sexy way. This is owed to the context Polish is designed for: gaming.

 

(11-21-05) by Carsten Brunke