Don't mix logical design with physical design. Logical design operates over layers and physical design - tiers. Web Service is not a layer. It is simply a tier.
In logical design there is standard approach: UI layer-> BL layer -> DAL
In physical design all layers can reside within one client-side application connecting local database, or can be distributed over the remote tiers. But for distributed applications usually is added one more layer: Application layer, which hides from BL layer communication over the wire.
After three years of Django development, I've learned the following.
The ORM is the access layer. Nothing more is needed.
50% of the business logic goes in the model. Some of this is repeated or amplified in the Forms.
20% of the business logic goes in Forms. All data validation, for example, is in the forms. In some cases, the forms will narrow a general domain (allowed in the model) to some subset that's specific to the problem, the business or the industry.
20% of the business logic winds up in other modules in the application. These modules are above the models and forms, but below the view functions, RESTful web services and command-line apps.
10% of the business logic winds up in command-line apps using the management command interface. This is file loads, extracts, and random bulk changes.
It's very important that view functions and RESTful web services do approximately nothing. They use models, forms, and other modules as much as possible. The view functions and RESTful web services are limited to dealing with the vagaries of HTTP and the various data formats (JSON, HTML, XML, YAML, whatever.)
Trying to invent Yet Another Access Layer is a zero-value exercise.
Best Answer
The question is too open ended so the answer is: it depends.
What needs do your applications have for the data? Is it just data access or some business logic involved? If it is just accessing of data, do you really want the client to have direct control over it? How similar are the three applications? Do they share functionality or just data?
As I see it there are two main paths you can chose:
1 - expose a web service for the business, with the data hidden behind the web service. This is a good setup if the three clients (I'll call the desktop app, web app and cell phone "clients" since that is what they are) share functionality (i.e. they are different views for the same business model). This avoids duplicating similar business logic in all the clients;
2 - expose the data directly with a web service. This is a good setup if the three clients have nothing in common but just use the same data for different purposes. But in this case, with the three sets of business logic, where are you going to put the logic? In the clients? How will that work for the desktop application (considering you install this desktop app 300 times or so)? You again need some service and the clients to be thin clients not thick ones.
If you take 1) and 2) into consideration you will see that usually it is better to have a service layer in front of your data.
Going back to the "it depends", analyze your special needs first and only then choose the solution that is best suited for your situation.
How about a point 3? make your data access layer into a library (.jar, .dll or whatever technology you are using) and make that available to the (1? 2? 3?) business web services that serve your clients?