Monday, March 02, 2009

NSDI 2.0, REST and the OGC WMTS

As folks discuss emerging technology for the National Spatial Data Infrastructure (NSDI) it's healthy consider the feasibility of different approaches as emergent solutions. It's important to note that recent "NSDI 2.0" grassroots coalitions didn't identify a particular technology platform in the initial concept paper - unlike Google, Microsoft and Oracle that said "SOA". Why? Because our consensus process identified this as an area where community discussion and exploration of emergent approaches was needed - and also because we knew there were multiple approaches available.

With that said, technology approaches for building online SDIs range from proprietary to interoperable and everything in between - and there are two basic Client-Server architectures to apply, ROA and SOA (Service Oriented Architectures and Resource Oriented Architectures). Note - folks will need both in an "SDI 2.0" because there will be information exchange, transaction services and collaboration requirements that can be supported better by SOA standards and KVP OGC Web Services like WFS. We'll take a look at Peer-to-Peer (p2p) architectures in the future.

SOA and ROA are both client-server design patterns and the corresponding distributed programming paradigms that provide conceptual methodologies for developing distributed architectures. In the cases of ROA and SOA the distributed components are called resources and services, respectively. I've discussed SOA already so lets look at ROA quickly - and use the draft OGC WMTS Interface Standard edited by CubeWerx, CREAF and the Autonomous University of Barcelona as an example.

From the candidate OGC WMTS Interface Standard - "The first step in the resource oriented architecture style is to identify the resources and the relations between the resources. Then the RESTful approach gives us a way to manipulate these resources via standard HTTP requests. In this specification only HTTP GET will be used to download resources that are equivalent to the ones that can be retrieved by the GetCapabilities, GetTile and GetFeatureInfo operations in the procedure oriented architecture style."

and...

"The RESTful encoding for WMTS consists in a set of canonical URLs to the service metadata document, to the tiles, and to the FeatureInfo documents (one for each pixel)."

So the URL referencing a capabilities document should have the following syntax...

{WMTSBaseURL}/{version}/WMTSCapabilities.{format_extension}

where format_extension is an extension compatible with the text/xml MIME type and version refers to the version of the capabilities document requested.

To request a WMTS capabilities document from a WMTS server that implements geospatial ROA, a client could issue the following RESTful URL...

http://www.maps.cat/1.0.0/WMTSCapabilities.xml

If a client requests a document version or a format extension that's not available on a particular server, the server returns an HTTP Error 404 (File Not Found). Sweet.

To continue, the ServiceMetadata document of WMTS in the RESTful architecture style contains a description of a resource with the name "Tile". The “Get” element of the GetResourceRepresentation operation has an xlink:href attribute that advertises the URL to retrieve tiles.

So the URL referencing a tile map image should have the following syntax...

{WMTSBaseURL}/{layer}/{style}/{firstDimension}/{...}/{lastDimension}/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.{format_extension}

If the layer has zero or one style, don't include the {style} level in paths and the default style will be returned. If there are no dimensions don't include /{firstDimension}/{...}/{lastDimension}/ levels in paths.

So then a client could issue the following RESTful Tile URL for a resource representation...

http://www.maps.cat/etopo2/WholeWorld_CRS_84/10m/1/3.png


So there you go, geospatial ROA 101 for the web engineers. As an overarching concept what is key is interoperability - the shared agreements of our community. As consensus ROA standards advance in the future, and can be combined with SOA and used for access to geospatial and environmental data, this is positive. In the end, a key concept is providing an open, standards-based framework so geospatial data and environmental data can be maintained locally, closest-to-source, and then shared with the Nation through an online information network. Stay tuned, much more to come...

- Jeff

6 Comments:

At 3/02/2009 09:17:00 AM, Anonymous Bill Dollins said...

Good post, Jeff. Thanks for taking the time to follow up the spec with some plain language on potential implementations.

We are finding that REST, in addition to being a good model for new systems, is making it easier to extend existing systems in a relatively modular manner.

There are some environments, such as DoD, where SOA (and big SOA in particular) is still the rule of the day so having the flexibility to take both approaches is definitely a bonus.

 
At 3/02/2009 07:18:00 PM, Anonymous Josh Lieberman said...

Enjoyable reading, Jeff, but it's a false dichotomy between ROA and SOA. They consider different architectural aspects of a system but both deal with services, or "distinct ... functionality provided by an entity through interfaces". RESTful services are bound to resource-oriented interfaces. RPC-like services are bound to procedure-oriented interfaces. It can be the same functionality, just a different view from the eye of the invoker, as was intended in the WMTS RFC.

 
At 3/02/2009 08:11:00 PM, Blogger Jeff Harrison said...

Josh, there seem to be two 'extreme' camps of people on this topic. In the first, there are those that assert ROA and even the new buzzword 'Cloud Computing' are all subsets or refinements of the SOA architecture. In the other camp, there those that distinctly define SOA from ROA design patterns and the corresponding distributed programming paradigms that provide conceptual methodologies for developing distributed architectures (in the cases of ROA and SOA folks call the distributed components Resources and Services, respectively).

That's why I pointed out - ever so gently - that both are just Client-Server architectures.

Why make this distinction? Well because I happen to think it's an accurate way to portray the state of play in the community - and also to distinguish what are essentially different flavors of client-server architectures from a truly distinct new patterns - like the innovation and shift that will be jump started with modern peer-to-peer when IPv6 completely replaces the archaic IPv4.

 
At 3/03/2009 06:31:00 PM, OpenID Nuke said...

Remember SOA, ROA, WOA (look it up) and REST - non of these is a specification of any sorts. They are design approaches and principles. It is easy to see why some aspects are open for debate.
Personally I agree with Josh and see ROA as a subset of SOA, while REST is a design approach for a stateless service where resources can be accessed with no HTTP payload.
As Jeff mentioned P2P, especially the advanced serverless kind, will provide the true architectural revolution.

 
At 3/20/2009 07:05:00 AM, Anonymous Mike said...

I'll have to agree with Josh on this

REST vs RPC is, practically speaking, really HTTP vs SOAP

SOA is not SOAP, and WOA is not HTTP

SOAP and HTTP are technologies for enabling SOA

WOA is a subset of SOA that mandates the use of HTTP in a RESTful manner. SOA and WOA are not mutually exclusive.

REST is not a replacement for SOA since it is a separate, technological architectural layer

 
At 3/30/2009 07:31:00 AM, Blogger Jeff Harrison said...

Seems the community consensus on REST is - it's an architectural style for building Services - based on the architecture of the Web. In RESTful Services the primary consideration is which Resources are exposed - with a Resource being any information you want to make available to others.

In RESTful Services - Resources are identified by a URI - and the URIs are designed in a way that makes logical sense based on the type of Resource.

Still just Client-Server architectures. OK, I'll say "Client-Services" Architecture ;-)

 

Post a Comment

<< Home