Summarizing why WMS is Dead

At the urging of @wonderchook I did an Ignite talk at WhereCampDC titled: WMS is Dead

I feel that I've flogged this issue enough but nothing like putting in finishing nails in the coffin to tidy it up.


Architecture and Scaling
WMS was designed in the late 1990's, when we really didn't understand how the web worked at scale. I think that the dominant mental model of web services at that time was RPC and it's evident in the architecture of OGC W*S. The architecture was designed to mimic GIS systems, so WMS requests are standardized RPC calls to an abstract model of a GIS. Where WMS went wrong was that it ignored existing Web standards and that the Web's architecture and infrastructure was optimized for delivering documents via links. Ignoring URIs to retrieve standard well known mime types such as pngs contributes to it's clunky interface. Retrieving tiles via URIs is a Web native operation; whilst sending long requests to create a single document is not. That being said, I believe that layering a REST interface over WMS is a futile exercise in trying to hang with the cool kids. As Bruce Sterling often says, "Good luck with that."¹


Cartography
In WMS, you make make maps with SLD. I can't say enough that SLD is a bad idea. XML is for data, it should not be perverted in a single configuration, query, and pseudo programming language.


Projections
Projections have been cited as one reason WMS is superior to tile based mapping. My response is that Web mapping is a different medium from traditional cartography. In traditional cartography, the map maker has only the X and Y dimensions to convey information; which makes projections one of the most important tools for the cartographer. In web mapping, we have n dimensions to present information from info bubbles to interactive tools. Projections are still important for operations that require measurement, but that occurs on the backend and is less important for presentation.


Interoperability
WMS fails at interoperability because it is implemented at the application level. Chaining together a bunch of applications through a series of client requests does not result in a performant web application. In addition, WMS stateless (request/response) operations bypass web native optimizations such as HTTP caching; which has led to software such a MapProxy to overcome this shortcoming. Again this is a bandaid solution to a deeper architectural problem.


Interoperability should take into consideration how the Web is designed rather than providing an overlay that implements loosely-coupled client-server like architecture over the Internet. This means that interoperability should occur at a much lower level than application to application communications, such as data and document types.


I think that the prevalence of tile servers proves the point that URIs plus well known mime types trumps Web RPC. Data is out of the scope of WMS since it is primarily designed as a presentation interface (with lots of kruft), but I think it is important to the future of Web mapping as well as interoperability. 


When the W*S standards were under initial development, OGC made a bet that XML would rule the day; which is understandable since XML was the new hotness at the time. Implicit in this assumption was that XML parsers would improve, especially in the browser. However, as this blog explains, developers are tired of writing XML parsers and use JSON instead. JSON is a well supported and compact way to serialize data that trusts that the developer will use good taste to unpack the data instead of mandating the download of XML schema. The rise of fast and powerful Javascript engines as well as server side Javascript such as node.js was certainly not predictable. This does not bode well for W*S standards, which will be overcome by events even more quickly. For the INSPIRE folks, "Good luck with that."


I feel that the direction of Web mapping will be tied to Javascript on both the client and server side. We are already seeing this with the popularity of TileMill which uses node.js and client scripting libraries such as Leaflet and ModestMaps-JS. Like it or not, this direction in Web mapping is organic instead of top down from a standards body.


¹In all fairness, WMS was designed to retrieve a map dynamically based on a user's request. The use case was not, "I want a fast background map with data sprinkles"; which is the real world use case.