Mobile phone/J2ME <-> JBoss - anyone with starting pointers?

[tldtld]

I've staretd a project today, where I want to have an ultra thin J2ME client application connecting to a JBoss server to pull a list of text items to display in a list. So a super simlpe array of strings.

Searching Google and jboss.org didnt give me any starting pointers if its even possible to do.

My application is running EJB 3 in JBoss 4.2.1 - and I have full control of the mobile phones in use - so almost anything goes!

Any pointer to start me down the correct path are much appreciated.

[ron_sigal]

I can tell you that at one point Tom Elrod started an attempt to make Remoting usable in a micro environment, when someone in the community raised a similar issue. Unfortunately, I think the guy that asked for the feature sort of disappeared, and the idea didn't take off. The goal was to create a slimmed down client which used a subset of the usual JVM facilities - e.g., no use of timeouts. For example, the socket transport has a MicroSocketClientInvoker which doesn't use timeouts, and the subclass SocketClientInvoker which does use timeouts.

To tell you the truth, I don't know much about J2ME, and I don't know how much more work it would take to adapt, say, the socket transport to work in a J2ME environment. However, it's easy enough to add a new transport to Remoting - you just need factories for creating client and server invokers. Also, you can start with a small core remoting jar that omits the out-of-the-box transports.

The Remoting Guide (http://labs.jboss.com/jbossremoting/docs/guide/index.html) is a good place to start, if you're not already experienced with JBoss Remoting. If you're interested in looking into it further, maybe I can help you along.

[tldtld]

Hi Ron

Thanks a lot for the heads up. I've been tinkering with the Sun WTK kit, which includes a J2ME webservice stub generator. Although it seems to not like Tomcat responses, it works as such in a PC emulator (just not on the phone itself). A registered bug with a empty tag that it doesnt like.

I would like a non-WS approach though. So let me look at the docs and I'll buzz you if I give it a go.

/Thomas

[trustin]

I think we need to provide a JME client that is dedicated to JME platform, not like the current approach to maintain the same codebase.

For example, we could define a very simple protocol that can be implemented very easily in JME and provide the support for that protocol in Remoting. Remoting server should be able to serve multiple protocols at once of course, as it is today in Remoting 2.

On the mobile device side, we could provide very simple and JME-compatible API, which is different from the mainstream client API.

Once Remoting 3 starts to use MINA, we will never be able to implement JME client with Remoting 3 codebase at all, so I think this is the way to go.