Architectural Options
Each cell phone could communicate with every required city traffic system. This solution distributes the networking and processing load onto many clients, but also means that each client needs to know how to communicate with each remote system (assuming the remote systems do not share the exact same protocol and implementation).
There could be a single intermediary server which would communicate with each of the cell phones and each of the city traffic systems. This means the intermediate server is a single point of failure (unless made redundant, perhaps via clustering) but also that each client only needs to be able to communicate with one server (via one protocol).
The second solution, illustrated below, is better. By keeping the client simple and pushing complexity to the server, the complexity becomes easier to manage. Mitigating the weaknesses of cell phones--a slow processor, weak user interface, slow and intermittent network access--is a secondary benefit.
The intermediary server architecture. The cell phone communicates via the carrier's network to the intermediary server, which processes requests and dispatches them to other systems, as needed.
Other benefits of the intermediary server architecture
Though cell phones are constantly improving, they are still low powered consumer devices. There are certain activities that, while perhaps achievable on a cell phone, are easier done on a server. If the traffic congestion service offloads complicated tasks, such as email notifications to family or friends regarding late arrival or map generation for route finding, to the server, more functionality can be offered without complicating the client.
It is possible to cache information retrieved from the city traffic systems at the intermediary server. Therefore, when everyone is stuck at one interchange, the city traffic database is not queried repeatedly, and users will see better performance.
For development purposes, the intermediary server offers fewer interactions to manage and debug. Rather than M x N interactions caused by M clients talking to N systems, there are M+N interactions.
Authentication and access control become easier; the single server can handle these sometimes complicated tasks. The traffic congestion service can easily make sure users have paid and if there are premium features added, one point of authorization makes controlling access easier.
When the protocol to access the city traffic systems change there is no need to track down and persuade users to upgrade the application on their cell phone; instead the intermediary server can be easily upgraded. Clients can use whatever protocol is best for communicating over the wireless network, rather than being forced to understand the (perhaps different) protocols of the remote systems.
However, an intermediary server means more testing and more code to maintain, and if that server fails, the application is inaccessible. However, the alternative architecture, each client talking to each remote system, is a protocol management nightmare, requiring complex J2ME clients.
