Digital Earth Weblog

Calendars at the ready! The Free and Open Source Software for Geospatial (FOSS4G) conference will be occurring in Sydney from 20-23 October 2009. That’s Tuesday to Friday inclusive. Key dates:

Online Registration Opens:	20 April 2009
Abstract Submission Deadline:	01 June 2009
Early Registration Deadline:	31 July 2009

The call for presentations is open.

Now, the author of this site has obviously been hiding under a rock because he missed this completely. The heads-up came from the company that provides PostgreSQL support to the author’s employer.

SOA requires discipline to implement, and can involve new roles. In that regard it seems a bit like Scrum. It’s easy to do something that looks like Scrum, but it is quite difficult to maintain the discipline to do Scrum as it was intended.

Another parallel is shiny tools. There are a lot of tools that help with agile software development, but they can often be a distraction. SOA appears to suffer from the same issue.

Just thinkin’.

My new role has a strong enterprise architecture flavour, but is limited to one business unit. Last week I attended the ZapThink LZA Bootcamp held in Melbourne. I paid my own way, and it was worth the trip.

» Read more...

Posts to this blog have been scarce in recent times. This has been partly due to a large change in my work role and responsibilities, and partly due to overall workload.

I’m still on the learning curve in my new role, and have not felt comfortable writing about it. As that learning curve starts to flatten out, and a few deadlines are met, I will start posting some thoughts about the experience.

Simplifying the argument over global warming.

If the embedded YouTube video doesn’t render in your feed reader of choice, you can access it directly at YouTube.

As many people have noted, the Yahoo! Internet Location Platform has been released. After looking at the examples it all made sense, but two things stood out:

1. Request: The use of a custom query mechanism rather than using HTTP query strings. (This is addressed in Part 1 of this post.)
2. Response: The lack of URIs to identify related resources.

What follows is just a quick exploration of the second of these two issues.

URIs for Related Resources

The response documents provided by the Yahoo! Internet Location Platform do not contain any URI’s to identify related resources. This seems like a lost opportunity to make client applications less fragile and make life easier for developers. It could also make scaling on the server-side easier. (Yes, I’m talking about using REST.)

The current approach provides some of the information required to construct URIs, but the client application needs to be aware of the URI pattern to used to construct the URI for each type of resource.

There can be three types of related resources implied in a location search result:

1. Related locations. e.g. Country, state, admin, locality, etc.
2. Pages of matching records from the same collection of search results.
3. Neighbouring geographies.

1. Related Locations:

Using the Sydney Opera House landmark search example, the related country is returned as:

<country type="Country" code="AU">Australia</country>

 

If an application wishes to take any action that requires knowing the centroid or bounding box of Australia it must know how to construct the correct URI to query the server. e.g.

http://where.yahooapis.com/v1/places.q('Australia')

 

This creates a fragile client application. If the URI construction rules, the host domain, or the URI path change then the client applications will break. The client application needs to know too much about the internal workings of the service. i.e. It is more tightly coupled that it needs to be.

An alternative solution is to identify each related resource with a fully formed URI, in the original response document, which the client application could then dereference:

<country yahoo:uri="http://where.yahooapis.com/v1/place/23424748"
  type="Country" code="AU">Australia</country>

 

Yahoo! can then make all the changes they want to the URI that identifies the Australia resource representation without breaking client applications. It doesn’t matter if they change the URI to:

http://where07.yahoo.com/location/australia

 

The client application will still work provided it still understands the structure of the response document. (Data coupling is a topic for another day.)

2. Paging:

Using the Springfield place search example, when a place search matches more records than it returns in the firts response document this is indicated using:

<places ... yahoo:start="0" yahoo:count="5" yahoo:total="61">

 

These three attributes provide useful information for the client application, but again, in order to get the next five matching results the client needs to know how to construct the appropriate URI:

http://where.yahooapis.com/v1/places.q('springfield');start=5;count=5

 

