Cała impreza zaczęła się od krótkiego wykładu Grzegorza Dudy na temat samej konferencji, spraw organizacyjnych i sponsorów. Potem odbyła się burza mózgów dotycząca zagadnień poszczególnych sesji, kilka osób próbowało szybko opanować bilokację i po krótkim szaleństwie żółtych karteczek przekładanych w pośpiechu po całej planszy całość w końcu ruszyła.

Pierwsza sesja w której uczestniczyłem dotyczyła DDD i anemicznego modelu. Dyskusja była ciekawa, dyskutanci bardzo profesjonalni, jednak brakowało (przynajmniej mi) krótkiego wstępu dotyczącego samego DDD.

Druga sesja dotyczyła przyszłości Springa w kontekście ostatnich zmian licencyjnych, braku postępów w rozwoju nowych funkcjonalności i planach wprowadzenia opłat za szeroko pojęty support. Wydaje mi się, że wszyscy zgodnie twierdzili, że zagranie nie do końca było fair, ale należy poczekać co dadzą opłaty. Temat zebrał przy jednym stoliku większość uczestników konferencji, a mniejszość zajmowała się sprawami refaktoringu.

Po obiedzie, zaskakująco smacznym nota bene, przysiadłem się do stolika gdzie toczyła się dyskusja na temat Scali. Niestety od pewnego momentu mój mizerny poziom wiedzy dot. języków funkcyjnych, zmusił mnie do rozpoczęcia wewnętrznych rozważań na tematy zmiany stolika :)

Czwarta sesja dotyczyła aspektów i AOP. Przyznaję się bez bicia, że wybrałem ją z braku innych ciekawych tematów, ale i tak dowiedziałem się kilku interesujących rzeczy dotyczących nie tylko aspektów, ale też adnotacji i zasad poprawnego programowania.

Ostatnia sesja to długa rozmowa o OSGi, rozpoczęta od trochę długiego wstępu, który na szczęście przerwano w odpowiednim momencie :) Potem dyskusja potoczyła się w arcyciekawym (przynajmniej dla mnie) kierunku virtualizacji, JVM’a i Xen’a. Niestety została przerwana losowaniem nagród. Nieskromnie pochwale się, że wygrałem książkę i udało mi się zdobyć jednego RefCardz’a, niestety nie do końca tego którego chciałem :)

Podsumowując: wielkie brawa dla Grześka (i jego żony) za zorganizowanie UNkonferencji i mam nadzieje, ze edycja druga odbędzie się jeszcze w tym roku :)

PS. W trakcie wszystkich dyskusji krążył po sali dyktafon, więc nieobecni będą mieli szanse posłuchać o czym rozmawialiśmy (nie wiem jaka będzie jakość dźwięku).

PS2. Więcej zdjęć można znależć tutaj

Kiedy wyschły pierwsze łzy na mojej twarzy i minęła pierwsza żałoba, postawiony zostałem przed koniecznością utworzenia w sposób całkowicie błyskawiczny nowej instancji serwera. Z wszystkich usług zależało mi najbardziej na serwisach SMTP oraz POP3. Rozpoczęła się walka z czasem. Miałem zaledwie kilka dni zanim listy już wysłane na adresy w mojej domenie rozpoczną swoją powrotną wędrówkę na adres nadawcy. Przejrzałem posiadany przeze mnie tabor sprzętowy i z przykrością stwierdziłem, że jedyna dostępna w tym momencie maszyna mogąca służyć moim celom to stary, wysłużony i rozpadający się laptop Asusa z Windowsem XP na swoim pokładzie. Jedyne co łączyło go z serwerem z prawdziwego zdarzenia to fakt, że zmieściłby się on w szafie serwerowej. Zresztą jak w każdej innej meblościance ;)

Działajmy!

Potrzebowałem łatwego w konfiguracji, darmowego, możliwego do zainstalowania na Windowsie oraz nie koniecznie naszpikowanego funkcjonalnością rozwiązania. W kontekście serwerów pocztowych obiła mi się o uszy fraza Apache JAMES. Wiedziałem, że jest to projekt napisany w całości w Javie oraz obsługujący protokoły SMTP oraz POP3. Dodatkowo z literki J na początku wnioskowałem, że krzywa nauczania właśnie dla mnie przyjmie wyjątkowo miłe kształty. Postanowiłem więc wypróbować na żywym organizmie wspomniane funkcjonalności agenta oraz zobaczyć co więcej oferuje.

Instalacyjka

Jeśli spodziewacie się wielostronnego, skomplikowanego oraz napisanego ciężkim technicznym językiem opisu instalacji to oczekujcie srogiego zawiedzenia. Przy wybraniu ścieżki dla osób nieprzejawiających skłonności sadomasochistycznych należy ściągnąć jedną z dostępnych binarnych paczek na stronie domowej Apache JAMES oraz rozpakować ją w dowolnie nam pasującym miejscu naszego systemu. W momencie pisania tego artykułu najlepsza wersja szczyciła się numerkiem 2.3.1.

Należy tutaj podkreślić, że JAMES ma budowę modularną pozwalającą na uruchomienie jedynie tych funkcjonalności, które wydają się być dla nas interesujące. Zatem paczka o której mowa zawiera tak naprawdę mikrokontener Avalon Phoenix (na próżno zda się szukanie jakiś o nim informacji w guglach, a przyczyny tego faktu postaram się przybliżyć w dalszej części) wraz z dołączonym Apache JAMESem. Zatem uruchamiać tak naprawdę będziemy mikrokontener, a nie bezpośrednio aplikację serwera pocztowego.

Niesie to za sobą kolejne implikacje. Znajomość Javy nie jest wymagana, a osoby ją znające nie będą w żaden sposób faworyzowane, aż do momentu w którym nie zdecydują się one na własnoręczne rozszerzenie serwera o specyficzne dla swoich potrzeb funkcjonalności. Rozszerzeń tego typu Apache JAMESa można dokonywać poprzez tworzenie tak zwanych mailetów (służy do tego Mailet API), ale ta możliwość nie pozostaje w obszarze zainteresowań tego artykułu.

Mój pierwszy raz

Przed przystąpieniem do konfiguracji aplikację można, a nawet należy uruchomić. Dokonamy tego w zależności od systemu operacyjnego wykonując run.bat lub run.sh. Jak udało mi się sprawdzić aplikacja równie bezproblemowo działa zarówno na Windowsach jak i Linuxach.

Wynikiem pierwszego uruchomienia powinien być log na konsoli podobny do poniżej zaprezentowanego.

Using PHOENIX_HOME:   C:\james-2.3.1
Using PHOENIX_TMPDIR: C:\james-2.3.1\temp
Using JAVA_HOME:      C:\Program Files\Java\jdk1.6.0_03\

Phoenix 4.2

James Mail Server 2.3.1
Remote Manager Service started plain:4555
POP3 Service started plain:110
SMTP Service started plain:25
NNTP Service started plain:119
FetchMail Disabled

W tak zwanym międzyczasie w katalogu apps/james pojawiły się pliki i foldery, które będą nam przydatne podczas konfiguracji serwera.

Konfiguracja

Ktoś kto miał do czynienia w przeszłości z innymi rozwiązaniami pocztowymi takimi jak Sendmail, Exim czy Postfix może powiedzieć, że ich konfiguracja jest prosta jedynie post factum ponieważ przegrzebał się przez tony dokumentacji i ma już to na szczęście za sobą. Będę się starał pokazać, że w przypadku Apache JAMESa jest nieco inaczej.

Nie opiszę tutaj wszystkich możliwych opcji, ale na przykładzie serwera, który miałem okazję konfigurować postaram się pokazać jak osiągnąć:

• serwer SMTP z autentykacji użytkowników
• serwer POP3 z obsługą szyfrowania i autentykacji

Sposób konfiguracji serwera

Do podstawowej konfiguracji serwera będzie nam potrzebny zwykły edytor plików tekstowych. Warto byłoby, aby nie był to jednak Microsoft Notepad, ale program, który w minimalnym choć stopniu wspiera edycję XMLa. Ja osobiście bardziej z przyzwyczajenia niż dlatego, że jest to rzeczywiście najbardziej odpowiednie narzędzie do tego celu wykorzystałem Eclipse‘a.

Aby zmiany, które wprowadzimy do konfiguracji zostały weszły w życie będziemy musieli serwer zatrzymać, a następnie ponownie uruchomić.

Podstawowa konfiguracja

Zlokalizujemy teraz plik konfiguracyjny apps/james/SAR-INF/config.xml. Nie należy się przejmować jego objętością, ponieważ większą jego cześć stanowią komentarze, które powinny nasze zadanie uczynić jeszcze łatwiejszym.

Rozpoczniemy od zmiany podstawowych własności serwera.

<config>
	<James>
		<!-- adres e-mail z którego będą wysyłane (przede wszystkim) informacje o niedostarczonej poczcie -->
		<postmaster>postmaster@bike-diary.org</postmaster>
		<!-- zezwalamy na dostarczanie maili jedynie na explicite wylistowane przez nas serwery -->
		<!-- nie zezwalamy na wysyłanie listów przy użyciu adresów IP -->
		<!-- wszystkie maila wysłane na adresy w domenie bike-diary.org będą traktowane jako maile do lokalnego dostarczenia -->
		<servernames autodetect="false" autodetectIP="false">
			<servername>bike-diary.org</servername>
		</servernames>
		(...)
	</James>
	<spoolmanager>
		<processor name="transport">
			(...)
			<!-- wyłączamy sprawdzanie z jakich adresów IP łączą się nasi użytkownicy -->
			<!-- zamiast tego zastosujemy autentykację SMTP -->
			<!--
				<mailet match="RemoteAddrNotInNetwork=127.0.0.1" class="ToProcessor">
				<processor> relay-denied </processor>
				<notice>550 - Requested action not taken: relaying denied</notice>
				</mailet>
			-->
			(...)
			<mailet match="All" class="RemoteDelivery">
				<!-- wymagane przez niektóre serwery SMTP, aby dostarczenie wiadomości mogło się powieść -->
				<mail.smtp.localhost>
					bike-diary.org
				</mail.smtp.localhost>
			</mailet>
		</processor>
	</spoolmanager>
	(...)
	<remotemanager enabled="true">
		(...)
		<!-- przy zdalnej konfiguracji serwera będziemy korzystali z szyfrowania -->
		<useTLS>true</useTLS>
		<handler>
			(...)
			<administrator_accounts>
				<!-- hasło składające się z 8 gwiazdek jest nie do złamania ;) -->
				<account login="root" password="*********" />
			</administrator_accounts>
			(...)
		</handler>
	</remotemanager>
	<pop3server enabled="true">
		<!-- wybieramy port 995, ponieważ będziemy chcieli szyfrować połączenia -->
		<port>995</port>
		<useTLS>true</useTLS>
		(...)
	</pop3server>
	<smtpserver enabled="true">
		(...)
		<handler>
			(...)
			<!-- nie chcemy z naszego serwera zrobić przystani dla spamerów -->
			<authRequired>true</authRequired>
			(...)
		</handler>
	</smtpserver>
	(...)
	<sockets>
		<server-sockets>
			(...)
			<!-- ponieważ chcemy używać szyfrowania musimy odkomentować poniższy fragment -->
			<factory name="ssl"
				class="org.apache.avalon.cornerstone.blocks.sockets.TLSServerSocketFactory">
				<ssl-factory>
					<keystore>
						<file>conf/keystore</file>
						<!-- zmień domyślne hasło -->
						<password>secret</password>
						<!-- zmień domyślne hasło -->
						<key-password>keysecret</key-password>
						<type>JKS</type>
						<protocol>TLS</protocol>
						<algorithm>SunX509</algorithm>
						<authenticate-client>false</authenticate-client>
					</keystore>
				</ssl-factory>
			</factory>
		</server-sockets>
		(...)
	</sockets>
</config>

