Skip to main content

(xmlrpc/soap/rest/anything?) web services with J2ME?

5 replies [Last post]
Anonymous

Hello,

I'm looking into exposing various aspects of a service API on a J2ME client.

I am frustrated at the lack of options (thus far) and would like to know
what your experiences are. I have a already existing Spring / EJB 3 API on
the server side which in turn has entities with many-to-one Collections and
so forth.

I cant modify the API but I can add to it, exposing it as an endpoint using
XFire, for example.

The first natural candidate would be SOAP, but I didn't find much in the way
of actual JSR 172 support. So then I started looking into kSOAP, which would
be fine if I could find more documentation on it and could somehow generate
stubs (there's far too many things in the API to make it worth "dynamically"
invoking. Even when I tried invoking it dynamically I couldnt seem to get
the kSOAP implementatino to play nicely with my new-ish SOAP 1.2 stack.

Then, it occurred to me I might have better luck with XMLRPC and just accept
passing xmlrpc structs back and forth as the API -- which would be ok if
there was somehow a way to do it reliably and consistantly.

I understand I might have better luck if i force open the original APIs and
somehow seperate the entities from their service layers, making them
implement kvmSerializable and impleenting all those ridiculous methods on
each entity (not desirable).

I am now looking at really just giving up the ghost and rewriting the
endpoint using RESTlets (which is a completely new API for me, but at least
it would be guaranteed to work with J2ME and the basic http connector, given
that i completely rework the way the APIs exposed.

What is the opinion of the list on service exposure like this? Any anecdotal
evidence for or against any of these ideas/solutions? Unfortunately, except
for JSR 172 , the trail on a lot of these technologies seems to gone cold
around 2003, so Im also a bit put off by the lack of continued support.

Any insight is appreciated, thanks.

--
Joshua Long
Sun Certified Java Programmer
http://www.joshlong.com/

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
akhilarora
Offline
Joined: 2004-12-17
Points: 0

If you choose to go the RESTful route, here are some client-side libraries to make the job of writing RESTful client easier - https://meapplicationdevelopers.dev.java.net/mobileajax.html. Take a look at the sample programs for usage. Note that this is prototype code and not standardized at this point. Comments, suggestions, feedback welcome.

Stefan Haustein

Hi Josh,

the problem with SOAP is that there is way too much overhead (message
size, parsing) for J2ME. I would recommend REST. If you use kXML2, you
can easily switch to WBXML later, perhaps combined with gzip.

Best regards,
Stefan Haustein

Josh Long wrote:
> Hello,
>
> I'm looking into exposing various aspects of a service API on a J2ME
> client.
>
> I am frustrated at the lack of options (thus far) and would like to
> know what your experiences are. I have a already existing Spring / EJB
> 3 API on the server side which in turn has entities with many-to-one
> Collections and so forth.
>
> I cant modify the API but I can add to it, exposing it as an endpoint
> using XFire, for example.
>
> The first natural candidate would be SOAP, but I didn't find much in
> the way of actual JSR 172 support. So then I started looking into
> kSOAP, which would be fine if I could find more documentation on it
> and could somehow generate stubs (there's far too many things in the
> API to make it worth "dynamically" invoking. Even when I tried
> invoking it dynamically I couldnt seem to get the kSOAP implementatino
> to play nicely with my new-ish SOAP 1.2 stack.
>
> Then, it occurred to me I might have better luck with XMLRPC and just
> accept passing xmlrpc structs back and forth as the API -- which would
> be ok if there was somehow a way to do it reliably and consistantly.
>
> I understand I might have better luck if i force open the original
> APIs and somehow seperate the entities from their service layers,
> making them implement kvmSerializable and impleenting all those
> ridiculous methods on each entity (not desirable).
>
> I am now looking at really just giving up the ghost and rewriting the
> endpoint using RESTlets (which is a completely new API for me, but at
> least it would be guaranteed to work with J2ME and the basic http
> connector, given that i completely rework the way the APIs exposed.
>
> What is the opinion of the list on service exposure like this? Any
> anecdotal evidence for or against any of these ideas/solutions?
> Unfortunately, except for JSR 172 , the trail on a lot of these
> technologies seems to gone cold around 2003, so Im also a bit put off
> by the lack of continued support.
>
> Any insight is appreciated, thanks.
>
> --
> Joshua Long
> Sun Certified Java Programmer
> http://www.joshlong.com/
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send
> email to listserv@java.sun.com and include in the body of the message
> "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Thomas Landspurg

Agree. I usually use kKML for XML parsing and doing either REST or
eventually some simple XML-RPC stuff. Enough for most of the usage, and this
save a lot of space to write a usefull client....

--
Thomas Landspurg
http://blog.landspurg.net

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Josh Long

Thank you so much for the responses! Any more are appreciated, of course.

I guess I had better start learning the basics behind REST and how to map
service methods on a stateless session bean to that way of thinking. :-)

Thanks again,

Joshua Long
Sun Certified Java Programmer
http://www.joshlong.com/

On 5/6/07, Thomas Landspurg
wrote:
>
> Agree. I usually use kKML for XML parsing and doing either REST or
> eventually some simple XML-RPC stuff. Enough for most of the usage, and this
> save a lot of space to write a usefull client....
>
>
> --
> Thomas Landspurg
> http://blog.landspurg.net===============================================...
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Joe Bowbeer

On 5/6/07, Josh Long wrote:
>
> I'm looking into exposing various aspects of a service API on a J2ME client.
>

If you want your client to be lean, robust, portable and performant,
then implement a RESTful service and use kXML2 on the client.

kXML2 won't add much code to your MIDlet and performs well.

kSOAP is a simple layer on top of kXML2. I consider it more proof of
concept than useful. (I think its implementors are of this opinion,
too.)

kXML2 gives you the control that you're likely to need in the long run
(when you need to patch-over incompatibilities, handle exceptions in
different ways, control the service threads, etc.).

I couldn't get kSOAP to work with a .NET service I needed to use, so I
gave up on it early, but I would have dumped it eventually in any
event.

I would prefer to use kXML2 over some unknown JSR-172 implementation
in many situations.

--
Joe Bowbeer

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".