J and I and Me
2007-09-26
  JAOO: The new guardian.co.uk (Matt Wall, Guardian, Erik Dörnenburg, Thoughtworks)
Guardian Unlimited ist eine der ersten und größten Zeitungs-Web-Sites in Europa. Ursprünglich war die Site mit TCL, Perl, Apache usw. gebaut und sehr schwer zu ändern. Sie haben dabei statt einem hierarchischen Ansatz einen Tag-basierten Ansatz gewählt. Dadurch kann man Seiten mit Artikeln erzeugen lassen, die bestimmte Worte enthalten.

Die Implementierung basiert auf einem Java Open Source Stack. Spring 2.0 wird genutzt. Spring dient auch und vor allem als Integrations-Plattform der verschiedenen Technologien. Dann wird noch Hibernate 3, Velocity 1.5, YUI/JSON, EHCache, ROME, C3PO etc. Der Resin-Web-Server wird als Produktivumgebung genutzt und entwickelt wurde auf Jetty. Sie haben auch Ruby on Rails evaluiert, aber hatten damals nicht das Vertrauen in diese Plattform.

Als Design-Ansatz wurde Domain Driven Design (DDD) genutzt mit dem Ziel einer klaren und expliziten Modellierung der Domäne. Trotz der scheibaren trivialen Domäne - CMS ist ja eigentlich ein Thema für Standard-Software - gab es eine Menge spezifischem Business-Code. Vor allem das DDD-Prinzip der Ubiquitous Language wurde genutzt, also die gemeinsame Sprache im gesamten Projekt, die sowohl von den Nutzern, Entwicklern und auch im Code genutzt wird. Dadurch wird die Domäne auch im Code wirklich abgebildet.

In dem Projekt haben die Entwickler einen eigenen Aspekt gebaut, der bei einer Änderung an der Site auch gleich den Cache invalidiert. Dabei hängt sich der Aspekt an die Transaktions-Verwaltung, so dass beim Beenden der Transaktion auch dei Objekte aus dem Cache entsprechend entfernt werden. Hier sind man den Power von Spring und Spring AOP.

Ein wichtiges Problem ist natürlich Performance. Der Guardian hat im Schnitt 150 Millionen Hits pro Monat, wobei es sehr unterschiedlich viel Belastung gibt und vor allem die Lastspitzen sind das Problem - man denke nur an 9/11. Alle Seiten werden dynamisch erzeugt. Sie nutzen EHCache für Hibernate Objekte und für HTML-Komponenten. Die Hibernate-Objekte tauchen recht schnell im Cache auf, weil viele Seiten dieselben Objekte verwenden. Bei einem reinen HTML-Cache würde das deutlich länger dauern. Ein Server hat nach ungefähr 4 Minuten einen voll funktionsfähigen Cache. Außerdem machen sie in Bezug auf den Prozess Performance-Tests und ein einfaches Design. Auch beim Cache dominitert Einfachheit: Sie nutzen EHCache, der einfach ist und gut verstandende Konfigurations-Parameter hat.

Zuvor lief die Seite auf Vignette und TCL. Dadurch waren die Seiten mit URLs ausgestattet, wie http://www.guardian.co.uk/story/0,,125425,0.html . Das neue System hat URLs wie http://www.guardian.co.uk/news/iraq/2007/06/28/cabinet . Die alten Bookmarks sollten aber weiterhin funktioniere. Das ist notwendig, weil 30-40% des Traffics auf alte Seiten geht, also von alten Bookmarks kommt. Dazu haben sie mit Apache ein System gebaut, dass die alten URLs auf die neuen URLs abbildet. Sie nutzen mod_asis dafür und schicken den Inhalt eines Files auf der Platte als Antwort. Dieses File enthält dann das Redirect - ein recht einfacher Ansatz.

Der Talk zeigt recht deutlich, wie man sehr große Sites mit Technologien wie Spring implementieren kann. Dabei bekommt man auch sehr gute Performance hin - mit relativ "normalen" Ansätzen. Und man kann mit AOP dann auch interessante Features implementierten - wie zum Beispiel das Cache-Handling.

Labels: , , , , ,

 
Bookmark and Share
  JAOO: Help! Which web Framework should I use? (Alef Arendsen, Interface21)