Powyższy listing przedstawia wprowadzone przeze mnie zmiany do domyślnej konfiguracji serwera wraz z dołączonymi komentarzami wyjaśniającymi powód powstania modyfikacji. Umieszczenie tutaj całej zawartości pliku konfiguracyjnego nie miałoby swojego uzasadnionego sensu, a jedynie znacząco zaciemniłoby prezentowany przeze mnie przykład. Należy jednak zauważyć, że w prawdziwym środowisku produkcyjnym bardziej świadomy swoich potrzeb użytkownik wprowadziłby znacznie większą ilość usprawnień.

Przygotowywanie wsparcia dla szyfrowania

Nim przystąpimy do ponownego uruchomienia serwera konieczne będzie jeszcze wygenerowanie składowiska kluczy (ang. keystore) oraz umieszczenie dostarczonej wraz z Sun JDK paczki dostawców usług kryptograficznych w odpowiedniej lokalizacji.

Dla powyższego przykładu keystore możemy utworzyć przy pomocy dostarczonego wraz z Sun JDK narzędzia keytool.

keytool -genkey -keypass keysecret -keystore keystore -storepass secret

Powyższe polecenie należy wykonać w folderze apps/james/conf. Więcej informacji na temat generowania kluczy można uzyskać tutaj.

Przed przystąpieniem do ponownego uruchomienia serwera musimy jeszcze odnaleźć plik sunjce_provider.jar znajdujący się wewnątrz instalacji Sun JDK. Wspomniany plik należy przekopiować do folderu lib katalogu instalacyjnego Apache JAMESa.

Ponowne uruchomienie serwera

Oczywiście jeżeli mamy otwartą konsole w której jest uruchomiony właśnie serwer aplikacji, to do jego zatrzymania moglibyśmy użyć nieśmiertelnego Ctrl-C ;) My natomiast nauczymy się tą czynność wykonywać w bardziej prawidłowy sposób i przy okazji poznamy kolejny komponent Apache JAMESa, jakim jest RemoteManager.

Wspomniany przed chwilą RemoteManager domyślnie uruchamiany jest na 4555 porcie i komunikuje się ze światem zewnętrznym przy pomocy protokołu telnet. Służy on do ogólnie pojętego zarządzania serwerem pocztowym w tym między innymi pozwala na dodawanie, modyfikowanie oraz usuwanie kont użytkowników.

Z poziomu Windowsa w celach połączenia się z RemoteManagerem możemy wykorzystać PuTTY.

Zalogujmy się zatem wybierając typ połączenia telnet, odpowiedniego hosta oraz port 4555. Naszym oczom powinna ukazać się zachęta do wprowadzenia danych uwierzytelniających (należy zerknąć do pliku konfiguracyjnego w celu upewnienia się jakie dane powinny zostać tutaj wprowadzone). Niestety z przykrością stwierdzam, że wprowadzane przez nas hasło będzie widoczne na ekranie komputera. Należy zatem zachować szczególną ostrożność by krytyczne dane nie zostały przechwycone przez osoby do tego niepowołane. W wyniku udanego logowania oraz wpisania komendy HELP powinniśmy zobaczyć ekran podobny do poniżej zaprezentowanego zawierający wszystkie aktualnie dostępne polecenia obsługi.

Currently implemented commands:
help                                    display this help
listusers                               display existing accounts
countusers                              display the number of existing accounts
adduser [username] [password]           add a new user
verify [username]                       verify if specified user exist
deluser [username]                      delete existing user
setpassword [username] [password]       sets a user's password
setalias [user] [alias]                 locally forwards all email for 'user' to 'alias'
showalias [username]                    shows a user's current email alias
unsetalias [user]                       unsets an alias for 'user'
setforwarding [username] [emailaddress] forwards a user's email to another email address
showforwarding [username]               shows a user's current email forwarding
unsetforwarding [username]              removes a forward
user [repositoryname]                   change to another user repository
shutdown                                kills the current JVM (convenient when James is run as a daemon)
quit                                    close connection

Analizując powyższą listę można w łatwy sposób uzyskać informację na temat dostępnych opcji. Nas w tym momencie będzie interesowała opcja shutdown powodująca grzeczne zakończenie pracy przez serwer. Po udanym zatrzymaniu oraz ponownym uruchomieniu mikrokontenera powinniśmy już na konsoli ujrzeć, że nowe ustawienia weszły w życie (możemy to na przykład sprawdzić weryfikując numery portów na których uruchomiły się poszczególne usługi). Jeżeli coś sugeruje, że serwer nie uruchomił się prawidłowo warto spojrzeć na konsolę oraz zerknąć do folderu z logami apps/james/logs.

Od tej pory po każdorazowej zmianie ustawień serwera polegającej na modyfikacji pliku konfiguracyjnego będziemy musieli wykonać ponowne uruchomienie serwera w sposób jaki został powyżej opisany.

Podstawowe testy usługi

W celu skutecznego przetestowania usług należy przy pomocy RemoteManagera dodać użytkownika testowego (bądź rzeczywsitego). Następnie zgodnie z wprowadzonymi w pliku konfiguracyjnym serwera parametrami można dodać nowe konto pocztowe w swoim ulubionym kliencie poczty. Szczególną uwagę zwrócić należy na ustawienia protokołu SMTP oraz POP3.

Na koniec w ramach przetestowania podstawowej funkcjonalności serwera można wysłać ze swojego innego konta pocztowego na serwerze zewnętrznym wiadomość na testowy adres i vice versa. Jeżeli obie wiadomości zostaną pomyślnie dostarczone będzie to oznaczało, że podstawowa funkcjonalność serwera działa. Hurra!

W przypadku wystąpienia błędów warto przejrzeć pliki logów w poszukiwaniu wartościowych wskazówek oraz sprawdzić ponownie konfigurację serwera.

Czego więcej można się spodziewać?

Przeglądając plik konfiguracyjny można łatwo zorientować się jakie inne nieopisane przeze mnie w tym artykule funkcjonalności posiada Apache JAMES. Za ciekawostkę z pewnością można uznać moduł IMAP (będący w momencie pisanie przeze mnie tego tekstu w fazie eksperymentalnej). Bardziej zainteresowanych czytelników z czystym sumieniem mogę odesłać do oficjalnej dokumentacji Apache JAMESa.

Komu serwer, komu – bo idę do domu.

Literka E w nazwie serwera ma oznaczać, że ma on służyć do rozwiązań biznesowych. Czy rzeczywiście tak jest? Trudno jest mi to jednoznacznie ocenić. Z pewnością sprawdza się wspaniale w zastosowaniach domowych oraz w fazie deweloperskiej rozwoju aplikacji korzystających z serwera pocztowego. Nie lada zaletą jest także jego rozszerzalność, która umożliwia nam w łatwy sposób dodawanie nowych specyficznych funkcjonalności. Zatem każdy musi sobie sam odpowiedzieć, czy Apache JAMES jest rozwiązaniem spełniającym oczekiwania. W moim mniemaniu jest on z pewnością produktem, który zasługuje na swoją szansę.

Wątpliwości architektoniczne

Serwer Apache JAMES jest wciąż mniej lub bardziej dynamicznie rozwijany. Tym bardziej wątpliwości może budzić fakt, że korzysta on z mikrokontenera Apache Avalon, który już dawna temu przestał być wspierany. Na stronie domowej serwera pocztowego można jednak znaleźć informacje, że wspomniane rozwiązanie nie przysparza żadnych większych problemów. Mimo to autorzy planują przenieść swój produkt na inne, wspierane środowisko. Kiedy to będzie miało miejsce? Tego nie wiadomo.

Lineczki

• Strona domowa Apache JAMES
• Generating keys

Wprowadzenie.

Na jBPM składają się:

Siłą jBPM jest właśnie jPDL który łączy pracę analityka i programisty w jednym pliku. Analityk najpierw modeluje proces (np.  sprzedaż produktu) wyszczególniając na grafie kierunkowym wszystkie istotne kroki danego procesu. Etap ten jest podobny do modelowania diagramu przepływu lub przypadków użycia znanych z UML czyli przyjazny dla analityka. Następnie programista po otrzymaniu takiego pliku zaczyna podpinać do poszczególnych węzłów grafu różne akcje i zadania (np. wywołanie zdalnego systemu, zapis do bazy danych). Użyłem słowa podpinać gdyż programista przy pomocy GPD wskazuje po prostu klasy które mają być użyte do obsługi.  Kolejną miłą właściwością jBMP jest persystencja  oparta o Hibernate co pozwala na umieszczenie tabel jBPM’a zarówno obok tabel naszej aplikacji jak i w całkowicie oddzielnej bazie danych. W bazie danych zapisywane są definicje procesów, instancje procesów oraz dane zgromadzone w zadaniach (task).

Jak to się robi.

Początek jest banalnie prosty wpisujemy  http://www.jboss.org/jbossjbpm/  pojawia nam się strona z wielkim przyciskiem DOWNLOAD  i idąc tym tropem ściągamy sobie jPDL Suite. Tak zdobytą paczkę rozpakować należy w dowolnym miejscu i przejść do katalogu “designer” z tego miejsca odpalamy anta który zainstaluje nam eclipse.  Można też po prostu ściągnąć sobie eclipse i rozpakować go do katalogu ./designer/eclipse.

Po uruchomieniu eclipse tworzymy nowy projekt JBoss jBPM/Process Project. Dajemy mu nazwę i klikamy ‘Finish’. Naszym oczom ukazuje się przykładowy projekt wraz z  jednym handlerem i JUnit testem.  Najważniejszą częścią tego przykładu jest plik procesdefinition.xml który zawiera  graf kierunkowy determinujący przebieg procesu, jest napisany w języku jPDL.

Bloki procesu (grafu) dzielą się na kilka grup. Dokładny opis wszystkich bloków był by bardzo obszerny więc przedstawię tylko podstawowe.

States służą do określenia kolejnych kroków procesu istotnych z punktu biznesowego i  wykonywanych automatycznie(bez ingerencji użytkownika) np. odpytanie o dane jakiegoś zewnętrznego systemu.

Tasks Node jest specyficznym stanem gdyż jest przeznaczony do umieszczania w nim zadań do wykonania dla człowieka. Proces przechodzi dalej w chwili zakończenia zadania przez człowieka np. następnego dnia. W czasie obsługi danego zadania w dowolnym momencie można zapisać jego aktualny stan.

Fork i Join służące do rozdzielenia procesu na kilka równolegle wykonywanych ścieżek. Istotną rzeczą jest że fork i join zawsze pracują w parach i wszystkie ścieżki wychodzące z jednego forka muszą skończyć się w jednym joinie. Proces oczekuje na bloku Join do zakończenia wszystkich ścieżek.

Transition jest to połączenie pomiędzy blokami procesu określające kierunek przejścia. Z bloku może wyjść dowolna liczba połączeń. Jeśli podczas wyjścia z bloku nie jest podana nazwa połączenia proces przechodzi po pierwszym (kolejność w xml).

Każdy blok ma możliwość podpięcia klasy obsługującej wyjątki, oraz dowolną liczbę klas obsługujących akcje, wykonywanych gdy nastąpi zdarzenie do których są przyporządkowane(np. node enter, node leave). Akcje mogą być również przyporządkowane do Transitions.

<?xml version="1.0" encoding="UTF-8"?>
<process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="simple">
	<start-state name="start">
		<transition name="to_state" to="first">
			<action name="action"
				class="com.sample.action.MessageActionHandler">
				<message>Going to the first state!</message>
			</action>
		</transition>
	</start-state>
	<state name="first">
		<transition name="to_end" to="end">
			<action name="action"
				class="com.sample.action.MessageActionHandler">
				<message>About to finish!</message>
			</action>
		</transition>
	</state>
	<end-state name="end"></end-state>
</process-definition>

public class MessageActionHandler implements ActionHandler {

	String message; 

	public void execute(ExecutionContext context) throws Exception {
		context.getContextInstance().setVariable("message", message);
	}
}

Jak widać w powyższym kodzie pole message nie posiada metod get i set jego wartość jest bezpośrednio wstrzykiwana z definicji procesu. Interfejs ActionHandlera posiada tylko jedną metodę do której jako parametr przychodzi ExecutionContext zawierający definicję procesu i jego instancje(wszystkie).

