I am building a server sided html rendering browser that renders html and sends jpegs to the mobile client. I need to figure out how to build a server that grabs jpegs and streams them in a session to a client that i am going to write in j2me
It isn't completely clear what you mean by "live" but I'm guessing that you are talking about making requests to a server side process that renders URLs passed in and returns an image. One of the easiest ways I know of doing this is with Java and SWT. You can use the SWT browser widget and capture the canvas then convert that to whatever image type you want. The browser widget uses firefox to render pages so they should look pretty good.
I would write a servlet that serves one jpeg at a time, and a midlet that requests the next jpeg every so often.
Well, there are better solutions than plain JPEGs. I've implemented systems like this, and you would do better to use a video codec such as MPEG-2, MPEG-4 ASP, H.264, etc than JPEG, and send updates as p-frames (i.e. deltas from the previous image), and if there's "too big" a change (or missed update, or new client added to an existing stream), send an i-frame.
Even without using a video codec, sending differences will often be preferable. Use some other mechanism to encode diffs.
In terms of how to get the buffer to send, you can use a number of framebuffers to render to, and set up the framebuffer code to start a timer when a change is made, and while changes are occurring send periodic changes, when enough time has gone by since the last change (not sent yet) send an update (probably shorter time than the first value), and also probably include some sort of strobe that forces an update that can be invoked on certain occurrences (if you can, for example, get a page-load-completion indication from the browser, which you can with a little work in Firefox by changing the chrome, etc).
[added]
For examples of other solutions, look at remote-desktop protocols and programs like VNC, RDP (Windows Remote Desktop), etc - that's effectively what they're doing, again with fancier compression and damage-region tracking.
For framebuffers, you can use standard linux/etc framebuffer code (probably simplest), or even something like XVFB (which gives you access to more info about what and why things are changing than a raw framebuffer).