The MapPoint service is a commercial offering by Microsoft which gives developers access to a wide variety of mapping functionality through a web service interface. Well that's how it used to be anyway. For a while MapPoint was just a web service and a technology that powered products like Autoroute, then for a while it became Microsoft Virtual Earth which did nothing apart from change what appeared on the map images that you loaded from the servers. Then Microsoft launched their Bing extravaganza which meant that it's now called Bing Maps - well it is when one logs into the control panel but the service is still called MapPoint. It's highly confusing and makes it intensely difficult to find what one wants on the Microsoft site, especially on plumbing the depths of MSDN. For the purposes of this diatribe however, MapPoint is a web service that uses the SOAP protocol.
the process could fail catastrophically, mostly due to the abject bloody-mindedness of the MapPoint service
SOAP and PHP have not always been the most accommodating of bedfellows, it wasn't until version five that PHP had the language constructs to support SOAP (namely XML and Objects) and even now they're not exactly seamlessly integrated. Version four of PHP relied upon pure-PHP to manage SOAP, while five introduced a dedicated extension and related classes. The classes themselves are basic, and lamentably the Zend Framework concentrates more on serving SOAP content than consuming. In short, talking to the MapPoint service using PHP is a pain and fraught with problems - most predominantly is that MapPoint is a service built with .NET in mind (indeed the service was originally called MapPoint .NET), PHP just happens to be supported through the open-standard nature of the protocol.
The term "cloud computing" is being bandied about more and more recently, sometimes termed "x as a service", its proponents make it out to be the embodiment of an ideology whereby one doesn't worry about the details and simply wants to get things done. From my perspective as a developer, the most interesting parts of the CC paradigm revolve around infrastructure, service and storage but unlike a great many others, I'm unwilling to jump head-first into using CC implementations.
Growing up for me has always been about trying to get the most amount of bandwidth realistically available to me, often times verbally fighting for it, be it with my sister or the IT providers at my university. Coming from that background I have a healthy respect for how precious people make bandwidth out to be and the detrimental effects not having enough of it can cause. In this light, you can understand why I'm wary of cloud computing. Internet access is still not as ubiquitous as many people, most densely-packed city dwellers, make it out to be. The application end of the CC scale I'm always going to meet with scepticism, my documents are stored on my hard drive which is eminently more tangible than an increasingly ephemeral idea of connectivity.
five nines uptime isn't what these services are pushing as their tagline
Other uses of CC though include offering a service beneficial to developers and producers alike, and this for me is where the allure begins. Not having to worry about storage requirements or dedicated server space for a project is an enticing prospect, cutting out a swathe of niggles and possible overheads, breaking it down to what many feel is the future: it just works. Being able to simply sign up and start pulling and pushing data through a well defined API, to a service rather than a dirty filesystem has an elegance to it. Or perhaps the idea that servers are no longer tied to a physical machine, instances just minutes away from being summoned to life as quickly as they can be brought down.
