MobileLJ Architecture
Overview
MobileLJ is a Java 2 Micro Edition MIDlet designed to run on cellphones and
PDAs. It arose from my desire to write a J2ME application. While
I know J2SE and J2EE fairly well, previously I knew nothing about J2ME. As
such, it went through several design revisions until I came across one that
worked well, within the constraints of both the Micro Edition limitations
and real-world limitations.
The MobileLJ software is a client/server application. The Java client
talks to a forwarding server that parses the request, sends it to LiveJournal
using the special LJ protocol, interprets the result, and sends it back to
the Java client. As a privacy advocate, I am a little wary of having
a centralized server like that, but it seemed to be the only reasonable solution.
Both the client and server code are Open Source, copywritten under
the GPL. The server is a single PHP script, so should run on a variety
of servers (Apache, IIS, Unix, Linux, Windows). You are not only allowed
to set up and run your own relay server, you are encouraged.
The initial architecture designs of MobileLJ called for a Java app that talks
directly to the LiveJournal servers. The prototypes were looking good,
with one exception. "400 Bad Request." It turns out that the
KVM reference implementation that comes with Sun's J2ME Wireless Toolkit
really likes to send POST data using HTTP 1.1 "chunked" encoding. It
also turns out that the latest stable builds of Apache really do not like
"chunked" encoding for POSTs. The solution was to implement HTTP/1.0
POSTs entirely using raw sockets or go with a more easily parsable client/server
format. Because of processor and memory constraints (and because I
did not feel like re-inventing the wheel) I went with the latter.
Client
The MobileLJ client is a standard J2ME application. In theory, it should
run on any platform: any cellphone, PDA, or pager that supports the J2ME
runtime. It talks a custom client/server protocol to a MobileLJ server.
The server parses the input, relays it to the official LiveJournal
server, interprets the response, then sends a response message back to the
client.
The client talks over raw sockets using a scaled down HTTP/1.0 protocol.
It sends a standard HTTP POST request, but the response is expected
to be quite simple. The first line of the response headers is scanned
for an error code. If it is "200" it continues processing. If
it is any other code, processing stops and the code (and any text string
following, up to the first newline) is displayed to the user. The rest
of the headers are skipped over. Once the body of the response is reached,
only the first line is scanned. This line is then displayed to the
device's screen. The line should be the human-readable response from
the MobileLJ server--something like "Successful post" or "LJ server reports
invalid password."
The client is really no more intelligent than that. It caches your
name+password in nonvolatile memory in your handheld device so that it does
not need to be re-entered every time you wish to post, but is a fairly simple
application. At present there are little, if no, exception checks for
out of memory. This did not pose a problem while testing on the emulator,
but in a real-world situation in a limited-memory device, this may be an
issue. A URL encoded copy of the text entered in the "entry" (and "subject,"
for that matter) text field is made in memory. This text box accepts
up to 4000 characters. This means that if you use the maximum post
size (rather difficult using a numeric keypad as your keyboard, but still
possible), the device will require at least 8K free to hold the original
and the copy. This is in addition to any other runtime stack or heap
information the app is using. Of course, this is unlikely to cause
a problem under normal usage, but is still a potential issue.
Server
The MobileLJ server is a single page of PHP. It has enough intelligence
to relay a request to LiveJournal and interpret the response. It performs
absolutely no persistent caching of data (i.e. it never saves anything to
a database or file), and keeps an incoming requet's username, password, and
post information in memory long enough to relay it. It also contains
some macro definitions at the top of the code. One take the server
offline (sending a user-defined friendly error message to any Java client
trying to access the server). Another puts the server in debug mode--it
will accept a request, pretend that it relayed it properly to LJ, then send
back a "successful" response to the MobileLJ client.
Because the page uses nothing but the most simple PHP commands and doesn't
care about anything on the local system, it can be run on any web server
supporting PHP. Feel free to place this on your own web server.
Running Your Own Server
You are welcome (and encouraged) to run your own server. To do this,
you will need three things in addition to your PHP-supporting web server:
the mobilelj.php script, the MobileLJ.jar file (this is a special ZIP file
containing all of the executable code that runs on the cellphone), and the
MobileLJ.jad file (this is a special text file that describes the MobileLJ.jar
file and includes a few server connection parameters).
mobilelj.php: Place this file somewhere on your server. The
official MobileLJ server holds this in the root directory ("http://netninja.com/mobilelj.php").
To make support easier, it is suggested you place it there.
MobileLJ.jar/MobileLJ.jad: You do not need to modify the *.jar file,
only the *.jad. Locate the three entries at the bottom: host
, postUrl, and requestPath. postUrl is the socket
URL that the request are sent to. Do not get this confused with a standard
"http://" URL. It is quite different. It consists of the word
"socket://" followed by the server name, a colon, and the port and nothing
more. Do not put a directory after this. Do not put a page
name after this. That is what the other two parameters are for. The
host parameter is for the "Host:" HTTP header, in case you are connecting
to a server that supports virtual hosts. It should be the same server
name used in postUrl. requestPath is the file portion
of the URL. It is used after the "POST" command in the HTTP request.
Basically, it is the file portion of the URL. It starts with
a forward slash, may or may not have directories (it is suggested not to
use subdirectories), followed by "mobilelj.php", the server page name. By
default, all of this is lower case. For the sake of consistency, it
is suggested to keep it all lower case. While IIS is not case-sensitive,
Apache is.
$Id: MobileLJ_Architecture.html,v 1.1 2002/04/21 21:33:28 enigma Exp $