magazinJava • Architekturen • SOA • Agile

Geo-Tutorial: Laufen im Kreis »37

www.javamagazin.de

Cloud ComputingClouds jenseits des Standards mit BASE »76

Employer BrandingDer Kampf um die besten Fachkräfte »90

CD-INHALT

Österreich € 9,80 Schweiz sFr 16,80Deutschland € 8,50 5.2010

Alle CD-Infos ab Seite 3

Neue Sprachen für die JVM

Video von der W-JAX 2009

in voller Länge

EuropEan HEadquartErs - LangEn, gErmany

LifEray gmbH — robErt - boscH - strassE 11, 63225 LangEn, gErmany

tEL: +49 - (0) 6103 - 3018570 • fax: +49 - (0) 6103 - 3018571

now get the best of both worlds.Liferay Enterprise Edition gives you all the benefits of open source with the stability, security, and reliability of an enterprise subscription.

and with version 5.1, get the latest in soa, social networking, and collaboration technology, all at a fraction of the cost of oracle® or ibm®.

for more information, email us at sales@liferay.com.

you spoke. We listened. you spoke. We listened. yintroducing Liferay Enterprise Edition.

Liferay 5.1 Enterprise Edition

Maintenance Subscription2.950 Eur/server/year

Platinum Support (24x7)19.950 Eur/server/year

compare oracle® Webcenter suite: 125.000 Eur / processor, support 27.500 Eur / yr, as of 6 / 2008

CDinkl

.

Java Magazin 5.2010

Build-Tools im

Vergleich Silverlight für Java

Twitter m

it Lift Google M

aps und Android Cloud Com

puting

JAVA

Mag

Google Maps und AndroidStandortbestimmung »101

Twitter mit LiftMarke Eigenbau »52

Silverlight für JavaGeht das? »45

Alle Infos im Heft

Build-ToolsMaven, Ant und Gradle im Vergleich »60

„Maven 3 wird das beste Maven” Interview mit Jason van Zyl »70

WEITERE INHALTE

Gradle 0.8

Maven 2.2.1

OpenLayers 2.8

Moonlight

Ant 1.8

EclEmma

Apache UIMA 2.3

Apache PDFBox 1.0

Cloud BASE: Internetanwendungen jenseits der Standards

76 www.JAXenter.dejavamagazin 5|2010

ittwoch, der 29. Juli 2000 – wel­che Erinnerungen verknüpfen Sie mit diesem Tag? Vielleicht

war es ein schöner Sommertag, den Sie mit Partner(in), Familie, Freunden ver­bracht haben, vielleicht war es aber eher

düster und gewittrig oder es hat wie aus Eimern geschüttet ...

Der 29. Juli 2000 war jedenfalls ein geschichtsträchtiger Tag für das Web. Beim ACM Symposium on the Principles of Distributed Computing (PODC) hat Eric Brewer an diesem Tag eine Keynote mit dem Titel „Towards Robust Distributed Systems“ gehalten [1]. In diesem Vortrag hat er die Emp­fehlung ausgesprochen, im Umfeld zunehmend verteilter Systeme und webbasierter Anwendungen bei den Bemühungen um Datenkonsistenz eine gewisse Umsicht und Vorsicht walten zu lassen. Denn bei verteilten Systemen

stehen Availability und Consistency der Daten in Konkurrenz.

In seinem Vortrag führte Eric Brewer die Unterscheidung zwischen ACID und BASE ein. Dabei steht ACID für Atomi­city, Consistency, Isolation und Durabi­lity – diese Abkürzung ist im Umfeld von Datenbanken und Transaktionen bes­tens eingeführt. Die Abkürzung BASE bedeutet Basically Available, Soft­state und Eventually consistent. In der Ge­genüberstellung von Säuren und Basen verbirgt sich gleichzeitig ein eleganter Hinweis auf die Verwendung der Ab­kürzungen. Dahinter stehen nicht scharf abgegrenzte oder auch nur abgrenzbare

Jumping Jack FlashCloud Computing erobert längst die Herzen und Budgets von Managern und IT-Bereichen. Kommt da wirklich etwas Neues, oder etikettieren wir nur wie-der einmal Produkte und Initiativen um? Ist Cloud Computing mehr als nur die Verlängerung der Innovationen rund um Virtualisierung, Standardisierung und Automatisierung? Wir lernen in diesem Artikel die Architekturklassen ACID und BASE zu unterscheiden, warum und wie uns das CAP-Theorem als Architekten eindeutige Entscheidungen abverlangt und schauen in die Wiege des Cloud Computings sowie hinter die Kulissen großer Websites wie Amazon und Google.

von Lothar Wieske

