Softwarearchitektur

Eclipse Summit Europe 2010

Wolfgang Strunk — Thu, 20 May 2010 20:41:31 +0000

Vom 2.-4. November findet wieder die Eclipse Summit Europe in Ludwigsburg statt. Ich bin jetzt zweimal dort gewesen und war beide Male begeistert von der Möglichkeit, mit den Eclipse-Entwicklern und PMC Mitgliedern zu diskutieren, aber auch konkrete Probleme meiner Firma anzusprechen.

Der “Call for Papers” ist noch nicht rausgegangen und daher ist auch noch Zeit, die eigenen Ideen dort zu präsentieren.
Jetzt heißt es, die Mittel für die Konferenzteilnahme einzuwerben.

Jährliches Meeting der GI Fachgruppe Softwarearchitketur

Wolfgang Strunk — Tue, 11 May 2010 18:51:42 +0000

Am 15.+16. July 2010 trifft sich in München die Fachgruppe Softwarearchitektur der Gesellchaft für Informatik. Das ganze ist in diesem Jahr verpackt in eine kleine Konferenz mit dem Titel Software Architectures for the Cloud.

Ich erinnere mich noch deutlich an das Jahr 2004 und das Gründungstreffen des GI-Arbeitskreises Software Architektur. Komischerweise ging es damals in Oldenburg eigentlich nur darum, ein Buch zu schreiben. Es wirkte irgendwie wie abgesprochen und etliche Teilnehmer waren doch etwas überrascht. Das ganze kam mir darüber hinaus sehr akademisch vor und ich habe mich die letzten 6 Jahre deshalb aus den GI Aktivitäten herausgehalten.

Die Agenda für dieses Jahr sieht aber eigentlich recht spannend aus. Ich denke, daß ich in diesem Jahr den Kontakt ‘mal wieder aufnehmen werde, zumal ich Florian Matthes auch persönlich ganz gut kenne.

Software Experts Summit in Munich

Markus Völter — Wed, 07 Apr 2010 18:45:00 +0000

On June 9 there will be a nice little 1 day conference on software engineering in Munich. The speakers are all part of the IEEE Software industry advisory board. Since the board meeting will take place the two days before in Munich, the chair of the board, Frances Paulisch, has taken the chance to do a littel conference "on the side".

The conference, although branded "SIEMENS", is accessible to non-SIEMENS folks. So if you're interested, take a look at the agenda, it does look interesting.

Buchrezension: Stefan Tilkov – REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien

Eberhard Wolff — Tue, 23 Feb 2010 10:24:00 +0000

Ein neues Feature von Spring 3 ist die Unterstützung von REST. Dieser Architektur-Ansatz für verteilte Systeme nutzt HTTP und die Ansätzes des Webs deutlich anders, als man dies zum Beispiel von Web Services gewohnt ist. Wie man technisch REST-Anwendungen implementiert sollte klar sein - eben mit Spring 3. Aber ist bei diesem Ansatz zu beachten?

Genau diesen Bereich deckt Stefan Tilkov mit seinem Buch "REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien" ab. Es enthält eine ausführliche Darstellung des REST-Ansatzes als Architektur und beantwortet daher genau die Fragen, die man bei einem Einstieg in REST hat. Man kann an dem Buch deutlich erkennen, dass der Autor viele Erfahrungen im Bereich Architektur und insbesondere REST gesammelt hat. Er wägt verschiedene Ansätze ab, kommt zu schlüssigen Empfehlungen und betrachtet das gesamte Thema erfrischen unideologisch. Auch die Abgrenzung zu den WS-*-Technologien gelingt so sehr gut und nachvollziehbar. Die zum Teil dann doch spitzen Kommentare finden sich in den Fußnoten und dienen eher der Auflockerung.

Das Buch führt zunächst kurz in REST ein, um dann das Gezeigte durch eine Fallstudie in der Praxis zu zeigen. Dann werden die wesentlichen Elemente (Ressourcen, Verben, Hypermedia, Repräsentationsformate) detailliert erläutert und am Beispiel des Atom-Protokolls praktisch verdeutlicht.

