URLs for 10 minutes

Protect Your Site With URL Rewriting seems a little bit of a mad suggestion. They are basically suggesting that you change your application's URIs every 10 minutes to prevent XSS and XSRF (Cross Site Request Forging).

We could mitigate much of the risk of these vulnerabilities by frequently changing our URLs—not once every 200 years but once every 10 minutes. Attackers would no longer be able to exploit application vulnerabilities by mass e-mailing poisoned hyperlinks because the links would be broken and invalid by the time the messages reached their intended victims. With all due respect to Sir Tim, while "cool" URIs may not change, secure ones certainly do.

The negatives seem vast and I wonder what this is really trying to solve, as they say at the end:

An automatically expiring URL can still be exploited by an attacker with access to a Web server of his own. Instead of sending out malicious hyperlinks that point directly to the vulnerable page, he can send out hyperlinks that point to his own site. When his site gets a hit from one of the phished e-mails, it can contact a landing page on the vulnerable site to obtain a valid time stamp and then redirect the user accordingly.

If you are a REST advocate then maybe a quick read over, The Resource-Oriented Architecture in Action, may soothe you (from the excellent book, RESTful Web Services).

LOL (List of Links)

• Hamcrest integrated in JUnit 4.4 and above (JMock like expectations). Also allows Popper theories (the link in the release notes is available through archive.org). which are similar to TestNG's data points. There are also some examples: here, here, here and here (using Groovy).


• Window Licker an interesting approach to Swing testing. See the Calculator example and XP Day 2008 presentation.


• The bushfires are retribution for the damned. Apparently, God waited 5 months (or maybe he was too busy appearing in toast) to smite those Victorians down. The most annoying part of this is the fuzzy thinking. Instead of considering that it might be poor fuel management practices, bad advice on whether to stay or leave or global warming it's actually about abortion. If you can speak of a real Christian attitude, the people of North Queensland donating their flood relief money straight to the Victorians seems more along the right lines.


• Haskell book to read and buy. Luckily in that order.


• SemWeb project VoiD a simple vocabulary for linking and describing different data sets.


• A couple of ways of fixing the billion dollar mistake using Java Rebel or maybe Maybe Monad (using Java 5 for loops even). Speaking of which: Monoid fingertree (trees in Haskell) and JQuery is a Monad (apparently that makes it slow). I also realized that Void is a valid type in Java Generics which is helpful in the dreaded Visitor pattern.


• Bill Moyers on Gaza and Dr Izzeldine Abuelaish sharing his grief on Israeli television. More information is available from ABC's Foreign Correspondent story, "The Doctor and his Daughters" because the wikipedia page has been deleted.


• The Poppendieck's on Lean development as to balance Martin Fowler on Scrum.


• Straight Skeleton as a way to generate a skeleton from a polygon.


• RESTEasy JBoss' REST framework.


• Microsoft's terrible vengence, Songsmith. If you love music don't click here.


• And What's up for Java in 2009?

Time for REST

The best part of the latest release of JRDF is not code that we've written but Restlet. Restlet provided an excellent abstraction for providing RESTful web services and allows deployment without a container (the distributed and local server are both about ~6MB in size).

This has allowed us to quickly develop a web service that answers SPARQL queries that can be from one or many machines. We're using it to query the results from MapReduce tasks in our Hadoop cluster but it could probably be used as a general way to query other SPARQL services.

It's still early days and there's a lot that still needs to be added (and re-added) such as limiting result sizes, being able to choose which format to return and better JSON support. A lot of it has been pushed out in time to show a front-end at SSWS.

It would be good to have a Javascript client that submits the SPARQL queries and handles the ordering and such rather than having the distributed query server hang onto all results until returning.

Download it here.

Round of Links

• Apache Hadoop Wins Terabyte Sort Benchmark "One of Yahoo's Hadoop clusters sorted 1 terabyte of data in 209 seconds...This is the first time that either a Java or an open source program has won." There were just under 1000 nodes, the benchmark results are hosted by HP (a tad more detail here).