Teil 1: Amazon Web Services: Flagg-schiff des Cloud Computings

Teil 2: Elastic Compute Cloud: Darf es noch ein Server mehr sein?

Teil 3: BASE: Internetanwendun-gen jenseits der Standards

Artikelserie

CloudBASE: Internetanwendungen jenseits der Standards

www.JAXenter.de

Anwendungsklassen – vielmehr umrei­ßen beide Konzepte ein Kontinuum von Abwägungen und Entscheidungen. In diesem Kontinuum muss der Architekt den pH­Wert seiner „Lösung“ zwischen Availability (BASE) und Consistency (ACID) einpegeln.

Eric Brewer fasste in seinem Vortrag gemeinsame Erkenntnisse und Erfah­rungen aus der Arbeit einer Reihe von Menschen der akademischen und indus­triellen Welt zusammen. Zu jener Zeit war er zum einen Professor an der UC Berkeley und zum anderen Gründer von Inktomi Corporation. Inktomi hatte als Ausgründung der UC Berkeley damals etwa 700 Mitarbeiter und baute Search Engines und Web Caches. Im Dezember 2002 wurde Inktomi von Yahoo! gekauft.

Auf der eigentlichen Schlüsselfolie des Vortrags schaltete Eric Brewer jedoch von zwei auf drei um. Denn in Gänze geht es um drei systemische Merkmale: Availability, Consistency und Partition Tolerance. Und kurz und trocken hieß es dann: „You can have at most two of these properties for any shared­data system.“ Diese Beziehung ist im Jahr 2000 als Bre­wer­Hypothese (Brewer Conjecture) in die Annalen eingegangen. Zwei Jahre später haben dann Seth Gilbert und Nancy Lynch vom MIT die Hypothese formal bewiesen [2], und damit entstand eigentlich erst im Jahr 2002 das Brewer­Theorem oder auch CAP­Theorem, weil Consistency, Availability und Partition Tolerance in Beziehung gesetzt werden.

Heute stehen Websites wie Amazon und Google genau in der Nachfolge der grundsätzlichen Abwägung zwischen Availability und Consistency. Deswegen soll es in diesem Artikel um einige der Phänomene im Umfeld des Brewer­The­orems und im Vorfeld des Cloud Com­putings gehen.

Wirtschaftliche Bedeutung des CAP-Theorems

Die Aberdeen Group hat Ende 2008 ei­ne interessante Untersuchung mit dem vielsagenden Titel „Customers are Won or Lost in One Second“ veröffentlicht [4]. Darin wurden 160 Organisationen hinsichtlich ihrer Best Practices bei der Optimierung der Antwortzeiten ihrer unternehmenskritischen Webanwen­

dungen befragt. Die Kernaussagen die­ser Untersuchung waren:

… business performance (as measured ■by customer satisfaction, conversions, etc.) begins to suffer at 5.1 seconds of de-lay in response times of web applications …… only one second of additional delay ■in the response times of web application could significantly impact some of the top business goals … one second of delay in reponse times of ■web applications can impact customer satisfaction by up to 16 %

Mit ihren Einsichten und Zahlen hat die Aberdeen Group einen wichtigen Im­puls für die gemeinschaftliche Arbeit von Businessanalysten und technischen Architekten gegeben. Gemeinsam soll­ten beide Funktionsträger fachliche Mengengerüste und technische Platt­formunterstützung mit den Geschäfts­zielen (bspw. Kundenzufriedenheit) vor dem Hintergrund von Kosten, Um­satz und Gewinn ausbalancieren. Klar wird aus den angesprochenen Zahlen und Effekten, dass die Geschäftsmodel­le von Amazon (Internethandel) und Google (Internetwerbung) auf Availa­bility fokussieren, und das hat Auswir­kungen in den Infrastruktur en dieser Websites.

Es gibt übrigens für die Auswir­kungen verzögerter Antwortzeiten bei Amazon und Google interessante Zah­len [4]. Amazon hat herausgefunden, dass jeweils 100 Millisekunden Verzö­gerung zu einem einprozentigen Um­satzrückgang führen. Untersuchungen von Google weisen für zusätzliche 500 Millisekunden bei der Generierung von Suchergebnissen einen zwanzigprozen­tigen Rückgang der Anfragen nach.

Technische Bedeutung des CAP-Theorems

Bisher sind die Konzepte Availability, Consistency und Partition Tolerance eher informell in Erscheinung getreten. Gerade vor dem Hintergrund zitierter Beweisführungen ist das natürlich pro­blematisch, weil das mathematische Re­sultat auf präzise und formale Definiti­onen aufbaut. Keine Angst, es wird jetzt

