Poprzedniego wieczora staraliśmy się trochę zintegrować i chyba dlatego prezentacja Adam Biena nie zbyt zapadła mi w pamięć. Z tego co pamiętam to zaczęło się od omówień zmian w JRE: JRE kernel, lepsza komunikacja na linii JavaScript-Applet, możliwość wyspecyfikowania per-applet wymagań co do pamięci, specyfikowanie per-applet wymagań co do wersji JRE. Następnie Adam przeszedł do JavaFX. Było to mniej więcej wszystko to samo co na pozostałych prezentacjach na ten temat. Jedyne co mnie "obudziło" to pisanie testów JUnit w JavaFX. Pojawiło się pytanie czy można to robić w stylu JUnit 4.X, czyli za pomocą annotacji. Odpowiedz było prosta: można użyć JUnit w wersji 4.X, ale nie można korzystać z annotacji, ponieważ JavaFX nie wspiera annotacji!.
RESTful Web Services with Spring 3.0
Znużony trochę prezentacją na temat JavaFX na drugie pół godziny przeniosłem się do sali obok aby posłuchać Arjena Poutsmy. Było to praktycznie to samo co Arjen zaprezentował jakiś czas temu w Warszawie. Arjen oprócz tego, starał się wytłumaczyć czym Spring Framework REST support różni się od implementacji JAX-RS: ten pierwszy dotyczy interfejsu human to machine a ten drugi machine to machine. Fuknkcjonalności w stylu: filtr, który obchodzi ograniczenie przeglądarki do wysyłania jesdynie żądan POST i GET, używanie file extensions w celu określenia żądanej reprezentacji (kolejne obejście przeglądarki) mają ułatwić tworzenie aplikacji zgodnych z paradygmatem REST. Jednak jak to później Arjen w rozmowie uściślił @MVC/@REST ma duże zastosowanie dla web development, a JAX-RS dla RESTful services, czyli ma stanowić konkurencje dla SOAP WebServices. Arjen wspomniał także o RestTemplate czyli o REST po stronie klienta. Na koniec pojawiło się pytanie związane z security w świecie REST. Po stronie serwera nic się nie zmienia i standardowo używać form-based authentication oraz SpringSecurity(jest w stanie sprawdzać prawo do wywołania zasobu także na podstawie użytej metody HTTP), a dla RestTemplate używać basic/digest authentication i przesyłać nasze credentials przy każdym żądaniu.
Glassfish
Dodatkowa, nieplanowana prezentacja przeprowadzona przez Antonio Goncalves na temat GlassFish. Antonio zaprezentował jak zainstalować, skonfigurować i używać GlassFish. Wyglądało to jako typowy step-by-step turtorial - od pobierania instalki poprzez uruchamiania serwera i jego konfiguracje każdy etap został zaprezentowany z uprzednio przygotowanych filmików flashowych- nic nie miało prawo nie działać :). Filmiki zostały stworzone przez Antonio na podstawie kroków opisanych w GlassFish Quick Start Guides.
Serwer można zainstalować w 3 trybach: "development", "cluster", ""enterprise". Nie obyło się bez pokazania 2 alternatywnych interfejsów dostępu do serwera: Admin Console i asadmin oraz narzędzie (stworzone w swingu) do instalowania/aktualizowania komponentów samego serwera Update Center. Bardzo mi się spodobało, że Antionio miał przygotowane slajdy omawiające architekturę samego serwera i na tej podstawie wyjaśniał poszczególne pojęcia: domain, administration server, node agent, cental repository, cluster, server instance. Na końcu jeszcze krótka informacja na temat Glassfish V3 , jako referencyjnej implementacji JEE6, z modularną architekturą opartą na OSGI. Rozmawiając na temat OSGI w kontekście V3 z Antionio, usłyszałem, że jak na razie nie ma żadnych planów aby serwer mógł hostować aplikację użytkownika oparte na OSGI.
What's new in Java EE 6
Antonio Goncalves tym razem opowiadał na temat JEE6. Same wydanie specyfikacji jest dość mocno opóźnione z tym co pierwotnie zakładano, a dodatkowo wokół paru specyfikacji zrobiło się dość dużo szumu i wiele emocji :). W JEE 6 pewne specyfikacje zostały "wycięte" m.in.: JAX-RPC, EJB 2.1 entity beans, JSR 88, JAXR. Wprowadzono w końcu pojęcie profili, czyli JEE ma przestać być jednym wielkim monolitycznym kolosem w stylu one size fits all. Aktualnie w przygotowaniu są 3 profile, przy czym jakie specyfikacje będą należeć do jakiego profilu jeszcze nie jest w 100 % pewne.
JEE6 wprowadza wiele zmian i to, w każdej warstwie JEE:
- Servlets 3.0 (annotacje, fragments, możliwośc rejestrowania/odrejestrowywania servletów, przetwarzanie asynchroniczne), JSF 2.0, AJAX support, JSP jako technologia niszowa
- JAX-WS 2.2, JAX-RS(nie wspiera client-side REST)
- EJB 3.1(optional local intefaces), @Singleton (per application per JVM), @ConcurrencyManagement, EJB Lite, EJB asynchronous methods ( zwracją null lub Future, domyślnie dla nich Propagation.Requires_NEW), możliwość pakowania EJB w WAR, globalne ( przenośne) nazwy JNDI, Timer Services API( prawie jak Cron), Embeddable EJB Container
- JPA 2.0 (m.in. mapowanie kolekcji komponentów, rozbudowa JPQL, dodatnie Criteria API, nowe mechanizmy lockowania)
- Web Beans przemianowane na JDCI
Batch processing = EJB Lite + Timer + Asynch calls + Embeddable Container
Automation of functional tests
Tomasza Kaczanowskiego w swojej prezentacji przedstawił nam idee automatyzacji testów funkcjonalnych. W przypadku testów funkcjonalnych pojawia się zawsze problem związany z przygotowaniem środowiska uruchomieniowego dla testów, które powinno jak najbardziej przypominać środowisko produkcyjne. Przygotowanie takiego środowiska oraz mechanizmu automatyzacji testów funkcjonalnych nie zawsze jest łatwe/możliwe do osiągnięcia i często trzeba do tego podejśc pragmatycznie. Tomasz na podstawie własnych doświadczeń przedstawił w jaki sposób przeprowadził automatyczne funkcjonalne testowanie 2 odmiennych systemów: klasyczny system JEE z interfejsem web, system oparty na OSGI z interfejsem SOAP WebSerices. Przygotowanie środowiska dla testów funkcjonalnych zostało rozbite na poszczególne fazy:
- stworzenie bazy danych -przykładowe narzędzia: hibernate3-maven-plugin, SQL-maven-plugin
- załadowanie danych - użycie DBUnit (podobno DBUnit ma problemy z ładowaniem duzej ilości kodu napisanego w PL/SQL), SQL-maven-plugin
- wrzucenia aplikacji - cargo-maven-plugin, capistarano ?
- uruchomienie testów - selenium-maven-plugin, soapui-maven-plugin
SOLID design principles
Super zabawna prezentacja przeprowadzona w typowym włoskim stylu. Prezentacja bazuje na
Object Oriented Design principles zdefiniowanych przez wujka Boba czyli Boba Martina.
Bruno Bussola zaczął od omówienia czemu powinno nam zależeć na posiadaniu "good design" oraz jakie są symptomy, że coś jest nie tak z naszym designem:
- rigidity - wprowadzenie zmiany jest nieprzewidywalne(bardzo trudne/nie możliwe do oszacowania pod względem czasu i kosztu). Nawet mała zmiana powoduje, że musimy zmieniać coraz to kolejne elementy (change marathon)
- fragility - wprowadzenie zmiany w jednym elemencie powoduje, że zaczyna "się sypać" w innym teoretycznie nie powiązanym fragmencie
- immobility - poszczególne elementy są ze sobą tak powiązane, że nie ma szans aby "wyjąc" pojedyńczy element i re-użyć go.
- viscosity - przy wprowadzeniu zmiany o wiele łatwiej jest napisać "hack"niż zrobić to poprawnie - zgodnie z designem
- Single Responsibility Principle - klasa powinna odpowiadać za tylko 1 aspekt(posiadać pojedynczą odpowiedzialność), czyli powinien być tylko pojedynczy powód dla którego mielibyśmy wprowadzać zmiany w klasie. Przykładowo, klasa Employ nie powinna jednocześnie posiadać metod związanych z obliczaniem pensji, persystencją i generowaniem raportu na podstawie danych użytkownika, a interfejs Modem nie powinien posiadać metod związanych z obsługa komunikacji(stop/start) i obsługą komunikatów. Dośc łatwo jest znaleźć klasy, które łamią te zasady: są to zazwyczaj te, które pełnią role facady: *Controller, *Manager
- Open-Closed Principle: powinniśmy móc dodawać nową funkcjonalność do naszego kodu bez dokonywania zmiany w istniejącym kodzie. W Javie stosunkowo łatwo się implementuję tę zasadę za pomocą polimorfizmu. Oczywiście trzeba starać się/umieć przewidzieć jakie funkcjonalności mogą/mają szansę się zmienić...
- Liskov Substitution Principle - zasada zastępowania, czyli możliwość przekazania zamiast obiektu danej klasy, obiekt podklasy bez zmieniania żadnych oczekiwanych zachowań. Wszystko to bardzo ładnie przedstawia przykład kwadrat i prostokąt. Czy kwadrat jest prostokątem? Z matematycznego punktu widzenia tak, ale niestety takie myślenie nie jest zgodne z tą zasadą. Prostokąt ma szerokość i wysokość, przy czym obie te wartości są niezależne - możemy zmienić jeden z wymiarów bez zmieniania drugiego z nich. Kwadrat ma tylko 1 wymiar - szerokość, ale skoro widzimy go jako prostokąt to możemy zmieniać jego wysokość i szerokość. Zmiana jakiejkolwiek z tych wartości wpływa bezpośrednio na drugą, czyli łamie kontrakt określony przez prostokąt.
- Interface Segregation Principle - zasada określająca, że powinniśmy używać interfejsów do definiowania zależności pomiędzy 2 elementami kodu. Jeśli klasa wystawia kilka "grup powiązanych metod", w szczególności gdy każda z tych grup jest wykorzystywana przez innego klienta, zależnośći takie powinno się przedstawić w postaci pojedynczego interfejsu dla każdej z "grup metod"(pojedynczy klient zależy od pojedynczego interefejsu, który enkaspuluje powiązane ze soba metody, a nie od interfejsu zawierającego wszystkie możliwe metody)
- Dependecy Inversion Principle - Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji. Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji.
Developing RESTful Web services with Jersey
Prezentacja Jakuba Podlesaka na temat JAX-RS, a w szczególności projektu Jersey. Zaczęło się standardowo od tego czym jest REST: resources, uniform service interface, multiple representations, hypermedia exhchange (boot URI paradigm), stateless. Jersey będący RI JAX-RS może zostać uruchomiony w Java Servlets Container, embedded HTTP Server, JAX-WS Provider. Jesrsey (nie wiem czy jest to w specyfikacji JAX-RS) jest w stanie wygenerować nam WADL, dokument opisujący nasze usługi oraz dodatkowo wprowadza @Consume. Annotacja ta pozwala na bindowanie ciała żądania HTTP do obiektu. Z tego co wiem to jest to coś nad czym aktualnie pracuje Arejn Poustsma w ramach Spring @Rest.
Jeresey out-of-box wspiera JAXB, czyli marshalling/unmarshalling w formatach XML oraz JSON jest zapewniony. Content-negotiation jest określany na podstawie nagłówka Accept oraz rozszerzenia zasobu. Aby wysyłać z poziomu przeglądarki żądania HTTP: PUT i DELETE używany był plugin do firefox - Poster.
Pomimo tego, że JAX-RS dotyczy jedynie warstwy serwerowej Jersej posiada także API dla klientów usług REST.
Brak komentarzy:
Prześlij komentarz