In dieser Session gab mein Kollege Alef Arendsen eine Übersicht über Web Frameworks. Da Alef wie ich auch für Interface21 arbeitet, ist er natürlich voreingenommen.

Er zeigte erstmal Servlet-Code, wie er 1997 war. Dann JSPs als nächster Schritt, dann die Trennung zwischen View und Controller. Und dann kam Struts, das diesen Ansatz ebenfalls implementiert. Und das war dei Evolution nur bis 2001. Und bis heute (2007) ist noch eine ganze mehr Menge an Frameworks gekommen. Also: Welches soll man benutzen? Die typische Berater-Antwort: Das kommt darauf an...

Es gibt viele nicht-technische Aspekte, die man beachten muss:


Technisch gibt es unterschiedliche Aspekte, und die Frameworks eignen sich für unterschiedliche Themen. Dabei geht es vor allem darum, die rechte Abstraktionsebene zu finden. Es gibt eben keine Evolution von Struts zu JSF, es sind zwei unterschiedliche Ansätze.

Nehmen wir als Beispiel eine Anwendung mit einem zustandsbehafteten Workflow. Das Beispiel ist ebookers.com, bei dem man Reisen buchen kann. Soetwas kann man als einen Ablauf bzw. Workflow modellieren. Dazu kann man Spring Web Flow nutzen. Man kann dann den Ablauf in Eclipse grafisch modellieren. Dabei ist das Zustands-Management vollständig transparent und wird einfach vom Zustands-Automat ausgeführt. Man kann auch Teile des Ablaufs wiederverwenden und man zum Beispiel den Back-Button besser unterstützten. Allerdings muss man dazu den Zustand in der Http-Session, in der Datenbank oder auf dem Client speichern. Dabei werden Ressourcen verwendet, was die Skalierbarkeit beeinflusst.

Als Beispiel für eine zustandslose Anwendung zeigte er ilse.nl, die zweitgrößte niederländische Suchmaschine. Sie ist vollständig mit Spring MVC implementiert. Der Betreiber dachte zuerst, er könnte die Anwendung nur mit C++ implementieren. Ein Trick hier war, die Views mit SAX zu rendern und die Anwendung vollständig zustandslos zu implementieren. Für die Anwendung werden 3 Maschinen für das Frontend genutzt und 2 für das Backend. Eine ähnliche niederländische Seite benötigt anscheinend 400 Maschinen. Die letzteren haben allerdings einen zustandsbasierten Ansatz.

Was ist mit zustandsbehafteten Modellen? JSF hat ein limitiertes Navigations-Modell, weil es keine Navigations-Regeln gibt. Also muss man ein Framework wie Spring Web Flow nutzen, um das zu JSF hinzuzufügen. Diese Regeln kann man in XML (oder auch in Java) definieren. Alef zeigte dann ein Beispiel für einen Flow, der sogar Ausdrücke für die Steuerung des Ablaufs enthielt.

Google Web Toolkit hat einen ganz anderen Ansatz. Es kompiliert Event-Handling-Code, der in Java geschrieben ist, zu JavaScript, der dann im Web-Browser ausgeführt werden kann. Eine Integration zum Beispiel in Spring Web Flow gibt es noch nicht, aber darüber wird zumindest nachgedacht. Das Programmiermodell von GWT ähnelt einem traditionellen GUI-Modell wie AWT oder Swing.

Bei Struts, Spring MVC und Struts 2 hat man ein Request/Response-orientiertes Modell, das man allerdings durch Spring Web Flow ergänzen kann - wenn es notwendig ist.

Ein weiterer interessanter Gedanke: Sollte die HttpSession vielleicht durch Zustand entweder auf dem Client oder dem Server abgelöst werden? Immerhin ist die Http-Session eigentlich nur ein Hack, um ein zustandsloses Protokoll mit Zustand zu versehen.

Aber weiter mit dem Vergleich: JSF speichert die Zustand der Komponenten in der Session, was eben die Skalierbarkeit negativ beeinflusst. Dependency Injection und Navigation kann zum Bespiel durch Spring und Spring Web Flow ergänzt werden. Spring Web Flow speichert den Zustand auf dem Server - entweder in der Session oder in der Datenbank. GWT hingegen nutzt den Client für den Zustand. Der Zugriff auf den Server ist explizit, so dass man merkt, was man tut. Das ist gut, weil Remote Zugriffe eben wesentlich langsamer sind als lokale Aufrufe. Allerdings hat es keine Lösung für Dependency Injection - und es gibt noch keine Integration mit Spring. Natürlich kann man Spring immer noch auf dem Server nutzen. Struts, Spring MVC und Struts 2 haben keine eigene Features für Zustand - außer der Session. Dependency Injection kann man zum Beispiel durch Spring "nachrüsten". Diese Frameworks eignen sich also vor allem für zustandslose Anwendungen.

