sobota, 22 maja 2010

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.

piątek, 26 marca 2010

4developers

Dziś miałem okazje wziąć udział w konferencji 4developers. Udział w konferencji zawdzięczam mojemu ukochanemu Poznan JUG.

Walka o życie – kuzyni i następcy Javy opanowują świat Michael Hunger prezentacja była tak nudna,że po 10 minutach wyszedłem i przeniosłem się do sali ze ścieżki PHP. Pomimo tego że nigdy nie napisałem linijki w PHP(z czego tak naprawdę jestem dumny) to temat cloud computingu przemawiał do mnie jak najbardziej.

PHP w chmurze Ivo Jansch prezentacja okazała się bardzo ciekawa i nie miała za wiele wspólnego z PHP. Na początku omówione zostały podstawowe pojęcia związane z cloud computing, a w szczególności: IaaS, PaaS, SaaS. Jeśli chodzi o IaaS to jest to podstawowy poziom, który z punktu widzenia klienta opiera się na tym że uzyskujemy dostęp do hardware (sami definiujemy wymagania co do tego hardware )na którym możemy zainstalować system operacyjny, a następnie samą aplikacje. To gdzie fizycznie zostanie uruchomiona aplikacja najczęściej nas nie interesuje...
Instalacja systemu operacyjnego jest zazwyczaj pomijana ze względu na to, że najczęściej wybiera się obraz maszyny wirtualnej z zainstalowanych już systemem operacyjnym. Jako developer dostajemy dostęp do takiego "obrazu" i możemy sobie instalować naszą aplikacje. Ivo szczególnie polecał zaznajomienie się z rackspacecloud, który ma dostarczać bardzo wygodne API, dzięki któremu z poziomu PHP można odpalić nową maszyną wirtualną i zdeployować aplikacje. Kolejny poziom to PaaS, czyli w tym przypadku przechodzimy o poziom wyżej - z poziomu systemu operacyjnego na którym możemy sobie odpalić dowolną aplikacje, otrzymujemy platformę (w pewnym sensie możemy mówić o serwerze-usłudze) na którym odpalamy naszą aplikacje. Najlepszym przykładem jest tutaj Google App Engine który pozwoli nam zdalnie deployować aplikacje napisane w Java i Python. Jak na razie nie ma dostępnej darmowej infrastruktury PaaS dla PHP (istnieje płatne rackspacecloud sites). Ostatni poziom to SaaS czyli gdy tak na prawdę sama aplikacja jest usługą, z której to możemy korzystać. Najlepszym przykładem to Google Apps (docs, spreadsheet) lub też SalesForce CRM. Następnie Ivo omówił typowe problemy (choć lepiej nazwać to specyfiką środowiska) związane z tworzeniem aplikacji uruchamianych w chmurach: bezpieczeństwo, obsługa stanu, regulacje prawne. Na końcu wspomniał jeszcze o private developer clouds(jako VMware vSphere oraz tych udostępnianych przez terremark).
Automatyczne generowanie kodu Marek Berkan prezentacja sponsora, która niestety okazała się bardzo słaba. Mimo, że nie spodziewałem się cudów, to jednak liczyłem na coś więcej ... Przedstawione zostało parę scenariuszy, w których to generowanie kodu ma być bardzo użyteczne: generowanie kodu encji oraz DAO na podstawie schematu bazy danych, generowanie obiektów Javy z XML. Wszystko to było mało odkrywcze: użycie Hibernate, JAXB. Patrząc na Hibernate z punktu widzenia "generacji kodu" to wyniki nie są oszałamiające: głowną bolączką ma być brak automatycznego generowania stałych definiujących nazwy kolumn. W czasie prezentacji pokazał 2 pomysły, które wydają się bardzo sensowne: generowanie stałych dla propertiesów Strutsowych form beanów oraz dla kluczy bundli. Dzięki temu wszelkie zmiany w źródle (definicji form beana czy plikach bundli) są wyłapywane przez kompilator.
TopLink Grid – skalowanie aplikacji korzystających z Java Persistence API Waldekmar Kot - jedna z najlepszych (przynajmniej dla mnie ) prezentacji. Waldek zaczął trochę ospale od przedstawienia standardu JPA i podstawowych pojęć z nim związanych: EntityManager, EntityManagerFactory, PesistenceUnit i czegoś tam jeszcze. Ze względu na to że używam Hibernate nie do końca rozumiem te wszystkie pojęcia...
Następnie omówił standarodowe mechanizmy cachowania: cache transakcyjny(patrząc z perspektywy Hibernate cache związany z Session), oraz ten drugi (nie pamiętam dokładnie jakiego Waldek użył sformułowanie, ale chodziło o cache na poziomie SessionFactory czyli, second-level cache). Ten ostatni jest współdzielony przez cache transakcyjne w ramach pojedynczego JVM, ale może być także współdzielony w ramach wielu JVM. W ten to sposób doszedł do sedna, czyli pojęcia Data Grid: jako osobnej warstwy (najczęściej osadzonej na innym JVM/innej maszynie fizycznej niż nasza aplikacja ) która świadczy usługi przechowywania ale także może przetwarzać obiekty. Zazwyczaj taki Data Grid składa się z większej liczby węzłów, które to tworzą ze sobą sieć Peer-to-Peer i dostarczają nam możliwość bezpiecznego/skalowalnego/wydajnego przechowywania w pamięci dużej ilości danych. Bardzo podobała mi się mechanizm związany z możliwością wykonywania operacji bezpośrednio na Data Grid: zamiast ściągać dane do aplikacji, modyfikować je i odsyłać, można "wysłać" operacje bezpośrednio w Data Grid. Połączenie ze sobą Data Grid (w przypadku Oracle mówimy tu o konkretnym produkcie Oracle Coherence) wraz z implementacją JPA (Oracle Toplink) daję nam Oracle TopLink Grid. Takie połączenie pozwala na zwiększenie wydajności i skalowanie naszej warstwy DAO poprzez sam mechanizm cachowania, ale jednocześnie dostarcza kilku nowych możliwości. Chodzi o to że Oracle Coherence pracujący tuż za plecami naszej warstwy DAO (ale przed bazą danych) może pracować w jednym z 3 trybów:
  • Cache: standardowy second-level cache (cachowanie na podstawie id)
  • Read: w stosunku do trybu powyżej, nasze zapytania SQL są "przechywytywane" przez Data Grid, interpretowane oraz pobierane bezpośrednio z cache. Zapytania mają być rozpraszane na poszczególne instancje składające się na Data Grid (osobiście jestem ciekaw jak wygląda to w przypadku zapytań agregujących które przechodzą wzdłuż przez dane fizycznie przechowywane na innych instancjach Data Grid)
  • Entity: dodatkowo w przypadku modyfikacji najpierw modyfikowane są obiekty w Data Grid a później dane w bazie danych. Jednocześnie jest możliwe takie ustawienie że dane do modyfikacji są buforowane (ze względu na ilość lub czas) i wysyłane w 1 paczce do bazy danych.