W momencie wykonania kompletnej implementacji wszystkich zdarzeń oraz podpięciu interfejsu użytkownika, mieli byśmy piękną trzy etapową obsługę czegoś. Gdyby była to aplikacja wykonana tradycyjnie każda zmiana wymagała by w mniejszym lub większym stopniu dostosowania istniejących elementów. Lecz gdy mamy do czynienia z grafem możemy po postu w dowolnym miejscu dodać kolejny element. Jak widać na rysunku poniżej.

Wbrew pozorom takie rozszerzanie aplikacji zdarza się dość często szczególnie jak mamy do czynienia z procesami decyzyjnymi oraz organizacją pracy w rozwijających się przedsiębiorstwach.

Podsumowanie.

JBPM to platforma do modelowania procesów biznesowych oparta o grafowy język jPDL. Nadaje się świetnie do tworzenia systemów które mają na celu przydzielać zadania do wykonania dla poszczególnych osób w złożonym środowisku procedur i przepisów.

Dla chcących pisać widgety na bardziej pospolite telefony komórkowe jest nadzieja w postaci platformy WidSets, uruchomionej i wdrożonej przez koncern Nokia, jednak nie tylko na telefony tej firmy przeznaczona.

Użytkowanie

Platforma WidSets współpracuje z ponad trzema setkami modeli telefonów komórkowych i opiera się o aplikację, którą w telefonie należy sobie zainstalować. Aplikacja ta łączy się z naszym kontem, założonym w internetowym serwisie WidSets, pobiera dane o wybranych przez nas widgetach i wyświetla je na ekranie naszego telefonu.

Oczywiście, najpierw trzeba sobie w serwisie założyć owo konto. Zanim to jednak zrobimy, serwis WidSets udostępnia nam bardzo ciekawie pomyślaną demonstrację swoich możliwości – na specjalnej stronie mamy dostępną całą bibliotekę widgetów do wyboru, oraz emulator telefonu komórkowego, na którym możemy podpatrzeć, jak aplikacja będzie wyglądać i działać.

Gdy już zdecydujemy się na rejestrację, będziemy przez jej proces poprowadzeni jak za rączkę – serwis najpierw pyta o typowe dane rejestracyjne, a następnie pomaga nam pobrać i zainstalować aplikację w telefonie. Trzeba przyznać, że to także jest świetnie rozwiązane – dostępne są trzy drogi, do wyboru w zależności od stopnia zaawansowania użytkownika, w różnym stopniu absorbujące jego uwagę:

• Dummies podają numer telefonu, na który przychodzi sms z linkiem, pod którym znajduje się aplikacja do zainstalowania,
• Techies przepisują podany na stronie URL do przeglądarki w komórce,
• a Geeks pobierają plik JAD, który ręcznie przenoszą i odpalają w telefonie, instalując tym samym aplikację.

Ja wybrałem to środkowe rozwiązanie, co pozwoliło nie czuć mi się ani jak oporny (dummy), ani jak geek.

Po zainstalowaniu w telefonie, aplikacja łączy się z kontem w serwisie i można przejść do konfiguracji, która polega głównie na wybraniu z biblioteki interesujących nas widgetów. Biblioteka jest dość obszerna i zawiera mnóstwo programów przydatnych bardziej (wiadomości, pogoda, organizatory czasu, skrzynki e-mailowe…) lub mniej (gry i inne czasoumilacze). Bardzo fajne jest to, że swoje widgety można wybierać nie tylko za pośrednictwem telefonu, ale też w komputerze, logując się w serwisie – nawet, gdy nasz telefon nie jest z nim połączony, my możemy zobaczyć i skonfigurować nasz pulpit (dashboard), a nawet – odpalić emulator komórki, w którym możemy przetestować jego działanie.

Testowałem działanie WidSetsów na mojej Nokii E50 i wszystko działa bardzo dobrze. Dodatkowe ułatwienie, podejrzewam, mogą mieć posiadacze telefonów z wbudowanym WiFi (np. Nokia E51), którzy nie muszą się łączyć z internetem za pośrednictwem swojej sieci komórkowej.

Tworzenie

Jak większość serwisów widgetowych (NetVibes, Opera, Apple…), także WidSets udostępniają możliwość tworzenia własnych widgetów. Przede wszystkim w serwisie dostępna jest opcja szybkiego generowania widgeta. Ma on, oczywiście, ograniczone możliwości – można w nim stworzyć właściwie tylko czytnik kanałów RSS lub podobnych i najwyżej wybrać skórkę, która nam będzie odpowiadać – ale niektórym to w zupełności wystarcza (coś podobnego, ale dla widgetów “desktopowych”, oferuje serwis wstaw.to).

Dla użytkowników bardziej wymagających i tych z zacięciem programistycznym, WidSets oferują cały Software Developer’s Kit do tworzenia bardziej zaawansowanych programów. Taki wdget składa się z dwóch plików: XML-owego deskryptora (plik widget.xml) oraz z kodu aplikacji (plik *.he). Dodatkowo mogą się na niego składać pliki zasobów, np. obrazki w formacje jpg lub png.

Plik widget.xml zawiera informacje o naszym widgecie: w sekcji <info> znajdują się informacje o widgecie, np:

 <info>
   <name>Flag Selector</name>
   <version>1.0</version>
   <author>Developer</author>
   <shortdescription>Displaying some flags</shortdescription>
 </info>

Następnie w sekcji <parameters> opisane są opcje i parametry widgeta – analogicznie do taga <widget:preferences> w UWA:

 <parameters>
   <parameter type="string"
                name="widgetname"
                description="Name of widget"
                help="This is the name of the widget"
                editable="false"
                sendtomobile="true"
                visible="true">
     <value>
       Flag Selector
     </value>
   </parameter>
 </parameters>

Następnie, w sekcji <resources> wymienione są dodatkowe źródła danych, np. style, z których aplikacja będzie korzystać (składniowo podobne do CSS), np:

<stylesheet>
   bkg {
     background: vgradient white silver;
   }

   frame {
     background: solid silver;
   }

   flag {
     align: hcenter vcenter;
     border: 2 2 2 2;
     border-type: rectangle red;
   }

   nametext {
     align: hcenter vcenter;
     color-1: green;
     font-1: medium bold;
     background: vgradient silver white;
   }

   greetingtext {
     align: hcenter vcenter;
     color-1: blue;
     font-1: medium bold;
     background: vgradient white green;
   }

   about {
     align: hcenter vcenter;
     color-1: blue;
     font-1: large bold;
     background: solid orange;
   }
 </stylesheet>

albo pliki zasobów, np. graficznych:

 <img scale=”true” src="finland.png"/>
 <img scale=”true” src="uk.png"/>
 <img scale=”true” src="eu.png"/>
 <img src="bkg.png"/>

Wreszcie – podany tam jest plik (tylko jeden) z kodem źródłowym widgeta:

 <code src=”flagselector.he”/>

W ostatniej sekcji deskryptora, <layout>, wymienione i opisane są widoki widgeta, których zasadami wyświetlania zajmuje się skrypt aplikacji. Elementy graficzne podobne są do komponentów Swingowych:

 <layout minimizedheight="60px">
   <view id="miniView">
     <img src="minimized.png"/>
   </view>
   <view class="bkg" id="mainView">
     <script id="flag" top="10%" right="80%" bottom="60%" left="20%"/>
     <script id="name" top="65%" right="100%" bottom="80%" left="0%"/>
     <script id="greeting" top="80%" right="100%" bottom="100%" left="0%"/>
   </view>
 </layout>

Gdy już deskryptor mamy napisany, pora zasiąść do kodu właściwego. Piszę się go w języku skryptowym WSL, czyli WidSets Scripting Language. Jest on podobny w składni do Javy, choć mocno ograniczony. Cały kod widgeta opiera się na klasie, w której musimy zdefiniować metody startWidget() oraz openWidget() – od nich rozpoczyna działanie nasza aplikacja. Przepływ programu polega na odpowiednim odnoszeniu się do zdefiniowanych w deskryptorze, w sekcji <layout>, widoków i elementów. Mamy też możliwość sięgania po zdefiniowane tam zasoby i parametry, a także możemy definiować akcje klawiszy telefonu komórkowego.

Bardzo istotnym elementem API są usługi pobierania treści – nasz widget może być czymś więcej, niż lokalną aplikacją, działającą na lokalnych danych (jak gra bądź kalkulator). Możliwe jest sięganie do danych z różnych usług webowych. Dostępne są cztery rodzaje usług:

• Syndication do pobierania treści z kanałów RSS, Atom czy RDF,
• Webfeed do pobierania niestandardowych treści,
• Image do pobierania grafiki, oraz
• HTTP do wykonywania żądań HTTP GET i HTTP POST.

Dzięki temu, oraz dodatkowym usługom (np. autentykacji) można stworzyć widgeta, który będzie sięgał do różnych źródeł internetowych, pobierał i kompilował interesujące nas dane, a następnie wyświetlał w przystępnej formie na ekranie naszego telefonu.

Użytkowanie tego, co się stworzyło

Gdy już skrypt i deskryptor mamy napisane, możemy przejść do kompilacji, testowania, a wreszcie – umieszczenia na swoim pulpicie. Kompilator jest dołączony do SDK w postaci programu devkit, uruchamianego z linii komend. Na początek musimy zalogować się na swoje konto w serwisie WidSets:

devkit login [LOGIN] [HASŁO]

a następnie wydajemy jedną komendę:

devkit run [ŚCIEŻKA_DO_WIDGETA]

a program naszego widgeta skompiluje, spakuje do ZIPa, wyśle do serwisu i uruchomi emulator komórki, w którym możemy widgeta przetestwować od razu. Ponieważ widget jest od razu wrzucany na nasz WidSetsowy pulpit, możemy go także od razu przetestować w prawdziwym telefonie.

Kompilator devkit posiada jeszcze mnóstwo dodatkowych opcji, ale nie będę się w nie tutaj zagłębiał. Dość powiedzieć, że daje on całkiem pokaźne możliwości.

Po pozytywnym przetestowaniu nasz widget możemy dodać do biblioteki publicznej, aby inni też mogli go sobie pobrać i z niego korzystać, ale nie jest to oczywiście konieczne.

Podsumowanie

WidSets jest naprawdę ciekawą technologią, pozwalającą na tworzenie małych, prostych a użytecznych aplikacji, do których można mieć dostęp wszędzie za pośrednictwem telefonu komórkowego. Mogą mieć zarówno charakter lokalny (czyli przetwarzać dane, wprowadzane bezpośrednio do telefonu albo korzystać z jego zasobów – istnieje np. możliwość pobierania danych z aparatu fotograficznego w telefonie), jak i zdalny, gdy aplikacja sięga po zasoby lub informacje z Internetu, by je obrobić i wyświetlić.

Źródła

• WidSets Wiki
  • Pierwsza aplikacja (stąd brałem fragmenty kodu do przykładów w artykule)
  • WSL w skrócie
  • Opis WidSets SDK
• WidSets API – dokumentacja a’la Javadoc
• WidSets SDK - pobieranie

Widgety – małe aplikacje użytkowe lub rozrywkowe, po polsku zwane często gadżetami – można spotkać coraz częściej, zarówno w sieci – na widgetach oparte są serwisy stron startowych (personalized homepages), jak NetVibes czy iGoogle – jak i poza nią, w aplikacjach desktopowych (panel gadgetów w Windows Vista albo Apple Dashboard pod Mac OSem), a nawet w telefonie komórkowym. Każdy z wymienionych serwisów widgetów istniał jednak osobno – iGoogle, NetVibes, Apple czy Opera (która od wersji 9 także wspiera widgety) miały swoje technologie i swoje zbiory gadżetów do pobrania i wykorzystania. Niektóre z nich udostępniały te technologie wszystkim, pragnącym samemu napisać jakąś małą aplikację, tym samym powiększając bibliotekę danego serwisu, ale cały czas taki twórczy użytkownik ograniczony był tylko do jednej platformy.
Dlatego też NetVibes – pionier w dziedzinie owych stron startowych – postanowił przerobić swój MiniAPI 0.3, w którym wcześniej można było pisać moduły do zamieszczania w ich serwisie, na nowy API, który został zaprezentowany w wersji 1.0 pod nazwą Universal Widget API.

