GeeCon dzień 1

The Future of Java - keynote w wykonaniu Thorbiörn Fritzona zdecydowanie nie rzucał na kolana. Chyba trochę zabrakło pomysłu na prezentacje. Thorbiörn rozpoczął od wspominania czasów gdy Sun był firmą zatrudniającą geeków (" We are geeks, we have no friends. We have peers and treat them as friends"), którzy robili "cool stuff", ale nie mieli zbytnio głowy do robienia pieniędzy. Takie podejście (jak i sami ludzie, z których część odeszła z firmy) uległo zmianie po przejęciu firmy przez Oracle. Jednak samo przejęcie nie ma w zdecydowany sposób wpłynąć na los samej Javy. Większość produktów oferowanych przez Oracle (nie mówimy tu o bazie danych) jest oparta na Javie i dlatego powinno vendorowi zależeć na tym aby język i sama platforma dalej się rozwijała. Zresztą skoro sama Java jest "open-source" to nawet gdyby Oracle miał upaść (co podobno mu w niedalekiej przyszłości nie grozi) to i tak sam język wraz z JDK pozostanie. Ogółem podobno nie ma się co martwić, a nawet można wyglądać w przyszłość z nadzieją: Oracle już teraz się angażuje (poprzez m.in. przekazywanie kodu) w działania na rzecz OS oraz wyszedł z inicjatywą wprowadzenia zmian w JCP, ale w tej ostatniej sprawie żadnych dalsze szczegóły nie zostały podane...
Następnie Thorbiörn przedstawił parę cech nadchodzących w Java 7, napomknął o planowanym połączeniu grup tworzących JRockit i HotSpot, dalszym rozwoju NetBeans platform oraz GlassFish (wersja org i com).
Wspomniał dodatkowo o JRockit Mission Control oraz wchodzącym w jego skład JRockit Flight Recorder jako narzędziach do monitorowania i diagnozowania działania JVM. To ostanie narzędzie ma mieć możliwość nagrywanie co się dzieje w JVM (coś w stylu czarnych skrzynek w samolotach nagrywających parametry lotu) a następnie można wykonać dump nagranych parametrów w zadanej przez nas chwili/interwale.

Object Teams: The Next Dimension of Modularity - bardzo ciekawa prezentacja poruszająca temat związany z modułowością/modularnością. Temat ten w obecnej chwili kojarzy mi się od razu z zapowiadanymi zmianami w Java 7 lub też OSGI, jednak prezentacja dotykała trochę innego tematu. Zaczęło się od przypomnienia/objaśnienia czemu powinno zależeć nam na modularności: write/read/understand/change one piece at a time, clean reusability. W tradycyjnym/książkowym podejściu OO system składa się z obiektów - bytów posiadających dane oraz zachowanie. Zachowanie systemu jest definiowane jako zbiór interakcja pomiędzy obiektami (każdy z obiektów dodaje swoją cegiełkę). Podejście to ma mieć kilka zasadniczych wad:

• no boundaries - struktura taka nie pozwala nam w łatwy sposób określić, który obiekt z którym może się komunikować.
• bloated classes - implementacja danego zachowania ma być realizowana przez wiele klas, a dodawanie kolejnych zachowań powoduję dodawanie kolejnych elementów do istniejących klas co powoduję, że nasze klasy są bardzo rozbudowane i mają wiele odpowiedzialności
• scattered behaviour - skoro realizacja danego zachowania jest rozrzucona pomiędzy wieloma klasami można spodziewać się problemów przy maintaince: tudności w zmienianiu/dodawaniu/usuwaniu danego zachowania

Nie do końca zgadzam się z tymi argumentami. Wydaję mi się, że system napisany zgodnie z zasadami OO nie musi mieć tych (wszystkich) wad.
Drugie podejście opiera się na strukturze, w której to mamy do czynienia z operacjami oraz encjami. Operacje są bezstanowe i implementują logikę systemu a jednocześnie manipulują encjami (strukturami), które nie posiadają metod, a jedynie przechowują dane. Takie podejście też ma swoje wady