• Microsoft buys Powerset one of the interesting things is that they use Hadoop (see their blog). It's hard to tell whether this is bad or good for Hadoop.


• Google vs Microsoft - oh for structure.


• Tom talking about GridGain from his presentation in February. C++ isn't as productive as Java?


• Applets are back (according to Sun).


• Why commenting is for n00bs. "And Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within academia to try to force people to model everything. Programmers hate that. These languages will never, ever enjoy any substantial commercial success, for the exact same reason the Semantic Web is a failure. You can't force people to provide metadata for everything they do. They'll hate you."


• Some interesting discussion on Web 2.0 and the future of the web.


• Rich text editor for browsers. Not free though.


• Linked data and what it is.


• ThoughtWorks Podcasts (the REST talk was what drew me to it).


• Turtle specification. I've been looking at this for serialization of RDF molecules but it seems that you can't have blank nodes as objects using the nested syntax.


• Semantic Web for bioinformatics.


• Data structure stuff: Linear Bloom Filters, Bloom filters for Spell Checking, Optimal Bloom Filter replacements and scalable btree and B-tries for Disk-based String Management.

You Are Here, Now

• Mammal rise 'not linked' to dinos Perhaps the best part is the beautifully rendered result of evolution for the last 166 million years. Good global warming? "However, the supertree shows that the placental mammals had already split into these sub-groups by 93 million years ago, long before the space impact and at a time when dinosaurs still ruled the planet."


• Guice Talk by Google Listing all the good ways DI makes your code better - and yes testing is the main one, more OO is another, better than service locater (J2EE) etc. Not much new here, except for no XML, for people who have been doing this for a while.


• Another Google talk by the Cyc people referenced in Priming the Pump and Threshold Conditions . With many examples that will be familiar for Semantic Web proponents.


• Closures for Java JSR Scala gets a mentions as does the BGGA proposal.


• Three reasons that REST is not RPC "Being able to do state transition processing at disparate locations is hugely powerful...A single process can span machines offering differing levels of scalability, reliability and security."


• Six of One, a Half Dozen of the Other "Closures vs. objects should really be a koan". I think this was off a reddit post at some stage. Leads to a purely functional OO system in Scheme.

Planet RDF Roundup

• Research Project: Pig Given Yahoo's usage of Hadoop it's good to see them building a query layer on top of it. And it's not SQL - hence the name - it's relationally based (it uses bags and still has DISTINCT) because that scales. Hah! Some of the documentation is gold, "In a conventional database management system, SQL queries are translated into relational algebra expressions, which are in turn translated into physical evaluation plans. Pig Latin queries are already an algebra, so we're bypassing the first layer." It even has nested relations and a flatten operation (which removes the nesting). A good read at "Yahoo Pig and Google Sawzall". Notes that Google's Sawzall looks like Scala.


• REST Compile/Describe & WADL together with I finally get REST. Wow. all link to WADL. In what seems like an age ago, I remember several enterprise architects asking what the REST equivalent to WSDL was. The later has one of the best one liners to describe REST, "state machine as node graph traversed via URI". An example of how to use is give in "REST Describe first working Beta released"


• Stavanger, oil, and the Semantic Web Talks about the "Norwegian Semantic Web Days" which covered things such as the OBO foundary.

RDF is DOOMed and other links

• The Future of the World Wide Web, testimony of Sir Timothy Berners-Lee, via Seth Ladd. Some commentry by Nate Anderson.
• Peak Code "At some point, half of the total lines of code for that platform will be written. The further a platform gets past its peak, the less attractive adding new features to it becomes since there is less and less potential return on investment due to the dwindling number of programs that could benefit from the improvements."
• REST Issues, Real and Imagined False Choice: “High” vs. “Low” REST, Red Herring: The Evils of POST, Red Herring: URI Design, Red Herring: Cookies Are Bad and False Choice: Machines vs. People. Sure to be answered in, "REST Books Galore (Sam Ruby also mentions the recent flood of REST books).
• RDFRoom DOOM rendering of FOAF via Semantic Desktop Workshop wrapup
• What engineering has in common with manufacturing and why it matters "Engineering – software engineering in our case – is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory."
• It’s Not RDF versus Microformats "If your world is limited to business cards, social events and reviews then I can see where you might favour expression in HTML. Humans want to read those things too. But the world is bigger than social networking and there are other types of first-class data that people want to exchange with one another."
• Ruby on Rails IDE comparison. Favours NetBeans.
• The State of Swing Mentions one of the small Java 6 enhancements, SwingWorker.