Was ist also mit Templating oder GUI-Design? Bei GWT kann man das HTML nicht mehr wirklich ändern oder gar von einem Designer ändern lassen - man kann allerdings CSS zum Anpassen des Design nutzen. Mit JSPs kann man Tag Libraries nutzen. AJAX muss man dann aber selber irgendwie mit JavaScript bauen. Da HTML-ähnlich ist, kann man es eher vpn Designer bearbeiten lassen. FreeMarker oder Velocity ist im Prinzip ähnlich. JSF ist deutlich anders. Es bietet auch Chancen für Anbieter von Komponenten. Man sollte es auf jeden Fall mit Facelets nutzen. AJAX ist durch einige Erweiterungen wie z.B. Spring Faces, IceFaces etc. integrierbar.

Ingesamt ein ganz gute Überblick - und die Session war auch sehr gut besucht.

Labels: , , , , ,

 
Bookmark and Share
  JAOO: Keynote Matt Thompson (Sun)
Jede Woche gibt es 30 Mill neue Leute am Netz - das beinhaltet Mobil-Telefone und Fernseh-Netze etc. Sun macht Geld durch die Infrastruktur. Seiner Meinung nach geht es von Terminal Anwendungen mit viel Server-Anteil über Client/Server-Anwendungen mit mehr Client-Anteil über Web Applikationen hin zu Rich Internet Applications, die wieder etwas mehr Client-Anteil haben. Und dann gibt es Integrated Rich Clients. Dabei wird weniger Code geschrieben und mehr Kollaboration zwischen Entwicklern. Diese Rich Clients sind das erklärte neue Ziel von Sun für Java.

Die Entwickler beeinflussen die Technologie-Auswahl in den Unternehmen und sind daher sehr relevant für Sun - daher sind sie auch auf dieser Konferenz..

Es gab dann eine Demo einer Anwendung auf einem Handy. Die Anwendung kann eine Karte zeugen. Dann gab es eine Dem der Sun SPOTs, Das sind kleine programmierbare devices, siehe dieser Link. Damit kann man einige coole Sachen machen, die auch zum Beispiel Geräte steuern können.

Nach der Demo ging es dann mit Folien weiter. Ruby war ein Thema - Rails funktioniert und die bisher größte Ruby on Rails Anwendung auf Glassfish deployt werden.Spring FX war natürlich auch ein Thema und die neue Consumer Runtime ebenfalls.

Da ich noch einen Termin hatte, habe ich den Rest der Keynote nicht gesehen - es ist aber klar, dass Sun das Thema Java auf dem Client ernst meint.

Labels: ,

 
Bookmark and Share
2007-09-25
  JAOO: Grails: Spring + Hibernate reinvented. (Graeme Rocher, Skills Matter)
Graeme ist CTO bei Skills Matter, eine Training-Firma in Großbritannien, und leitet den JSR für Groovy.

Grails ist inspriert von verschiedenen Frameworks. Es basiert auf Groovy, Spring, Spring MVC, Hibernate, Quartz, Sitemesh, Embedded Jetty and HSQLDB. Und natürlich basiert es damit auch auf Java. Damit ist es ein Full Stack. Groovy ist dabei sowohl Java-freundlich und hat auch viele Features - andere Sprachen auf der JVM bieten nur entweder das eine oder das andere. Groovy ähnelt Java, Java-Code kann gültiger Groovy-Code sein. Aber wirklich nützlich ist es, wenn man mehr Rücksicht auf Groovy nimmt. Durch die Ähnlichkeit zu Java wird die Migration zu Groovy deutlich einfacher. Und es benutzt die vorhandenen APIs und Frameworks.

