30 maja 2009

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ę.

25 maja 2009

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).

12 maja 2009

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ć.

7 maja 2009

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.