All Annotations

JSR-311: a Java API for RESTful Web Services?

I am still not so sure what they want to do exactly, but it seems to be based on JRA which has annotations of the form:

@Get
@HttpResource(location="/customers")
public List getCustomers();

For me a more interesting JSR would be one that would standardise the @rdf annotations the way so(m)mer is doing it.

The RESTlet framework was created because:

"I noted the lack of a REST framework in Java. The only project that came close to it was 1060 NetKernel developed by 1060 Research but it had too many features for my needs and I found that the mapping of REST concepts was not as direct as I was expecting."

It seems that annotations are an exceedingly useful tool, especially having used Elmo's annotations of interfaces to generate beans from RDF (link to PDF documentation). Annotating interfaces rather than classes, seems to be the way to go, given that interfaces can represent relationships like multiple inheritance. Elmo was inspired by subject oriented programming that provides a way "to group common behaviours and separate these different roles into unique interfaces and reusable classes." It's especially useful for unplanned extensions (through composition).

Googling for the various projects brought up, Tripresso looking at mapping RDF to OO (including Java, Ruby, Python and PHP projects). If object to relational mapping is the Vietnam of computer science, I wonder what object to RDF mapping is.

See the previous discussion, RDF on Rails ( mentioning ActiveRDF, RdfReactor, etc) and Henry Story's original, Java Annotations & the Semantic Web.

World Wide VB

Two interesting talking points at the moment between Google's AJAX Framework and Continutations. Starting with, Continuations and GUIs, "...Web UIs are drastically constrained, offer a paucity of controls, and enforce a brutally linear control flow; and these are good things. I remember, in the early days, people saying “Once you know how to use one Windows app, you know how to use them all”. Ha ha ha. But you know what? Once you know how to use a browser, you are well on the way to being able to use most Web apps. The best AJAX apps are still very Web-like (as in, the Back button always works); but they’re faster and more responsive and nicer to look at. The worst AJAX apps are like bad Nineties VB."

This linked to: Continuations, cont’d "...there’s no need to drive a continuation bulldozer through your webapp, when a little REST garden spade will work quite nicely (and won’t tear up your lawn in the process). Don suggests that there may be other, more legitimate use cases for continuations outside of web applications, and I have no reason to disagree, but I would like to look at them pretty carefully."

The seed of the continued continuations conversation was, "Will Continuations continue?".

The Google Web Toolkit gets a reasonable overview, "GWT: Googles plain Java AJAX tools". This seems to be a similar approach taken by DWR 2.0 (out since late April) - using Java to write Javascript. DWR 2.0 also supports Jetty's AJAX continuations.

Update: So GWT is not like DWR. With DWR you still create your HTML and Javascript pages directly. With GWT you use widgets and lay them out like Swing - there's no direct access to the Javascript or layout. There is some criticism that this approach is at the wrong level of abstraction. One of the potential advantages is the ability to test drive the Java code and then deploy the Javascript - and hope that there are no bugs in only the Javascript version.

A Link in Time

• Getting more than what you pay for with open source databases. The tale of using a free database, using a commercial one and then putting the free one back. A quote: "There are a lot of companies out there paying dearly for commercial databases (and operating systems for that matter). As far as I'm concerned they might as well be flushing that money down the toilet. Actually, they might be better off. We certainly would have been."


• For the metrically minded, "Two Motivational Metrics for Agile Teams". So as long as you convince people that "Time to Obstacle Removal" and "Obstacles Removed per Iteration" are good metrics.