Man kann mit Grails ein Anwendungs-Skelett generieren lassen. Es enthält Controller, Domänen-Objekte usw. Die kann man dann in einem integrierten Web-Server starten. Es gibt auch eine passende Konfiguration und man kann recht einfach neue Controller integrieren. Es gibt ein automatisches Data Binding von den Request-Parametern zum Objekt, so dass man die Parameter nur einfach als Argument übergeben muss, was das Data Binding deutlich vereinfacht. Auch kann man die Objekte sehr leicht als JSON oder XML rendern. Ebenfalls kann manmit dynamischen Findern Datensätze suchen lassen.

Seiner Meinung nach ist die Java-Persistenz zu komplex. Und es gibt bei Java zu viele XML-Konfigurationen. Grails löst das bei Persistenz dadurch, dass es ein eigenes Hibernate-Mapping definiert. Es heißt GORM. Dadurch werden Methoden wie save() usw. automatisch implementiert. So hat man die Vorteile von Hibernate und die Transaktionen von Spring. Die Criteria-API von Hibernate wird auch unterstützt. GORM funktioniert mit Groovy- und Java-Objekten.

Auch die Implemeniterung von Tag-Libs wird einfacher - und es gibt einige vorbereitete Tag-Libs. Dabei werden Closures verwendet, was die Programmierung wesentlich einfacher macht.

Ebenfalls gibt es eine eigene DSL, um URLs auf Controller und Actions abzubilden. Dabei kann man beispielsweise Teile der URL automatisch in Parameter umwandeln lassen und verschiedene Controller oder Actions abhängig von der URL anstoßen lassen. So sind REST-mäßige URLs sehr leicht implementierbar.

Ebenfalls gibt es Unterstützung für die Spring Scopes und für Spring Web Flow. Dabei gibt es für Spring Web Flow auch eine eigene DSL. Dadurch gibt es eine Alternative zu der XML-Konfiguration von Spring Web Flow. Zusammen mit der Untestützung für Scopes kann man auch leicht Objekte im Flow speichern.

Es gibt auch eine Menge an Plug-Ins für Erweiterungen, die von einer größeren Anzahl an Committern betreut wird. So gibt es Integration für XFire (SOAP) und Suchen mit Lucene und Compass. Es ist sehr einfach, dadurch Services mit verschiedenen Technologien zur Verfügung zu stellen. Interessant auch, dass eine Spring Security Integration gibt.

Labels: , , , ,

 
Bookmark and Share
  JAOO: Painless Persistence with Active Record (Oren Eini & Hamilton Verissimo)
Es geht in diesem Talk um das Castle Projekt, ein .NET Open Source Projekt. Es soll die Entwickler - wenig überraschend - produktiver machen und besteht aus Active Record (Persistenz), Mono Rail (Web) und Windsor (IoC Container). Und dann gibt es noch einige weitere Projekte unter diesem Dach. Der .NET-Ansatz ohne Active Recrod ist, einfach die Tabellen in die Anwendung zu ziehen, was zu "Spaghetti Persistenz" führt. Ein anderer Ansatz ist Ad-Hoc-Persistenz, bei der man das Tool verwendet, dass man gerade in die Finger bekommen hat. Oder der Database Adminstrator baut die Persistenz, was zu jeder Menge Overhead wie Stored Procedures führt und man kann die Persistenz nicht wirklich selber ändern. Oder man baut ein Data Mapper von Hand - was auch nicht eine reine Freude ist. Oder man nutzt ein O/R Mapper.

Castle Active Record legt den Fokus auf Einfachheit. Ein Active Record ist ein Klasse, die neben den Domänen-Daten auch Operationen für die Persistenz enthält. Konkret implementiert man dann eine C#-Klasse und annotiert die einzelnen Properties und die Klasse. Dann muss man noch von einer Oberklasse erben. Daraus wird auch das Schema erzeugt. Man kann mit annotierten Referenzen dann auch relationale Beziehungen aufbauen. Das geht sowohl mit 1:n als auch mit n:m-Beziehungen.

WIe bekommt man in dieses Modell jetzt Anfragen? Hier verwendet Active Record HQL von Hibernate. Was ich überraschend finde, da man auch auf LINQ so etwas hätte aufbauen können. Man kann auch Anfragen nach Instanzen anhand den Werten ausführen, also alle Kunden mit einem bestimmten Namen. Außerdem gibt es geschickte Anfragen wie Where.User.Name.isNotNull oder Where.User.Name.Like("ore",MatchMode.Start) etc.

