Java web service and pocket pc

Question

Hi all. I am looking for some advice on how best to go about the following. I have looked on the internet and found info on relevent parts, but not sure how to interact them all together.
I want to develop an application for a pocket pc (probably windows mobile 5.0) that will interact with a web service(in java). The pocket pc will send some sort of authentication to the service, which will then query a database and send the relevent information back to pocket pc.
I have read things on SOAP, WSDL and AJAX etc... but am unsure how to put them all together.
If anyone has any advice, good tutorials or links then they are greatly appreciated.
Regards

Answer 1

Hi all. I am looking for some advice on how best to
go about the following. I have looked on the
internet and found info on relevent parts, but not
sure how to interact them all together.Join the crowd :-) For most of this stuff, it seems we're ALL finding our way around.
I have read things on SOAP, WSDL and AJAX etc... but
am unsure how to put them all together.That's kind of like asking "how long is a piece of rope?" It depends on what you need it for.
Try w3schools.org for some great tutorials on some of the underlying technologies that power the above.
SOAP is nice and all if you want to use third-party libraries and you need industry-standard interactivity (for example with vendors or customers), but if you're doing everything in-house (i.e. your own application will consume the web service you wrote) then I'd seriously consider REST-based webservices. They're easier to write because you're free from the limitations of SOAP, and your apps can be smaller and with fewer parts.
Screw WSDL. Use it only if you are forced to. Axis has a great WSDL generator and if you can deploy everything in Axis, then you're good to go. I started writing my webservices using Axis and WSDL->Java generators and I was all cool and stuff because I was doing what everyone said was the best way to write these new applications. It took me a while to realize that most of that advice was coming from the people that were writing the software the real applications were based on, not using the stuff they had written to build real apps with. The perspective is completely different.
Then I had to maintain that mess and it wasn't worth it because all of my uses for webservices are internal. I write the server and client portions both. There's no need to complicate the issue with technologies that are meant for interacting with other systems which you have no control over, nor any knowledge of how they're consuming the information you're providing.
As to specific documentation, that's a little harder to come by. Your best bet is to first and foremost: read the specs on w3.org. No other pieces of documentation will be as in-depth and informative as the spec. If you're using spec-compliant implementations, then you've already got all your documentation. They're dense, I agree. They take forever, I agree. But I have yet to find anything that can rival the depth of understanding I gain from the specifications. Read the specs. All of them. Download them, print them out, stuff them in a fat folder (mine's in a 3-inch binder) and keep them handy. It seems like enterprise-level webservice-enabled apps will require lots of third-party support libraries, use lots of different technologies, and the documentation required to help the developer actually use all of this stuff will become critical. That's why I say print stuff out and keep it in one spot.
If you can get any good out of these third-party libraries for generating clients, then more power to ya. I think they're a waste of time, myself, because I can write a client quicker and make it far more easy to maintain if I just do it from scratch. I'm only interested in using these technologies to make it quicker, more effiicient, easier to maintain, etc... be careful you don't get carried away with the vastly divergent advice you'll get on how to build your app and end up making it much more complicated and harder to maintain than it would have been had you not used industry-standard methodologies. Think small and simple.
To get started, I would get a really good XML IDE. I use oxygen (http://www.oxygenxml.com). Version 7 is out, which has XQuery debugging and lots of other stuff. Have your company buy it. It's worth it. (has eclipse integration too). Then download Sarissa: http://sourceforge.net/projects/sarissa it's a great cross-browser javascript library for doing AJAX stuff. We use it for our AJAX applications and it's great. Fairly well documented too. Then use as much client-side processing as you can get away with because with webservices, your XML processing will hammer the server. Our IBM dual 3GHz/8GB RAM machine is chugging constantly. We process around 300,000 pages of XML in a normal business day, and it's intensive processing (lots of SQL serialization and transforms). We're trying to offload as much work to the client as we can. We're using Mozilla now, so that's making life much easier for us. Even the embedded mozillas have fantastic support for AJAX-friendly technologies.
As for putting everything together, well, you're pretty much on your own there. In our environment, we have a custom XML-based intranet portal, which I had to write myself because there's nothing out there that does what we need it to, we use Postgres as our enterprise database, JBoss as our application server, Apache as our front-end, and oh yeah, we have an AS-400 on which resides all the "real" data. Just try and find documentation on serving data via an AJAX-enabled enterprise app from data that resides on DB2/400 and generating the interface on the client using XSLT. Or how about getting data from the postgres server into an RPG program using a webservices client on the 400. I don't even think I'm supposed to be doing stuff like that, let alone be able to find documentation on a solution that someone has come up with.
Now if someone would just make a good JavaScript IDE, AJAX would take off like a bat out of hell. How long has JavaScript been around now? 10 years-ish? And how many good IDE's are there for JavaScript? Zero. Really irritates me sometimes... A good Mozilla-based AJAX-friendly JavaScript IDE would be a HUGE and I mean HUGE benefit to the webservices community.