• The, "I'm sick of the comparison between building and software" rant.


• Martin Fowler has recently updated his "The New Methodology" with half a dozen or so flavours of agile, which one are you?


• Don't Click It for those people with zero button mice. The first example of a gesture to replace a click just seems ridiculously hard.


• Examples of using Chickenfoot for Firefox: Rewrite the Web
  The table sort, how to get a book from the library, simple examples and timely.


• Another REST framework - Restlet.


• Getting stuff done - the quick version


• How not to get a PhD

AJAX and REST

Why I think AJAX breaks REST "The Web is a hypermedia application. According to REST, following a link you should be transferred to a state representation which is associated with a particular URI (in the case of the Web, a URL). As it happens, together with that state representation we may also get some code that our hypermedia document viewer (the browser) executes. Depending on the interactions with the end-user, another program, the environment, etc. the executed code may make use of asynchronous calls to change the represented state that our viewer has loaded. It does so by usually fetching more state, possibly in a REST-friendly way (i.e. HTTP requests). However, during the user-application interactions, the URI remains the same even though the state representation that is rendered on our screens has obviously changed. Now, some AJAX applications may force a change in the URI effectively simulating a state transition but most of the ones I have used do not."

REST is a way to expose services and AJAX is a way to write client software - they can't really effect one another.

AJAX can break the ability to save client state, in exactly the same way that frames do (complete with breaking the back button). AJAX applications may or may not update the URI in the browser to represent the current state it is in, but you can certainly write them so that they do (just like frames).

In a RESTful approach the architecture puts restrictions on the server, not how the client represents its current state:"...each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server."

Also, AJAX - beyond the buzzwords.

Update: Why I think AJAX breaks REST continued "What I did say is that the use of the AJAX approach to building distributed applications, or even just client-side ones, encourages a move away from the REST principles and that those building distributed applications should be aware of that...We just can't call all the good things out there RESTful."

I take REST principles to mean providing URIs to represent the current state they are in. However, I don't see browsers or client side applications as being RESTful or not. Tabs, frames, pop-ups, running code in Flash, Javascript, and applets; all of these things are not represented by the URI in the toolbar.

The only thing that's guaranteed in REST is that a client changes state when it goes to a URI (the representation of the state) on a server. How it represents that state is entirely up to it.

There are good reasons why everything just isn't represented by a URI, but I do think that more things should be. One is space requirements, imagine GMail storing every state that your mail box is in and providing the ability to go back and forward (very Xanadu perhaps).

Things I've Read

* Evangelical Scientists Refute Gravity With New 'Intelligent Falling' Theory related to Boing Boing's $250,000 Intelligent Design challenge (UPDATED: $1 million) and Flying Spaghetti Monster.
* JUnit-Addons and GSBase so at least only two software projects have to reinvent the wheel.
* Non-blocking Data Sharing in Multiprocessor Real-Time Systems "In this paper, we present an efficient non-blocking solution to the general readers/writers inter-task communication problem our solution allows any arbitrary number of readers and writers to perform their respective operations."
* Why I Prefer SOA to REST "The problem is that although it is easy to model resources as services as shown in the example in many cases it is quite difficult to model a service as a resource. For example, a service that validates a credit card number can be modeled as a validateCreditCardNumber(string cardNumber) service. On the other hand it is unintuitive how one would model the service as a resource. For this reason I prefer to think about distributed applications in terms of services as opposed to resources." Now people can just argue about what is intuitive (credit card gateways on the Web existed before SOAP - must have been REST I guess).
* I Need a New Language: Rel? "I want a language for table programming. I think you can write programs in this language that do everything we expect of an application programming language -- building GUIs, reacting to mouse events, listening to sockets -- everything. Don't model your domain as objects. Model it as relations...I can imagine programs that have a relvar (Date's term for a relational variable: essentially a table or a view) for MouseState."
* Package Scoping And Unit Testing "Package scoping particularly shines during unit testing. Some programmers argue that you should only test through the public API. Don't be silly. Limiting your tests to the public API contradicts the spirit of unit testing and subjects you to unnecessary dependency pain. I prefer to isolate and limit the amount of code I test at one time, and test as close to the code as possible." Somewhat related, JSR 277 - Java Module System
* Web as Platform Mash-Ups "There have been a lot of excellent posts and articles this week about APIs, the Web as Platform, web sites as software companies, and so forth..."
* Ruby, Python, "Power" "There are different opinions on the relative power of Ruby and Python. I'm not much more authoritative than other resources (though I'm not less authoritative either; most comparisons between the two languages are flawed). Ultimately I don't believe there are many (any?) places where one language is more "powerful" than the other (and not just in the "they are both Turing complete" sense)"