Vererbung wird auch unterstützt - NHibernate wird dabei genutzt. Und auch Validierung wird unterstützt. Die basiert auf Annotationen, die man an die Property hängt. Ist es auch möglich, statt einem Active Record ein Repository zu bauen entsprechend dem Domain Driven Design von Eric Evans. Dabei werden dann die Persistenz-Operationen in einer eigenen Klasse implementiert. Lazy Loading und Caching wird auch unterstützt. Es git auch ein Query-Analyser. Einige esoterische Mappings werden nicht unterstützt und es gibt keine Unterstützung für Stored Procedures für CRUD-Operationen.

Labels: , , , , ,

 
Bookmark and Share
  JAOO: Democratizing the Cloud (Erik Meijer, Microsoft)
Sein Albtraum ist, dass Ray Ozzie ihn fragt: "Was ist die Story für Cloud-Anwendungen?" Traditionell gibt es 3-Schicht-Architekturen, die manchmal komisch aussehen. Er will das ändern - und dabei die irreversiblen Entscheidungen möglichst spät treffen. Außerdem würde er nicht gerne was neues erfinden, sondern bei dem bekannten bleiben.

Der Nutzer will die größten Probleme mit möglichst wenig Problemen lösen - dadurch wird eine Technologie erfolgreich, nicht durch die Coolheit oder so. Sein Beispiel ist Validierung, die sowohl auf Server als auch auf dem Client läuft. Und das soll mit Annotationen funktionieren. Er zeigte dann eine Demo, wiie man mit AJAX ein Dictionary implementieren kann. Das ganze ist dann transparent verteilbar. Dann muss man nur noch neben IL von .NET auch noch JavaScript unterstützen und schon hat man das überall lauffähig. WIe macht man Grafiken? Für 3D muss man nur Dreiecke zeichen können. Und die kann man mit HTML-DIVs bauen. Und damit kann man den berühmten Teapot animieren - allerdings hat er das nicht live gezeigt. Da auch der MS SQL Server IL kann, kann man dann Abfragen verteilen usw. Dadurch wird dann Verarbeitung in einer Cloud von Computern recht einfach - und darum ging es in diesem Talk.

Labels: ,

 
Bookmark and Share
2007-09-24
  JAOO: Introduction to Spring.NET
Wieder mal JAOO in Dänemark. Die erste Session, die ich mir angetan habe, ist "introduction to Spring.NET" von Mark Pollack, meinem Kollegen und Spring.NET Committer.

Spring.NET unterstützt wie Spring/Java auch Dependency Injection, AOP und Support Libraries für andere Libraries sowie Unterstützung für Integrations-Tests. Damit ist auch die Architektur analog mit Web-Layer, Service-Layer und DAO-Layer. Er erklärte dann DI und den Sinn von DI. Außer, dass es <object> statt <bean> heißt, ist es dasselbe wie bei Spring/Java. Ähnlich auch die IObjectFactory statt BeanFactory oder IApplicationContext. Sogar die Konfiguration eine Web-Anwendung ist vergleichbar.

Spring.NET hat auch eine Expression Language, mit der man Properties komplexe Ausdrücke zuweisen kann oder einfache Code-Schnipsel. Von Java können Features wie Annotationen oder Skript-Sprachen-Unterstützung übernommen werden.

ASP.NET wird auch unterstützt und Spring.NET bietet dort Dependency Injection an. Analog auch ADO.NET mit der Unterstützung für Transaktionen, einer technologieunabhängigen Exception-Hierarchie usw. Auch deklaratives Transaktions-Management gibt es. Und auch bei Spring.NET werden verteilte oder lokale Transaktionen unterstützt. Und natürlich gibt es dann auch ein AdoTemplate, mit dem man den Code für den Zugriff auf Datenbanken implementieren. Vor allem sind die Oberklassen zum Beispiel für StoredProcedures ein Vorteil.

Bei AOP kommt nicht AspectJ zum Einsatz, sondern es gibt zum Beispiel eien DSL für das Exception-Handling, die auf der Spring Expression Language basiert.

Im wesentlichen sind also alle Features vorhanden und die Konzepte sind sehr ähnlich. Und es gibt schon einige Anwender wie Siemens oder Oracle Consulting in Israel.

Labels: , ,

 
Bookmark and Share
  DAO tot?