Temat na pewno był bardzo ciekawy, ale ze względu na ograniczenia czasowe (dobrze, ze po tej prezentacji był obiad- a tylko szczęśliwcy dostali voucher :( , można było jeszcze trochę Waldka dopytać) nie udało się pokazać więcej.


Zbuduj pierwszą aplikację typu RIA z wykorzystaniem Flex 4 Piotr Walczyszyn
- bardzo fajna prezentacja, której głównym punktem była prezentacja Desktop Keeley :) Prezentacja składała się z 2 części: teoretycznej, w której omówione zostały podstawowe informacje na temat platformy FLEX, oraz praktycznej, w której to Piotr przedstawił w jaki sposób tworzyć w niej aplikacje. W części pierwszej można było usłyszeć o Flex SDK, sposobach komunikacji pomiędzy modułami SWF a częścią serwerową (SOAP, HTTP/HTTPS, AMF/AMFS, RTMP/RTMPS). Nie mogło się obyć bez prezentacji przykładowych aplikacji wykorzystujących FLEX: http://www.windowshop.com/, http://www.taaz.com/makeover.html, oraz "popisowej" http://www.adobe.com/devnet/flex/tourdeflex/. Następnie pojawiło trochę informacji na temat Adobe AIR, czyli runtime umożliwiający uruchamianie aplikacji Flex na desktop. Dzięki temu że można wyjść poza sandbox przeglądarki można skorzystać z dodatkowej funkcjonalności: instalacja i uruchamianie jako natywna aplikacja, dostęp do systemu plików, dostęp do wbudowanej bazy danych SQLite, możliwość uruchamianie aplikacji na wielu platformach: Windows, Mac, Linux a także Nokia S60 i Android...
"Lokalnym" przykładem aplikacji Adobe AIR to e-deklaracje, a inne ciekawe można zobaczyć na stronach Adobe. W 2 części Piotr przedstawił w jaki sposób stworzyć prostą aplikacje we Flex 4: aplikacja stworzona we FLEX łączy się z serwerem - Apache Tomcat, BlazeDS, MySQL. Musze przyznać, że robiło to duże wrażenie, szczególnie jeśli chodzi o skrócenie czas developmentu - choć nie do końca wiem czy to zasługa FLEX4 czy Flex Builer. Szczególnie spodobał mi się w części klienckiej mechanizm automatycznego generowania proxy oraz dto dla wystawionych na serwerze usług. Co ciekawe, zaimplementowany został (bez pokazania szczegółów) mechanizm asynchronicznego powiadamiania klientów. Miał to działać na takiej zasadzie, że usługa dodająca element do bazy wysyłała wiadomość do JMS topic. Na tym topicu "słucha" BlazeDS i powiadamia klientów za pomocą HTTP.
Możliwość asynchronicznego powiadamiania klientów (server push) bez potrzeby korzystania z warswty pośredniej - JMS, ma być zaimplementowana w komercyjnym Flash Media Server lub open-source red5.