APIs on REST

* XINS is a technology used to define, create and invoke remote APIs. XINS is specification-oriented. When API specifications are written (in XML), XINS will transform them to HTML-based documentation and Java code for both the client- and the server-side. The communication is based on HTTP.
* Axis 2.0 Support for REST "Axis2 can be configured as REST Cantainer and can be used to send and receive restful web services requests and responses. The REST Web Services can be access in two ways, using HTTP GET and POST."
* REST vs API "The starting point is usually that somebody has an API that is intended to shield the developer from the inner workings of SOAP and perhaps another protocol or three. The person is thinking about adding REST support (generally in the form of removing the requirement for a SOAP envelope and adding support for additional HTTP methods). What can go wrong?"

Objectifying the Web

REST versus Object-Orientation (and a little python) "From my perspective, the concepts of Object Orientation (OO) and REST are comparable. They both seek to identify "things" that correspond to something you can about and interact with as a unit. In OO we call it an object. In REST we call it a resource. Both OO and REST allow some form of abstraction. You can replace one object with another of the same class or of the same type without changing how client code interacts with the object. The type is a common abstraction that represents any suitable object equally well."

REST and Object Orientation via OWL "So the most important aspect of RESTful programming as Benjamin points out is that now all objects are universally nameable and universally accessible. A few simple verbs allow us to create, delete and change the state of these resources. Access Control Lists allow fine tuning of responsibilities for a resource. And OWL gives us the Object Oriented conceptual structure to predict and understand the content of these resources and how they relate to others."

People seem to forget that method calls in Java or whatever can be considered message passing. What could be more OO than REST? GET isn't analogous to "getFoo" or "getBar" on a JavaBean object. The semantics behind GET/POST/PUT/DELETE is better thought of as how you are changing the object (related to Create Retrieve Update Delete (CRUD)). What could be more RESTful than OO?

The Dining Philosophers in REST "...it's trivial to encapsulate transactions into a single atomic exchange, and exposing those encapsulations as first class entities is generally a pretty good idea. And it certainly fits with the REST model of the world. MUCH more so, in fact, than RPC, as it forces one to aggregate those operations in the server design rather than leaving it open to the client to abuse. In fact, I'd even say that doing so is critical to the ability to build workable distributed systems."

Also related "Using RDF to improve Object-First Development".

Bunch of Links

* Too Darned Big to Test - Make it smaller.
* XForms Editor in OpenOffice.org and A First Look at OpenOffice.org 2.0.
* Why REST is Better - Part 3 - Links to Push and Pull Message Delivery in the PSB Architecture.
* Open Source Profilers for Java. Also mentions the free but not open source JFuild.

REST vs the Rest

Web Resources and WS-Resources " Now I can still only really talk from the point of view of first impressions, but it seems to me that the WS-Resource approach seems generally more concrete than the resource abstraction of RDF. I think it likely that WS-Resource constructs could be modelled in RDF. However, the emphasis of WS-Resource is very much on the protocol, so this isn’t really comparing like with like."

"I can see how state can be managed using WS-Resources, but what I having discovered is why the assumption is made that because SOAP++ messaging is usually done statelessly, it has to be that way. State can (and often is) maintained at both client and server sides of communications. If state that is global across client and server is needed then that can be maintained using one of the many reliable messaging protocols possible on top of HTTP."