nicht unnötig kompliziert und es geht nicht um die Wiedergabe der formalen Beweisführung in ihren Tiefen. Aber es geht um ein Verständnis wichtiger Ent­wicklungslinien in der konzeptuellen Durchdringung von Konsistenz.

Brewer deutet ein Kontinuum Avail­ ■ability/Consistency an und formuliert das CAP­TheoremGilbert und Lynch beweisen das CAP­ ■Theorem und unterscheiden Strong/Weak Consistency

Abb. 1: CAP-Theorem

Anzeige

Cloud BASE: Internetanwendungen jenseits der Standards

78 www.JAXenter.dejavamagazin 5|2010

Vogels (Amazon) verdeutlicht Even­ ■tual Consistency als Unterkonzept von Weak Consistency und die Bedeutung für Amazon Dynamo als Storage Sys­tem in der Umsetzung bei AmazonPritchett (eBay) entwickelt Consisten­ ■cy Patterns zur schrittweisen Optimie­rung von Availability bei gleichzeiti­ger Relaxierung von Consistency im Übergang von ACID zu BASE

Gilbert und Lynch sprechen eigent­lich nicht von Consistency, sondern von Atomic Consistency. Sie fordern eine totale Ordnung aller Operatio­nen, sodass sie wie eine Perlenkette auf der Zeitschnur aufgefädelt werden können. Und dann soll jede Leseope­ration, die nach einer Schreiboperati­on beginnt, entweder den Wert dieser oder einer späteren Schreiboperation liefern. Für Continuous Availability fordern Gilbert und Lynch, dass jeder Request an das System eine Response liefern muss. Für die Präzisierung von Partition Tolerance wird dem Netz­werk zunächst der Verlust beliebig vieler Nachrichten von einem Kno­ten zu einem anderen Knoten erlaubt. Partitionierung (in Komponenten) bedeutet dann, dass alle Nachrichten von Knoten in einer Komponente zu Knoten in einer anderen Komponen­te verloren gehen. Und mit Partition Tolerance macht dieser Verlust von Nachrichten eigentlich nichts weiter aus. Mit der Begriffsbildung Atomic Consistency werden die Gemeinsam­keiten und Unterschiede zu „A“ und „C“ elegant herausgearbeitet und neu gefasst. Denn Database Atomicity und Database Consistency beziehen sich auf Transaktionen als Operati­onsfolgen, während im Kontext des CAP­Theorems mit Atomic­Consis­tency­Eigenschaften einer einzigen Request­/Response­Operation be­schrieben werden.

Auf dieser Grundlage beweisen Gilbert und Lynch dann ihre ersten bei­den Theoreme: „It is impossible in the ... network model to implement a read/write data object that guarantees the … properties ... Availability (and) Atomic consistency in all fair executions (inclu­ding those in which messages are lost.“

Für die Ellipse vor dem Netzwerkmo­dell steht beim ersten Theorem „asyn­chronous“ und beim zweiten Theorem „partially synchronous“. Beim „partially synchronous Network“ verfügen die Knoten im Netzwerk noch über Timer. Im Gedankengang des Artikels spielt die Unterscheidung der beiden Netz­werktypen eine Rolle, in diesem Artikel werden wir sie jedoch übergehen. We­sentlich scheint für die hiesigen Belan­ge der Abschnitt mit der Überschrift „Weaker Consistency Conditions“. Da­mit wurde die tiefere Beschäftigung mit Eventual Consistency als praxisfähigem Ausschnitt von Weak Consistency ein­geläutet.

Eventual Consistency bei Amazon

Werner Vogels, CTO bei Amazon, ver­tieft im Artikel „Eventually Consistent“ für ACM Queue im Dezember 2008 die Rolle von Amazon Dynamo für die Infrastruktur [5]. Im Untertitel stellt er seinen Ausführungen voran: „Buil­ding reliable distributed systems at a worldwide scale demands trade­offs – between consistency and availabili­ty“. Bei Amazon, Google & Co. gibt es ein Credo: Fehler sind der Normalfall. Dahinter verbirgt sich nicht etwa Defä­tismus oder Sarkasmus. Vielmehr wird aus dieser Einsicht ein klarer Architek­tur­ und Designauftrag abgeleitet. He­runtergebrochen auf die Themenstel­lung dieses Artikels heißt das: Network Partitions sind sicher – deswegen kann es Consistency und Availability nicht gleichzeitig geben.

Abhängig davon, was die Serverseite bietet, muss der Entwickler auf Clientsei­te damit umgehen. Wenn die Serverseite den Schwerpunkt auf Consistency legt, wird es Abstriche im Bereich von Avail­ability geben, und der Entwickler wird Strategien entwickeln müssen für Daten, die zwar geschrieben werden müssen, aber nicht geschrieben werden können. Wenn die Serverseite der Availability den Vorrang gibt, wird es Abstriche im Bereich von Consistency geben und der Entwickler wird Strategien entwickeln müssen, ob und wie er gegebenenfalls auch mit leicht überalterten Daten arbei­ten kann.

Für den clientseitigen Umgang müs­sen zunächst einmal die unterschied­lichen Arten und Eigenschaften von Consistency geordnet und in Beziehung gesetzt werden. Bei Strong Consistency garantiert das System, dass nach einer Schreiboperation alle nachfolgenden Leseoperationen diesen geschriebenen Wert sehen. Bei Weak Consistency ga­rantiert das System nach einer Schreib­operation erst nach dem Eintreten einer Reihe von Bedingungen, dass alle nach­folgenden Leseoperationen diesen ge­schriebenen Wert sehen. Der Zeitraum zwischen dem Abschluss der Schreib­operation und dem Eintreten aller Be­dingungen wird dabei als Inconsistency Window bezeichnet. Eventual Consis­tency stellt eine Sonderform von Weak Consistency dar in dem Sinne, dass ohne weitere Schreiboperationen letztend­lich alle Leseoperationen diesen zuletzt geschriebenen Wert sehen. Wenn keine Fehler eintreten, kann die maximale Größe der Inconsistency Window auch aus unterschiedlichen Kenngrößen des Systems errechnet und angegeben wer­den.

Wahrscheinlich gestaltet sich Even­tual Consistency auch deswegen etwas sperrig, weil es zumindest deutsche In­formatiker etwas schaudert, wenn sie einfach ihrem intuitiven Sprachgebrauch folgen. Dann heißt „eventual“ eher etwa­ig und möglich und nicht letztendlich und schließlich. Das System rauscht also nicht in ein nichtdeterministisches Nir­wana von dannen, sondern folgt einer zeitlichen Entwicklung im Sinne von t ­> ∞. Zusätzlich benennt Vogels noch eini­ge Variationen und Kombinationen von Eventual Consistency:

Causal Consistency ■Read­your­writes Consistency ■Session Consistency ■Monotonic read Consistency ■Monotonic write Consistency ■

Auf der Serverseite haben Vogels und seine Mitarbeiter mit Amazon Dynamo ganze Umsetzungsarbeit geleistet. Ama­zon Dynamo ist ein Key/Value Storage System, das von vielen internen Diens­ten genutzt wird. Jeder nutzende Dienst von Dynamo bekommt seine eigene

webinale 2010 | 31. Mai – 02. Juni 2010Maritim proArte, Friedrichstraße, Berlin

www.webinale.de

Don’t miss the

Early Bär bis zum

22. April!

Veranstalter:Präsentiert von:

Partner:

einfach einladen.

Gold: Silber: Bronze:

Save up to €100 and get a FREE netbook!

FREE!

Anzeige

Anzeige

CloudBASE: Internetanwendungen jenseits der Standards

www.JAXenter.de 81javamagazin 5|2010

Instanz, die möglicherweise mehrere Rechenzentren umspannt. Entwurfs­ziel von Dynamo ist die Möglichkeit der Kontrolle seines Verhaltens entlang der Vorgaben der systemischen Merkmale der Gesamtanwendung. Der Architekt kann sich seine Dynamo­Instanz damit so parametrieren, dass er die Entwick­lungsvorgaben hinsichtlich Availability, Consistency und Kosten erfüllt.

Eventual Consistency bei eBay

Dan Pritchett, Technical Fellow bei eBay, entwickelt im Artikel „BASE: An ACID Alternative“ für ACM Queue im Juli 2008 einige Consistency Patterns, die über relaxierte Consistency zu op­timierter Availability führen [6]. Der Untertitel macht die Motivation klar: „In partitioned databases, trading so­me consistency for availability can lead to dramatic improvements in scalabi­lity“. Es gibt zwei grundsätzliche Strategien für das Skalieren von Datenbanken: ver­tikale und horizontale Skalierung. Verti­kale Skalierung hebt die Datenbank auf leistungsfähigere Hardware. Horizonta­le Skalierung erlaubt mit Database Nor­malization (Zerlegung in unterschied­liche Spalten) und Database Sharding (Zerlegung in unterschiedliche Zeilen) zwei Taktiken, die miteinander kom­biniert werden können. Offensichtlich erfordert eine Strategie der horizonta­len Skalierung grundsätzlich die Eigen­schaft Partition Tolerance. Nach Brewers Theorem müssen deswegen für die Ei­genschaften Consistency und Availability Abwägungen stattfinden und Entschei­dungen getroffen werden.

Pritchett illustriert einige Consis­tency­Überlegungen an einem stark vereinfachten Schema mit zwei Ta­bellen für ein Auktionssystem. Die Tabelle User enthält grundlegende Benutzerinformationen und jeweilige Summenbeträge für Kauf und Verkauf. Die Tabelle Transaction enthält für je­de Transaktion ihren Einzelbetrag und setzt die IDs für Käufer und Verkäufer in Beziehung. Mit jedem Kauf/Verkauf wird eine Zeile in die Tabelle Transac-tion eingefügt und in der Tabelle User werden die entsprechenden Summen aktualisiert:

Begin transaction

Insert into transaction(xid, seller_id, buyer_id,

amount);

Update user set amt_sold= ... where id=$seller_id;

Update user set amt_bought= ... where id=$buyer_id;

End transaction

Möglicherweise kann das Consistency Constraint relaxiert werden, dass beide Tabellen User und Transaction das finan­zielle Ergebnis sofort und übereinstim­mend wiedergeben (müssen). Wenn zu­gelassen wird, dass die User­Tabellen mit ihren Summenbeträgen erst in einem zweiten Schritt verzögert aktualisiert werden, dann wird die Consistency der Tabellen User und Transaction kurzzei­tig geopfert und verzögert wiederher­gestellt. So entsteht folgende gesplittete Transaktion:

Begin transaction

Insert into transaction(id, seller_id, buyer_id,

amount);

End transaction

Begin transaction

Update user set amt_sold= ... where id=$seller_id;

Update user set amt_bought= ... where id=$buyer_id;

End transaction

Nun sind die Updates und damit auch die Consistency für die Tabellen User und Transaction entkoppelt. Die weite­ren Transformationen sind im Artikel detaillierter beschrieben, hier soll eine Skizze der zugrunde liegenden Ideen genügen. Im nächsten Schritt kommt Persistent Messaging zum Einsatz, um die Updates der Tabellen User und Tran-saction auch transaktionell abzusichern. Die bisherige Lösung ist bislang nur dann fachlich korrekt, wenn die Sum­menbeträge letztlich nur als Schätzun­gen verstanden werden, die auch die eine oder andere Transaktion auslassen.Eine technisch korrekte Umsetzung genauer – und nicht nur geschätzter – Summenbeträge könnte von einer ei­genständigen Komponente für Persis­tent Messaging ausgehen. Dann käme jedoch über 2PC (Two Phase Commit) eine Kopplung von Database und Mes­saging zustande, die die Effekte der Ent­kopplung der Updates in den Tabellen User und Transaction kannibalisieren würde.

Die Verfügbarkeit errechnet sich aus dem Produkt der Verfügbarkeiten von Komponenten. Eine Transaktion, die zwei Datenbanken in einem 2PC einbindet, hat bei einer Verfügbarkeit der Einzeldatenbanken von 99,9 % ei­ne Verfügbarkeit von nur noch 99,8 %. Die reduzierte Verfügbarkeit von 0,1 % bedeutet in der Umrechnung auf den Monat 43 Minuten weniger. Also liegen die Nachrichten genau wie die Tabellen User und Transaction in der­selben Datenbank, um ohne 2PC aus­kommen zu können und damit keine Auswirkungen hinsichtlich Availabili­ty zu haben.

Nun gibt es zwei Verarbeitungspro­zesse zum Einstellen einer Transakti­on in die Tabelle Transaction und zum Nachziehen der Summenbeträge in der Tabelle User. Der Prozess zum Nach­ziehen der Summenbeträge liest Nach­richten aus und verändert Werte für die Summenbeträge. Eigentlich läuft das wieder auf eine 2PC­Situation hinaus. Für die Lösung dieser Problematik wird das Konzept einer idempotenten Ope­ration benötigt. Diese kann einmal oder mehrere Male mit gleichem Resultat angewendet werden. Eine idempotente Operation erlaubt deswegen auch par­tielle Fehler. Denn wenn sie wiederholt ausgeführt wird, ändert das den Endzu­stand des Systems nicht in unzulässiger Weise. Nun sind aber Updates im Regel­fall nicht idempotent.

Im Beispiel der Auktion muss also eine Buchführung (Tabelle) her, die genau mitschreibt, welche Updates bereits erfolgreich durchgeführt wor­den sind und welche noch ausstehen. Wenn diese Tabelle ein erfolgreiches Update verzeichnet, wird die zuge­hörige Nachricht als Arbeitsauftrag gelöscht. Dieses Vorgehen ist tolerant gegenüber partiellen Fehlern, kommt aber ohne 2PC­Mechanismen und da­mit verschlechterte Availability aus. Im Artikel von Pritchett werden weitere Ideen zur Entkoppelung von Opera­tionen (Ordnung von Nachrichten und Transaktionen) vorgestellt, die im Zusammenspiel in einer optimierten Availability auf Kosten einer relaxier­ten Consistency resultieren. BASE mit dem Konzept der Eventual Consisten­

+++ wwww.webinale.de +++ wwww.webinale.de +++ wwww.webinale.de +++ wwww.webinale.de +++

Catch theEarly Bär!+ spare 100€

E-BUSINESS & ADVERTISING:Künftig entscheidend für den Erfolg (fast) jeder Marke: Produktinfo und -inszenierungMichael Behrens Jung von Matt/next

Der Rechtsrahmen für Social-Media-MarketingHenning Krieg Osborne Clarke

Fuck Technology – Die Idee ist das ZielAndreas Schimmelpfennig Elastique

SEO is getting SocialChristoph Burseg The Reach Group

SOCIAL NETWORKS & COMMUNITIES: Zeitalter des sozialen KontextsChristoph Bornschein Torben, Lucie und die gelbe Gefahr GmbH

Verbreitung und Monetarisierung von Apps und Games in Social NetworksOlaf Kroll MySpace

20 Jahre Mauerfall im Social Web – Die Story hinter BerlintwitterwallChristian Clawien construktiv GmbH Carsten Hein

Was man alles falsch machen kannDennis Bemmann Business Angel

Tracks & Sessions /Auszug

webinale Specials/Auszug

Onlinemarketing Day

Im Marketingmix hat die Onlinewerbung längst ihren festen Platz. Die Möglichkeiten sind jedoch vielschichtig und die Zielgruppen-ansprache im Netz unterliegt ganz eigenen Gesetzen. Auf dem Onlinemarketing Day erklären Werbepro�s die neuesten Trends und welche Möglichkeiten es gibt, den User auf sich aufmerksam zu machen.

RIA Day

Rich Internet Applications sind im Web wie das Salz in der Suppe. Nutzt man sie nicht, fehlt etwas. Der RIA Day zeigt, was State of the Art ist in Sachen RIA-Technologie. Vor allem, welche RIAs rocken und an welchen Rich-Internet-Applikationen es sich künftig zu messen gilt.

Mobile Revolution Day

Dem Mobile Web wurde bereits vor Jahren eine glänzende Zukunft vorhergesagt, mit Smartphones wie dem iPhone ist es nun endlich da und scheint unsere Kommunikationsgewohnheiten deutlich zu beein�ussen. Vor allem die Applikationen für iPhone, BlackBer-ry und Android sind es, die dem Nutzer Zugang zu vollkommen neuen Möglichkeiten gewähren. Wie die Zukunft des Mobile Webs aussieht, wie es unser Leben verändert, wie man für iPhone, And-roid & Co. entwickelt, zeigt der Mobile Revolution Day.

webcuts

Im Rahmen der webinale �ndet das Internet-Filmfestival webcuts statt. webcuts präsentiert seit 2001 die besten Internet�lme der Welt. Das Festival �ndet am 1. Juni 2010 statt. Teilnehmer der webinale haben kostenlosen Zugang. Eintrittskarten gibt es zudem auch im Vorverkauf und an der Abendkasse. Alle Informationen zu webcuts �nden Sie unter webcuts.org.

webinale – the holistic web conference

Business, Design und Technology sind die drei grundlegen-den Pfeiler für Erfolg im World Wide Web. Die webinale hat sich diesen drei Pfeilern verschrieben. Holistisch, ganz-heitlich wird das Internet betrachtet und durchleuchtet. Die Konferenz konzentriert sich nicht auf einzelne Fragmente, sondern hat stets das große Ganze im Blick. Der webinale

gelingt damit ein Brückenschlag zwischen Designern, Webentwicklern und Managern wie sonst keiner anderen Veranstaltung. Dabei konzentriert sie sich nicht allein auf das Heute – die webinale wirft immer auch einen Blick in die Zukunft, zeigt Trends und liefert heute bereits die Ant-worten auf die Herausforderungen von morgen.

31. Mai – 02. Juni 2010Maritim proArte, Friedrichstraße, Berlin

FUTURE & MOBILE WEB:Case study: Avatar Augmented Reality Experiences with Mattel, Mc Donald and Coca-ColaEric Gehl Total Immersion

Browse the WorldMartin Lechner Mobilizy

Die Zukunft der Web StandardsPatrick Lauke Opera Software

DESIGN & USABILITY:Webdesigntrends 2010Vitaly Friedman Smashing Magazine

An Artists Role in Creating Online ExperiencesNathan Jurevicius Illsutrator

Infoporn oder Transparenz? Sinn und Unsinn von generati-vem Design.Andrea Krajewski Hochschule Darmstadt

Augmented Editorial DesignJulian Koschwitz Interaction Designer

Mehr Charakter, mehr Individualität, mehr WebfontsIvo Gabrowitsch FSI FontShop International

Cloud BASE: Internetanwendungen jenseits der Standards

82 www.JAXenter.dejavamagazin 5|2010

cy bietet hierfür einen leistungsfähigen Arbeits­ und Denkansatz.

Bedeutung in der und für die Praxis

Bei Amazon, Google und Yahoo! sowie vielen anderen sind Infrastrukturen entstanden, die die soeben vorgestellten Ideen im Umfeld von BASE und Eventual Consistency aufnehmen, weiterentwi­ckeln und umsetzen. Die Systeme Ama­zon Dynamo, Google File System, Goo­gle Bigtable und Yahoo! PNUTS sind in wissenschaftlichen Veröffentlichungen vorgestellt worden. Und diese Veröffent­lichungen haben auch zu Nachbauten in der Open­Source­Welt geführt. Es gibt also unterschiedliche Zugänge für eine praktische Vertiefung dieser Themen und in den nächsten Absätzen sollen die pro­minenten Vertreter im Sinne einer ersten Orientierung kurz vorgestellt werden. Open­Source­Systeme für eigene Experi­mente sind beispielsweise Cassandra, Dy­nomite, HBase, Hypertable, Voldemort.

Amazon Dynamo

Vielfach zitiert sind die Einsatzbedingun­gen von Apache Dynamo: „... even if disks are failing, network routes are flapping, or data centers are being des troyed by torna­dos. …“. Apache Dynamo ist ein „highly available key­value storage system“. Dy­namo besteht aus einem Netz von voll­ständig gleichberechtigten Rechnern. Es gibt keine zentrale Steuerung und jeder Knoten kann jede Aufgabe wahrnehmen. Damit skaliert die Architektur von Ama­zon Dynamo in einfachster Weise durch das Hinzufügen weiterer Knoten. Um die gewünschten Eigenschaften zu errei­chen, werden eine Reihe von bekannten Verfahren genutzt. Consistent Hashing, Gossip, Hinted Handoff, Sloppy Quorum und Vector Clocks sind relevante Stich­worte, die zeigen, dass für ein vertieftes Verständnis von Amazon Dynamo einige Vorarbeiten erforderlich sind [7].

Google File System und Bigtable

Google hat mit dem Google File System (GFS) ein verteiltes Dateisystem gebaut, das für große Dateien mit mehreren GB optimiert ist. Inhalte werden nur selten gelöscht oder überschrieben – sie wer­

den aber oft mit hohen Durchsatzanfor­derungen gelesen – außerdem werden oft Inhalte angehängt. Ein GFS Cluster besteht aus einem Master und vielen Chunk­Servern. Mehrere hundert oder tausend Chunk­Server speichern Chunks als 64 MB große Ausschnitte von Dateien. Der Master erhält alle Anfragen für eine Datei und liefert als Antwort die dazuge­hörigen Chunk­Server. Der Client holt dann direkt von den Chunk­Servern die benötigten Chunks für seinen Dateizu­griff. Google Bigtable ist ein performanter skalierbarer Data store auf der Grundlage einer „sparse distributed multi­dimen­sional sorted map“. Er baut u. a. auf dem Google File System auf und liegt u. a. der Google App Engine zugrunde [8], [9].

Yahoo! PNUTS

PNUTS (Platform for Nimble Universal Table Storage) ist „a massively parallel and geographically distributed data base sys-tem“ für die Webanwendungen bei Yahoo!. PNUTS wurde für den Betrieb in mehre­ren und über mehrere Rechenzentren ent­worfen und bietet dafür „per­record time­line consistency“, d. h. alle Repliken eines Records werden in derselben Reihenfolge aktualisiert. Records sind versioniert – ein Client kann bei Leseoperationen nach der neuesten Version fragen oder auch einen leicht veralteten Record zulassen. Damit lässt sich clientseitig die benötigte Consis­tency wählen und einstellen [10].

Zusammenfassung

CAP­Theorem und Cloud Computing – was hat das miteinander zu tun? Nun, Eric Brewer hat in seinem Vortrag eine Tür aufgestoßen und ein Kontinuum aufge­spannt. ACID vs. BASE bzw. Consistency vs. Availability. Im CAP­Theorem wurde dieses Kontinuum um eine dritte Dimen­sion erweitert: Partition Tolerance.

Größe, Verteilung und Wachstum ge­hören zu den zentralen Herausforderung für die Websites und Clouds von Amazon, Google und Co. Größe und Verteilung führen zu einem veränderten Umgang mit Ausfällen und Fehlern – Wachstum erfordert eine in Architektur und Design verankerte Fähigkeit zur Skalierung. Aus den Arbeiten von Brewer, Gilbert und Lynch wird klar, dass die Verfügbarkeits­ (Availability) und Verteilungsanforde­

rungen (Partition Tolerance) auch im Cloud Computing zu einem veränderten Umgang mit Consistency führen müssen. „A“ und „P“ werden nur auf Kosten von „C“ möglich. Nun haben Amazon, Goog­le und Co ihre Hausaufgaben gemacht. Mit Amazon Dynamo und Google Bigta­ble sind In frastrukturen mit neuartigen Ansätzen für Consistency und Scalability entstanden. Diese Infrastrukturen kön­nen und müssen in einfacher Weise durch das Hinzufügen zusätzlicher Compute­/Network­/Storage­Ressourcen wachsen – ihre Architektur liefert die Möglichkeit, und ihre Größe schafft die Notwendigkeit. Und damit kann die eigene Infrastruktur dann auch für die Mitnutzung geöffnet werden. Der Ausbau des eigenen Ge­schäftsmodells auf der Grundlage neuer Availability­ und Scalability­Dimensi­onen schafft so die Grundlage für den Einstieg in ein weiteres Geschäftsmodell – Cloud Computing.

Lothar Wieske ist Enterpri-se Architect. Als Architekt hat er Anwendungsland-schaften entworfen, und als Coach hat er Teams bei Veränderungen begleitet.

Seine Themen sind Cloud Computing, Model-driven Development sowie systemisches Coaching und agile Ent-wicklung.

Links & Literatur

[1] http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

[2] http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

[3] http://www.gomez.com/download/Aberdeen_WebApps.pdf

[4] http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it

[5] http://queue.acm.org/detail.cfm?id=1466448

[6] http://queue.acm.org/detail.

[7] http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

[8] http://labs.google.com/papers/gfs-sosp2003.pdf

[9] http://labs.google.com/papers/bigtable-osdi06.pdf

[10] http://www.brianfrankcooper.net/pubs/pnuts.pdf

Das Beste aus beiden Welten mit InterSystems Caché®

Für höchste Performance können einfach strukturierte wie auch komplexe Daten ohne Umwege direkt auf der untersten Speicherebene persistiert werden

Für höchste Produktivität können alle Daten sofort relational mit SQL und ebenso vollwertig objektorientiert ausgelesen und verändert werden

Für höchste Sicherheit bleibt die Transaktionssicherheit in jeder Phase erhalten

Für höchste Skalierbarkeit wächst Caché mit Ihrer Anwendung – von einer eingebetteten Datenbank bis hin zu verteilten Systemen

Der relationale AnsatzUm hohe Transaktionsraten zu gewährleisten, werden viele Datensätze in BLOBs oder CLOBs aggregiert. Die Auswertung der Daten erfolgt später über SQL.

Vorteile: Stabil und erprobt Transaktionssicher Bewahrt die referentielle Integrität

Nachteile: Aufrechterhalten der referentiellen Integrität kostet

Performance Streams können nicht performant durchsucht werden und

müssen für Auswertungszwecke wieder entflechtet werden

Die NoSQL-DebatteDaten werden nicht relational, sondern meist in hierarchischen Strukturen in Form von Key Value-Paaren über verschiedene Zugriffsmethoden wie REST oder Konstrukte wie XML abge-legt.

Vorteile: Hohe Transaktionsraten Auswertung über Meta-Informationen Ein festes Schema ist nicht zwingend erforderlich

Nachteile: Transaktionssicherheit wird nicht immer gewährleistet

Erhöhter Lernaufwand, da neue proprietäre Abfrage-sprachen/-methoden zu erlernen sind

Besuchen Sie uns auf der JAX 2010:03. – 07. Mai 2010Rheingoldhalle, Mainz

Persist & PerformSowohl Applikationen, die Massendaten verarbeiten und auswerten, als auch transaktionsintensive

Web 2.0-Anwendungen müssen heute einen Kompromiss zwischen Persistence und Performance �inden.

Was wäre, wenn Sie beides haben könnten?

ANZEIGE

100317_AZ_Intersystems_A4.indd 1 17.03.2010 10:03:54 Uhr

www.entwickler.de

Java-Magazin-Abonnement abschließen auf www.entwickler.de

Jetzt abonnieren und 3 TOP-VORTEILE sichern!

Alle Printausgaben frei Haus erhalten1

Im entwickler.kiosk immer und überall online lesen – am Desktop und mobil

2

Mit vergünstigtem Upgrade auf das gesamte Angebot im entwickler.kiosk zugreifen

3