Schließlich geht es um Features wie Sitzungen, Skalierbarkeit, Caching, Sicherheit, Dokumentation und erweiterte Anwendungsfälle, die dann an einer Erweiterung der ersten Fallstudie praktisch gezeigt werden. Dabei wird die Fallstudie komplexer und deckt viele typische Anforderungen im Enterprise-Umfeld ab. Den Abschluss bildet eine Betrachtung zu "Enterprise SOA mit REST".

Insgesamt ist das Buch eine kurzweilige, kompakte und sehr gut gelungene Einführung in REST und auf jeden Fall zu empfehlen.

Wer gleich zugreifen will:

bzw.

REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien

Some Thoughts on Cathedrals and Software Architectures

Martin Lippert — Fri, 11 Dec 2009 09:39:00 +0000

While preparing a talk on module systems and architectures I remembered some old talks I listened to talking about architectures and arguing why an explicit software architect is necessary within professional projects. Many of them used the analogy of building a dog-house versus building a cathedral. For a small dog house, you don't need an architecture. But for the cathedral you do. Hm, agree, but where is the point?

I think the world has changed. Today for most software systems the analogy of building something like a cathedral is no longer a good choice. And I hope that people no longer have a cathedral in mind when designing software. We have learned that building software is a learning process, that requirements change all the time, that we need a short time-to-market, and most of all that we need feedback all the time - and react to this feedback quickly. Agile methods reflect this and allows us to move forward to modern ways of software development.

But our view on architectures need to reflect this. Modern software architectures need to be build for flexibility, for changing requirements all the time, for changing even fundamental layers of our software in a flexible way without causing tremendous costs. Having a cathedral in mind don't help you here. But if you still like the analogy of building real buildings (even though I think this is not always a good analogy to building software at all), you should take a look at some modern office buildings. Maybe they are not as beautiful as some of the old cathedrals, but they are built for flexibility.

But building flexible architectures is not an easy task. We need to build a flexible architecture and at the same time just what we need without designing all possible stuff upfront. Sounds like contradictory goals, eh? Hm, in some way, they are. I think modularity can help you to solve this conflict. Modularity (and I mean modularity on a higher level than individual classes or packages, but more something like Bundles in OSGi) helps you to think about dependencies, coupling, cohesion, and many of these nice design principles. And I think we all agree on having a good, decoupled design makes life easier when things change - and they will change.

Slides from Meet-The-Experts on Architecture

Martin Lippert — Fri, 11 Dec 2009 09:23:00 +0000

Last friday I was invited to give a talk at the Meet-the-Experts event in Solingen. I talked about my view on architectures in an agile world and how module systems drive those architectures for a flexible future. Here are the slides:

How Module Systems Drive Architectures (pdf)

Enjoy!

Über Architekturen und Perfektion

Eberhard Wolff — Fri, 06 Nov 2009 11:49:00 +0000

Wenn ich mir Architekturen ansehen, wie sie typischerweise präsentiert werden, muss ich an dieses Photo denken:

Ein völlig sauber, möglichst quadratisches Gebäude mit rechten Winkeln - das ist es, was man meistens als Ziel für die Architektur präsentiert bekommt. Oder die tatsächliche Architektur des Systems soll wirklich so aussehen. Meistens gibt es da aber dann die sprichwörtlichen "kleinen" Ausnahmen.

In Wirklichkeit erinnern mich die tatsächlichen Architekturen eher an das hier:

Das ist das Spiel "Villa Paletti", zum bekommen bei Amazon. Dabei geht es darum, dass jeder Spieler Säulen seiner Farbe ganz nach oben auf das Gebäude stellen muss, bis es einstürzt. Es gewinnt der Spieler mit den wertvollsten Säulen auf der obersten Ebene.

