SOA to nie jest worek z usługami!

Często spotykam się z podejściem, w którym ogranicza się SOA do roli worka z usługami. Zgodnie z tym podejściem trzeba mieć dobry worek – tj. ESB + rejestr UDDI – i to w zasadzie powinno wystarczyć, by osiągnąć korzyści związane z SOA. Otóż nie wystarczy!

Przeważnie struktury organizacyjne firm są dużo bardziej skompilowane niż to, co daje się wyrazić na dowolnym rysunku. W szczególności, firma, a także jej poszczególne piony – w tym IT – składają się z kilku (-nastu, -dziesięciu, -set) niezależnych grup. Często grupy te posiadają duże autonomie.

Kilka spośród wspomnianych grup w pionie IT zainteresowanych jest „wdrożeniem SOA”, tj. – tłumacząc na nieco bardziej przyziemny język – chciałoby zacząć przygodę z implementacją nowych projektów w oparciu o WebService’y. No i zaczynają.

Po pewnym czasie pada decyzja o „wdrożeniu SOA” na poziomie korporacyjnym, które to wdrożenie polegałoby na synchronizacji wysiłków tychże niezależnych grup. Zaczyna się kucie żelaza.

Postanawia się, że trzeba zainstalować ESB i rejestr UDDI, aby usługi wytwarzane przez poszczególne grupy mogły być łatwo „upubliczniane”. Po chwili dochodzi się do wniosku, że w zasadzie to nie jest potrzebne jedno, wspólne ESB. Różne grupy mają swoich różnych faworytów a ponadto (co pewnie ważniejsze) każda z grup chce mieć pełną kontrolę nad środowiskiem – tak jak to było do tej pory – aby móc pracować w sposób najwygodniejszy dla siebie. Mamy więc kilka instancji ESB (co akurat nie ma rzeczywiście większego znaczenia) oraz wspólny rejestr UDDI. Upiiii! Udało się! … No tak, tylko co się udało? Oczywiście udało się wiele, ale nie jesteśmy jeszcze nawet blisko pełnego wdrożenia SOA.

To co otrzymaliśmy w efekcie to „worek usług” – usługi wytwarzane są przez kilka niezależnych grup, które po prostu rejestrują to co zrobią w UDDIu i spodziewają się, że będzie to użyteczne dla innych.

Naturalnie jeden worek drugiemu nierówny – worek świeżych pomarańczy dla przykładu to całkiem miła perspektywa; tyle że w praktyce otrzymamy raczej worek podgniłych bulw niewiadomego – i zapewne bardzo różnego – gatunku, bliższego raczej ziemniakom niż cytrusom. Dlaczego tak marnie oceniam perspektywę zawartości worka, do którego wrzuca się na zasadach opisanych w poprzednim akapicie? O tym poniżej.

Wszystko dzieje się za sprawą rozbieżności celów i konfliktu interesów. Wyobraźmy sobie taką – zupełnie codzienną – sytuację: do jednej z grup używających SOA w modelu worka usług przychodzi przedstawiciel biznesu i składa żądanie wykonania nowej aplikacji, dostarczającej jakichś tam, bliżej jeszcze nie określonych, funkcjonalności. Od razu pada też termin – ma być za 3 miesiące! Po krótkich przepychankach namaszcza się kierownika projektu, któremu stawia się jeden cel i w którego interesie leży osiągnięcie tego celu. Tym celem jest naturalnie dostarczenie wspomnianych funkcjonalności na czas!

Aplikacja ma między innymi wysyłać maile i w razie potrzeby rejestrować eskalacje. Usługa do wysyłania maili jest już zaimplementowana i zarejestrowana w UDDIu, ktoś tam wykonał też system obsługi reklamacji, który udostępnia – poprzez usługi zarejestrowane w UDDIu – funkcjonalność związaną z eskalacjami. Super! Wystarczy jeszcze napisać 4 usługi do przeglądania danych klientów i 2 do przeglądania danych zamówień. Józek zna świetny framework do robienia GUI dla WebService’ów (polecam TIBCO GI – patrz artykuł „TIBCO General Interface – Warstwa widoku dla SOA”); damy radę! Byle tylko działać szybko. Jakie mają być usługi? Po pierwsze mają działać a po drugie mają być dostarczone na czas, tj. za miesiąc, żeby było na czym testować GUI.

Usługi SOA – przy przyjęciu modelu „SOA jako worek usług” – będą właśnie takie jakie mogą być, jeśli jedynym stawianym celem będzie poprawność działania i czas dostarczenia. Oczywiście wszystko to są cele zupełnie zasadnicze, ale brakuje jeszcze postawienia co najmniej dwu celów: jakości i spójności. To, jak bardzo mogą się różnić miedzy sobą worki z usługami wykonanymi z, albo bez stawiania tych celów, oraz co precyzyjnie kryje się za celami pod kryptonimem „jakość” i „spójność” to już osobna dyskusja.

Oczywiście łatwo powiedzieć, że należy najzwyczajniej w świecie postawić odpowiednie cele, tyle że przede wszystkim trzeba mieć komu je stawiać i trzeba kogoś kto w sposób obiektywny oceni, w jakim stopniu cele te są osiągane. W modelu opisanym powyżej, gdzie SOA to worek, do którego wrzuca się dowolnie usługi wykonane przy okazji implementacji projektów biznesowych, nie ma osób ani mechanizmów, które pozwalałyby na stawianie i osiąganie tych celów.

SOA to oczywiście jest w dużej mierze pewna kolekcja usług, tyle że powinna to być kolekcja budowana świadomie, nie zaś luźny worek. Ważne jest, aby ta kolekcja usług była rozwijana i utrzymywana przez grupę powołaną w tym właśnie celu. Nadrzędnym, a najlepiej jedynym celem tej grupy powinno być dostarczanie usług, które oprócz tego że działają i są dostarczane sprawnie, są także wykonane zgodnie z wszelkimi kanonami sztuki. Różnica między produktami takiej dedykowanej grupy (zwanej Centrum Kompetencyjne SOA) a zsumowanymi produktami grup które mają postawione zupełnie inne cele (tj. cele zaspokajania bieżących potrzeb biznesu) może być krytyczna – krytyczna dla oceny, czy SOA ma sens czy nie.

Proces wytwórczy usług SOA, w podejściu nastawionym na jakość i wartość ponad-projektową, opisałem w artykule „Proces dostarczenia usług w architekturze SOA”.

Wdrożenie SOA metodą małych kroków

SOA jest strategią w dużej mierze specyficzną: trudno oszacować zwrot z inwestycji; trudno stwierdzić czy dany – wdrożony w jakiejś firmie - zestaw mechanizmów i procedur to już SOA, czy jeszcze nie; trudno nawet powiedzieć co to jest SOA. Oczywiście chodzi o takie SOA które dostarcza to czego się po nim spodziewamy; bo jeśli sam fakt „wdrożenia SOA” ma kogokolwiek uszczęśliwić, to nic nie stoi na przeszkodzie żeby przykleić tę etykietę do czegokolwiek, w dowolnej chwili.

Nie sposób ocenić perspektywy zwrotu z inwestycji w SOA, zatem zapewne warto postarać się tę inwestycję – w sensie kosztu – zmniejszyć. Koszt można skutecznie zmniejszyć obierając strategię wdrożenia nazwaną przeze mnie tutaj - mało innowacyjnie - strategią małych kroków.