• no encapsulation for data - encje trzymają tylko dane a nie posiadają metod, które działałyby na tych danych
• no “natural” structure within operation module - zdecydowanie takie podejście jest bardzo mało obiektowe i wygląda mało naturalnie
  
• no re-use between operations - każda z operacji to osobny "świat"

Podejście takie od razu przypomina mi Anaemic Domain Model oraz Transaction Script opisywane przez Martina Fowlera.
Wady obu podejść: Data Centric i Behavoiur Centric ma być pozbawiony ObjectTeams. Jest to projekt, w którym to dla naszych obiektów (tych obiektów trzymających dane oraz posiadających zachowania) nazywanymi od teraz "base" są tworzone struktury "role", a ich zarządzaniem zajmują się struktury "team". Dla danego "Base" może być zdefiniowane jedno lub więcej role. Przypomina to trochę mechanizm dziedziczenia, ale jest to coś innego: dany base może występować nie tylko w wielu role ( a nawet w wielu role tego samego typu), a poza tym role są dynamiczne - w czasie działania dana instancja może występować w wielu role. Team implementują dane zachowanie (use-case) poprzez enkapsulacje interakcji pomiędzy zbiorem obiektów role. Role wzbogacają/zmieniają zachowanie odpowiadających im instancji base poprzez mechanizm call interception. W ten sposób core behviour znajduje się w base, zachowania base specyficzne dla danej funkcjonalności są zawarte w role, które to są zdefiniowane w team. Do tego dochodzi jeszcze mechanizm Team Activation, ktory pozwala na drobno ziarniste włączanie/wyłączanie mechanizmu call interception.
Całość wygląda całkiem, całkiem. Pomimo tego, że role są dynamiczne, eclipse w postaci Object Teams Development Tooling (OTDT) ma zapewniać bardzo dobre wsparcie podczas developmentu, a jako dodatkowy plus ObjectTeams ma też działać pod Equinox.

Easy to Use Highly Available Java Database Access- niestety nie byłem na całej prezentacji i przyszedłem po około 20 minut po rozpoczęciu. Craig przedstawiał MySql Cluster jako transakcyjną baza danych zaprojektowaną z myślą o pracy w silnie obciążonym środowisku wymagającym szybkiego, wydajnego i wysoce-dostępnego dostępu do danych. Jako przykład infrastruktury wskazano MySQL Cluster Carrier Grade Edition, które to ma pracować z dostępnością "5 9's" wykonując miliony operacji na minute. Razem z długą listą firm, które to korzystają z takiego rozwiązanie oraz wybranymi scenariuszami użycia zrobiło to naprawdę duże wrażenie. Oczywiście osiągnięcie takich wyników niesie ze sobą pewne (a dla osób przyzwyczajonych do pracy z typowymi bazami SQL dość znaczne) ograniczenia co do mechanizmów przechowywania danych (na prezentacji Craig wspomniał jedynie o typach danych i braku ograniczenia foreign-key). W dokumentacji projektu jasno jest napisane, że przejście z MyIsam czy InnoDB na NDB (specyficzny dla MySQL Cluster storage engine ) może wymagać zmiany schematu, zapytań albo nawet zmian w samej aplikacji.
Dostęp do MySql Cluster można uzyskać za pomocą: C++ API, SQL ( za pomocą MySQL Server) oraz MySQL Cluster Connector for Java. Ten ostatni interfejs udostępnia 2 możliwości: , ClusterJ lub ClusterJPA jako plug-in dla OpenJPA. ClusterJ przypomina na pierwszy rzut oka JPA/JDO, też mamy do czynienia z mapowanie, ale trochę innym i zdecydowanie uboższym od tego, do którego jesteśmy przyzwyczajeni. Jest to związane z tym, że MyClusterJ nie jest out-of-box bazą z interfejsem SQL - czyli mapowania nie przekładają się na SQL a na wewnętrzne API MySQL Cluster. Interfejs ClusterJ udostępnia nam dobrze znane obiekty: SessionFactory, Session, Transaction, Query, ale mapowania robimy na interfejsie a nie na klasie. Dodatkowo nie są wspierane takie mechanizmy jak: relacje, dziedziczenia, tworzenie tabel/indexów na podstawie mapowania a zapytania zawsze dotyczą pojedynczej tabeli. ClusterJPA stanowi pewne rozszerzenie i obejście w/w ograniczeń (jestem ciekaw jaki podzbiór JPA jest tak naprawdę wspierany). Jest to plugin dla OpenJPA, który pewne operacje: primary key reads, inserts, updates, deletes wykonuje przy pomocy ClusterJ API, a pozostałe realizuje za pomocą JDBC (czyli SQL). W przypadku innych providerów JPA wszystkie operacje będą wykonywane za pomocą JDBC.