Co nowego w Java SE 7? Marcin Kalas hmm nie do końca chyba słuchałem, a przynajmniej nic nie zanotowałem... chyba przychodzą na tą prezentacje miałem złe nastawienie: no bo przecież mój ukochany Websphere 6.1 działa na Java 5... Z tego co pamiętam to zostało wspomniane o paru udogodnieniach:
nowe File I/O, udogodnienia związane z przetwarzaniem równoległym JSR 166, nowy garbage collector, skompresowany wskaźnik 64 bitowy. Myślę że wszystko co było powiedziane można znaleźć tu

Craftsmanship i wzorce projektowe Sławek Sobótka - prezentacja zdecydowanie mniej techniczna od innych, ale całkiem ciekawa. Sławek skupił się na przedstawieniu wzorców projektowych jako ważnego ogniwa dojścia do profesjonalizmu. Wzorce nie tylko wypada znać, rozumieć, ale też wiedzieć kiedy stosować. Ważne jest aby pamiętać, że zastosowanie każdego z wzorców niesie ze sobą określone korzyści ale też i koszty. Mi osobiście spodobało się użycie chain of responsibility do wybierania strategii oraz wzbogacanie strategii poprzez decorator.

Modele komponentowe SCA, OSGi, Distributed OSGi i OSGi Enterprise a Java EE Jacek Laskowski - dziwna prezentacja, chyba nie do końca wiem do czego Jacek dążył ... Rozpoczęło się od próby zdefiniowania podstaw: interfejs, usługa, komponent poprzez bardziej abstrakcyjne byty: "rusztowanie" i "szkielet", ale później poszło już z górki. Jacek przedstawił historie powstawania "architektur komponentowych" na platformie Java. Zaczęło się od JavaBeans, przez EJB, Spring, JEE, OSGi, Spring DM, OSGi Blueprint Container, Distributed OSGi, Enterprise OSGI, SCA. Ja wyłączyłem się przy SCA i tego przejścia nie zaczaiłem...
Prezentacja miała omawiać aspekty programowania deklaratywnego, ale tak na prawdę przemieniła się (przynajmniej ja to tak odebrałem) jako refleksje na temat architektury komponentowej na platformie. Jacek (w mojej ocenie) popełnił 2 błędy/nieścisłości:

  • przyrównanie JavaBean do POJO - JavaBean to jest POJO, ale POJO to niekoniecznie JavaBean.
  • Spring to nie tylko DI, ale też AOP i Abstraction Of Services. Jest to znacząca różnica, szczególnie w momencie gdy historycznie porównujemy Spring do J2EE.

piątek, 15 stycznia 2010

ArithmeticOperationFactoryBean