Sedno strategii małych kroków można przekazać w kilku zdaniach. Przede wszystkim unikamy dużych inwestycji w SOA samo w sobie. Podłączamy się raczej do projektów które mają już uzasadnienie biznesowe (i budżet) z racji dostarczania pożądanych funkcjonalności. Zacznijmy więc od nakreślenia naszej wizji – wymarzmy sobie, jak byśmy chcieli by nasze SOA wyglądało – i zacznijmy wdrażać po kawałeczku przy okazji realizacji kolejnych projektów, mających swoje niezależne uzasadnienie i finansowanie.

Najprawdopodobniej postęp wdrożenia SOA będzie blokowany, jeśli tylko zacznie ono być postrzegane bardziej jak kula u nogi (ryzyko), niż jak światełko w tunelu (szansa). Zadbajmy więc o odpowiedni dobór projektów pilotażowych – projektów które staną się naszym poligonem doświadczalno-wdrożeniowym.

Należy wybierać takie projekty-piloty, które mają duże szanse powodzenia – aby uniknąć ryzyka zwalenia winy na SOA, w razie gdyby projekt-pilot zakończył się fiaskiem.

Należy wybierać takie projekty-piloty w których istotna – najlepiej krytyczna – część funkcjonalności w sposób naturalny może być zaimplementowana za pomocą zestawu usług i w których fakt implementacji tych funkcjonalności za pomocą usług znacznie upraszcza implementację aplikacji samych w sobie (tj. reszty projektu nie będącej usługami).

Wybierajmy takie projekty-piloty, które dają szansę na re-używanie usług, a więc projekty używające w dużym zakresie tych samych obiektów (danych) biznesowych.

Implementujmy i testujemy przy okazji implementacji projektów-pilotów narzędzia i procesy uniwersalne – tj. należące do infrastruktury SOA - ułatwiające implementacje, utrzymanie i dokumentację usług, tak aby z czasem SOA zaczęła wnosić większy bagaż korzyści niż kosztów. Taka marchewka szybko zacznie przyciągać jednostki zewnętrzne. Oczywiście pod warunkiem, że uda nam się owe jednostki zewnętrzne przekonać, że marchewka jest duża.

Metodą przeciwstawną do metody drobnych kroków jest metoda inicjalnej inwestycji. Jeśli zależy nam na czasie, dysponujemy znacznymi środkami, dobrym zespołem ludzi, którzy wiedzą co i jak oraz nie boimy się, że może się nie udać, to… to mimo wszystko nie koniecznie warto się decydować. Wdrożenie SOA jest przedsięwzięciem na tyle skomplikowanym, że zawsze powinien to być proces szyty na miarę. Szycie wymaga czasu i… wielu poprawek krawieckich, tym bardziej że środowisko w którym szyjemy ma tendencje do zmieniania się w czasie.

Rzecz jasna całkiem bez inwestycji nie obędzie się tak czy inaczej. Tak czy inaczej trzeba oddelegować do tych zadań kilka osób, przynajmniej w częściowym wymiarze. Tak czy inaczej nie obędzie się bez jakichś serwerów. Tak czy inaczej trzeba rozważyć kwestię oprogramowania – być może najtaniej (biorąc pod uwagę koszt roboczogodzin programistów) będzie kupić jakiś dobry, kompletny produkt.

Osobnym problemem strategicznym jest wybór między marchewką i kijem. Ja osobiście jestem zwolennikiem mariażu, tj. należy zadbać o to, aby SOA było przede wszystkim atrakcyjne (marchewka), ale należy też aktywnie zachęcać niezależne jednostki istniejące w firmie, by przynajmniej spróbowały podporządkować się opracowanym regułom i technikom tworzenia rozwiązań w architekturze SOA (kij). Oczywiście dając tymże jednostkom prawo do zgłaszania obiekcji.

Fix na problemy z aplikacjami WWW w IE8

Jeśli ktoś ma aplikację WWW, która wygląda OK w IE7 a w IE8 zaczęła się rozłazić - i naturalnie chciałby to poprawić - to okazuje się, że jest na to prosty sposób. Wystarczy dodać nagłówek:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

Rusza sprzedaż mojej książki do SCJP

Właśnie odebrałem z drukarni 150 egzemplarzy drugiego wydania mojej książki "Przygotowanie do certyfikacji SCJP 6". Tym samym rusza sprzedaż. Zainteresowanych kupnem zapraszam do serwisu getSCJP.pl.

Drukowana wersja mojej książki do SCJP

Właśnie odebrałem z drukarni egzemplarz próbny drugiego wydania mojej książki "Przygotowanie do certyfikacji SCJP 6"! Wyszło całkiem dobrze i tym samym ruszam z drukiem - nakład ma być gotowy na najbliższy poniedziałek. Poniżej "rozkładówka" okładki.

Zdecydowałem się na wydruk 150 szt. Przy druku offsetowym cena per egzemplarz drastycznie spada wraz ze zwiększaniem nakładu więc zdecydowałem się na zwiększenie planowanej pierwotnie liczby. 24 sztuki pójdą do bibliotek w ramach egzemplarza obowiązkowego, kilka sztuk rozdam, kilka zostawię dla siebie, więc do sprzedaży zostanie pewnie jakieś 110 sztuk. Koszt druku zwróci mi się jeśli sprzedam mniej więcej połowę z tego. Jestem dobrej myśli:)

Wydanie drugie różni się w stosunku do pierwszego - dostępnego nieodpłatnie w postaci plików PDF - kilkoma rzeczami. Przede wszystkim książka została zaktualizowana tak by odpowiadać najnowszej wersji egzaminu na SCJP 6. Poprawiono także wszystkie błędy wskazane przez czytelników, w tym błędy ortograficzne oraz błędy składu.

Przy okazji - to bardzo miłe uczucie, trzymać w rękach książkę własnego autorstwa. Jeszcze milej będzie sprzedać choć kilkadziesiąt egzemplarzy i wiedzieć, że jest ona użyteczna.

Monitorowanie JVM z użyciem JConsole

Zdarzyło mi się ostatnio popełnić aplikację, która intensywnie tworzy nowe wątki. Wątki te powinny istnieć od kilku do kilkudziesięciu sekund. Niby wszystko działa, ale jak by się tu upewnić, że wątki rzeczywiście kończą się niezawodnie po wykonaniu swojej pracy? Najwygodniej byłoby monitorować ich liczbę z użyciem jakiegoś narzędzia do monitorowania JVM. Takim narzędziem, prostym i ogólnodostępnym (jest częścią JDK) jest JConsole.

Przede wszystkim trzeba włączyć możliwość monitorowania JVM, tj. należy uruchomić monitorowaną aplikację przekazując do JVM (do polecenia java) argument:

-Dcom.sun.management.jmxremote

Następnie, za pomocą polecenia:

jps

należy sprawdzić ID procesu JVM i już możemy uruchomić aplikacje JConsole wydając polecenie:

jconsole <ID procesu JVM>

To wystarczy by cieszyć oczy wykresami, które są takie ładne, że nawet nadają się do pokazania swojemu Managerowi. Przykładowo, interesujący nas wykres pokazujący liczbę wątków:

Statystyki dla bloga z pomocą Google Analytics

