One of the interesting events of GeoWeb 2009 – Cityscapes was a very entertaining debate on the “ideal” architecture for the GeoWeb. This was an interesting debate… not simply for the insights provided by the debaters about the relative merits of REST, or SOA, or P2P… nor for the entertainment provided by the presenters. What was really interesting was the very different conceptions of the Web held by the debaters, and by many of those in attendance at the GeoWeb conference. Some people have even asked me where is the “web” in GeoWeb?
The Web – as in “World Wide Web” – is, of course, concerned with a global network of hyperlinked documents or, perhaps more properly, a collection of webs of documents since there is no guarantee that all the sub-webs are interconnected with one another. This concept of the web has beenenormously successful, and has enabled not only a world of commerce, but also an every growing web of interactions among people through social media and social networking. In this world of the web of documents, human beings play a dominant role, and the weak typing and semantics of hyperlinks is perhaps an annoyance, but not much more. The people at the controls interpret the material returned in the link, and it is the person in the loop that makes it all work.
The SOA people (I am not arguing the merits of any architecture here, nor even what SOA means) do not, buy and large, come from the perspective of documents, but rather information processing and databases. The notion of a hyperlink (especially as a URL), while not irrelevant, is not central to this point of view. The primary issue is finding and then using an information processing resource. Take, for example, a common case from commercial aviation. An aircraft has just left an airport in Paris, bound for New York City, when a large snow storm forces the closure of the Kennedy Airport. This event then requires that a new route be computed for the aircraft, and this must be done using information from the aircraft respecting its position, altitude, speed, weight, number of passengers, and remaining fuel, as well as the destinations and connecting flights of the passengers and crew. One can see this requirement being handled by sending a message containing the required information to a route computation service, with the computed route with associated contextual information being returned to the aircraft. Copies of the revised route are then also forwarded to the new airport destination, Kennedy Airport, other aircraft along the intended route, the airline (or airlines), and various components of the air traffic management system. Nothing in this process especially suggests hyperlinking, but it does suggest messaging and response.
The airline problem above is, of course, greatly simplified, however, it implies the interaction between multiple systems, across multiple agencies, each doing specific data processing tasks (one may be scheduling the landings at the new destination airport, another displaying the current flights paths across the Atlantic), and each interconnected with one another. This implies both implicit and explicit orchestration of these different processing components to accomplish a specific task; for example, a styling process might obtain the computed flight paths from multiple sources and generate a visualization (map) of the current flight traffic. Many people think of this as System of Systems. I think we might also refer to this as a Web of Systems. In such a web, the interconnection between systems is based on messages and responses, and while each system may have an IP address, and the message might be communicated at base by HTTP, there may be no use of hyperlinking in the process at all.
So increasingly I would think of GeoWeb as meaning not only the web of documents, but equally, and I think ultimately more importantly, as a Web of Systems. You may have heard me say that SDI should mean business process integration, and this is another way of saying the same thing.
None of this should imply that I think that hyperlinking has no role in the GeoWeb. Far from it. SVG, KML, and GML all make wide use of hyperlinking and, in some cases, hyperlinking is a completely natural aspect of system design. Think of the display of flight paths. Clicking on a path to obtain additional information, whether sourced locally or far away, makes perfect sense. Nor should it be understood that I believe that REST architectures have no place in the GeoWeb. Not at all.
What I am saying is that much of the GeoWeb is, and will be increasingly concerned with, the local and global integration of systems – with the GeoWeb as a web of systems – and REST architecture is not pre-ordained as the architecture to builds such a web. As powerful as it has been in the web of documents, I believe there are serious issues with trying to build the web of systems in such a fashion.
Some of the issues revolve around the weak typing and weak semantics of a hyperlink. In the web of documents this does not matter so much, since this is a world with a person in the loop. Get the wrong document? Check again. Much tighter specification of type and semantics is required in the web of systems, or chaos may result. Similarly, there are security concerns with the web of documents, and with the stateless connections that this generally implies.
Many of you will object, and say that the REST architecture can solve all of these problems, and this may well be. I only assert that you must think of REST as it applies to a Web of Systems and not be stuck in the “past”, where Web mean only a web of documents.
SOA approaches, such as SOAP (or those based more directly on POST), have confused some people because they use the primary component of the Web of Documents, namely the HTTP server, as the fundamental message transport. When they do this people, think “web server” and hence web of documents, when nothing of the sort is implied. SOAP is not bound to a particular transport protocol, so it could just as easily run over socket connections (TCP/IP), or a messaging middleware such as JMS, as over HTTP. Even the use of HTTP operations (POST, GET, PUT) are often “perverted” in a world more dominated by point to point messaging. The ubiquity of HTTP servers is what has driven the use of HTTP below SOAP or other Web service encodings, and not any overt intention to make use of the web of documents and hyperlinked resources.
So GeoWeb = Web of Systems (and a web of documents). Think about it!
Part of this blog post was published as “Thinking of GeoWeb as a Web of Systems” in the “Building the GeoWeb” column in the January 2010 issue of GeoWorld Magazine.