Z czym to się je?

Pierwszą i najważniejszą zaletą Universal Widget API (w skrócie UWA) jest – jak sama nazwa wskazuje – jego uniwersalność. W tej chwili napisane w nim widgety można zamieścić nie tylko na stronie NetVibes, ale także z powodzeniem zaimportować na stronach iGoogle czy Live.com, umieścić na pasku gadżetów Visty czy MAC OSa, według twórców działają też na iPhone oraz pod Operą desktopową (Opera na urządzenia mobilne jeszcze nie jest na nie gotowa), ale tych ostatnich nie udało mi się uruchomić (nie jestem użytkownikiem Opery, a jej mechanizm importowania widgetów stanowi dla mnie barierę nie do przeskoczenia), a zapowiadanych jest jeszcze więcej platform (m.in. Facebook czy wspomniana Opera Mobile). Dodatkowo taki gadżet można umieścić w ramce (iframe) na dowolnej stronie, np. na blogu.
Napisany pod UWA widget stanowi kombinację HTMLa (rzecz jasna z CSSem), JavaScripta i AJAXa – te technologie wystarczą do napisania całego, działającego widgeta. Dodatkowo możliwości widgeta można znacznie rozszerzyć, podpinając go pod zewnętrzny skrypt PHP czy JSP albo pod WebService oparty na dowolnej technologii.
Dość prostym przykładem jest czytnik RSS – w UWA można go zawrzeć w pojedynczym pliku XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:widget="http://www.netvibes.com/ns/">
<head>
  <title>RSS Reader</title>

  <link rel="stylesheet" type="text/css" href="http://www.netvibes.com/themes/uwa/style.css" />
  <script type="text/javascript" src="http://www.netvibes.com/js/UWA/load.js.php?env=Standalone"></script>

  <widget:preferences>
    <preference name="url" type="text" label="URL" defaultValue="http://j2ee.pl/feed/" />
    <preference name="limit" type="range" label="Number of items to display" defaultValue="10" step="1" min="1" max="25" />
  </widget:preferences>
  <script type="text/javascript">
    var RSSReader = {}

    RSSReader.feed = false;
    RSSReader.display = function(feed) {
      if(feed) RSSReader.feed = feed;
      var feedList = widget.createElement('ul');
      feedList.className = 'nv-feedList';
      var j = 0;
      for(var i=0; i < RSSReader.feed.items.length; i++) {
        if(j >= widget.getValue('limit')) break;
        var item = RSSReader.feed.items[i];
        var li = widget.createElement('li');
        var a = widget.createElement('a');
        a.href = item.link;
        a.target = '_blank';
        var displayTitle = item.title;
        if(search != '') {
          displayTitle = String.highlight(displayTitle, search);
        }
        a.innerHTML = displayTitle;
        var title = item.content.stripTags().truncate(255);
        a.desc = title;
        a.onmouseover = function() {
          UWA.Utils.setTooltip(this, this.desc, 250);
        }
        li.appendChild(a);
        var display = true;
        if(display) { feedList.appendChild(li); j++;
      }
    }
    widget.setBody(feedList);
  }
  widget.onLoad = function() {
    widget.log('RSSReader.onLoad');
    UWA.Data.getFeed(widget.getValue('url'), RSSReader.display);
  }
  widget.onRefresh = widget.onLoad;
</script>
</head>

<body>
  <p>Loading ...</p>
</body>
</html>

Przepis na gadżet

Rdzeniem napisanego w UWA widgeta jest pojedynczy, statyczny plik XHTML, zawierający w nagłówku odniesienie do przestrzeni nazw NetVibes:

 xmlns:widget=“http://www.netvibes.com/ns/”

Następnie w nagłówku strony należy umieścić w tagu preferences opcje widgeta – takie, które będą dostępne dla użytkownika po kliknięciu odpowiedniego linka na stronie (w zależności od platformy link ten może wyglądać inaczej):

 <widget:preferences>
  <preference name="url" type="text" label="URL" defaultValue=" http://j2ee.pl/feed/" />
  <preference name="limit" type="range" label="Number of items to display" defaultValue="7" step="1" min="1" max="10" />
 </widget:preferences>

Oczywiście, posiadanie właściwości nie jest niezbędne – można napisać widget bez żadnych opcji dostępnych dla użytkownika. Wtedy po prostu pozostawia się tag pusty:

 <widget:preferences/>

Aktualnie UWA udostępnia kilka typów opcji, opartych na rodzajach pól w HTML-owych formularzach: text, password, boolean (odpowiednik checkbox), list (odpowiednik select), range (coś jak list, tylko z automatycznie generowanymi wartościami liczbowymi) i hidden. Trwają pracę nad obsłużeniem pól typu textarea. Wartości owych właściwości mogą zostać wykorzystane we właściwym javascriptowym kodzie widgeta w dalszej części strony za pomocą metody getValue obiektu widget.

Danie główne – obiekty widget i UWA

Kod javascriptowy kręci się wokół obiektu widget, którego metody analogiczne do zdarzeń (onLoad, onRefresh i inne) zawierają lub wywołują właściwy kod programu. Najczęściej – jeśli widget nie jest tylko lokalną aplikacją (np. grą), tylko sięga do zewnętrznych źródeł danych – kod ten zawiera jedną z dostarczanych przez UWA AJAXowych metod pobierania danych. W przykładzie, w metodzie onLoad można to znaleźć w linijce:

 UWA.Data.getFeed(widget.getValue('url'), RSSReader.display);

Obiekt UWA.Data dostarcza kilka podobnych metod do wyboru. UWA.Data.getText() zwraca odpowiedź w formacie plain text, getXml() – w formacie XML, getJson() – w formacie danych JSON, getFeed() jest formą tego ostatniego, z tym, że JSONowa odpowiedź dodatkowo jest kompatybilna ze wszystkimi formatami źródeł danych – RSS, Atom i inne. Wszystkie metody pobierają dwa argumenty – adres źródła danych oraz nazwę funkcji, do której ma zostać przesłana odpowiedź (w przykładzie naszego czytnika RSS jest to metoda RSSReader.display()). Dodatkowo obiekt UWA.Data posiada metodę request(), która pobiera argumenty w postaci adresu oraz obiektu, przechowującego szczegóły żądania. Tak naprawdę wszystkie wymienione wcześniej metody (getText, getFeed itp.) są odpowiednio przeładowaną metodą request. Metody tej w czystej postaci używa się przy bardziej zaawansowanych potrzebach.
Same źródła natomiast mogą być zupełnie dowolne – pod adresem, przekazywanym do metody, może znajdować się (jak w naszym przykładzie) kanał RSS, ale może to być dowolna inna zawartość (np. skrypt PHP, ASP czy JSP) generująca odpowiedź w odpowiednim formacie. Może to być, jak już wspomniałem, skrypt specjalnie na potrzeby tego widgeta napisany.
Wracając do naszego przykładu – skoro już metoda getFeed zwróciła nam JSONowy obiekt z podanego adresu, przyjrzyjmy się metodzie, do której odpowiedź z serwera jest przekazywana. Metoda display przetwarza zawartość zwróconego obiektu feed i na jego podstawie buduje ciało strony. Używane są do tego metody obiektu widget takie, jak createElement, tworząca element HTMLowy podanego jako argument typu (np. widget.createElement(’a’) stworzy odnośnik) oraz metod obiektów reprezentujących owe elementy (addContent, setHTML, setStyle…). W ten sposób tworzona jest struktura DOM dokumentu, która, gdy już będzie gotowa, ładowana jest do ciała strony metodą widget.setBody, zastępując aktualną jego zawartość (dlatego jedyną zawartością znacznika <body> jest tymczasowy tekst „Loading…”, który znika po tym, jak metoda display przetworzy odpowiedź na żądanie).

Deser – skrypty wykonywane po stronie serwera

Jak już wspomniałem, widget może sięgać do źródeł danych specjalnie dla niego utworzonych, np. skryptów PHP. Jako przykład podam widgeta, pobierającego dane nie z jednego, a z wielu kanałów Atom (w tym przypadku – blogów z serwisu Blogger, których adresy przechowywane są w pliku myfeed.txt) i informujący o tym, kiedy każdy z nich był ostatnio aktualizowany.

Poniżej cytuję sam kod JavaScript z pliku XHTML widgeta. Nie korzysta on z żadnych ustawień (preferences) widgeta, więc obudowanie go odpowiednim kodem XHTML, wzorowanym choćby na powyższym przykładzie czytnika RSS, nie będzie trudne:

<script type="text/javascript">
var xmlHttp = false;
var blogNote = false;
var MyFeed = {
  feed : false,
  feedArray : false,
  oneFeed : false,
  processFeed : function(feed) {
    widget.log(feed);
  }
}

MyFeed.parseFeeds = function(feed) {
  if(feed) MyFeed.feed = feed;
  widget.log(feed);
  var feedList = widget.createElement('ul');
  feedList.className = 'nv-feedList';
  feedArray = new Array();
  for(var i=0;i<MyFeed.feed.list.length;i++) {
    var li = widget.createElement('li');
    var titleTxt = widget.createElement('a');
    titleTxt.className = 'myFeed_blogTitle';
    titleTxt.href = MyFeed.feed.list[i].url;
    titleTxt.target = '_blank';
    titleTxt.innerHTML = MyFeed.feed.list[i].title;
    li.appendChild(titleTxt);
    li.appendChild(widget.createElement('br'));
    var dateTxt = widget.createElement('span');
    dateTxt.className = 'myFeed_when';
    dateTxt.innerHTML = MyFeed.getWhen(MyFeed.feed.list[i].entry_when);
    li.appendChild(dateTxt);
    li.appendChild(widget.createElement('br'));
    var articleTxt = widget.createElement('a');
    articleTxt.className = 'myFeed_title';
    articleTxt.href = MyFeed.feed.list[i].url;
    articleTxt.target = '_blank';
    articleTxt.innerHTML = MyFeed.feed.list[i].entry_title;
    li.appendChild(articleTxt);
    li.appendChild(widget.createElement('br'));
    var categoriesTxt = widget.createElement('span');
    categoriesTxt.className = 'myFeed_categories';
    for(var j=0;j<MyFeed.feed.list[i].entry_cats.length;j++) {
      var categoryTxt = widget.createElement('span');
      categoryTxt.className = 'myFeed_category';
      categoryTxt.innerHTML = MyFeed.feed.list[i].entry_cats[j];
      categoriesTxt.appendChild(categoryTxt);
      if(j+1 == MyFeed.feed.list[i].entry_cats.length) {
        break;
      }
      categoriesTxt.innerHTML += ', ';
    }
    li.appendChild(categoriesTxt);
    feedList.appendChild(li);
  }
  widget.setBody(feedList);
}

MyFeed.getWhen = function(datestr) {
  var then = parseInt(datestr);
  var now = Date.parse(Date());
  var whentxt = "";
  var when = now - then;
  if(when < 3600000) {
    whentxt = ""+Math.floor(when/60000)+" minut temu";
  } else if (when < 86400000) {
    whentxt = ""+Math.floor(when/3600000)+" godzin temu";
  } else {
    whentxt = ""+Math.floor(when/86400000)+" dni temu";
  }
  return whentxt;
}

widget.onLoad = function() {
  var url = 'myfeed.php';
  UWA.Data.getJson(url, MyFeed.parseFeeds);
}
</script>

Widget ten wysyła zapytanie do specjalnie utworzonego skryptu PHP, który sam pobiera dane z kanałów i na ich podstawie generuje odpowiedź w formacie JSON, którą odsyła do aplikacji. Następnie metoda parseFeeds ze zwróconego JSONa (w specjalnie utworzonym formacie, nie tym zwracanym przez metodę getFeed – oto dowód, że w formacie JSON można przesyłać naprawdę dowolne dane, nie tylko te kompatybilne z uniwersalnym formatem kanałów RSS i podobnych).

Oto zawartość pliku myfeed.php:

<?php
error_reporting(E_ALL);
header ("Content-type: text/plain");

if(!file_exists("myfeed.txt"))
  echo "";
else {
  $file = fopen("myfeed.txt","r");
  echo " { \"list\" : ";
  $ec=0;
  while(!feof($file)) {
    if($ec == 0)
      echo " [ ";
    else
      echo " , ";
    $ec++;

    $url = chop(fgets($file));
    $xmlDoc = new DOMDocument();
    $xmlDoc->load($url);

    //get elements from "<feed>"
    $feed=$xmlDoc->getElementsByTagName('feed')->item(0);
    $feed_title = $feed->getElementsByTagName('title')->item(0)->nodeValue;
    $feed_url = $url;
    $feed_author = $feed->getElementsByTagName('author')->item(0)->firstChild->nodeValue;

    //get and output first "<item>" element
    $feed_entry=$xmlDoc->getElementsByTagName('entry')->item(0);
    $feed_entry_when = strtotime($feed_entry->getElementsByTagName('published')->item(0)->nodeValue)*1000;
    $feed_entry_cats = $feed_entry->getElementsByTagName('category');
    $feed_entry_categories = array();

    //get post categories
    for($i=0; $i<$feed_entry_cats->length; $i++) {
      $feed_entry_categories[] = $feed_entry_cats->item($i)->attributes->getNamedItem('term')->nodeValue;
    }
    $feed_entry_title = $feed_entry->getElementsByTagName('title')->item(0)->nodeValue;

    echo " { \n";
    echo "\"title\" : \"" . str_replace("\"","\\\"",$feed_title) . "\" , \n";
    echo "\"author\" : \"" . $feed_author . "\" , \n";
    echo "\"url\" : \"" . $feed_url . "\" , \n";
    echo "\"entry_when\" : \"" . $feed_entry_when . "\" , \n";
    echo "\"entry_title\" : \"" . str_replace("\"","\\\"",$feed_entry_title) . "\" , \n";
    echo "\"entry_cats\" : ";
    for($i=0; $i<count($feed_entry_categories); $i++) {
      if($i==0)
        echo " [ ";
      else
         echo " , ";
      echo "\"" . $feed_entry_categories[$i] . "\"";
    }
    echo " ] \n";
    echo " } \n";
  }
  echo " ] }";
}
fclose($file);
?>

Plik myfeed.txt, z którego powyższ skrypt czyta adresy kanałów Atom zawiera po prostu kilka adresów kanałów z kilku zaprzyjaźnionych blogów w serwisie Blogger.com.

Przydatność do spożycia

UWA jest wynalazkiem bardzo nowym, wciąż jeszcze rozwijanym i nie w pełni kompatybilnym z wszystkimi tymi platformami, którymi przechwalają się twórcy. Nie mniej jednak wyraźnie widać jego zalety i możliwości. Nie miałem możliwości przetestować jego działania pod Vistą czy MAC OSem ani na iPhone, a testy pod Operą zakończone były porażką, ale w głównych zastosowaniach – na stronach NetVibes, iGoogle czy w ramce iframe na dowolnej innej stronie – sprawdzają się bardzo dobrze. Myślę, że gdy zostanie dopracowane i przeniesione na jeszcze większą liczbę platform (telefony i urządzenia mobilne inne niż iPhone), Universal Widget API może cieszyć się zasłużonym zainteresowaniem, a programy w nim napisane mogą być w równym stopniu proste, jak przydatne.

Tomcat

W trakcie normalnego działania klastra sesje są replikowane między wszystkimi komputerami przy użyciu jednej z następujących metod:

1. Replikacja poprzez współdzielony sieciowy system plików (PersistanceManager + FileStore)
2. Replikacja do bazy danych (PersistanceManager + JDBCStore)
3. Replikacja w pamięci (SimpleTcpCluster)

Jeżeli jeden z Tomcatów ulegnie awarii jest usuwany z klastra a powiązane z nim zapytania są automatycznie przekierowywane przez loadbalancera. Sesje powiązane z uszkodzonym serwerem mogą zostac w zależności od konfiguracji wygaszone lub nie.

Przynależność do klastra jest określana przy pomocy pakietów UDP wysyłanych przez wszystkie Tomcaty, ze skonfigurowanym tym samym adresem multicastowym oraz portem. Replikacja sesji odbywa się przy użyciu pakietów TCP.

Zawór replikacji (ReplicationValve) służy do określenia kiedy zapytanie zostało zakończone i klaster może rozpocząć replikację.

Element w pliku server.xml konfiguruje domyślnie klaster z następującymi parametrami:

• Membership z adresem multicastowym 228.0.0.4 i portem udp 8012
• Potwierdzenie wysyłane co sekundę, usunięcie z listy po 30 sekundach bez odpowiedzi od danego Tomcata
• Odbiorca wiadomości SocketReplicationListener na domyślnym adresie IP oraz pierwszym wolnym portem z zakresu 8015 – 8019
• Replikacja oparta o ReplicationTransmitter w trybie fastasyncqueue
• Dodane ClusterSessionListener oraz ReplicationValve.

Wystarczy to do podstawowego skonfigurowania klastra, np. na maszynie developerskiej, jednakże w środowisku produkcyjnym zaleca się modyfikację ilości wątków obsługujących replikację i tryb replikacji.

Tipsy:

• Dokumentacja dotycząca klastrowania znajduje się tutaj: Tomcat 5.5, Tomcat 6.0
• Obiekty które są zapisywane w sesji muszą implementować java.io.Serializable (np. dto w kreatorach springowych)
• Na serwerach należy włączyć obsługę multicastu (np. pod Linuxem: ifconfig eth0 multicast)
• W web.xml powinien znajdować się element <distributable />, który powoduje, że dana aplikacja jest zdolna do działania w środowisku rozproszonym, czyli np. w klastrze.
• Najważniejszym elementem jeżeli chodzi o wydajność replikacji jest parametr replicationMode, konfigurowalny w elemencie <Sender …/>

Apache i mod_jk

Mod_jk to moduł do apache’a obsługujący komunikację z Tomcatem. Worker to instancja Tomcata na której uruchomione są servlety i do której przekierowywane są zapytania. Mod_jk jest konfigurowany, tak jak inne moduły, w pliku apache.conf lub httpd.conf. W niektórych dystrybucjach (np. debian) pliki konfiguracyjne modułów znajdują się w podkatalogu mods-enabled i są includowane w głownym pliku konfiguracyjnym.

Konfiguracja mod_jk

Moduł ładowany jest przy pomocy dyrektywy:

LoadModule jk_module ${sciezkaDoKataloguZModulami}/mod_jk.so

Następnie musimy dodać plik z workerami:

JkWorkersFile /etc/apache/workers.properties

Oczywiście plik workers.properties znajdować się może w dowolnym miejscu widocznym przez Apache’a.

Dodatkowo, należy też skonfigurować punkt montowania, czyli scieżkę od której przetwarzaniem zapytań zajmować będzie się Tomcat.