Dostałem wczoraj od Grzegorza Duda pytanie o statystyki mojego bloga... zawstydziłem się, że mam je takie słabe - nie w tym sensie, że mam mało odsłon, tylko w tym, że np. nie wiem jaki procent ruchu przychodzi z konkretnych witryn - i postanowiłem coś z tym zrobić. Rozwiązanie oczywiście jest banalne - Google Analytics. Jak to skonfigurować do monitorowania bloga na blogspocie można przeczytać - po angielsku - w artykule "How to track your Blogger statistics with Google". Ja właśnie zrobiłem to u siebie. Co prawda chwalę dzień przed zachodem słońca bo jeszcze nie wiem czy i jak będzie to działało, ale zakładam że będzie OK. W końcu tyle już dobrego o GA słyszałem.

Książka gotowa!

Właśnie opublikowałem ostatni rozdział. Niniejszym ogłaszam więc, że wydanie pierwsze książki "Przygotowanie do certyfikacji SCJP 6" zostało ukończone. Zapraszam do lektury! A poniżej wykres pokazujący liczbę dotychczasowych unikalnych pobrań poszczególnych rozdziałów. Właściwie to jest to liczba unikalnych IP z jakich pobrano poszczególne pliki. Sam nie wiem czy to dużo czy mało. Zawsze coś.

Książka już prawie gotowa

Jest już przedostatni rozdział mojej książki do SCJP. Jeszcze tylko jeden i będzie koniec. Przy okazji - dziękuję wszystkim którzy dopytują się mnie czemu tak długo nie publikowałem kolejnych rozdziałów i tym samym mobilizują mnie do sprawnego przejścia z trybu wakacyjnego do trybu pracy. Dziękuję także za wszelkie uwagi co do książki. Okazuje się, że zastrzeżenia dotyczą głównie błędów ortograficznych i błędów składu. Postanowiłem, że w drugim wydaniu książki ten problem musi być wyeliminowany. Ze wstępnego rekonesansu wnioskuję, że zlecenie profesjonaliście korekty książki tej objętości to jakieś 500-800 PLN (3-4 PLN za stronę A4). Chyba trzeba się będzie zdecydować - powinno się zwrócić jeśli uda mi się sprzedać z 50 sztuk wersji drukowanej. Zobaczymy.

Zmienił się egzamin na certyfikat SCJP 6

Jak donosi kolega Kamil Wójcik zmienił się nieco egzamin na certyfikat SCJP 6. Wszystkich których interesuje co się konkretnie zmieniło zapraszam do lektury informacji na ten temat, którą to opublikowałem na moim portalu getSCJP.pl na stronie "Zmiany w egzaminie na SCJP 6".

Jest nowy rozdział książki do SCJP

Właśnie opublikowałem kolejny rozdział mojej książki do SCJP - "Wątki". Zostały jeszcze dwa rozdziały i będzie komplet. Przy okazji - pod koniec lipca wybieram się na dłuższy urlop co jest równoznaczne z wstrzymaniem prac. Nie wiem czy zdążę do tego czasu ukończyć książkę. Pewnie nie, zatem przyjdzie na ten moment poczekać do przełomu sierpnia i września.

Ze spraw organizacyjnych związanych z wydaniem książki - właśnie otrzymałem informację, że zostałem zarejestrowany jako wydawca w ogólnoświatowej bazie wydawców i jednocześnie, że przydzielono mi do wykorzystania pulę 10-ciu numerów ISBN (akr. International Standard Book Number).

W międzyczasie zacząłem zgłębiać temat tzw. egzemplarzy obowiązkowych. Okazuje się, że istnieje obowiązek przekazywania bibliotekom publicznym egzemplarzy wszystkiego co wydawane jest na terytorium RP. W sumie wyjdzie tego 24 egzemplarze (20 bibliotek po jednym egzemplarzu oraz po 2 egzemplarze dla Biblioteki Narodowej i Biblioteki Jagiellońskiej). Co ciekawe, trzeba przekazywać także egzemplarze publikacji elektronicznych, także tych publikowanych wyłącznie w Internecie. Nie udało mi się jeszcze ustalić co to jest egzemplarz publikacji udostępnianej wyłącznie w formie elektronicznej w sieci. Napisałem w tej sprawie zapytanie. Może trzeba będzie nagrać na CD/DVD?

Co to znaczy "dobrze napisać artykuł"?

Zainteresowałem się ostatnio na poważnie (z racji książki którą piszę) problematyką sprawnego władania językiem... polskim, z naciskiem na język pisany. Kupiłem opasłe tomisko traktujące o tymże języku i rozpocząłem mozolne (książka jest niezwykle gruba) studia. A tymczasem dostaję komentarz czytelnika do mojego ostatniego artykułu - że jest nieczytelny (choć merytorycznie dobry), z racji braku podziału na akapity.

Postanowiłem więc przeprowadzić eksperyment i przeredagowałem tekst co nieco. Tekst podzieliłem na akapity, które przy okazji przekonstruowałem tak, by nadać im w miarę możliwości charakter analityczny.

Akapit analityczny (powtarzam z pamięci za książką o której przed chwilą wspomniałem) to taki akapit, który zaczyna się od natychmiastowego - w pierwszym zdaniu - przedstawienia treści akapitu. Dalsze zdania stanowią rozwinięcie i wyjaśnienie stwierdzenia otwierającego akapit. Chodzi o to, aby dało się czytając tylko pierwsze zdania każdego akapitu wyłapać sens i tematykę tekstu. Naturalnie nie zawsze i nie każdy akapit powinien być właśnie taki - urozmaicenie formy też jest wskazane.

Zobaczmy co z tego wyszło i czy jest lepiej. Oto artykuł "Co to znaczy "dobrze wykonać projekt"?" w wersji 2.0:

Co to właściwie znaczy „dobrze wykonać projekt”? Zamyśliłem się co nieco nad tym inspirowany konferencją, na której ostatnio zdarzyło mi się gościć, a właściwie tym co tam usłyszałem. Widziałem na konferencji świetną prezentację o programowaniu sterowanym testami – brawa dla prelegenta; na innej prelekcji z kolei słyszałem uszczypliwe żarty ze strony publiki wykpiwającej praktyki wykonywania poprawek (tzn. bug-fixów) bezpośrednio na systemie produkcyjnym. Ktoś tam jeszcze mówił o ciągłej integracji (na tej prelekcji nie byłem), ktoś inny w jeszcze inny sposób promował techniki i sposoby tworzenia „dobrego” oprogramowania.

Odnoszę wrażenie, że wszyscy jako aksjomat przyjmują, że aplikacja powinna być zrobiona przede wszystkim „dobrze”; możliwie kompleksowo przetestowana, możliwie jak najprzyzwoiciej wdrożona.

Ja tymczasem mam wrażenie, że w rzeczywistości rzadko chodzi o osiągnięcie właśnie tych celów. Właściwie wymienione powyżej to raczej środki do pewnego celu a nie same cele, tylko czy rzeczywiście zastanawiamy się nad tym, co jest prawdziwym celem?

Oczywiście wszyscy mamy potrzebę odczuwania zadowolenia z wykonywanej przez siebie pracy – a satysfakcję mamy przeważnie z pracy wykonanej dobrze – tyle tylko, że może nie do końca potrafimy sobie zdefiniować, co to „dobrze” oznacza.