The High Availability Non-Stop, Fault-Tolerant Services Tutorial - całkiem ciekawa prezentacja dotyczącą tworzenia skalowalnych i "niezatapialnych" systemów.
Eugene rozpoczął od samych podstaw. Na początku omówił czym jest skalowalność (własność systemu umożliwiająca obsługę rosnącej ilości pracy lub też łatwość rozbudowy istniejącego systemu w przypadku zwiększenia zapotrzebowania na pewne zasoby: sieć, moc obliczeniowa, dostęp do BD), typy skalowalności: horizonal-out ( dodanie nowych węzłów mających taką samą funkcjonalność jak te dotychczas), vertical-up (rozbudowa istniejących węzłów poprzez dodanie zasobów, np. pamięci, procesorów, storage). Dalej zdefiniował high availability (w zadanym okresie czasu zapewnienie całkowitej ciągłość działania systemu pod kątem funkcjonalnym ) i podał sposób obliczania dostępności jako 100 - (100*D/U) gdzie D to unplanned downtime a U to uptime. Szczególnie podkreślił fakt, że uptime != available (system może być uruchomiony, ale ze względu na np. problemy z siecią jest niedostępny). W ten sposób przeszedł do tabelki definiującej poziom dostępności jako ilość 9 - w zależności od ilości 9 system nie będzie up przez określony czas w roku. Określanie dostępności w taki sposób ma wiele niedoskonałości i ma służyć głównie w materiałach marketingowych. Problemem samy w sobie jest uptime (system jest up, ale ze względu na awarie sieci jest niedostępny dla klientów), poza tym z powodów problemów wydajnościowych system może być uznany za up, ale praktycznie nieużyteczny dla użytkowników, gruboziarniste uśrednianie poziomu dostępności nie odzwierciedla wymagań wielu systemów (brak dostępności systemu w okresie peak load a niedostępność w okresie "wakacji" ). Definicja HA oraz sposobu mierzenia uptime powinny zostać jasno sprecyzowane w SLA (Service level agreement). Po tym teoretycznym wstępie (choć nie wiem czy go do końca poprawnie zrozumiałem) przeszedł do bardziej praktycznych zagadnień:

• load balancer - "rozrzuca" żądania pomiędzy 2 lub więcej zasobami, ukrywając je jednocześnie przed klientami, którzy widzą jedynie pojedynczy zasób w postaci load balancera. Mogą być bezstanowe (typowe dla żądań webservices) lub stanowe (np. dla systemów wymagających współdzielenia sesji HTTP). Istnieje wiele możliwych algorytmów "rozrzucania" żądań do zasobów, np. na podstawie contentu, priorytetów, mocy obliczeniowej zasobów, itd.
• cache - przechowywanie danych które są "ciężkie" do pobrania lub obliczenia. Cache sprawdza się szczególnie dobrze dla danych read-only. Problemem niestety są wszelkie bezpośrednie zapisy do danych trzymanych w cache. Standardowo można to rozwiązać przez write-through - synchronicznie uaktualniamy cache oraz storage, write-behind - wartość w cache oznaczamy jako dirty i zapisujemy do storage asynchronicznie, no-write allocation - zakładamy, że z cache tylko czytamy i nie ma zapisów. Podane strategie chyba mają dotyczyć tylko przypadków w których to cache pełni role "proxy" dostępu do faktycznego data source. Osobiście nasunął mi się przypadek w którym do data source jest modyfikowany "z boku" przez inna aplikacje która jest nieświadoma cache. Odwołania do cache mogą być realizowane w sposób nie jawny (,np. Terracota, która też posiada API do cachowania ) lub jako bezpośrednie (,np. Coherence, Memcache). Wspomniał także o web caching i wyróżnił 2 podejścia: web accelerators ( użycie CDN jak S3, Akami , które to będą serwować zasoby) lub proxy cache (Squid)
  