W ostatnim projekcie miałem potrzebę zdefiniowania w konfiguracji Spring prostych arytmetycznych zależności między wartościami propertiesów. Nie ma sensu zdefiniowanie maksymalnej ilości wątków w puli ThreadPoolTaskExecutor gdy nie skorelujemy jej z ilością połączeń puli do bazy danych (przy założeniu że nasze taski korzystają z bazy danych). W moim przypadku poszczególny task potrzebował dokładnie 2 połączenia do bazy danych.
Chciałem mieć możliwość wyrażenia, że dane property ma mieć wartość 2 * wartość innego property.
Po krótkim googlowaniu nie udało mi się nic znaleźć i stwierdziłem, że łatwo samemu coś takiego napisać. W tym celu stworzyłem własną klasę FactoryBean, której zadaniem było wykonywanie operacji mnożenia na injectowanych parametrach.

private TypeConverter typeConverter = new SimpleTypeConverter();

public void setParam1(Object param1) {
this.param1 = param1;
}

public void setParam2(Object param2) {
this.param2 = param2;
}

public Object getObject() throws Exception {
Object result = null;
BigDecimal param1Converted = convert(param1);
BigDecimal param2Converted = convert(param2);
BigDecimal result = param1Converted.multiply(param2Converted);
return result;
}

private BigDecimal convert(Object obj) {
return (BigDecimal) typeConverter.convertIfNecessary(obj, BigDecimal.class);
}
public Class getObjectType() {
return BigDecimal.class;
}

Wyglądało to całkiem,całkiem ale pomyślałem, że bardzo prosto byłoby zbudować bardziej generyczne rozwiązanie. Implementacja FactoryBean dla innej 2-argumentowej operacji byłaby prawie identyczny, a jedynie różniłaby się oepracją na klasie BigDecimal. Dodatkowo chciałem mieć możliwość specyfikowania typu danych wyniku operacji arytmetycznej.
Generyczny ArithmeticOperationFactoryBean:

public abstract class ArithmeticOperationFactoryBean implements FactoryBean,
InitializingBean {
private TypeConverter typeConverter = new SimpleTypeConverter();
private Object param1;
private Object param2;
private Class<?> resultType;

public void setResultType(Class<?> resultType) {
this.resultType = resultType;
}

public void setParam1(Object param1) {
this.param1 = param1;
}

public void setParam2(Object param2) {
this.param2 = param2;
}

@Override
public void afterPropertiesSet() throws Exception {
if (param1 == null || param2 == null) {
throw new IllegalArgumentException(
"operation arguments can not be null");
}
if(resultType == null){
resultType = BigDecimal.class;
}
}

@Override
public Object getObject() throws Exception {
Object result = null;
BigDecimal param1Converted = convert(param1);
BigDecimal param2Converted = convert(param2);
BigDecimal operationResult = executeOperation(param1Converted,
param2Converted);
result = operationResult;
if (resultType != null) {
result = convert(operationResult, resultType);
}
return result;
}

protected abstract BigDecimal executeOperation(BigDecimal param1Converted,
BigDecimal param2Converted);

@SuppressWarnings("unchecked")
private <T> T convert(Object obj, Class type) {
return (T) typeConverter.convertIfNecessary(obj, type);
}

private BigDecimal convert(Object param) {
return convert(param, BigDecimal.class);
}

@Override
public Class<?> getObjectType() {
return resultType;
}

@Override
public boolean isSingleton() {
return true;
}

}

FactoryBean odpowiedzialny za operacje:

public class MultiplicationFactoryBean extends ArithmeticOperationFactoryBean {

@Override
protected BigDecimal executeOperation(BigDecimal param1,
BigDecimal param2) {
return param1.multiply(param2);
}
}

Użycie takiego FactoryBean w konfiguracji wygląda w następujący sposób:

















Konfiguracja definiuje w context dwa beany:"foo" typu java.lang.Double oraz "myInteger" typu java.lang.Integer. Wartość foo jest 24.

Zamiast dziedziczenia może lepiej byłoby zastosować tu wzorzec strategy, ale jest to w takim przypadku chyba pomijalne...
Dodatkowo, ekspsresywność rozwiązania nie rzuca na kolana, ale dla prostych zastosowań nadaję się moim zdaniem co najmniej przyzwoicie.