Dobrze – w pewnej konkretnej sytuacji – może przecież oznaczać przede wszystkim szybko. Może firma która zleca nam wykonanie jakiegoś rozwiązania ma w planach zakup albo wykonanie poważnego systemu w przyszłości a póki co chcą tylko czegoś taniego i wykonanego szybko, po to by móc dodać do swej oferty możliwie szybko nowy produkt; po to by pomóc sobie samemu zdefiniować wymagania funkcjonalne dla aplikacji docelowej? A może są jeszcze jakieś inne powody? A może nie powinniśmy się zastanawiać dlaczego? Może po prostu powinniśmy słuchać i starać się odpowiadać na rzeczywiste zapotrzebowania, zgłaszane przez tego, który za implementację nowego rozwiązania zapłaci?

To co staram się powiedzieć można de facto wyrazić w jednym zdaniu – dopasowujmy sposób pracy (sposób wykonywania i wdrażania rozwiązań) do faktycznych celów i istniejących założeń, nie do aksjomatów narzuconych nam nie wiadomo jak, kiedy i przez kogo.

Pamiętajmy jednak aby nie popadać ze skrajności w skrajność. Gdybyśmy rzeczywiście zechcieli kiedyś pokusić się o dostarczenie rozwiązania-prowizorki, nie zapominajmy, że prowizorki często są najtrwalsze. A jeśli już zdecydujemy się na wypuszczenie naprędce upichconego gniota, to liczmy się z tym, że ktoś kiedyś – nie rozumiejąc okoliczności – zapyta… „kto tą aplikację (…) wykonał”? No ale sztuka kreowania wizerunku i zabezpieczania się przed potencjalnymi atakami to już inny temat.

Co to znaczy "dobrze wykonać projekt"?

Inspirowany co nieco konferencją na której ostatnio zdarzyło mi się gościć, a właściwie tym co tam usłyszałem, zamyśliłem się co nieco nad tym, co to właściwie znaczy „dobrze wykonać projekt”. Widziałem na konferencji świetną prezentację o programowaniu sterowanym testami – brawa dla prelegenta; na innej prelekcji z kolei słyszałem uszczypliwe żarty ze strony publiki wykpiwającej praktyki wykonywania poprawek (tzn. bug-fixów) bezpośrednio na systemie produkcyjnym. Ktoś tam jeszcze mówił o ciągłej integracji (na tej prelekcji nie byłem), ktoś inny w jeszcze inny sposób promował techniki i sposoby tworzenia „dobrego” oprogramowania. Mam wrażenie, że wszyscy jako aksjomat przyjmują, że aplikacja powinna być zrobiona przede wszystkim „dobrze”, możliwie kompleksowo przetestowana, możliwie jak najprzyzwoiciej wdrożona. Tymczasem ja mam wrażenie, że w rzeczywistości rzadko chodzi o osiągnięcie właśnie tych celów. Właściwie wymienione powyżej to raczej środki do pewnego celu a nie same cele, tylko czy rzeczywiście zastanawiamy się nad tym, co jest prawdziwym celem? Oczywiście wszyscy mamy potrzebę odczuwania zadowolenia z wykonywanej przez siebie pracy – a satysfakcję mamy przeważnie z pracy wykonanej dobrze – tyle tylko, że może nie do końca potrafimy sobie zdefiniować, co to „dobrze” oznacza. A może dobrze w pewnej konkretnej sytuacji oznacza przede wszystkim szybko? Może firma która zleca nam wykonanie jakiegoś rozwiązania ma w planach zakup albo wykonanie poważnego systemu w przyszłości a póki co chcą tylko czegoś taniego i wykonanego szybko, po to by móc dodać do swej oferty możliwie szybko nowy produkt; po to by pomóc sobie samemu zdefiniować wymagania funkcjonalne dla aplikacji docelowej? A może są jeszcze jakieś inne powody? A może nie powinniśmy się zastanawiać dlaczego? Może po prostu powinniśmy słuchać i starać się odpowiadać na rzeczywiste zapotrzebowania, zgłaszane przez tego, który za implementację nowego rozwiązania zapłaci? To co staram się powiedzieć można de facto wyrazić w jednym zdaniu – dopasowujmy sposób pracy (sposób wykonywania i wdrażania rozwiązań) do faktycznych celów i istniejących założeń, nie do aksjomatów narzuconych nam nie wiadomo jak, kiedy i przez kogo. Pamiętajmy przy tym aby nie popadać ze skrajności w skrajność. Gdybyśmy rzeczywiście zechcieli kiedyś pokusić się o dostarczenie rozwiązania-prowizorki, nie zapominajmy, że prowizorki często są najtrwalsze. A jeśli już zdecydujemy się na wypuszczenie naprędce upichconego gniota, to liczmy się z tym, że ktoś kiedyś – nie rozumiejąc okoliczności – zapyta… „kto tą aplikację (…) wykonał”? No ale sztuka kreowania wizerunku i zabezpieczania się przed potencjalnymi atakami to już inny temat.

Opublikowałem rozdział "Kompilator oraz Maszyna Wirtualna"

Opublikowałem rozdział "Kompilator oraz Maszyna Wirtualna". Co prawda pisanie zakończyłem już jakoś w środę a opublikowałem de-facto w piątek, ale dopiero dziś znalazłem chwilę by podzielić się z wami tą radosną nowiną:) Wszystkich zainteresowanych moją książką do SCJP zapraszam ponownie na portal getSCJP.pl.

Jest kolejny rozdział książki o SCJP

Jest kolejny rozdział mojej książki o SCJP - rozdział pierwszy - pt. "Klasy, interfejsy, typy wyliczeniowe". Pokrywa on zakresem cele egzaminacyjne SCJP nr. 1.1, 1.2 i 7.1, tj.:

1.1 Napisz kod, w którym deklarujesz klasy (wliczając klasy abstrakcyjne i wszelkie formy klas zagnieżdżonych), interfejsy i typy wyliczeniowe oraz zademonstruj poprawne użycie instrukcji package i import (w tym import statyczny).

1.2 Napisz kod, w którym deklarujesz interfejs oraz kod, w którym implementujesz lub dziedziczysz z jednego lub wielu interfejsów. Zaimplementuj klasę abstrakcyjną oraz klasę, która dziedziczy z klasy abstrakcyjnej.

7.1 Mając podany fragment kodu oraz scenariusz napisz program w którym używasz odpowiednich modyfikatorów dostępu, prawidłowo deklarujesz pakiet oraz używasz instrukcji importu, w którym używasz podanego fragmentu kodu poprzez dziedziczenie lub kompozycję.

Jest już rozdział o kolekcjach i typach generycznych

Właśnie opublikowałem kolejny rozdział mojej książki "Przygotowanie do certyfikacji SCJP 6". Rozdział popkrywa temat kolekcji, map i typów generycznych. Radość moja z jego ukończenia tym większa, że jest on dość obszerny i w większości składa się z tekstów nie publikowanych na tym blogu w formie artykułów. Swoją drogą - często słyszy się, że ktoś nie do końca rozumie temat typów generycznych. Nie wiem czy to dlatego że jest to mechanizm względnie nowy (w porównaniu do samej Javy) czy że rzeczywiście względnie trudny. W każdym razie - niezależnie od certyfikacji SCJP - polecam wszystkim podjęcie próby zrozumienia tematu z pomocą mojej książki. No i oczywiście czekam na informację zwrotną... czy sie udało.