It would be helpful to developers if the original response included a URI for both the next five and the previous set of records (if applicable):

<next count="5" 
  yahoo:uri="http://where.yahooapis.com/v1/places.q('springfield');start=10;count=5"/>
<previous count="5" 
  yahoo:uri="http://where.yahooapis.com/v1/places.q('springfield');start=0;count=5"/>

 

This is a less compelling example, because it assumes that the client application always wishes to obtain matching results in fixed size sets, whereas the approach taken by the Yahoo! Internet Location Platform allows the client application to make that choice on-the-fly.

3. Neighbouring Geographies:

The current response documents do not include any details about neighbouring geographies, but there is a neighbouring geographies query. Client applications must know how to construct yet another URI to obtain this information:

http://where.yahooapis.com/v1/place/12795711/neighbors 

 

Why not simply add a new element to the response document that provides that URI?

<neighbors type="State" 
  yahoo:uri="http://where.yahooapis.com/v1/place/12795711/neighbors"/>

 

Conclusion:

Taking a more standardised approach to adding query parameters to URIs, and providing URI’s to related resources, would enable developers to create less fragile client applications. The Yahoo! Internet Location Platform also appears to have missed an opportunity to deliver a true REST interface in an application where it would be very well suited, however…

Caveat: All the above has been written knowing nothing about the business or design constraints that shaped the Yahoo! Internet Location Platform. There are likely to be many perfectly sensible reasons for the design choices that were made.

As many people have noted, the Yahoo! Internet Location Platform has been released. After looking at the examples it all made sense, but two things stood out:

1. Request: The use of a custom query mechanism rather than using “HTTP query strings”:http://en.wikipedia.org/wiki/Query_string.
2. Response: The lack of URIs to identify related resources. (This is addressed in Part 2 of this post.)

What follows is just a quick exploration of the first of these two issues.

Query Mechanisms

The Yahoo! Internet Location Platform uses an interesting mixture of three different query syntax styles.

1. The place name search syntax looks like an object method call.

/places.q('sydney%20opera%20house')

 

Yahoo!‘s function-like syntax places.q(‘place%20name’) makes it look like q is a method on the places object. That would suggest the underlying implementation may have leaked into the interface (surely not!).

2. The paging parameters, start and count, are semicolon delimited strings.

/places.q('springfield');start=0;count=5

 

Avoiding the use of HTTP query strings would allow HTTP caches to cache the results of the place name searches. That would improve performance on common searches while reducing the load on the Yahoo! servers. However, that would prevent Yahoo! from controlling access and accurately metering usage.

3. And, query strings are still used to determine language and format of the resource:

/places.q('usa')?lang=fr
/place/2487956?format=json

 

There goes the caching theory, so why not just use plain vanilla query strings for all parameters and keep it consistent? Example:

/places?q=springfield&start=0&count=5&format=json&

 

It’s dead easy to construct a query string from a map, or dictionary, of name/value pairs and append it to a GET request. Using a non-standard and inconsistent approach creates more work for developers.

Continue to Part 2

This website was previously hosted on a shared FreeBSD server at TextDrive (now Joyent). It served us well for several years, but suffered from typical shared server problems, like needing reboots and pauses while waiting for shared resources.

Yesterday I migrated the website to a shiny new Shared Accelerator server, running OpenSolaris. It appears to be responding noticeably faster.

If you notice any issues I’d appreciate it if you could let me know.

The Open Web Application Security Project promotes security best practices for web application development. OWASP have run training and conferences in the US and Europe. The good news is that Australia has been added to the list, along with Asia and Israel.

When	27-29 February 2008
Where	Gold Coast Convention Center, QLD
What	Training agenda, Conference agenda

Useful OWASP artifacts:

• The OWASP Top Ten most critical web application security flaws.
• The OWASP Guide to Building Secure Web Applications

If you build web applications I highly recommend taking the time to look at those documents.

Anyone else find the rules for the new OGC Individual Membership kind of…well…restrictive?

» Read more...