Wenn man sich die dabei entstehenden Konstruktionen anschaut, sind sie sicher ein Gräuel, wenn man ein Gebäude mit möglichst vielen rechten Winkeln und klaren Strukturen bevorzugt. Und natürlich ist das Ziel einer Software-Architektur nicht, dass sie am Ende einstürzt.

Aber die entstehenden Entwürfe haben auch Vorteile: Auf dem Bild kann man erkennen, dass die oberste Ebene nur von zwei Säulen unterstützt wird. Hier kommt man also mit einem sehr geringen Material-Einsatz aus - und bei einem klassischen Entwurf würde man sicher jede Ebene mindestens mit drei Säulen unterstützen. Es kann also im Laufe des Spiels eine Konstruktion entstehen, die mit weniger Material mehr Höhe erreicht, als dies bei einer im Vorhinein geplanten Konstruktion der Fall wäre.

Die andere interessante Eigenschaft des Spiels ist, dass man ständig evolutionär weiterentwickelt. Das Gebäude umfasst immer alle Bausteine und wird schrittweise "optimiert", also höher. Das ist bei dem Gebäude auf dem anderen Bild sicher nicht der Fall. Dort wird das Gebäude gebaut, es dann irgendwann "fertig" und kann danach eigentlich nicht mehr wirklich verändert werden. Bevor es "fertig" ist, kann man es nicht benutzen. Für Software ist das eine schlechte Eigenschaft, weil man dann die Software nicht ernsthaft weiterentwickeln kann.

Ich bin nun der Meinung, dass "Villa Paletti" eine wesentlich bessere Metapher für Software-Entwicklung ist als das Gebäude weiter oben. Warum?

Software entsteht evolutionär. Es wird ständig weiterentwickelt, angepasst usw - ein klarer, rechteckiger Entwurf kann dabei nicht entstehen.

Selbst wenn ein "sauberer" Entwurf entstehen könnte - das "Villa Paletti"-Modell ist teilweise überlegen, wie man am Beispiel des Material-Einsatzes sieht.

Für die Software-Entwicklung bedeutet das aus meiner Sicht, dass wir uns von den klaren, rechteckigen Entwürfen verabschieden müssen - wir werden sie eh nicht realisieren können. Wenn man es dennoch versucht, landet man bei Stackenblocken, weil man es eben nicht schafft, alles in rechten Winkeln anzuordnen. Zu Stackenblocken gibt es unter http://www.youtube.com/watch?v=QEN5-_93gQg ein sehr sehenswertes Video.

Das bedeutet aus meiner Sicht:

Lebe damit, dass die Architektur nicht perfekt sein wird!

Beeinflusse aktiv, welche Teile architekturell besser und schlechter sind. Wenn nicht alles perfekt sein kann, muss man dafür sorgen, dass zumindest die wichtigen Teile eine gute Architektur haben.

Setze also Prioritäten: Probleme, mit denen man leben kann, sollte man nicht korrigieren. Beispielsweise ist ein sauberer Entwurf kein Wert an sich, sondern er hilft bei der Weiterentwicklung. Ein sauberer Entwurf für einen Teil, den man nicht weiterentwickeln wird, macht daher kaum Sinn.

Entwickel daher die Architektur und die Software evolutionär weiter. Man kann nicht ein sauberes, neues Gebäude bauen - es wird früher oder später wieder umgebaut werden, das muss evolutionär passieren und das Umschalten auf das neue Gebäude wird nicht einfach sein.

ObjektSpektrum-Article on Agility & Architecture

Martin Lippert — Fri, 26 Jun 2009 20:28:00 +0000

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.

Incremental Design at SEACON 2009

Martin Lippert — Fri, 26 Jun 2009 09:08:00 +0000

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!

REST: ein Architekturstil und kein weiteres Protokoll

Wolfgang Strunk — Tue, 09 Jun 2009 21:55:33 +0000

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:

Jedes “Ding” bzw. jede Ressource hat eine ID
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.
Es gibt standardisierte Methoden für alle Ressourcen
- Get
- Put
- Post
- Delete (und einige wenige andere)
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.
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.

Best practices for Web services versioning