Jest rozdział "Zagadnienia programowania obiektowego"

Właśnie opublikowałem kolejny rozdział mojej książki do SCJP - "Zagadnienia programowania obiektowego". Rozdział pokrywa cele egzaminacyjne SCJP w zakresie punktów 5.1, 5.2 i 5.5, tj.:

5.1 Napisz kod zgodnie z pryncypiami ścisłej hermetyzacji, prostych zależności i dużej spójności oraz opisz zalety takiego kodu.

5.2 Mając podany scenariusz napisz kod w którym demonstrujesz zrozumienie polimorfizmu. Oceń, kiedy konieczne jest zastosowanie rzutowania oraz opisz błędy jakie mogą powstać w związku z rzutowaniem. Wskaż, które z tych błędów są błędami czasu wykonania a które błędami kompilacji.

5.5 Napisz kod, w którym występują relacje IS-A oraz HAS-A. Wyjaśnij, na czym polegają te relacje.

Jak element HTMLa LINK fałszuje statystyki stron

Właśnie zakończyłem proces dodawania kodu zliczającego odsłony mojego nowego portalu GetSCJP.pl i przy okazji tegoż wykryłem ciekawą rzecz która ma niebagatelne znaczenie dla uzyskania dobrych, tj. prawdziwych danych. Otóż jeśli na mojej stronie HTML był element LINK z atrybutem REL o wartości 'next' to Firefox (wersja 3.0.10) oprócz pobierania tej strony o której pobranie został poproszony pobierał także stronę wskazywaną przez tenże element LINK. Co prawda element LINK z atrybutem REL o wartości 'next' służy właśnie dlatego by wskazać przeglądarce jaka strona jest "następna w kolejce do przeglądania" (zgodnie z jakimiś tam przewidywaniami) więc nie ma nic złego w tym że Firefox za wczasu pobiera taką stronę starając się wyprzedzić żądania użytkownika, jednak z punktu widzenia osoby implementującej statystyki oznacza to tylko i wyłącznie fałszowanie danych. Jeśli więc - kimkolwiek jesteś - chcesz uzystać dla swoich stron prawdziwe statystyki upewnij się lepiej, że takich elementów LINK na twoich stronach nie ma. Dodam jeszcze że IE nie wykazywał takich zapędów "optymalizacyjnych".

Jest kolejny rozdział mojej książki do SCJP - Wyjątki

Właśnie opublikowałem kolejny rozdział mojej książki do SCJP pt. "Przygotowanie do certyfikacji SCJP 6". Rozdział ma tytuł "Wyjątki" i pokrywa cele egzaminacyjne SCJP w zakresie od punktu 2.4 (bez tematu przysłaniania metod) do 2.6, tj:

2.4 Napisz kod w którym używasz wyjątków i zaimplementuj kod obsługi wyjątków (try, catch, finally) oraz zadeklaruj metody i metody przysłaniające, które rzucają wyjątki.

2.5 Określ, jakie są efekty rzucenia wyjątku przez wskazany fragment danego programu. Wyjątek ten może być wyjątkiem kontrolowanym (tj. typu „checked”) jak i nie kontrolowanym (typu „un-checked”).

2.6 Określ, jakie sytuacje mogą spowodować rzucenie wyjątków: ArrayIndexOutOfBoundsException, AssertionError, IllegalStateException, llegalArgumentException, NumberFormatException, NullPointerException, ExceptionInInitializerError, StackOverflowError, ClassCastException oraz NoClassDefFoundError. Wskaż, które z nich są rzucane przez Wirtualną Maszynę Javy (ang. akr. JVM) a które – i w jakich okolicznościach – powinny być i są rzucane przez programistę.

Wydaję książkę do SCJP

W lutym 2008 ruszyłem z serią artykułów prezentujących materiał pod egzamin SCJP. Trwało to nieco ponad rok, ale w końcu akcja doczekała się końca który wieńczy dzieło. W miniony weekend powołałem do życia nowy portal – www.GetSCJP.pl – poświęcony w całości tej tematyce i rozpocząłem na tymże akcję publikacji mojej książki "Przygotowanie do certyfikacji SCJP 6". Książka jest już prawie gotowa i zdecydowałem się na upublicznienie jej we fragmentach. Będę ją publikował rozdział po rozdziale aż w końcu uda mi się skompletować całość (mam nadzieję zrobić to przed końcem wakacji studenckich). Pierwszy rozdział - "API" - już jest. Zapraszam do lektury i komentowania. Rozdział pokrywa cele egzaminacyjne SCJP w zakresie od punktu 3.1 do 3.5, tj:

3.1 Napisz kod, w którym używasz klas opakowujących typów prostych (np. Boolean, Character, Double, Integer) oraz wykorzystujesz funkcjonalność „auto-boxingu" i „un-boxingu". Wskaż różnice między klasami String, StringBuilder oraz StringBuffer.

3.2 Mając podany scenariusz pracy z systemem plików, czytania z plików, zapisu do plików oraz interakcji z użytkownikiem zaimplementuj rozwiązanie używając następujących klas z pakietu java.io: BufferedReader, BufferedWriter, File, FileReader, FileWriter, PrintWriter oraz Console.

3.3 Napis kod, w którym serializujesz oraz de-serializujesz obiekty używając następujących klas i interfejsów z pakietu java.io: DataInputStream, DataOutputStream, FileInputStream, FileOutputStream, ObjectInputStream, ObjectOutputStream oraz Serializable.

3.4 Używając klas standardu Java SE z pakietu java.text napisz kod, w którym formatujesz oraz parsujesz daty, liczby i wartości walutowe z uwzględnieniem lokalizacji. Mając podany scenariusz, wskaż metody których należy użyć aby uwzględnić konkretną albo domyślną lokalizację. Opisz przeznaczenie oraz sposób użycia klasy java.util.Locale.

3.5 Używając klas standardu Java SE z pakietu java.util oraz java.util.regex napisz kod, w którym formatujesz oraz parsujesz stringi lub strumienie. Napisz kod w którym używasz klas Pattern i Matcher oraz operacji split(...) z klasy String; użyj wyrażeń regularnych (ograniczone do elementów . (kropka), *, +, ?, \d, \s, \w, [] oraz ()). Elementy *, + oraz ? musisz umieć zastosować tylko jako operatory zachłanne a nawiasy jako elementy grupujące - nie jako mechanizm pobierania dopasowanych fragmentów tekstu. Dla operacji na strumieniach napisz kod który używa klas Formatter i Scanner oraz operacji printf(...) i format(...) z klasy PrintWriter. Użyj odpowiednich parametrów formatujących tekst (ograniczone do parametrów %b, %c, %d, %f oraz %s).

Tłumaczenie "open-source" jako "otwartoźródłowa"

Natrafiłem dziś w sieci (w artykule "Direct Web Remoting (DWR) 3.0 w wersji Release Candidate") na termin "otwartoźródłowa" (np. biblioteka otwartoźródłowa) w miejscu gdzie większość z nas użyłaby terminu "open-source" (np. biblioteka open-source). Co myślicie o takim tłumaczeniu? Znacie może jeszcze jakieś inne, zgrabne i jednoznaczne? Przyznam, że mi termin otwartoźródłowa się spodobał i zamierzam zacząć go używać.

