Designing a mobile web server and client for traff

问题:

I have been a bit confused on how best to go about this.

The thing: I'm creating a j2me mobile app that will send compressed data via HTTP to a web server, which then will uncompress the request, fetch the data, compress it and send back to client.

One similar solution to this is: T-Booster

The Problem: I'm confused on how to send a compressed http request from the client app, what technology to use for the server and how best to go about implementing it. Assuming the server is handing thousands of requests at a time, what will be the effect on the whole application?

Comments are well appreciated. Thanks.

回答1:

Approach I: Top Criteria's: Compression, Security and Architectural design freedom

The perceivable best way to achieve data compression is to create custom language that is understandable by the mobile client and its server only. You can add next level compression to it by using GZIP / LZW or any other compression algorithm.

Pros:

1. Customize the payload content with minimal headers and send it to the server.
2. Relatively secured from eaves-droppers, also an extra level of encryption would do no harm but to be considered on need basis.
3. Tow levels compression reducing the total payload.
4. Does not have any depending on any 3rd party encoder/decoder library, unless you use GZIP / encryption libraries. Hence its portable across platforms.
5. As 3rd party libraries are not used, assuming no gzip and no encryption algos, there is no commercial licensing hassles.

Cons:

1. Difficult to maintain the custom language, should be supported with architecture, design and javadoc's
2. Relatively high time to create payload if used multiple compressors viz. custom language encoding, GZIP compression and encryption library.

Example: In this link Opera Mini read section on Functionality.

.

Approach II: Top Criteria: Strict project timelines

For quick disbursement of the project use 3rd party compressors like GZIP and industry standard webservice content exchange formats like SOAP and JSON.

Pros:

1. Quick integration, adherence to standard approach's which make the web-server component easier to develop
2. No time consume in inventing the wheel, like is said no time consumed in architecturing and developing custom language.

Cons:

1. The level compression is driven by 3rd party libraries where-in the actual content might not be compressed. The library would just restructures similar to Shannon / Rate-Distortion theory.
2. The compression works the same in low end / high end device so the heap memory consumption might be blocker on low memory devices.
3. Dependency on 3rd party libraries, you never know when the support is pulled back.
4. You might get pulled into the vicious circle of commercial licensing when using 3rd party libraries, unless you use open source libraries.

Example: http://developers.sun.com/mobility/apis/articles/wsa/

.

Edit: Some very useful links

1. Informit
2. DevX
3. Design Mobile Webservices
4. Providing web services to mobile users: the architecture design of an m-service portal

回答2:

I am not a J2ME developer but wanted to share my view as a Java developer. If you are communicating with your webserver then i am guessing that you will be calling a webservice(SOAP or REST). I did something similar with webservice for SOAP to compress the communication some time back. Here is what i followed. http://www.predic8.com/soap-compression-howto.htm