Web Architecture at JAX San Jose

Web Architecture at JAX San Jose

Jessica Thornsby

“The architecture of the Web is one of the most important reasons for its success.”

Brian Sletten is hosting the Web Architecture track at the upcoming JAX San Jose conference, and will also deliver a session on ‘Webs of Data: The Future Starts Now.’ In this interview, we asked him about his aim when creating the Special Day, his session on the adoption of REST, and his opinion of JavaScript.

JAXenter: The Web Architecture Day will examine a bunch of architectural elements for web applications and will feature five talks on this subject. What was your aim when creating the Web Architecture programme?

Brian Sletten: While most developers clearly understand “The Web”, it isn’t clear to me that they have thought much about why it works and where it will take us next. The architecture of the Web is one of the most important reasons for its success. I wanted to highlight fundamentals that aren’t always well understood and trends for the future. We will explore how the ideas generalize to Webs of Data and how Identity creeps into the architecture in a decentralized way. I also wanted to contrast these uses with scenarios where the standard architecture does not work as easily or well. This includes handling massive amounts of data in high volume scenarios. As a track, “Web architecture” is rich with possibilities now and in the future. It should help developers who spend their lives thinking about objects and functions tackle bigger concepts.

JAXenter: You will talk about the adoption of REST and the impact it has on web architecture. What exactly does this session cover?

Brian: The concepts of REST were largely reverse engineered from the Web to provide a theory of architectural style. It is horribly misunderstood by people who think it is simply an “easy” way to do Web Services or some kind of reaction to SOAP. On the contrary, it is an approach to help us build networked software systems that demonstrate properties of scale (up and down!), flexibility, evolvability and generality among others. What is less well understood is that this is also a gateway toward a perspective where information has identity and the freedom to change form at the whim of the consumer. Once we adopt this perspective, we are able to create Webs of data that mimic the fluidity and extensibility of much of the world around us. Information doesn’t generally have boundaries and we lie to ourselves and lose information when we try to shove it into static schemas and object models. We also ignore the fact that at any given time we are unlikely to have all the information we need. It will come to us through Web, through documents, through new data sources and we need a model that allows us to accumulate this content gradually and in real time. This talk will highlight the specific ways that the Web and REST and the Semantic Web collaborate to fulfil this vision.

JAXenter: JavaScript is currently facing a renaissance and this is changing the general expectations of the user. Are these new expectations changing the way we define web architecture?

Brian: JavaScript, like any technology, has its uses and abuses. It is not fundamentally a problem for Web architecture on the client. In fact, in Roy Fielding’s thesis, he highlights as optional the ability to have code-on-demand capabilities like JavaScript and other languages as part of the hypermedia payloads that are returned to push processing locally. There is a cost to establishing TCP-based connections and if decisions can be made on the client without incurring that cost, it is a fine thing to do. Those decision may also reach back to the server as necessary to fetch or update information resources. As long as the JavaScript (by way of its developers) understands the Web and the idea of information resources, the two can live happily together. Many of the user interface-related uses of JavaScript will be affected by the developments in HTML 5 such as drag and drop, input validation, etc., but it remains a key part of responding to messages, interacting with the user, etc. It is natural for developers to want to work in the same language for both client and server implementations to avoid context switching. When the journey was from the server to the client, we saw technologies like GWT. As developers of more traditional Web applications do more on the server, things like node.js appear. And, as we push data back and forth between these systems, it becomes convenient to use a serialization form like JSON. The key thing to remember is that the Web (both public and private aspects of it) are so much more than end points for particular applications, however. In that reality, most JSON-based serializations don’t currently handle term conflict or different structures or other complexities that arise when you have to think beyond your own needs. This is why the concept of content negotiation is important and everything can’t or shouldn’t just be JSON.

Inline Feedbacks
View all comments