Proces dostarczenia usług w architekturze SOA

Model funkcjonowania działów IT w firmach, widziany z lotu ptaka, jest dosyć prosty. IT pełni rolę czysto służebną, tj. ma za zadanie dostarczać rozwiązania informatyczne zaspokajające pewne potrzeby, tudzież kaprysy osób odpowiedzialnych za rozwój biznesu. Przedstawiciel biznesu zgłasza więc do działu IT zapotrzebowanie na nowe oprogramowanie wraz z szeregiem wymagań, które odnoszą się do tego, jak dana aplikacja ma wyglądać i funkcjonować i tym samym uruchamia odpowiedni proces analizy. Przeważnie wybrany zostanie ktoś odpowiedzialny za realizacje tych wymagań, tj. kierownik projektu. Jeśli realizowana aplikacja nie jest trywialna to z pewnością będzie ona wymagała interakcji z istniejącymi w firmie systemami, czy to finansowymi, sprzedażowymi, magazynowymi czy jakimikolwiek jeszcze innymi. W organizacji opartej na architekturze zorientowanej na usługi (tj. SOA) powinno się dążyć do tego, aby osoba odpowiedzialna za realizację zadania zdefiniowanego przez biznes mogła się skupić na tymże, komunikując światu zewnętrznemu – z którym realizowana aplikacja potrzebuje się komunikować – jedynie pewne niezbędne minimum, tj. czego ona od tego świata zewnętrznego chce. A chce ona od niego, aby wykonał na żądanie pewne określone zadania, tj. mówiąc innym językiem, aby udostępnił pewne usługi. Z punktu widzenia wspomnianego kierownika projektu szczególnie korzystne byłoby, gdyby mógł się on ograniczyć do sporządzenia listy usług, które muszą mu być dostarczone przez systemy zewnętrzne dla umożliwienia realizacji jego zadania. Lista ta staje się punktem wyjścia do uruchomienia nowego procesu zarządzania (ang. governance) architekturą SOA – procesu dostarczenia usług.

Proces dostarczenia usług składa się z kilku zasadniczych kroków. W pierwszym kroku zespół który ma za zadanie dostarczyć usługi przeprowadza wstępną analizę wymagań klienta – klient występuje tu w rozumieniu osoby która zgłasza zapotrzebowanie na usługi. Mając nakreślony w sposób ogólny wymagany zakres funkcjonalny i informacyjny dla każdej usługi należy ustalić, czy usługa o podobnym zakresie funkcjonalnym już istnieje, czy jest to usługa zupełnie nowa. Należy tutaj podkreślić, że osoby odpowiedzialne za dostarczenie usługi powinny podjąć wysiłek nakierowania żądań swego klienta na właściwe tory, jeśli stawiane przez niego wymagania nie wpisują się w dotychczas znane i realizowane schematy. Może zdarzyć się bowiem, że dekompozycja funkcjonalności aplikacji na usługi została wykonana nie prawidłowo i wymagana jest korekta. W szczególności, może zdarzyć się, że istnieje usługa o odpowiednim znaczeniu funkcjonalnym ale posługująca się innym zakresem informacyjnym. Jest to wyraźny sygnał, że należy podjąć wysiłek uspójnienia procesów biznesowych i używanego modelu danych. Należy pamiętać o tym, że usługi powinny odpowiadać pewnym operacjom mającym sens z punktu widzenia prowadzonego biznesu i należy dbać o utrzymanie spójności znaczeniowej usług z funkcjami biznesowymi.

Proces analizy – analizy prowadzącej do porozumienia obydwu stron, tj. klienta i dostawcy usług – nakreślony w powyższym akapicie koniec końców prowadzi do ustalenia się pewnej listy usług, z pośród usług istniejących, które mogą być użyte bez zmian, listy usług które są na tyle podobne, że wymagają jedynie pewnego dostosowania oraz listy usług zupełnie nowych, które muszą być zaimplementowane od podstaw. Usługi powinny być implementowane w oparciu o technologie które ściśle separują specyfikację usługi od jej implementacji; wymóg ten spełniają usługi sieciowe oparte o standardy SOAP i WSDL. Umożliwia to i promuje podział procesu wykonania usługi na fazę opracowania interfejsu i fazę implementacji. Dostawca usług w pierwszej fazie tworzy i przedstawia do akceptacji klientowi kontrakt usługi w postaci pliku WSDL a dopiero potem przechodzi do implementacji. Możliwość ustalenia interfejsu przed wykonaniem usługi ma ogromne znaczenie dla skrócenia czasu implementacji całego rozwiązania – zespół implementujący aplikację nie musi bowiem oczekiwać ze swoimi pracami na wykonanie całości pracy przez dostawcę usług. Aplikacja kliencka może być w pełni zaimplementowana nawet przed dostarczeniem implementacji tych usług. Warunkiem niezbędnym dla prawidłowej realizacji procesu jest jak widać postawienie definicji usługi, wyrażonej jako dokument WSDL, ponad jej konkretną implementację, która jest rzeczą wtórną. Co prawda dla programisty implementującego usługi na platformie Java EE (i innych analogicznych) kuszącym jest, aby pracę zacząć od implementacji usługi i na jej podstawie w sposób automatyczny wygenerować plik WSDL (obecna technologia sprawia że jest to łatwe), jednak jest to podejście nie celowe z globalnego punktu widzenia.

Podejście w którym zaczyna się od wytworzenia definicji WSDL – w przeciwieństwie do podejścia w którym na podstawie implementacji pliki WSDL generuje się automatycznie – ma szereg zalet. Specyfikacje w postaci dokumentów WSDL mogą być wykorzystane jako element kontraktu pomiędzy dostawcą a klientem tam gdzie zachodzi potrzeba utrzymywania stosunków formalnych, tj. otrzymania formalnej akceptacji projektu usług przed rozpoczęciem fazy realizacji. Kolejnym powodem dla którego warto w pierwszej kolejności opracować definicję usługi w postaci pliku WSDL jest możliwość przygotowywania testów usług równolegle z ich implementacją, na podstawie samego WSDLa. Warto taki tryb pracy uczynić standardem, niezależnie od niuansów i specyfik poszczególnych projektów. Korzyści staną się jeszcze większe i bardziej widoczne, jeśli pliki WSDL budowane będą w oparciu o globalne, kanoniczne typy danych.

W artykule „JAX-WS i Maven 2 w podejściu Contract First Development” opisałem w jaki sposób implementować usługi w takim podejściu z wykorzystaniem technologii oferowanych przez platformę Java EE 5.

Oracle kupuje Sun Microsystems

Producent baz danych Oracle kupuje firmę Sun Microsystems! Wartość transakcji to około 7,4 mld USD. Tym samym Oracle przejmuje wszystkie prawa do języka programowania Java, bazy danych MySQL, systemu operacyjnego Solaris oraz pakietu biurowego OpenOffice. Się porobiło. Ciekawe czy i jak wpłynie to na nasze, developerów życie.

SCJP - Tokenizacja tekstu

