The Mobile Web refers to access to the world wide web, i.e. the use of browser-based Internet services, from a handheld mobile device, such as a smartphone, a feature phone or a tablet computer, connected to a mobile network or other wireless network.

Traditionally, access to the Web has been via fixed-line services on large-screen laptops and desktop computers. However, the Web is becoming more accessible by portable and wireless devices and according to ITU (International Telecommunication Union) with current growth rates, web access by people on the move — via laptops and smart mobile devices – is likely to exceed web access from desktop computers within the next five years. The shift to mobile Web access has been accelerating with the rise since 2007 of larger multitouch smartphones, and of multitouch tablet computers since 2010. Both platforms provide better Internet access and browser- or application-based user Web experiences than previous generations of mobile devices have done. Companies around the world are creating mobile websites for other companies (for example “GO MO Group”).

The distinction between mobile Web applications and native applications is anticipated to become increasingly blurred, as mobile browsers gain direct access to the hardware of mobile devices (including accelerometers and GPS chips), and the speed and abilities of browser-based applications improve. Persistent storage and access to sophisticated user interface graphics functions may further reduce the need for the development of platform-specific native applications.

Mobile Web access today still suffers from interoperability and usability problems. Interoperability issues stem from the platform fragmentation of mobile devices, mobile operating systems, and browsers. Usability problems are centered around the small physical size of the mobile phone form factors (limits on display resolution and user input/operating). Despite these shortcomings, many mobile developers choose to create apps using Mobile Web.

Define the Web service interface first, then implement it

This is not only applicable from the view of mobile Web services, but also from the perspective of Web services design and from a higher level, the perspective of object-oriented software design. As you know, an interface is the contact between clients and service providers, and it is important that it stays stable (because, as you know, implementations are prone to change).

The definition of an interface of a function is quite direct and intuitive -- just think about:

• your goal
• what information you want to take in
• what kind of result you want to return to the client

Then you just write down the interface and it guides you through the implementation details.

This is a simple design guideline. Knowing your goal is very important, it can drive you to write your test case down and direct you to write the function implementation, and this is also the reason why test driven development (TDD) makes its way in the world of various development techniques.

Use Document/literal as your encoding style

Currently, there are three operation modes supported by standard JAX-RPC:

• RPC/encoded. Its strengths are its straightforward nature and that the receiver has an easy time dispatching this message to the implementation of the operation. Its weakness is that its type encoding info is usually just overhead, which degrades throughput performance.
• RPC/literal. Its strengths are the same as the encoded version and it is compliant with the WS-I Organization specifications.
• Document/literal. Its strengths are that there is no type encoding info, and any XML validator can validate the messages. Its weakness is that the operation name in the SOAP message is lost, so dispatching can range from difficult to impossible.

In the literature, you may also find a mode called Document/encoded (not many use this) and Document/literal wrapped (defined by Microsoft but with no specification; its major weakness is that it is more complex than the other modes). A thorough explanation of these operation modes can be found in "Which style of WSDL should I use?

Mobile users are not always on the same network.  At one moment they're at the office using a secured wireless access point that runs over a corporate network.  At other times they're at an airport using 3G data service from a carrier.  Or perhaps they're at home using semi-trusted wireless access to the Internet.  Of course, that's the very definition of being mobile.

It all has me convinced of one important concept:  mobile apps want to talk to the storage layer using web services. Mobile apps are not using NFS and CIFS to access content --- certainly not directly at least.  Using CIFS and NFS simply wouldn't work over mixed network types and has a host of security implications.

Using CIFS and NFS results in tethering users to particular networks and topologies.  It just wasn't designed for this new world of ubiquitous access to content.

The type of content that mobile users consume and create is largely unstructured consisting of documents, images, audio, video, etc.

The mobile apps could use web services to talk to an application server that acts as a proxy between the mobile app and the storage layer, but that's not always the most efficient method.

That's not to say that mobile applications won't and shouldn't talk to an application server at all.  There will still be database persistence layers that will routinely need to be accessed, but mobile users aren't generating a significant amount of structured data anyway.