Joey 1.0 released: J2EE application server for mobile devices


News: Joey 1.0 released: J2EE application server for mobile devices

  1. JoeySoft has released Joey 1.0, a mobile J2EE application server that runs in disconnected mode on J2ME and J2SE devices (from PDAs to laptops). Joey runs your servlets and JSPs in connected and disconnected modes.

    Joey is a framework for building, distributing, hosting, and updating web applications on mobile devices such as PDAs, laptops, mobile phones, TV set-tops, and any other web appliances.

    With Joey, you can:

    - Build enterprise applications once and deploy them across all platforms -- with one application, enable mobile phones, PDAs, barcode scanners, GPS receivers, TV set-top boxes, toasters and more!
    - Run all web-based applications in both connected and disconnected modes
    - Take your enterprise portal with you on your personal device
    - Simplify application development with your existing J2EE infrastructure

    Visit Joey 1.0 at JoeySoft

    Threaded Messages (19)

  2. Palm OS[ Go to top ]

    I'm unclear about your support for PalmOS devices... I see the download eval is for PocketPC PDAs?
  3. PalmOS Support[ Go to top ]

    We are working on a version of Joey that will work on MIDP (the Mobile Information Device Profile) as well as one that works on the PDA Profile.

    The MIDP version runs on PalmOS devices including the ones running PalmOS 3.5 and up. The PDAP version should work on all PalmOS devices running PalmOS 5.0 and up.

    Please email us at info at joeysoft dot com if you would like to participate in the beta program for either of these versions.

  4. PalmOS Support[ Go to top ]

    I would like to bring this discussion to a realistic level ...

    EJBs/J2EE would never work on a Palm nor on a cell phone for some simple reasons.

     a) MIDP v1.0 does not provide any networking support
        except HTTP based networking, which makes you at least
        able to access Web Services through SOAP/XML-RPC.

     b) A Palm is a constraint device if comes to its memory
        size, its CPU speed and the way Palm OS currently
        executes applications.

        for example parsing/validating XML files on a Palm
        makes no sense because it will take forever. On a Palm
        you are only able to persist application state using a
        MIDP record store. i could bet the HypersonicSQL
        database does not run on a Palm.

        with the appereance of MIDP 2.0 crucial networking and
        security classes were introduced. but that does not fix
        the problem that a Palm was never meant to run a server.

     c) The PDA Profile is in the flux since a while and i
        don't expect a RI to be released within the next couple
        of month. Maybe the PDA profile could leverage the
        infrastructure of the new Palm Tungston (Strong ARM
        compliant CPU) but as I said the PDA Profile is still
        unavailable. Additionally Palm itself did not make any
        efforts to release a MIDP version of the MIDP 2.0 RI,
        that means i am blaming Palm for beeing very passive in
        the field of Java support.

     d) current cell phones are running at a computing speed of
        50 - 100 MHz and are shipping with a memory size of
        about 100 KByte. That means you would never ever be
        able to parse for example the tiniest XML file. that is
        the reason why the JXTA project communicates over
        binary encoded XML messages. so running an EJB/J2EE
        server on a cell phone would only be able on a Symbian
        OS enabled device (aka a Smart Phone) like the Nokia
        devices or the Sony Ericsson P800/P802.

    having pointed out the above stuff, there is only one way of running EJB/J2EE application logic on a Palm or a Smart Phone:

    you have to convert any EJB/J2EE application component during the deployment process to a form of some kinda lightweight components that might run on a Palm/Smart Phone. that means the EJB application developer still develops standard J2EE applications but they are getting transformed into a proprietary form before they are getting installed onto a mobile device.


    daniel s. haischt
    founder of the iChilli(TM) mobile J2EE platform
  5. PalmOS Support[ Go to top ]

    I agree that getting an EJB server on a Palm or a cell phone would be a challenge, but not impossible. Getting an EJB server on a Zauras or iPaq would be simple, and is on the JBoss todo list. I have a few 200 Mhz PCs around with 32 MB and JBoss boots fine on them. You run into trouble when you try to run a stock application, but with tuning the machine has plenty of power for a single user. The next generation handleds are 400 Mhz 256 MB machines, which is way more power then a single user needs.

    I know some people that are working on porting the JBoss core to very small devices. They really aren't interested in EJB, but if you dig into the internals of JBoss you would see you actually need very little to have an EJB. It is something like 10-20 classes in memory. Where you get killed in small devices is caching, and JBoss does a lot of caching by default.
  6. PalmOS/MIDP Support[ Go to top ]

    I would call a _real_ EJB server on a MIDP device (i.e. a Palm) more than a challenge. For example there are no real RDBMS systems out there. AFAIK Pointbase and DB2 Everyplace are only supporting a small subset of SQL92.

    that means you have to adjust your persistence layer to handle those reduced RDBM systems.

    if you read the iChilli(TM) site, you definitly figured out that i am currently porting the OpenEJB system to PersonalJava.

    as for the Sharp Zaurus i already got OpenEJB running on that device because the Blackdown project is providing a JDK 1.3.1 for Strong ARM CPUs. Although i couldn't run Jboss because that thing eats all your remaining RAM (even if you are using OpenZaurus that is configured to use the whole 64MByte of available memory). So i would say Jboss is a bad example because it is currently a real J2EE _server_ system.

    OpenEJB was designed to be embeddable. I did some tests with OpenEJB and Jboss on a Sharp Zaurus and OpenEJB outperformed Jboss at every single test.

    And btw one other important issue - What will you do with an EJB container that is operating on a data replica in disconnected mode and produces inconsistent data? So it is not just the EJB container, you also need a replication/synchronization mechanism that allowes you to resolve inconsistent data with very little efforts.
  7. PalmOS/MIDP Support[ Go to top ]

    You forgot about HSQL. If you can't get Jboss to run out of the box in 32M you are doing something wrong. I got it to work in 8M in under an hour of tuning.

    Anyway I agree that the real trick is synchronizing the local store with the main store.
  8. PalmOS/MIDP Support[ Go to top ]

    Does HypersonicSQL run on a Palm (or a MIDP device)? I just read that for example the JDBC driver of Oracle 9i Lite just connects to the native ODBC implementation to talk to the DB. And I am not sure whether you can use that JDBC driver on Palm/MIDP too.

    Ok, I will try Jboss again ...

    btw - the synchrinization issues with mobile devices are completly different to those of distributed databases. I would say distributed databases are mainly maintained by experienced DBAs which are familiar with synchronization issues. If a PDA user synchronizes his device (containing an EJB container) he almost knows nothing about distributed applications, replication, partitioning and synchronization. So you really have to provide a convinient mechanism that reintegrates the mobile EJB container back into the J2EE server system.
  9. PalmOS/MIDP Support[ Go to top ]

    For the MIDP version, we plan to support the web container first. The footprint of this container will be under 200KB. We support connectivity to a pure-Java database such as Pointbase, which has a version that works on top of MIDP.

  10. PalmOS/MIDP Support[ Go to top ]


    I am not sure why you need a web container on a MIDP device ...

    Sure there are already open source servlet containers for jdk1.1.8 (i.e. PersonalJava/PersonalProfile) having a footprint of 200 KByte or less, but introducing each container of the J2EE spec (EJB, WEB, Applet) on a MIDP device might not be desirable.

    I for instance would distinguish a current Java application into three layers ...

     1) The Presentation Layer
     2) The Application Logic Layer
     3) The Persistence Layer

    Having mentioned the above three layers i would classify both, the web container and the EJB container to be the Application Layer. Only the HTML GUI resulting from a JSP page or a Servlet could be classified as the Presentation Layer.

    So if you are providing a web container for MIDP i see no need for an additional EJB container.

    Although why don't you leverage the LCD UI for MIDP? I would say programming with LCD UI is still a bit more convenient than providing a WAP/HTML based GUI that was produced using a web container. At least the LCD UI isn't based on asynchronous HTTP request, which allowes you to respond to user gestures in a more convenient way.

    btw - a already knew that IBM, PointBase, Oracle, CodeBase and Sybase are providing databases for MIDP.
  11. Repacked Tomcat?[ Go to top ]

    I find it hard to believe you have written a EJB server and a Web server yourself, so let's cut to the chase. Which web server and ejb servers did you embed? Based on the configuration files alone it looks like you embedded Tomcat 4.1, but given that you have no javax.ejb classes in the entire package I find it hard to believe you support EJB at all.

    So what do you offer besides a version of Tomcat that runs on a hand held? I know that Jetty does today for free, and I have heard that Tomcat runs on J2ME, but I'm not certain on that one.

    Good luck trying to compete with repackaged free software.

  12. RE: Repacked Tomcat?[ Go to top ]

    I think you are mistaken. Joey is about a J2EE server.
    This does NOT imply EJB. J2EE != EJB.

  13. from the website...[ Go to top ]

    "The Joey micro-application server can host any J2EE application, its constituent components such as JSPs, servlets and EJBs, and the data needed to run the applications efficiently"
  14. from the website...[ Go to top ]

    Download the code and run the following

      jar -tf Joey.jar

    There is only one jar in the distro, and it contains no javax.ejb classes, therefore no EJB. Also the config files are simply tomcat config files.

    And Noel J2EE means you support EJB and a ton of other stuff. J2EE >> EJB

    Where's the beef?
  15. from the website...[ Go to top ]

    I haven't had a chance to dig in yet - other than looking at the contents of the jar file... but the 'beef' wrt EJB may be in the synchronization with the app server. On paper (marketing brochure? :)) this does look interesting.
  16. EJB Support[ Go to top ]

    Joey 1.0 and 1.1 do not support EJBs. EJB support is on our roadmap and we will announce details as we go forward. Please contact us at info at joeysoft dot com if you are interested in learning more details in relation with specific projects.

  17. The Tomcat license is pretty liberal, but it doesn't allow hiding the fact that you're using it (or a derivative) The files are renamed, and there's no Apache-license-required acknowledgement in sight. Plus, the file server/joeySalesDBServer/utils.jar contains files named gnu/getopt/*, which strongly suggests GNU Getopt is being used without the LGPL requirements being met. Cute.
  18. The files in server/util.jar come from and are used to build one of the server side sample applications. There is no LGPL breach intended, nor is one occuring here. Please refrain from unnecessary innuendo.

  19. What about the apache license? Are you claiming that this is not repackaged Tomcat? If it is based on Tomcat, where is your "clear attribution to The Apache Software Foundation" and the copy of the Apache License in the distribution?
  20. Tomcat has a license[ Go to top ]

    Gnu getopt is LGPL'ed, and the rest of the Ostermiller code
    is GPL'ed. Tomcat itself also has a license, one that requires
    credit be given to the authors. Does "Joey" use Tomcat? If so, it violates the Apache license.