Tokenizacja to proces w wyniku którego monolityczny tekst zostaje podzielony na ciąg pojedynczych tokenów. Tokeny to ciągi znaków ograniczone ustalonymi separatorami takimi jak spacje czy przecinki, aczkolwiek separatorem może być dowolny ciąg który da się opisać w postaci wyrażenia regularnego. Najbardziej elementarny algorytm tokenizacji w Javie implementuje metoda split(…) z klasy String. Metoda ta dokonuje podziału tekstu reprezentowanego przez obiekt dla którego została wywołana używając separatora opisanego wyrażeniem regularnym przekazanym jako argument wywołania. Przykład poniżej:

public void tokenize() {
  String[] tokens = "dowolny tekst do tokenizacji".split("\\s");
        
  for(String token : tokens)
    System.out.println(token);
}

Wyrażenie regularne \s (które musimy zapisać jako \\s) oznacza biały znak (ang. whitespace character), tj. spacje, tabulacje, znaki nowej linii itd. Uruchomienie powyższej metody spowoduje więc wyświetlenie napisu:

dowolny
tekst
do
tokenizacji

Bardziej wyrafinowanych mechanizmów tokenizacji dostarcza klasa Scanner z pakietu java.util. Zasadnicza różnica w stosunku do metody split(…) polega na tym, że tokenizowany tekst jest przetwarzany stopniowo, w miarę potrzeby, i proces może być w dowolnej chwili zaniechany. Skanerem posługujemy się jak iteratorem. Klasa Scanner implementuje interfejs java.util.Iterator więc de facto jest ona iteratorem; pewnym szczególnym rodzajem iteratora, dzięki któremu możemy iterować po kolejnych tokenach przetwarzanego tekstu. Obiekt skanera tworzymy z użyciem jednego z kilku konstruktorów, z czego interesującymi dla nas są trzy pokazane poniżej:

public Scanner(String source)

public Scanner(File source) throws FileNotFoundException

public Scanner(InputStream source) 

Identyczna funkcjonalnie metoda jak pokazana w pierwszym przykładzie, tyle że zaimplementowana przy użyciu skanera mogłaby więc wyglądać następująco:

public void tokenize() {
  Iterator scanner = new Scanner("dowolny tekst do tokenizacji");

  while (scanner.hasNext())
    System.out.println(scanner.next());
}

W powyższym przykładzie nie określono separatora i w takim wypadku skaner używa separatora domyślnego jakim są białe znaki; stąd równoważność funkcjonalna z przykładem używającym metody split(…). Aby ustawić separator – opisany jako wyrażenie regularne – należy użyć metody useDelimiter(…) co pokazano poniżej:

public void tokenize() {
  Scanner scanner = new Scanner("dowolny tekst do tokenizacji");
        
  scanner.useDelimiter("\\s");

  while (scanner.hasNext())
    System.out.println(scanner.next());
}

Oprócz metod hasNext() i next() pochodzących z interfejsu Iterator, które zwracają wartości typu String, klasa Scanner implementuje metody hasNextInt() i nextInt(), hasNextBoolean() i nextBoolean() itd. dla pozostałych typów prostych. Przy użyciu tych metod możemy w łatwy sposób zaimplementować np. funkcję sumującą liczby naturalne występujące w danym tekście:

public int sum() {
  Scanner scanner = new Scanner("a 1 b 2 c 3 d e f");

  int sum = 0;
        
  while (scanner.hasNext()) {
    if (scanner.hasNextInt()) {
      sum += scanner.nextInt();
    } else {
      System.out.println("nie int: " + scanner.next());
    }
  }
        
  return sum;
}

Moja prezentacja o GIu na JAVArsovii 2009

Kolejna edycja JAVArsovii - JAVArsovia 2009 - już wkrótce; wszystko wskazuje na to, że 4-tego lipca. Trwają poszukiwania sponsorów, patronów medialnych i... prelegentów. Chcesz wystąpić na konferencji? Wystarczy wysłać swoje zgłoszenie na adres c4p@javarsovia.pl i poczekać chwile na akceptacje tematu. No, chyba że temat się nie spodoba i akceptacji nie będzie:) Chętnych na pewno nie zabraknie, więc pewnie trzeba się z tym liczyć. Ja w każdym razie się zgłaszam - właśnie wysłałem swoje zgłoszenie z tematem "TIBCO GI – Interfejs użytkownika dla architektury SOA". Oto jego treść:

TIBCO General Interface to projekt open-source, na licencji BSD, dostarczający bibliotek i narzędzi do implementacji aplikacji klasy RIA. GI to z jednej strony biblioteka klas JavaScript umożliwiająca stworzenie profesjonalnej aplikacji typu AJAX bez konieczności użycia serwera aplikacyjnego czy nawet kontenera serwletów; a z drugiej strony zaawansowane, dedykowane środowisko programistyczne - TIBCO General Interface Builder. Oferta bez precedensu. GI jest rozwiązaniem wszechstronnym i elastycznym, ale ze względu na zaawansowane wsparcie dla wywołań usług sieciowych szczególnie predysponowane do zaistnienia w architekturach typu SOA.

Prezentacja ma na celu zainspirować do bliższego przyjrzenia się rozwiązaniu TIBCO. GIa i prezentację o nim dedykuje i polecam zwłaszcza tym, dla których interfejs użytkownika nie jest pępkiem świata; dla pragmatyków, którzy wiedzą że najważniejsze jest nie widoczne dla oczu, ale że zarazem przeważnie właśnie to co widać decyduje o efekcie końcowym i ostatecznej ocenie naszej pracy.

Prezentację poprowadzi Mariusz Lipiński – Inżynier Oprogramowania, pasjonat technologii, IT i Javy w szczególności. Magister Informatyki, absolwent Wydziału Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego. Członek Warszawskiej Grupy Użytkowników Technologii Java (Warszawa JUG), współorganizator konferencji JAVArsovia 2008. Mariusz zatrudniony jest obecnie jako Architekt SOA w jednej z największych polskich spółek. Swoje przemyślenia o tematyce IT publikuje na blogu pod adresem www.mariuszlipinski.pl.

TIBCO General Interface – Warstwa widoku dla SOA

O projekcie TIBCO GI dowiedziałem się kilka dni temu. Początkowo sceptyczny w końcu postanowiłem spróbować i przekonać się ile to jest warte. Przedrostek TIBCO mógłby sugerować że chodzi o produkt komercyjny, ale nie tym razem; GI dostępny jest na licencji BSD. Zasadniczo rzecz ujmując GI to biblioteka DHTML (JavaScript + HTML) służąca do budowy aplikacji klasy RIA. Biblioteka sama w sobie jest dosyć niezła, tzn. bogata w dobrze wykonane, ładne i funkcjonalne komponenty typu AJAXowego, ale to dopiero początek zalet. To co mnie w GI zachwyciło to IDE, tj. TIBCO General Interface Builder. Przyznam, że nigdy jeszcze czegoś takiego nie widziałem (może mało widziałem) – IDE wykonane jako aplikacja WWW! Tych którzy chcieli by ewentualnie w tym momencie zakończyć lekturę artykułu – zgorszeni – uspokajam! Jest to naprawdę kawał świetnej roboty… nie, nie pracuje dla TIBCO:) Zacząć przygodę z GIem jest niezwykle łatwo. Wystarczy ze strony General Interface Developer Center pobrać dystrybucję w postaci pliku ZIP, rozpakować i uruchomić GI Builder otwierając w przeglądarce plik GI_Builder.html. Nie trzeba żadnego serwera aplikacyjnego ani nawet serwera WWW. GI Builder to aplikacja DHTML. Zachęcam do przejrzenia filmików dostępnych na stronach Developer Center aby zorientować się jak to wygląda. Dla tych którzy nie poczują dopóki sami nie spróbują przygotowano krótki kurs (ang. tutorial) w którym opisano krok po kroku jak zbudować prostą aplikację opartą na wywołaniu usługi sieciowej (ang. web service). To jest właśnie to co mnie w GIu urzekło najbardziej – łatwość z jaką możemy wywoływać usługi sieciowe i prezentować użytkownikowi wyniki tych wywołań. Poniżej ilustracja pokazująca jak takie wywołanie się definiuje.

