Together with my colleague Stefan Roock I wrote an article on building architectures in an agile way for the current issue of the German ObjektSpektrum magazine. The article is part of a controversy with Thomas Lieder about how to incrementally build architectures in agile projects.

In the introductory part of the controversy we talk about the basics of agile methods and the goal of keeping a flat cost curve for features over a long period of time. To achieve this goal we need to change and refactor the software all the time. This is an integral part of agile software development. We learned that its not possible to foresee the future and therefore decided to design only the next steps - and refactor, if we learn over time and find better designs if new requirements appear. This is quite clear on the low-level of individual classes and nicely supported by test-driven development and refactoring tools.

If we use the same argumentation for the architecture of a project, the discussions get a lot more controversy. People don't believe that it is easy to change and refactor the architecture of a system incrementally and flexible over time. We found this discussion often times quite unstructured and using the term architecture in various flavors and meanings. To ease the discussion about agile architectures we divide between the basic architectural style and the concrete architecture of a concrete system. Our opinion is that the basic architectural style is hard to change over time (for example changing a system from a standalone-rich-client application into a multi-user app-server-based system could be quite hard). In contrast to this we believe that changing the concrete architecture and structure of a system could be done incrementally and agile over time. This is obviously not true for every application. They need to be build from ground-up for flexibility and change. But how to build a system that is easier to change over time, even on the architectural level?

From our point of view, there are three fundamental characteristics of design you need to remember every day to build flexible architectures: understandable, loosely coupled and free of redundance. There are many well-known design principles that helps you to build such systems. Keep them in mind, build loosely coupled components, think about good APIs between them - and you are on the right track to build flexible applications and flexible architectures.

A few days ago I gave a short talk on Incremental Design at SEACON 2009, a new buzzword-free conference in Hamburg, Germany. Aside of the fact that this was the first conference in my beautiful home town (and only 15min away from home), I enjoyed to meet a lot of people there. I also made up a few slides for my talk, which you can now download as PDF (in German):

• Inkrementeller Entwurf (pdf)

And last but not least I used my new presentation tool called Session Five for the first time. Was absolutely great!

Ich war schon immer ein Freund davon, nicht alles selbst zu erfinden, sondern den Austausch mit anderen zu suchen und Best Practices anzunehmen. Um so mehr war ich erfreut, in der IT-Szene München eine Vortragsankündigung der JBoss User Group München zum Thema “Java API for RestFul Web Services und RESTEasy” zu finden. REST wurde bei uns schon länger als mögliche Schnittstelle für neue Clients diskutiert, ohne daß ich eine Ahnung gehabt hätte wie sich dieses “Protokoll” von den bisher verwendeten WebServices unterscheidet.

Die wichtigste Erkenntnis vorneweg: REST ist kein weiteres Protokoll, um Clients anzubinden sondern ein eigener Architekturstil, der zu einem anderen Anwendungsentwurf führt. Die Referenten Stefan Tilkov und Serge Pagop präsentierten zunächst einmal die Konzepte von Rest, um dann anhand der Implementation von JBoss RESTEasy konkrete Implementierungsbeispiele zu geben. Der konzeptionelle Überblick war prägnant und unterhaltsam und hat mich überzeugt, diesen Architekturstil mindestens prototypisch einzusetzen. Die Beispielsession hätte meiner Meinung nach noch konkreter mit Edit-Compile-Run Zyklen durchgeführt werden sollen.

Bei einem WebService Modell werden die Objekte und ihre Zugriffsmethoden über WSDL/SOAP einem entfernten Klienten zur Verfügung gestellt. Es existieren Tools, um auf Basis der WSDL-Beschreibung clientseitige Stubs zu generieren und dann in der präferierten Programmiersprache auf die Ojekte im Server zuzugreifen. Es wird also das auf dem Server vorhandene Objektmodell mit den angebotenen spezifischen Operationen lokal im Client zugreifbar gemacht.

Ganz anders bei REST. REST wurde von Roy Fielding in seiner Doktorarbeit definiert. REST kann man im wesentlichen durch die folgenden 5 Merkmale beschreiben:

