It's become really easy to program network data exchange between a wireless client and a server. Client will compose a long string (really long string) consisting of URL and another one, under the covers, the body of HTTP request, with headers and stuff. When done, it will begin transmitting it. And it will not expect anything in response until it's done sending. A servlet on the server side will read all the data from the request, decompose this data into transactions (this is the least of optimizations that is expected of a client, to combine several messages in one request). Then, the server will process all messages, combine all results in a payload (usually, a StringBuffer (*)), and return it all together in response.

Seeing anything wrong with that approach? While current wireless networks boast great bandwidth, making a connection and having the first bytes of transmission appear on the other end of the wire takes a sizable time to see. Which causes even smallest of transactions to appear intolerably slow.

It is possible to make this less painful to the user:
- the client must expect response from the server the very moment it estabilished connection;
- reading must be performed in parallel with writing;
- server and client must agree on the fact that every session of data exchange is not atomic, every session must be divided in smaller bites;
- it also holds true that the server must send the piece of information in response to every such bite-sized transaction as soon as it's done, should not wait till all transactions in request are processed.

Benefits
- network latency is reduced;
- application liveliness and user-frendliness is improved;
- less memory is needed on client and the server to complete exchange, as results are not buffered explicitly by applications on either side.

Complications:
- can not use IWeb interface in BREW, must program sockets (**); (J2ME is so much better in this regard, got a connection - have a DataInput/OutputStream);
- must program multiple threads (BREW programmers will find themselves at a disadvantage here);
- object-oriented approach on the server gets non-trivial, as operations have to be performed on-the-wire, meaning server has to operate on input and output streams and not on collection of transactions;
- substantial changes to the protocol of an existing system will be required, as both client and server must redefine result as sequence of successes and failures of small transactions and not a single result of all transactions
- as server processing gets potentially longer, special care has to be taken to prevent long-running transaction from occurring (***).

Overall, it may be impossible to convert an existing system built around simplistic approach. This prposed approach should be adopted before programming begins, during design phase.


(*) Ways to abuse StringBuffer exist and are not uncommon. Frequently, response to a particular message is constructed using StringBuffer, but the method itself would do a toString() which negates the benefit of using StringBuffer within the method body.

(**) A good third-party library may reduce the pain, but has to be purchased or licensed.

(***) E.g. if database is being accessed, connection must be obtained for every small transaction and released immeediately afterwards.