Na koniec jeszcze uzasadnienie dla tytułu dzisiejszego artykułu. Dlaczego napisałem, że TIBCO General Interface to warstwa widoku dla SOA? Ano dlatego że uważam że świetnie nadaje się do budowania małych aplikacji wspierających interakcje użytkowników z procesami (poprzez usługi) ale do budowy większych aplikacji monolitycznych już nie koniecznie. Wyobraźmy sobie, że jednym z kroków procesu biznesowego w firmie dla której implementujemy rozwiązanie jest weryfikacja pewnych danych w drodze kontaktu z klientem. Wszystko czego potrzebujemy to formatka która wyświetli listę takich zadań – zadań weryfikacji danych – oraz formatka ze szczegółami pojedynczej sprawy i guzikami odpowiadającymi możliwym wynikom weryfikacji. Oczywiście wspomnianą listę i szczegóły sprawy pobieramy wywołując usługę sieciową. W taki sam sposób zapisujemy wynik weryfikacji.

Mam SCJP 6

Zebrałem się w sobie i poszedłem na egzamin. Co prawda uczyłem się pod kątem SCJP 5, ale stwierdziłem że... no cóż, SCJP 6 będzie lepiej wyglądało "w papierach" a różnice są nie wielkie więc nie powinno być problemów. Powiem szczerze, że nie przypominam sobie żeby jakiekolwiek z pytań które miałem na egzaminie odwoływało się do nowinek Javy 6. W sumie czuje się trochę zaskoczony tym egzaminem. Zaskoczony jestem w tym sensie, że raptem tylko 3-ech czy 4-ech odpowiedzi udzieliłem opierając się w dużej mierze na wyczuciu, zamiast li tylko na wiedzy, tymczasem jak się okazało popełniłem aż 9 błędów (na 72 pytania). Potwierdza to jedno - egzamin jest podchwytliwy i łatwo jest przeoczyć zmyłki i triki autorów egzaminu. Suma summarum zdałem uzyskując 87% punktów.

SCJP - Test z wątków

Przyszło mi właśnie do głowy takie pytanko testowe pod kątem SCJP - jaki będzie efekt uruchomienia poniższego kodu (odpowiedź do "wytestowania"):

public class ThreadTest {
   public static void main(String[] args) {
       Thread thread = new Thread(new MyRunnable(), "my thread");

       thread.run();
   }
}

class MyRunnable implements Runnable {
   public void run() {
       System.out.print(Thread.currentThread().getName());
   }
}

1. wyświetlenie napisu 'my thread'
2. wyświetlenie napisu 'main'
3. brak efektu - żaden napis nie zostanie wyświetlony
4. program się nie skompiluje
5. program się skompiluje ale uruchomienie zakończy się wyjątkiem
   

Konferencja .NET w miejscu Javarsovii 2008

Koledzy ze społeczności .NET postanowili zorganizować konferencję. Impreza nazywa się Communities to Communities i planowana jest na 14 marca 2009 r. Ciekawostką jest, że odbędzie się ona w gmachu Wydziału Biologii Uniwersytetu Warszawskiego przy ulicy Miecznikowa 1 w Warszawie, a więc tam gdzie odbyła się Javarsovia 2008! Impreza organizowana jest przez grupy .NET i pokrewne z całej polski, w tym Warszawską Grupę .NET, Krakowską Grupę Developerów .NET, Poznańską Grupę .NET, Toruńską Grupę Deweloperów .NET, Wrocławską Grupę .NET i jeszcze kilka innych. Javarsovię 2008 organizowała sama jedna (ale za to jaka:) Warszawska Grupa Użytkowników Technologii Java i wypadło świetnie. .NETowcy mają przewagę liczebną; chyba pójdę i przekonam się jak wypadną jakościowo. Wstęp bezpłatny - chyba warto się przejść i poszerzyć nieco horyzonty.

Materiały z prezentacji o iBATISie na Warszawa JUG

Prezentacja odbyła się zgodnie z planem: całość trwała niespełna 2 godziny, były slajdy - które zgodnie z obietnicą publikuję (tu) -, były przykłady na żywo, była dyskusja. Chyba nawet udało mi się uzasadnić, że iBATIS w określonych sytuacjach jest lepszym wyborem niż Hibernate czy JPA. Kolega z widowni uzasadnił też przy okazji, podając przykłady, że i JDBC bywa dobrym wyborem, jeśli tylko natrafimy na sytuację wymagającą zastosowanie wyrafinowanych mechanizmów. Mam nadzieje, że się podobało.

Jestem IBM Certified SOA Solution Designer

Miło mi poinformować, że zdałem dziś egzamin "Test 667: Architectural Design of SOA Solutions" i tym samym zdobyłem certyfikat "IBM Certified SOA Solution Designer". Planowałem ten krok już od jakiegoś czasu, aż w końcu jakoś na początku grudnia, a może jeszcze w listopadzie wysłałem swoje zgłoszenie. Trwało to dosyć długo, po drodze ustalane były różne terminy, które z różnych względów były przesuwane aż do dziś, ale w końcu się udało... i oto jest. Udało mi się zdobyć aż 83% punktów, co przy wymaganym dla zaliczenia progu 55% jest niezłym wynikiem, tym bardziej, że egzamin był - obiektywnie rzecz biorąc - trudny. Trudny był nie dlatego, że wymagał jakiejś nadzwyczajnej wiedzy, ale dlatego, że wybierać trzeba było odpowiedź "najbardziej prawdziwą" a nie jedyną prawdziwą. Co do zakresu zaś, nie wystarczyłoby wiedzieć, co to jest SOA i co się kryje za pojęciami w stylu WS-* czy ESB oraz do czego służą poszczególne produkty IBM'a dedykowane dla SOA; trzeba było dodatkowo znać specyfikę i terminologię SOA sprzedawanego przez IBM'a. Może nawet w pierwszej kolejności trzeba skupić się na poznaniu IBMowego sposobu postrzegania, tj. reklamowania SOA. Poniżej zdjęcie raportu poegzaminacyjnego.

Moja prezentacja o iBATISie na Warszawa JUG

Już za niecałe dwa tygodnie – 20 stycznia 2009 – poprowadzę prezentację o iBATISie w ramach cyklicznych spotkań grupy Warszawa JUG. Temat prezentacji to „Coś między ORM a JDBC, czyli iBATIS Data Mapper”. Jak zwykle spotkanie odbędzie się w sali 5440 Wydziału MIM Uniwersytetu Warszawskiego przy ul. Banacha 2 w Warszawie. Zaczynamy o godzinie 18:00. Wstęp wolny! Zapraszam!