1. Jedes “Ding” bzw. jede Ressource hat eine ID
2. Die Resourcen werden über Links verknüpft.
   Der Server stellt dem Klienten die Verknüpfungen zwischen verschiedenen Ressourcen als Links zur Verfügung. Auch Statusübergänge werden als Link repräsentiert.
3. Es gibt standardisierte Methoden für alle Ressourcen
   • Get
   • Put
   • Post
   • Delete (und einige wenige andere)
4. Jede Ressource kann verschiedene Repräsentationen haben
   Es ist also möglich für verschieden Arten von Klienten unterschiedliche Repräsentationen nach außen zu geben: beispielsweise eine PDF-Repräsentation zum Drucken einer Rechnung und eine XML-Repräsentation zum Weiterleten der Teileliste an den Empfänger. Die benötigte Repräsentation wird zwischen Sender und Empfänger ausgehandelt. Selbst verschieden Versionen einer Ressource-Repräsentation können über diesen Mechanismus nach außen gegeben werden.
5. statuslose Kommunikation
   Eine Grundannahme ist, daß der Server keine Information über den Status des Klienten hält. Der Status eines Serverobjektes kann bzw. muß jederzeit wieder abgerufen werden können. Was der Klient jedoch damit macht, ob er eine URI bereits gelesen hat, ist Sache des Klienten und nicht des Servers. Es  gibt somit einen Ressourcenstatus, der im Server gespeichert wird, und einen Klientenstatus, den der Klient selbst speicher muß. Durch dieses Design kann der Server wesentlich besser skalieren.

Durch dieses einfache Modell,das in der HTTP Spezifikation festgelegt ist, können einheitliche und jedem bekannte Mechanismen für den Zugriff genutzt werden.Außerdem sind auch Fehlermeldungen mit einer festen Bedeutung vordefiniert und es ist möglich, für HTTP vorgesehene Cache- und Load-Balancing Mechanismen auch für den Zugriff auf den eigenen Backend-Server einzusetzen. Nicht zuletzt erlaubt es REST, den KLienten in jeder beliebigen Programmiersprache zu erstellen, für die eine HTTP-Client Bibliothek zur Verfügung steht.

Die REST Schnittstellen werden über Annotationen an bestehende Java Beans hinzugefügt.Die Annotationen beschreiben im wesentlichen den Pfad (die URI) einer Ressource und wie die öffentlichen Methoden mit auf Methoden der Objekte im Server und auf die Parameter dieser Methoden abbgebildet werden. Es bietet sich an, die Annotationen nicht in dem POJO selbst hinzuzufügen, sondern eine Ressourcenfassade einzuführen.

Stefan Tilkov präsentierte noch einen Ausflug zum Thema “asynchronous response handling“um aufzuzeigen, wie man in REST länger laufende Operationen oder Transaktionen modelliert. Auch hier hilft der HTTP Standard weiter: es gibt eine spezifische Antwort “202 accepted” die in einem solchen Fall zurückgegeben werden sollte. Sie zeigt an, daß die Bearbetung nicht abgeschlossen ist.Eine vom Klienten angegebene “Return URL” könnte vom Server aufgerufen werden, um sein Ergebnis zu posten.

Die Entscheidung für REST ändert definitiv die Architektur von Klient und Server, da nicht einfach das vorhandene Objektmodell über ein weiteres Protokoll zur Verfügung gestellt wird.Die wesentlichen Vorteile von REST sind, daß der Server einfach über einen Browser getestet werden kann und daß es einfach aus dynamischen Sprachen wie Ruby, JavaScript oder Python  genutzt werden kann.

Links

1. Fielding, Roy Thomas: Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000
2. Tilkov, Stefan:A Brief Introduction to REST . Online publication, Dec 10, 2007
3. RESTEasy, Online publication
4. Jersey, Online publication
5. Best practices for Web services versioning, Online publication
   Kyle Brown, Michael Ellis, IBM January 30, 2004
6. The REST Statelessness Constraint, Online Publication, Sat, 2009-Jun-13