JkMount /* tomcat1

Ta dyrektywa sprawia, że wszystkie zapytania które odbierze Apache będą przekserowane do Wolkera o nazwie tomcat1. JkMount może się powtarzać i umieścić ją można zarówno w globalnej konfiguracji, VirtualHost jak i w Location (tylko nazwa workera, ścieżka będzie z Location) .
Zamiast montowania każdego punktu z osobna można użyć pliku uriworkermap.properties przy pomocy dyrektywy JkMountFile wskazującej na plik z mapowaniem.

Konfiguracja workera

Workery znajdują się przeważnie w pliku workers.properties. W pliku powinna znaleźć się dyrektywa worker.list oraz definicja co najmniej jednego workera. Worker.list to lista oddzielonych przecinkami workerów, które będą udostępnione mod_jk. Workera definiuję się w następujący sposób:

worker.nazwaWorkera.type=
worker.nazwaWorkera.host=
worker.nazwaWorkera.port=

Typ to najczęściej ajp13, który zastąpił starszy ajp12 i udostępnił między innymi kompresje danych i obsługę SSL’a.

Konfiguracja loadbalancera

Loadbalancer to specyficzny typ workera który nie komunikuje się z Tomcatem, tylko zajmuję się zarządzaniem pozostałymi „prawdziwymi” workerami, czyli min. rozdziela zadania na poszczególne instancje Tomcata używając algorytmu Round Robin z wagami. Sprawdza też które Tomcaty z listy nie odpowiadają i nie wysyła do nich zapytań.

Konfiguracja definiuję się w nastepujący sposób:

worker.nazwaWorkeraLB.balance_workers=

Dodatkowo można skonfigurować sticky session, czyli czy loadbalancer powinien przekierowywać zapytania z istniejącym sessionId do obsługującego je wcześniej Tomcata. Domyślnie ta funkcjonalność jest włączona.

Workerom można przyporządkować rózne wagi (worker.nazwaWorkera.lbfactor) a w loadbalancerze zmienić metodę wyboru workera do którego przekazane zostaną zapytania (worker.nazwaWorkeraLB.method). Do wyboru są następujące metody:
•R[equest] – kryterium jest obłożenie zapytaniami. Domyślne ustawienie.
•S[ession] – kryterium jest obłożenie sesjami. Zalecane w przypadku ograniczonych zasobów do obsługi sesji.
•B[usyness] – kryterium jest aktualne obciążenie serwera. Zalecane w przypadku długich sesji, np. w aplikacjach udostępniających pliki.
•T[raffic] – kryterium jest ilość ruchu na łączu między Apachem a Tomcatem. Zalecane w przypadku ograniczonej łączności między klasterm a Apachem.

Linki:

• Pozostałe dyrektywy
• Konfiguracja pliku mapowań
• Dokumentacja workerów

Przykłady

Apache -> mod_jk -> 1 tomcat

Najprostszy przykład. Zapytania są przekierowywane do jednego tomcata.

Konfiguracja Apache 1:

workers.properties:

worker.list=tomcat1

worker.tomcat1.type=ajp13
worker.tomcat1.host=10.1.1.2
worker.tomcat1.port=8009

Konfiguracja Tomcat1:

server.xml, sekcja Service:

<Connector port="8009"  protocol="AJP/1.3" />

Apache -> mod_jk -> 2 tomcaty w klastrze

Najbardziej użyteczna według mnie konfiguracja, bez użycia balansowania DNS’owego lub sprzętowego. Balansowaniem zajmuje się mod_jk.

Konfiguracja Apache 1:

workers.properties:

worker.list=cluster

worker.tomcat1.type=ajp13
worker.tomcat1.host=10.1.1.2
worker.tomcat1.port=8009

worker.tomcat2.type=ajp13
worker.tomcat2.host=10.1.1.3
worker.tomcat2.port=8009

worker.cluster.type=lb
worker.cluster.balance_workers=tomcat1, tomcat2

Konfiguracja Tomcat’ów:

server.xml, sekcja Service:

<Connector port="8009"  protocol="AJP/1.3" />

server.xml, sekcja Host:

<Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster"/>

Dodatkowo, do należy dopisać jvmRoute=”${nazwaHosta}”, gdzie ${nazwaHosta} to odpowiednio tomcat1 i tomcat2

Apache -> mod_jk -> 1 tomcat jako loadbalancer -> 2 tomcaty w klastrze

Metoda ta używa aplikacji “balancer” uruchomionej na Tomcat’ie, który nie jest w klastrze. Zaletą tego rozwiązania jest możliwość dowolnego skonfigurowania balancingu. Wadą jest konieczność napisania klasy zajmującej się wyborem najlepszego Tomcata. Rozwiązanie to używa pliku workers.properties z przykładu pierwszego, konfiguracji klastra z przykładu drugiego oraz dodatkowego Tomcata, na którym działa aplikacja balancer. workers.properties przekierowuje zapytania na Tomcata pełniącego rolę LoadBalancera.

Czy istnieje sposób aby tego uniknąć (na przykład automatycznie logując się do aplikacji przy użyciu danych wprowadzonych podczas autoryzacji w domenie Windows)? Jak najbardziej tak – aczkolwiek nie jest to zadaniem trywialnym. Niniejszy artykuł opisuje proces integracji serwera BEA WebLogic z systemem Kerberos, jednakże jego celem nie jest wyjaśnienie wszystkich aspektów tego procesu (wyjaśnienie na tym poziomie szczegółowości mogłoby z powodzeniem wypełnić książkę). Celem tego artykułu jest raczej przeprowadzenie operatora domeny Active Directory przez proces integracji w najbardziej typowych warunkach.

Środowisko testowe

Środowisko testowe składać się będzie z trzech komputerów (p. Rys. 1):

1. zeus: pracujący pod Windows 2003 kontroler domeny olympus.net (ang. Domain Controller, DC), z uruchomionym Centrum Dystrybucji Kluczy (ang. Key Distribution Center, KDC) systemu Kerberos. (Uwaga: proces integracji różni się w zależności od wersji systemu Windows, pod kontrolą której pracują DC i KDC. Niniejszy artykuł opisuje proces integracji w oparciu o system Windows 2003).

2. athena: serwer aplikacji BEA Weblogic 9.2. Na potrzeby tego artykułu zakładamy, że systemem operacyjnym na serwerze athena jest system UNIX-owy

3. apollo: stacja robocza klienta, który jest zalogowany w domenie i chce uzyskać dostęp do aplikacji zainstalowanej na serwerze athena.

Rys. 1. Środowisko testowe i proces logowania się do aplikacji WWW zintegrowanej z systemem Kerberos (1 – Użytkownik zalogowany do stacji apollo.olympus.net próbuje uzyskać dostęp do części chronionej aplikacji WWW. 2 – przeglądarka użytkownika wysyła żądanie do serwera aplikacji WWW athena.olympus.net, i odbiera odpowiedź HTTP401, rozpoczynającą proces logowania się do aplikacji za pośrednictwem systemu Kerberos. 3 – Komputer apollo.olympus.net łączy się z KDC (zeus.olympus.net) i wysyła żądanie przyznania ticketa. 4 – po pozytywnej identyfikacji użytkownika i hosta w domenie, serwer KDC odsyła ticket do komputera apollo.olympus.net. 5 – ticket zostaje przekazany komputerowi athena.olympus.net. Po poprawnym przetworzeniu ticketu, proces identyfikacji użytkownika kończy się sukcesem. 6 – serwer athena.olympus.net łączy się z LDAP Active Directory, celem pobrania grup AD (traktowanych jako role użytkownika). Po pobraniu grup kończy się proces autoryzacji użytkownika w aplikacji WWW)

Konfiguracja w KDC

Proces integracji serwera Weblogic z domeną Windows należy rozpocząć od utworzenia w kontrolerze domeny zeus.olympus.net konta dla serwera aplikacji. Konto to musi spełniać kilka określonych warunków (p. tabela 1)

Typ pola	Wartość	Uwagi
First name	athena.olympus.net	Nazwa konta identyczna z nazwą hosta (oczywiście w domenie musi istnieć serwer DNS i ReverseDNS odwzorowujący dla hosta athena.olympus.net
Login	athena.olympus.net	Login taki sam jak nazwa hosta.
Hasło	longlongpassword	Hasło będzie wykorzystane dalej, do generowania pliku zawierającego klucz szyfrowania
Algorytm szyfrowania hasła	DES	Po włączeniu szyfrowania DES na koncie należy zresetować hasło konta, podając nowe hasło 100% zgodne ze star

Tabela 1. Konto w Active Directory przeznaczone dla serwera aplikacji

Integracja z systemem Kerberos wymaga zarejestrowania w KDC usług, z którymi będziemy się integrować. Dokonujemy tego poprzez ustalenie tzw. Service Principal Names, SPN, na podstawie których identyfikowane sa usługi, dla których system Kerberos wystawia tickety. Aby zarejestrować SPN dla serwera Weblogic, w linii komend serwera KDC (zeus.olympus.net) wpisujemy:

setspn -a HOST/athena.olympus.net@OLYMPUS.NET athena.olympus.net
setspn -a HTTP/athena.olympus.net@OLYMPUS.NET athena.olympus.net

gdzie athena.olympus.net to nazwa konta użytkownika (zarejestrowanego w kontrolerze domeny) z którego uruchamiany jest serwer aplikacji na komputerze athena.olympus.net@OLYMPUS.NET

Aby sprawdzić poprawność wygenerowanych SPNs należy na serwerze KDC wpisać następującą komendę:

setspn –L athena.olympus.net

po wpisaniu powyższej komendy, powinny zostać wyświetlone SPNs skojarzone z kontem Active Directory athena.olympus.net

Następnym krokiem jest utworzenie tzw. pliku keytab zawierającego klucz służący do szyfrowania i deszyfrowania ticketów wydawanych przez system Kerberos dla serwera athena:

ktpass -princ HTTP/athena.olympus.net@OLYMPUS.NET
-mapuser athena.olympus.net
-crypto DES-CBC-MD5
-ptype KRB5_NT_PRINCIPAL
-mapop set +desonly
-pass longlongpassword
-out c:\temp\athena.http.keytab

ktpass -princ HOST/athena.olympus.net@OLYMPUS.NET
-mapuser athena.olympus.net
-crypto DES-CBC-MD5
-ptype KRB5_NT_PRINCIPAL
-mapop set +desonly
-pass longlongpassword
-out c:\temp\athena.host.keytab

Podczas tworzenia pliku keytab należy podać SPN, dla którego tworzony jest plik keytab, algorytm szyfrowania ticketów oraz hasło użytkownika wymienionego w parametrze mapuser. Obydwa pliki keytab (zapisane na dysku w miejscu wyspecyfikowanym w parametrze out) przekazujemy następnie administratorowi serwera athena.

Konfiguracja serwera athena

Pierwszym krokiem konfiguracji serwera athena.olympus.net jest skonfigurowanie klienta systemu Kerberos, czyli przekazanie mu danych domeny OLYMPUS.NET. Dokonujemy tego poprzez wykonanie następującego wpisu w plikach /etc/krb5/kdc.conf oraz /etc/krb5/krb5.conf

[kdcdefaults] kdc_ports = 88,750 [realms] OLYMPUS.NET = { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /etc/krb5/kadm5.keytab acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s default_principal_flags = +preauth }

Tabela 2. Przykładowa treść pliku kdc.conf

Najważniejszym ustawieniem jest tutaj podanie ścieżki do pliku krb5.conf oraz włączenie preautentykacji dla wszystkich principali.

Kolejnym krokiem konfiguracyjnym jest utworzenie/edycja pliku krb5.conf, który powinien zawierać informacje o kontrolerze/kontrolerach domeny, algorytmie szyfrowania ticketów, ustawieniach klienta Kerberosa oraz samej domenie AD.

[libdefaults] default_realm = OLYMPUS.NET default_tkt_enctypes = des-cbc-md5 default_tgs_enctypes = des-cbc-md5 ticket_lifetime = 600 [realms] OLYMPUS.NET = { kdc = 10.1.1.1:88 kdc = 10.1.1.2:88 kdc = 10.1.1.3:88 kdc = 10.1.1.4:88 admin_server = 10.1.1.1 default_domain=OLYMPUS.NET } [domain_realm] .olympus.net = OLYMPUS.NET [appdefaults] autologin = true forward = true encrypt = true forwardable= true

Tabela 3. Przykładowa treść pliku krb5.conf, konfigurująca więcej niż jeden serwer KDC

Po utworzeniu/edycji dwóch powyższych plików, należy pobrać od administratora KDC dwa pliki keytab, które zostały utworzone podczas przygotowywania KDC do integracji z serwerem aplikacji.

Po otrzymaniu obu plików keytab należy je scalić za pomocą narzędzia ktutil, wydając następujące komendy:

ktutil – uruchamia narzędzie ktutil

rkt athena.http.keytab – wczytuje keytab HTTP

rkt athena.host.keytab – wczytuje keytab HOST

wkt athena.keytab – zapisuje scalony plik keytab

q – zamyka narzędzie ktutil

Po wykonaniu scalenia, należy sprawdzić poprawność konfiguracji wydając polecenie

kinit –k –t /<ścieżka>/athena.keytab

Jeżeli nie otrzymamy komunikatu o błędzie, konfiguracja hostów zakończyła się sukcesem i możemy przejść do konfiguracji serwera BEA WebLogic.

Konfiguracja serwera aplikacji

Aby rozpocząć konfiguracje, należy przygotować plik konfiguracji logowania w domenie JAAS dla serwera aplikacji, krb5.login.config. Powinien on zawierać m.in. dane niezbędne serwerowi aplikacji do zlokalizowania pliku athena.keytab. Przykładową treść takiego pliku przedstawia tabela 4.

com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="HTTP/athena.olympus.net@OLYMPUS.NET" useKeyTab=true keyTab="/etc/athena.keytab" storeKey=true; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required principal="HTTP/athena.olympus.net@OLYMPUS.NET" useKeyTab=true keyTab="/etc/athena.keytab" storeKey=true; };

Tabela 4. Przykładowa treść pliku krb5.login.config

Plik krb5.login.config powinien zostać utworzony w obrębie domeny serwera WebLogic. W dalszej części artykułu przyjmujemy, że został on utworzony w katalogu głównym domeny, oznaczanym jako $DOMAIN_HOME.

Po utworzeniu konfiguracji logowania domeny JAAS, należy uzupełnić zestaw parametrów rozruchowych serwera WebLogic o parametry specyficzne dla integracji z serwerem Kerberos. Listę parametrów zawiera tabela 5.

-Djava.security.krb5.realm=OLYMPUS.NET -Djava.security.krb5.kdc=10.1.1.1 -Djava.security.auth.login.config= ${DOMAIN_HOME}/krb5.login.config -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true -Dweblogic.security.identityAssertionTTL=-1 -Dsun.security.krb5.debug=true -DDebugSecurityAdjudicator=true -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugSecurityAtz=true

Tabela 5. Lista dodatkowych parametrów rozruchowych serwera BEA WebLogic

Na liście parametrów znajdują się między innymi nazwa domeny, adres KDC, położenie pliku konfiguracji logowania. Parametr weblogic.security.identityAssertionTTL określa czas (w sekundach) ważności pojedynczego ustalenia tożsamości logującego się do usługi. Standardowo ma on wartość 300, ustawienie na -1 oznacza, że od razu po zalogowaniu dane ustalenie tożsamości jest nieważne i proces logowania powinien się rozpocząć od nowa przy każdej następnej próbie uzyskania dostępu do aplikacji przez danego użytkownika. Ostatnie cztery parametry włączają tryb DEBUG logowania mechanizmów dokonujących identyfikacji i autoryzacji w WebLogic. Ustawienie ich na true powoduje duży przyrost logów, dlatego po fazie testów integracji najlepiej przestawić je na false. Logi autentykatorów znajdują się w katalogu DOMAIN_HOME/servers/<nazwa_serwera_weblogic>.

Po dodaniu parametrów rozruchowych należy uruchomić domenę i zalogować się do konsoli zarządzania serwerem. Po zalogowaniu się, należy przejść do Security Realms/<nazwa_domeny_JAAS> i wejść na zakładkę Providers.

Rys. 2. Konfiguracja autentykatorów serwera WebLogic zintegrowanego z domeną Active Directory.

Na zakładce Providers należy skonfigurować dwa autentykatory. Pierwszym z nich jest NegotiateIdentityAsserter, który powinien znaleźć się na szczycie stosu autentykatorów serwera WebLogic. Jego konfiguracja jest trywialna – w zdecydowanej większości przypadków wystarczy go tylko dodać do stosu.

Kolejnym autentykatorem, który należy skonfigurować w celu zintegrowania serwera WebLogic z domeną Active Directory jest ActiveDirectoryAuthenticator.

Rys. 3. Konfigurowanie ActiveDirectoryAuthenticator

Podczas jego konfigurowania (na zakładce „Provider Specific” p. Rys. 3), należy wprowadzić informacje o domenie AD, między innymi:

· adres IP Kontrolera Domeny

· port, na którym działa usługa LDAP AD zawierająca dane domeny

· gałąź użytkowników w drzewie LDAP AD

· gałąź grup w drzewie LDAP AD

· nazwę i hasło użytkownika zarejestrowanego w domenie, z uprawnień którego korzysta system podczas logowania się do LDAP AD. W naszym przykładzie, użytkownikiem takim będzie athena.olympus.net

Następnie należy przygotować naszą aplikację WWW do integracji z Kerberosem. Dokonujemy tego, zmieniając wpis dotyczący konfiguracji logowania w pliku web.xml aplikacji na:

<login-config>

<auth-method>CLIENT-CERT</auth-method>

</login-config>

Konfiguracja przeglądarki klienta

Zakładamy, że klient zalogowany na stacji apollo.olympus.net będzie uzyskiwał dostęp do aplikacji za pomocą przeglądarki MS Internet Explorer 7.0. Aby skonfigurować tą przeglądarkę do łączenia się z naszą aplikacją, należy dodać komputer athena.olympus.net do strefy „Lokalny intranet”. Dokonujemy tego poprzez wybranie z menu głównego przeglądarki pozycji „Narzędzia > Opcje internetowe”. Następnie, na zakładce „Zabezpieczenia” wybieramy pozycję „Lokalny intranet” i naciskamy przycisk „Witryny”. Upewniamy się, że opcje „Uwzględnij wszystkie lokalne witryny (sieć intranet), które nie należą do innych stref” oraz „Uwzględnij wszystkie witryny, które nie używają serwerów proxy” są zaznaczone. Później klikamy w przycisk „Zaawansowane” i dodajemy adres athena.olympus.net do listy witryn traktowanych jako lokalny intranet.

Następnie, na zakładce „Zabezpieczenia”, klikamy w przycisk „Poziom niestandardowy” i w sekcji „Uwierzytelnianie użytkownika” wybieramy opcję „Zaloguj automatycznie tylko w strefie intranetu”.

Podsumowanie

Czas na przetestowanie nowego sposobu logowania do aplikacji WWW. Aby tego dokonać, logujemy się na stację apollo.olympus.net i podajemy w przeglądarce adres sięgający do strefy chronionej naszej aplikacji. Jeżeli zamiast prawidłowego ekranu aplikacji zobaczymy ekran z błędem protokołu HTTP, przechodzimy do fazy debugowania właśnie wykonanej integracji. Ale to już temat na zupełnie inny artykuł.

Szczypta teorii

W żadnej poważnej publikacji nie może oczywiście zabraknąć części czysto teoretycznej! Pomimo faktu, że ta publikacja do tak zaszczytnego grona nie pretenduje, to z przykrością stwierdzam, że i tutaj teoretyczny wstęp znaleźć się niestety musi. Osoby niezainteresowane proszone są o przesunięcie paska przewijania odrobinę niżej.

Z roku na rok wdrażane systemy informatyczne stają się funkcjonalnie bardziej złożone, terminy ich oddania krótsze, a stawiane im wymagania jakościowe surowsze. Sprostanie ciągle rosnącym oczekiwaniom klientów biznesowych wymaga od firm rynku IT stosowania coraz większej ilości narzędzi formalizujących i automatyzujących proces wytwarzania aplikacji.

Już w tym momencie do grona narzędzi uważanych za niezbędne w cyklu wytwarzania oprogramowania zalicza się, i to z coraz większą stanowczością, aplikacje wspomagające proces ciągłej integracji (ang. Continuous Integration).

Uważam, że koncepcja Continuous Integration (dalej: CI) jest szczególnym przypadkiem wzorca projektowego i jako taka obecna była w informatyce w niesformalizowanej formie już od dawna. Jednak jej znacząca popularyzacja miała miejsce dopiero w okresie upowszechnienia się metodyki Extreme Programming. Z pewnością ogromny wpływ na taki stan rzeczy miały publikacje Martina Fowler‘a oraz Kenta Beck‘a, które nadały CI realne kształty i obudziły dyskusję na ten temat w światku informatycznym. Przedstawiona idea odbiła się dużym echem i w wielu projektach zaczęto wdrażać przedstawioną koncepcję.

Główna myśl stojącą za CI to wymuszenie zbudowania całego projektu w wyniku każdej najmniejszej nawet zmiany. Proces budowania powinien obejmować między innymi kompilację kodu źródłowego, sprawdzenie jego jakości przy wykorzystaniu różnych kryteriów (np. checkstyle‘a), wykonanie testów jednostkowych (np. JUnit) oraz weryfikacja stopnia w jaki pokrywają one kod źródłowy (np. Emma), wytworzenie artefaktów (w tym np. pliki war, dokumentacja). Wszystkie te działania koordynowane mogą być oczywiście przy pomocy Apache Ant, Apache Maven, czy też innego narzędzia przeznaczonego do budowania, chociaż dwa wymienione jako pierwsze wydają się być w tym momencie bezkonkurencyjne.

Widać więc zatem, że CI nie stara się wymyślać koła na nowo, a jedynie stanowi kolejną warstwę abstrakcji ponad szeroko już wykorzystywanymi narzędziami.

Zalety i wady

Podstawowe zalety CI wymieniane na większości stron internetowych związanych z tematyką, to:

• możliwość dokładnego określenia która z wprowadzonych zmian spowodowała dezintegrację rozwijanego systemu poprzez określenie w którym momencie któryś z testów jednostkowych przestał poprawnie przechodzić
• problemy związane z integracją są wykrywane i naprawiane na bieżąco
• natychmiastowa informacja na temat popsutego kodu
• natychmiastowe wykonywanie testów jednostkowych
• dostępność najnowszej wersji zbudowanej aplikacji bez konieczności jej ręcznego budowania
• możliwość śledzenia w czasie wartości różnych wskaźników opisujących różne parametry wytwarzanej aplikacji (np. stopień pokrycia kodu testami jednostkowymi)
• programiści zmobilizowani są do tworzenia lepszych rozwiązań; są bardziej świadomi, że każda wprowadzana przez nich zmiana może zostać poddana obiektywnej ocenie

Obok w/w zalet istnieją zapewne inne pomniejsze, które każdy z nas na swój sposób może w CI odnaleźć. Jakie są zatem minusy wdrożenia procesu ciągłej integracji? O wadach CI Internet dosyć głośno milczy i mnie również trudno jest znaleźć przynajmniej kilka wad, które mogłyby mieć generalny i warty wspominania charakter. Nie oznacza to jednak, że CI nie może nam przysporzyć dodatkowych problemów. Analizę potencjalnych minusów należy jednak przeprowadzić indywidualnie przy okazji wyboru konkretnego modelu realizacji CI. W większości jednak projektów używanie CI będzie sprawiać mniejsze problemy, niż te, które mogłyby wystąpić w wyniku jego nieużywania.

Manual vs. Automated

Manual Continuous Integration

Najprostszym możliwym sposobem wdrożenia CI w projekcie jest przerzucenie odpowiedzialności za jego stosowanie na programistów. Najprostszym i zarazem chyba najgorszym z możliwych. Mogłoby to polegać na zobowiązaniu osób związanych z procesem wytwarzania aplikacji do każdorazowego wykonywania serii żmudnych i mechanicznych czynności po każdej pojedynczej zmianie wprowadzonej do repozytorium. Niestety takie podejście ma bardzo wiele wad i wydaje się, że może się jedynie sprawdzać w bardzo małych projektach.

Podstawowe problemy związane z manualnym stosowaniem CI, które jestem w stanie w tym momencie wymienić, to:

• developerzy muszą poświęcić dodatkowy czas na procedury związane z CI
• występuje możliwość niedbałego podejścia developerów do stosowania CI
• obniżenie kreatywności developerów poprzez wykonywanie żmudnych i powtarzalnych procedur
• niedeterministyczne opóźnienia w publikacji artefaktów związane z koniecznością manualnego wykonania wszystkich procedur

Wymienione powyżej problemy, to jedynie niektóre z którymi możemy mieć do czynienia przy ręcznym stosowaniu koncepcji CI. Przedstawiona lista stanowi jednak dla mnie wystarczający powód, by CI w miarę możliwości starać się stosować jedynie w zautomatyzowanej formie. Tym bardziej, że proces przeprowadzania ciągłej integracji wytwarzanego projektu można bez większych przeszkód opisać w prostej sformalizowanej postaci. Umożliwi to jego automatyczne wykonywanie w wyniku konkretnego zdarzenia zachodzącego w naszym systemie (w klasycznej i najczęściej stosowanej postaci będzie to wprowadzenie przez developera zmian do kodu źródłowego projektu).

Automated Continuous Integration

Na szczęście, by wyrwać nas z marazmu związanego z ręcznym stosowaniem CI, przychodzą nam wyspecjalizowane narzędzia automatyzujące ten proces. Jeżeli nasze zakłopotanie nie mija, to tylko dlatego, że wybór odpowiedniego narzędzia, ze względu na ich mnogość, nie jest wcale prosty. Dostępnych jest przynajmniej kilkadziesiąt produktów tego rodzaju. Wybieranie aplikacji spełniającej nasze oczekiwania (w sposób możliwie najbardziej kompletny) powinno obejmować rozważenie licencji produktu, zastanowienie się nad czynnościami, które będziemy chcieli włączyć do procesu CI oraz z jakimi narzędziami chcielibyśmy, aby wybrana implementacja ACI współpracowała. Poza tym, co zostało wymienione, powinniśmy kierować się jak zawsze zdroworozsądkowymi kryteriami – podobnie jak przy doborze innych narzędzi.

W miarę kompletną listę narzędzi do automatyzacji procesu ciągłej integracji można znaleźć tutaj.

Gram praktyki

Kiedy już poznaliśmy teoretyczne podstawy CI najwyższy czas, aby przejść do jego praktycznego wykorzystania. Zaczniemy od określenia szczegółowych wymagań dotyczących modelu procesu ciągłej integracji, który chcielibyśmy zaimplementować w naszym przykładowym projekcie. By tego jednak dokonać wcześniej postaram się opisać w kilku słowach środowisko wytwórcze powiązane z naszym przykładowym projektem nazwanym przeze mnie Validator.

Elementy środowiska wytwórczego dla projektu Validator:

• Wiodący język programowania: Java
• Repozytorium: Subversion
• Narzędzie automatyzujące proces budowania: Apache Ant
• Silnik testów jednostkowych: JUnit
• Narzędzie do weryfikacji pokrycia kodu: Emma

A teraz cele, które chcielibyśmy osiągnąć dzięki zastosowaniu Automated Continuous Integration. Każde wprowadzenie zmiany do repozytorium powinno skutkować:

• kompilacją kodu źródłowego
• wykonaniem wszystkich testów jednostkowych (wraz z utrwaleniem rezultatów)
• obliczeniem stopnia pokrycia kodu testami na poziomie klas, metod oraz linii (wraz z utrwaleniem rezultatów)
• sprawdzeniem jakości kodu przy użyciu checkstyle (wraz z utrwaleniem rezultatów)
• zbudowaniem biblioteki w postaci pliku jar oraz udostępnieniu go do pobrania
• wysłaniem pod wskazany adres informacji w postaci maila o niepowodzeniu na jakimkolwiek etapie procesu

Jak łatwo można zauważyć jest to bardzo prosty przykład procesu ciągłej integracji – można wręcz rzec, że szkoleniowy. W przypadku prawdziwych projektów prawdopodobnie będziemy mieli do czynienia z wielokrotnie bardziej złożonymi mechanizmami. Nie należy się jednak tym przerażać, gdyż w większości sytuacji dodatkowa praca, jaką należy wykonać jest związana, nie z samym narzędziem ACI, ale z narzędziem służącym do budowy aplikacji (np. Apache Ant).

Hudson

Wpisując w Google hudson można by pomyśleć, że Hudson, to rzeka. Nic bardziej mylnego ;) Hudson nie jest może najbardziej popularnym narzędziem ACI, ale z pewnością jest projektem, który bardzo dynamicznie się w ostatnim czasie rozwija i posiada podatną na rozszerzalność architekturę. Istnieje wiele wtyczek rozszerzających funkcjonalność Hudson‘a o dodatkowe możliwości, a i tak ciągle pojawiają się nowe, a już istniejące są rozwijane. Widać, że projekt żyje – wróży mu to dobrą przyszłość. Hudson ma także jeszcze jedną niezaprzeczalną zaletę – osobiście bardzo lubię go używać i nie ukrywam, że mam nadzieję, że ten artykuł w jakiś, chociaż nieznaczny, sposób wpłynie na jego szybszą popularyzację.

Instalacja

Instalacja Hudson‘a jest wyjątkowo prosta. Wystarczy posiadać kontener servlet‘ów – może to być na przykład Apache Tomcat. W przypadku Tomcat‘a wystarczy jedynie przekopiować ściągnięty ze strony producenta plik hudson.war do katalogu webapps. Następnie uruchamiamy Tomcat‘a i to już wszystko! Przy standardowej konfiguracji Hudson powinien być dostępny pod adresem http://localhost:8080/hudson.

Konfiguracja Hudson‘a odbywa się poprzez Manage Hudson/System Configuration dostępne z głównej stronie. Minimalne ustawienia, jakie należy wprowadzić, to między innymi:

• lokalizacja instalacji JDK
• lokalizacja instalacji Ant/Maven
• konfiguracja serwera SMTP z którego będzie korzystał Hudson

Dodatkowo, aby umożliwić spełnienie wymagań, które sobie wcześniej postawiliśmy konieczne jest jeszcze ściągnięcie ze strony odpowiednich wtyczek i ich zainstalowanie:

• Emma – posłuży nam do śledzenia postępu pokrycia kodu testami (pomiędzy kolejnymi build‘ami)
• Violations – posłuży nam do obrazowania zastrzeżeń, jakie checkstyle ma w stosunku do naszego kodu

Instalacji plugin‘ów należy dokonać poprzez opcję Manage Hudson/Manage Plugins. Po zainstalowaniu wtyczek należy zrestartować serwer aplikacji. W tym momencie powinniśmy posiadać już Hudson‘a w postaci pozwalającej nam na osiągnięcie wyżej wskazanych celów. Teraz czeka nas jeszcze trochę pracy poza ACI związanej z czynnościami, które należy wykonać nawet, jeżeliby projekt nie korzystał z dobrodziejstw CI.

Skrypt budujący

Poniżej pozwoliłem sobie zamieścić używany w projekcie skrypt budujący Apache Ant. Jak łatwo można zauważyć jest to zwykły skrypt budujący i nic nie wskazuje na to, że był on przygotowany w celu późniejszej współpracy z Hudson‘em. Nie posiada on także żadnych magicznych powiązań z systemem ACI. Nic zatem nie stoi na przeszkodzie by wywołać go bezpośrednio za pomocą Ant‘a. Kompletne źródła projektu Validator można ściągnąć stąd.

<?xml version="1.0"?>
<project name="Validator" default="build_jar">

  <property name="main.source.dir" location="src" />
  <property name="test.source.dir" location="test" />
  <property name="lib.dir" location="lib" />
  <property name="build.dir" location="build" />
  <property name="dist.dir" location="${build.dir}/dist" />
  <property name="main.source.build.dir" location="${build.dir}/classes/source" />
  <property name="main.source.debug.dir" location="${build.dir}/classes/source_debug" />
  <property name="main.source.instrumented.dir" location="${build.dir}/classes/source_instrumented" />
  <property name="test.source.build.dir" location="${build.dir}/classes/test" />
  <property name="test.result.dir" location="${build.dir}/test" />
  <property name="violations.result.dir" location="${build.dir}/violations" />
  <property name="coverage.result.dir" location="${build.dir}/coverage" />
  <property name="code.coverage.metadata.file" location="${coverage.result.dir}/coverage.em" />
  <property name="code.coverage.xml.file" location="${coverage.result.dir}/coverage.xml" />
  <property name="code.coverage.html.file" location="${coverage.result.dir}/coverage.html" />
  <property name="checkstyle.result.file" location="${violations.result.dir}/checkstyle.xml" />
  <property name="main.jar.file" value="validator.jar" />

  <taskdef name="emma" classname="com.vladium.emma.emmaTask">
    <classpath>
      <fileset dir="${lib.dir}">
        <include name="emma_ant.jar" />
        <include name="emma.jar" />
      </fileset>
    </classpath>
  </taskdef>

  <taskdef resource="checkstyletask.properties" classpath="${lib.dir}/checkstyle-all-4.3.jar" />

  <path id="test.build.classpath">
    <pathelement location="${main.source.build.dir}" />
    <fileset dir="${lib.dir}">
      <include name="junit.jar" />
    </fileset>
  </path>

  <path id="test.runtime.classpath">
    <pathelement location="${main.source.instrumented.dir}/classes" />
    <pathelement location="${test.source.build.dir}" />
    <fileset dir="${lib.dir}">
      <include name="junit.jar" />
      <include name="emma.jar" />
    </fileset>
  </path>

  <target name="clean">
    <delete dir="${build.dir}" />
  </target>

  <target name="compile_main">
    <mkdir dir="${main.source.build.dir}" />
    <javac srcdir="${main.source.dir}" destdir="${main.source.build.dir}" />
  </target>

  <target name="compile_main_debug">
    <mkdir dir="${main.source.debug.dir}" />
    <javac srcdir="${main.source.dir}" destdir="${main.source.debug.dir}" debug="true" />
  </target>

  <target name="compile_test">
    <mkdir dir="${test.source.build.dir}" />
    <javac srcdir="${test.source.dir}" destdir="${test.source.build.dir}">
      <classpath refid="test.build.classpath" />
    </javac>
  </target>

  <target name="run_test" depends="compile_main,compile_main_debug,compile_test">
    <mkdir dir="${test.result.dir}" />
    <delete dir="${main.source.instrumented.dir}" />
    <mkdir dir="${main.source.instrumented.dir}" />
    <emma>
      <instr outdir="${main.source.instrumented.dir}" mode="fullcopy" merge="false" metadatafile="${code.coverage.metadata.file}">
        <instrpath>
          <pathelement location="${main.source.debug.dir}" />
        </instrpath>
      </instr>
    </emma>
    <junit fork="yes">
      <formatter type="xml" />
      <classpath refid="test.runtime.classpath" />
      <sysproperty key="emma.coverage.out.file" value="${code.coverage.metadata.file}" />
      <sysproperty key="emma.coverage.out.merge" value="true" />
      <batchtest todir="${test.result.dir}">
        <fileset dir="${test.source.dir}" />
      </batchtest>
    </junit>
    <emma>
      <report sourcepath="${main.source.dir}">
        <infileset file="${code.coverage.metadata.file}" />
        <xml outfile="${code.coverage.xml.file}" />
        <html outfile="${code.coverage.html.file}" />
      </report>
    </emma>
  </target>

  <target name="violations">
    <mkdir dir="${violations.result.dir}" />
    <checkstyle config="${lib.dir}/sun_checks_eclipse.xml">
      <fileset dir="${main.source.dir}" includes="**/*.java" />
      <formatter type="xml" toFile="${checkstyle.result.file}" />
    </checkstyle>
  </target>

  <target name="build_jar" depends="run_test,violations">
    <mkdir dir="${dist.dir}" />
    <jar basedir="${main.source.build.dir}" destfile="${dist.dir}/${main.jar.file}" />
  </target>

</project>

Z punktu widzenia Hudson‘a i konfiguracji, której musimy dokonać istotne będą jedynie wymienione poniżej elementy:

• położenie pliku validator.jar będącego efektem końcowym procesu budowania, który chcemy udostępnić jako artefakt
• położenie pliku XML zawierającego wyniki wykonania testów jednostkowych
• położenie pliku XML zawierającego informacje na temat pokrycia kodu testami jednostkowymi

Tworzenie nowego zadania Hudson‘a

Powoli zbliżamy się do meritum. Mając już gotowy projekt wraz z działającym skryptem budującym nie pozostało nam już wiele do zrobienia, by objąć go procesem ciągłej integracji. Właściwie dzieli nas od finału już tylko jeden krok, którym będzie utworzenie nowego zadania w Hudson‘ie.

Dokonanie tego nie będzie na szczęście niczym skomplikowanym:

1. z głównego panelu sterowania Hudson wybieramy opcję New Job
2. określamy nazwę dla tworzonego zadania
3. wybieramy free-style jako rodzaj projektu i przechodzimy do następnego ekranu, gdzie wpiszemy pozostałe szczegóły
4. wybieramy system kontroli wersji z którego będzie korzystał Hudson (w naszym przypadku będzie to Subversion)
5. jako warunek wywołania procesu integracji (Build Triggers) wybieramy cykliczne odpytywanie repozytorium (Poll SCM)
6. w harmonogramie wpisujemy łańcuch znaków zgodny z formatem crond (np. */2 * * * * – odpytywanie co 2 minuty)
7. następnie definiujemy, co właściwie będzie oznaczać dla Hudson‘a zbudowanie aplikacji – w naszym przypadku chcemy, aby było to wywołanie przy pomocy Ant‘a domyślnego celu zdefiniowanego w skrypcie budowania (zaznaczamy Invoke Ant)
8. przyszedł czas na określenie czynności, które zostaną wykonane po zakończeniu budowania aplikacji – zgodnie z wcześniejszymi ustaleniami będzie interesowało nas:
   1. zachowanie artefaktów (validator.jar) z procesu budowania (Archive the artifacts)
   2. opublikowanie wyników testów jednostkowych (Publish JUnit test result report)
   3. opublikowanie wyników pokrycia kodu testami (Record Emma coverage report)
   4. opublikowanie wyników sprawdzenia jakości kodu przy użyciu checkstyle‘a (Report violations)
   5. wysłanie informacji o integracji, która się nie powiodła (E-mail Notification)

Tym razem to już naprawdę wszystko! Po zatwierdzeniu konfiguracji (jeżeli wszystko zrobiłeś dobrze ;)), to możesz się już cieszyć działającym procesem ciągłej integracji.

Od tej pory możesz zacząć regularną pracę zapominając zupełnie o istnieniu Hudson‘a i sięgać do niego jedynie wtedy kiedy uznasz to za przydatne. A sytuacji takich może być co najmniej kilka:

• chęć uzyskania zbudowanej wersji aplikacji z konkretnego build‘a
• analiza zmienności w czasie różnych parametrów opisujących aplikację w celu określenia trendów (np. procentowe pokrycie testami kodu źródłowego)
• zatwierdzenie zmian w repozytorium, które spowodują niebudowanie się aplikacji spowoduje wysłanie maila na wskazany adres

Podsumowanie

Rozważany przez nas przykład był raczej przykładem trywialnym. Z tego też powodu może się wydawać, że Hudson nie pełni w nim znaczącej roli. Muszę się zgodzić z tą opinią – czym jednak system staje się większy i bardziej skomplikowany, tym ACI staje się bardziej niezbędny.

Miałem przyjemność pracować nad ogromnym systemem z wieloma podprojektami (repozytorium wielkości około 3GB), gdzie Hudson stanowił bardzo ważne ogniwo w procesie wytwarzania. Wydaje się więc, że jeżeli był w stanie poradzić sobie w takich warunkach, to dla większości standardowych zastosowań powinien być odpowiedni. Osobiście używam Hudson‘a, gdyż pozostając bardzo intuicyjny oraz łatwy w konfiguracji dostarcza możliwości na zupełnie wystarczającym dla mnie poziomie zaawansowania.

Mam nadzieję, że mimo ograniczonych środków przekazu udało mi się przekonać Cię do wypróbowania Hudson‘a na własnej skórze. Świadom jestem niestety, że artykuł ten to zaledwie czubek góry lodowej zarówno jeżeli chodzi o CI, jak i o samegoHudson‘a.

Bibliografia

1. http://en.wikipedia.org/wiki/Continuous_Integration
2. http://www.extremeprogramming.org/
3. http://hudson.gotdns.com/wiki/display/HUDSON/Home
4. http://martinfowler.com/

Jestem pod dużym wrażeniem. Gratuluje pomysłu i realizacji !