• cluster - grupa 2 lub więcej maszyn połączonych szybką siecią. Klaster jest widoczny dla użytkownika jako pojedyncza maszyna i jest budowany w celu zwiększania dostępności/wydajności systemu. Przy założeniu tej samej wydajności budowa klastra jest bardziej opłacalna niż skalowania pojedynczej maszyny (scale up). Wyróżniamy konfiguracje A/A (active/active) w której to wszystkie maszyny jednocześnie pracują oraz A/P (active/passive) w której to część maszyn rozpoczyna prace tylko gdy inne ulegną awarii - wymagane są co najmniej 2 węzły (główny i zapasowy), mechanizm wykrywania awarii oraz możliwość przełączenia ruchu do węzłów zapasowych w momencie awarii.
• grid - system, realizujący dane zadanie jako zbiór niezależnych od siebie tasków (Map-Reduce)

Następnie Eugene poruszył tematy związane z redundancy i fault-tolerance. W konfiguracji A/A w przypadku gdy nasza aplikacja jest bezstanowa sytuacja wydaje się bardzo prosta - jeden węzeł wylatuje i można działać dalej. W przypadku konfiguracji A/P (na której mają być uruchomione aplikacje "stanowe" które mają skalować się jedynie "w górę"- scale up) obługa fault-tolerance jest trudniejsza i droższa: wymagane jest przełączenia na zapasowe węzły i może wymagać ingerencji ze strony administratora. W dalszej części przedstawione zostały przykładowe konfiguracje i schematy architektur które mają zapewniać scalability i HA. Eugene chyba nie do końca wstrzelił się z czasem bo konfiguracje były dość rozbudowane i przybliżenie jakichkolwiek szczegółów trwałoby zdecydowanie za długo. Wspomniany został case w którym to pewna firma miała coraz to większe ilość danych do przetwarzania, ładowanie ich do bazy Oracle stawało się coraz bardziej bezsensowne: rosły koszty rozbudowy bazy a czas przetwarzanie rósł. Rozwiązaniem okazał się Hadoop. W innym przypadku dzięki zastosowaniu odpowiedniej architektury (w szczególności load-balancerów na wielu poziomach) bardzo łatwo można było przeprowadzać inkrementalne uaktualnienie systemu.
Ogółem prezentacja bardzo ciekawa, ale ze względu na czas przedstawiona trochę po wariacku.

Java in high-performance computing - chyba najciekawsza prezentacja dnia. Dawid po chwili mniej-czy-bardziej rozrywkowej przeszedł do konkretów: czy Java jest szybsza od C++?
Odpowiedz jest godna konsultanta: to zależy ... Dawid rozpoczął od zdefiniowania HPC (High-performance computing) na potrzeby swojej prezentacji: działamy w środowisku o ograniczonych zasobach (np. CPU, pamięć) i mamy ograniczony czas na wykonanie przetwarzania. System napisany w duchu HPC nie powinien mieć żadnych oczywistych wad. Dawid przedstawił kolejne przykłady, które ukazywały znaczne różnice w czasie wykonania w zależności od pewnych warunków/ustawień:

• funkcja dodająca 2 argumenty ma zdefiniowane odpowiednio argumenty: 2 inty (prymitywy), 2 Integery, Integer vararg. Różnice w czasie wykonania w zależności od maszyny wirtualnej potrafią wynieść nawet kilkanaście sekund.
• uruchomienie identycznej aplikacji na windows oraz ubuntu kończy się zupełnie inaczej pomimo tego, że są to te same JVM. Na ubuntu JVM uruchamiał aplikacje automatycznie w trybie "server VM"

Ze względu na to że mamy wielu dostawców JVM, istnieje wiele różnych wersji tych maszyn, mogą mieć włączone różne opcje, różne kompilatory (server/client) nie ma uniwersalnej metody tworzenia wydajnych aplikacji. Dodatkowo, to co faktycznie zostanie uruchomione nie jest do końca określone w bytecode. Jedyną drogą osiągnięcia wydajności wydaje się być cykl: zmierz-popraw-zmierz.
Jeśli chodzi o benchmarking to Dawid znów pokazał parę solidnych przykładów:

• czas wykonania martwego kodu może się różnić w zależności od JVM. HotSpot bardzo ładnie sobie radzi z usuwaniem martwego kodu, zostało to szczególnie ciekawie pokazane za pomocą odpowiedniej flagi dla JVM, dzięki której mogliśmy zobaczyć kod w assemblerze.
• Hostpot bardzo dobrze sobie radzi z wywołaniami metod wirtualnych: potrafi przeprowadzić optymalizację (aggressive inlining), ale w odpowiednim momencie może się z tego wycofać i powrócić do standardowego wywołania wirtualnego.
• wywołanie metody ze standardowego API javy (Integer.bitCount()) zostało zamienione przez JIT na odpowiednią instrukcje procesora, która to była dostępna na maszynie na której to aplikacja była uruchomiona.
  

Mierzenie wydajności wcale nie jest trywialne a wartości, które otrzymamy mogą zależeć od wielu czynników. Sam proces mierzenia powinien odbywać się w warunkach stabilnych: po fazie "warm-up", odpalamy odpowiednią ilość przebiegów, wyciągamy średnie, wariancje, min, max itd. Ważne aby nasze scenariusze testów odpowiadały faktycznym scenariuszom użycia systemu i aby mierzyć na środowisku docelowym, ponieważ jak się okazało ma to bardzo duże znaczenie...
Więcej na ten temat można znaleźć w artykule.
Pewne flagi wraz z objaśnieniami których używał Dawid można znaleźć tu

An Introduction to EclipseRT, Equinox and OSGi - nigdy nie byłem fanem prezentacji o eclipse. Uważam że jest to (bardzo) dobre narzędzie i tak na prawdę tylko narzędzie. Zdarzało mi się widzieć prezentacje o Eclipse RCP, Eclipse RAP czy Eclipse Platform, ale nie do końca byłem przekonany co do użyteczności tych narzędzi w tworzeniu rozwiązań biznesowych. Byłem w stanie wyobrazić sobie ich wykorzystanie do tworzenia różnego typu narzędzi lub "rozwiązań naukowych". Jak się później okazało, większa część środowiska myśli bardzo podobnie do mnie.
Chris rozpoczął od krótkiego objaśnienia OSGI: moduły jako bundle, import/export package, dynamiczne services, BundleContext, BundleActivator . Nie obyło się bez wspomnienia o korzeniach OSGI, OSGI Alliance, OSGI Specifications oraz implementacjach OSGI (np. Equinox, Fexlix, Knopflerfish, Concierge). Następnie Chris przedstawił EclipseRT jako zbiór narzędzi, frameworków oraz środowisk uruchomieniowych (runtimes) do wykorzystania przy budowie własnych rozwiązań, niezależnie od tego czy są to systemy typu desktop, web, SOA, enterprise, embedded. Na liście projektów wchodzących w skład EclipseRT można znaleźć wielu "starych znajomych" m.in: EclipseLink, Jetty, Birt, Swordfish, RAP, Virgo (Spring DM). Pomimo, że każdy z nich dotyczy zupełnie innej dziedziny to łączy je fakt uruchamiania na platformie Equinox (też wchodzi w skład EclipseRT). Dzięki temu, że pod spodem mamy OSGI, projekt oraz nasze własne aplikacje/moduły mogą korzystać z wszystkich dobrodziejstw związanych z tym środowiskiem. Jako przykład wykorzystanie EclipseRT został przedstawiony Toast. Jest to system do zarządzania flotą pojazdów, oparty na EclipseRT, który ma służyć jako działający przykład rozwiązania wykorzystującego mechanizmy i możliwości EclipseRT.
W dalszej części Chris wspomniał o stackless stack oraz o CODA - architekturze budowania systemów opartej o komponenty. Pomysł sam w sobie nie jest niczym nowym (już JavaBeans opisywało tworzenie aplikacji z komponentów), ale tym razem dzięki OSGI wszystko zapowiada się trochę inaczej.