Agile Services

I'm probably just combining two buzz words to appear like a consultant, but it's more like RDF for Agile Services.

When You Sit Down To Write A Description "...you discover that doing so is unnecessary."

"In a REST-style service, we want an analogy to the self describing hypermedia we have in the HTML scenario. First let's assume we'll use some form of XML as our hypermedia. It's easy to imagine a XML document. Maybe even more machine friendly would be an RDF document -- a bunch of RDF statements. Your client invokes GET on the well known URL of the service, and receives an RDF form. The RDF form describes the names of parameters and how to serialize them. So just as in the user driven HTML case, the client needs no foreknowledge of what the neccessary parameters do, or even what their names are. But we still need an automated "user" to fill out those parameters. Since the RDF form describes the parameters in RDF, your client can map the RDF types of those parameters to elements in its data model. Your client has to "understand" the service's ontology, sure. But that is a one-time mapping of ontology elements to, say, SQL queries."

Follow-up.

Achieving WS Functionality with REST

REST design questions "REST in its now-broadened meaning is easy to explain: pieces of data (likely XML-encoded) sit out there on the web, and you manipulate them using HTTP’s GET, PUT, and DELETE methods..."

"This very simplicity should raise some alarm bells, though. RDF also has an apparently simple data model, but for RDF 1.0, at least, the model turned out to be painfully incomplete, as I found out when I implemented my RDF parsing library. Is REST hiding any of the same traps? "

REST design question #2: listing and discovering resources "The second in my series of REST design questions is how to handle listing and paging, or, in fancier jargon, resource discovery. I prefer concrete examples, so I’ll start with one that I know is flawed and then try to find ways to fix it."

Where's the SOAP?

SOAP is boring, wake up Big Vendors or get niched "Evidence continues to mount that developers can' t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange. It is often described as "lightweight", but its RPC roots keep showing.

Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps--semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined "XML Web Services" calls. Now it seems the Creative Commons is responding to RESTful demand. Or more pertinently-not responding to SOAP demand because there isn't any."

"Whats a web service? Still a great question. But anyone that defines a Web Service using SOAP in the definition is missing out on where the action is. Distinctions between enterprise and "consumer" are breaking down. REST is evidently where that convergence is being played out, not WS-I."

Via Is SOAP a washout?.

Also, Interop is Hard: "If you find that you must use a toolkit to help with generating the contract, I'd recommend a technique that is similar to Steve's customer's: generate WSDL using a foreign toolkit, remove all unwarranted idioms and assumptions, and then try to import the result in the toolkit that you are using to develop the service."

Jon Udell had a very interesting post about Google's new map service (all plain XML/HTTP and XSLT where you want): Google Maps is a web of linked XML documents.

What a MEST

On Interoperability and Tim Ewald's 3 Web Services Stacks "Replacing a world of distributed applications written with DCOM, CORBA, Java RMI, etc with one where they are written using the WS-* protocols is a step in the right direction. I completely agree that it leads to better interoperability across technologies produced by the big vendors who are using incompatible technologies today.

But when your plan is to reach as many parties as possible one should favor simpler Web services technologies like plain old SOAP or just plain old XML (aka POX). Plain old XML doesn't necessarily mean following the principles of REST either."

Intersecting XML threads "What the REST vs SOAP and Doc vs RPC debates miss is the subtle point at which systems become multi-celular. At some point, evolution stopped producing organisms consisting of every bigger and bigger cells, and started producing organisms consisting of multiple differentiated cells. These cells communicate exclusively via message passing."

MEST is already omni-present, if you look for it "As far as I can tell, the basic idea behind MEST is that web services developers should be thinking about message passing instead of RPC calls. I completely agree. But I disagree with the idea that that means there should be one WSDL interface with one operation “ProcessMessage”. There's no need to go there, because we're there already."

Some of the earlier MEST postings were covered in "MEST Architecture".