Es gibt hier eine Diskussion, ob das DAO tod ist. Die Argumentation läuft darauf hinaus, dass das ursprüngliche J2EE-DAO-Pattern das Ziel hatte, die Unterschiede zwischen verschiedenen Persistenz-Technologien zu verbergen. Die Argumentation ist nun, dass mit JPA die API geschaffen wurde, die so mächtig ist, dass man die unterschiedlichen Technologien nicht mehr verstecken muss. Dazu kann man technisch erstmal einwenden, dass JPA beispielsweise gegenüber Hibernate ein Rückschritt ist, denn wichtige Features wie Filter oder UserTypes existieren nicht - aber auch weniger wichtige Features wie die Criteria API sind nicht vorhanden. Ich würde daher argumentiere, dass man mit JPA nicht weit genug kommt und man sich nicht nur auf diese Technologie verlassen kann - also hat das DAO seinen Sinn schon technisch nicht unbedingt verloren.

Noch interessanter ist diese Aussage vor dem Hintergrund der Architektur. DAOs sind eben nur eine Möglichkeit, auf eine Datenbank zuzugreifen. Wenn man Fowler's Buch "Paterns of Enterprise Application Architecture" zu Rate zieht, findet man zahlreiche Alternativen, von denen hier einige genannt seien:

WIe man sieht, ist das DAO nicht alleine auf der Welt. Daher stand es schon immer in Konkurrenz zu anderen Ansätzen. Der Griff zum DAO ist also eine Design-Entscheidung - die allerdings manchmal eher einem Reflex als einer Entscheidung zu entstammen scheint.

Ich würde allerdings argumentieren, dass die Implementierung einer Persistenz-Schicht nach dem DAO-Paradigma oft sehr sinnvoll ist. Besonders interessant ist in diesem Zusammenhand Eric Evans Buch über Domain Driven Design. Das Buch steht nicht im Verdacht, technik-zentriert zu sein. Also sollte es sich nicht dadurch beeindrucken lassen, dass es nun mit JPA eine neue Technologie hibt. Dennoch führt es aus, dass man im Design einer Anwendung ein Repository einführen kann. Das Repository ist ein Zugang zu den Objekten, die bereits existieren, im Gegensatz zu einer Factory, die neue Objekte erzeugen soll. Es kann Daten aus einer Datenbank oder aus einem Legacy-Anwendung auslesen und daraus Objekte erzeugen. Damit ergibt sich schon aus fachlichen Gründen der Bedarf nach einer Art DAO, das den Zugriff auf die persistenten Daten ermöglicht. Meinem Gefühl nach legt das Repository den Akzent vor allem auf fachlich motivierte Anfragen, während viele der Funktionalitäten des DAOs eher einfache Operationen wie Speichern umfasst.

Ein weiterer guter Grund für DAOs oder zumindest eine separierte Persistenz ist, dass man damit die Anwendung sehr leicht testen kann - man kann sehr leicht statt dem eigentlichen DAO in einem Test etwas verwenden, was bestimmte Testdaten zurückgibt. Das funktioniert dann ohne Datenbank und die üblichen Schwierigkeiten beim Testen mit Datenbank - Aufbau der Datenbank, Bilden von Testdaten und Aufräumen der Datenbank nach dem Test.

Vielleicht ist ein Grund für die Verwirrung das ein DAO eben nicht in erster Linie eine einfachere Migration von einer Persistenz-Technologie zu einer anderen erlaubt, sondern andere Vorzüge hat. Ich halte es jedenfalls immer noch für eine gute Idee, wenn man auch mit dem Begriff Repository vielleicht weiter kommt.

Ein letzter Hinweis: Vielleicht ist die Diskussion doch technisch begründet. Immerhin kann EJB 3 einen EntityManager nur in eine Session Bean injizieren. Damit hat man nur die Wahl die DAOs also Sessions Beans zu implementieren oder den EntityManager per Hand in die DAOs zu injizieren oder dort auf Dependency Injection zu verzichten. Vielleicht erscheint daher bei EJB 3 ein Ansatz ohne DAOs erstmal eleganter. Spring ermöglicht DI eines EntityManagers für jede Spring-Bean und verwendet dabei die in JSR 220 standardisierte @PersistenceContext-Annotation.

Labels:

 
Bookmark and Share
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff