"Po kilku nowych doświadczeniach ... "

Słowa kluczowe: XP, eXtreme Programming, SQL, persistence, fault tolerance, informatyka, AOP, JBossAOP, AOP libraries

Tak sobie pomyślałem, że może trochę za ostry byłem ostatnio. Niby SQL do kosza, ale jednak psiocząc na niego, psioczę również na Was - ludzi, którzy czasem zostają zmuszeni do jego używania (no i na siebie, bo w pracy muszę implementować na potrzeby firmy archaicznymi metodami, warstwę danych z użyciem SQL, twu :/ )
Jeśli jesteście zmuszeni: przez złego szefa, kolegów z pracy, dostaliście nową pracę i nie wolno nic złego powiedzieć, jesteście, jesteśmy w tym dziwnym świecie i czasem może niektórym lepiej jest po prostu "popłynąć" z wirem rzeki.. wtedy może i możnaby wybaczyć takie podejście do "persistence".

No dobra, ale czas na nowinki! :)

Pierwsze: tu nie chodzi o SQL lub coś innego. Postarajmy się sobie wyobrazić po co to wszystko? Po co cała ta informatyka? Pomijając aspekty formalne i naukowe, zostaje nam rzeczywistość. A rzeczywistość jest taka, że mamy prawdziwego człowieka, który najczęściej miał pomysł jak rozkręcić interes i potrzebuje zinformatyzować własne procedury tzw. biznesowe. Potrzebuje tego, bo z komputerem będzie łatwiej zobaczyć statystyki, prowadzić konta użytkowników, wykonywać internetowe płatności, wykorzystać system w celu ogólnodostępności systemu informatycznego z różnych fizycznie lokalizacji. To są bardzo ważne cele, które my jako informatycy musimy spełnić naszemu klientowi.
(druga rzeczywistość trochę bardziej skomplikowana to taka, że zastajemy już gotowy system, który nie spełnia wymagań klienta, oraz najczęściej z tego powodu sfrustrowanego klienta. W takim przypadku jednak konsekwencja, spokój, refactoring, testy i IMHO dotrzemy do portu)

Jaki jest więc nasz cel w tym momencie. Pierwsza i fundamentalna sprawa, to zrozumieć czego potrzebuje nasz klient. Nie damy rady tego zrobić bez dyskusji z klientem, bez dziesiątek historyjek użytkownika, bez kontaktu z nim.
Jeśli zrealizujemy ten pierwszy postulat, połowa sukcesu jest za nami. Co dalej? A dalej to już nasze informatyczne procedury. Dalej musimy przedstawić produkt informatyczny, który:

• realizuje wszystkie biznesowe potrzeby klienta, poprzez implementacje tzw. logiki biznesowej - core system
• udostępnia mechanizmy do obsługi i dostępu do takiego systemu - poprzez tzw. GUI.
• jest odporny na awarie, coś co nazwiemy tutaj fault tolerance

Popatrzmy teraz na każdą z tych części produktu informatycznego z osobna z perpektywy mojego doświadczenia.

Core logic

Ta część jest zdecydowanie najciekawsza i wcale nie najprostsza. Ale celem mym i osób mi bliskich jest zaimplementowanie takiego świata obiektowego, aby był zrozumiały dla czytelnieka (tak! czytelnika, nasz kod służy przecież do czytania, "piszemy go tylko raz"). Jeśli będzie prosty i zrozumiały, to łatwo go rozszerzymy, łatwiej znajdziemy dotkliwy błąd, łatwo zmienimy. Tego nie trzeba udowadniać. Jest to jedna z nielicznych rzeczy, które od dziś kategoryzuje w kategorii: obvious.
Bardzo dobrze by było, abyśmy także nie mieli żadnych ograniczeń w konstrukcji świata obiektowego. Myślę tu o strukturze "grafu" naszych obiektów: dowolne cykliczne referencje w grafie, dowolne struktury posiadające inny struktury (kolekcje), itp itd.. plus jeden główny korzeń całego grafu.

Core logic, znaczy także całkowicie czysty (plain) kod. Żadnego zapamiętywania danych, żadnej obsługi zdalnych wywołań lub czegokolwiek innego. Powiedzielibyśmy, że jest to program, który po uruchomieniu może "cośtam" zrobić, ale po zakończeniu pracy nic nie pozostaje. To takie programy, które pisaliśmy na pierwszym roku studiów.. (po "bazy danych" proszę czytać dalej)

A jak sobie poradziłem w życiu z przyjaciółmi w realizacji prostoty świata obiektowego. Najpierw dzięki uprzejmości Andrzeja dostaliśmy do ręki obiektową "in-memory" bazę danych. Skorzystaliśmy. Otrzymaliśmy główny kod, w miarę "czysty", co znaczy, że odwołania do warstwy danych nie były widoczne, ponieważ były ściśle zintegrowane z naszym światem

Jak sobie poradzimy na przyszłość? Identycznie. Zamiast Prevaylera użyjemy jednak PATa :)

Gui

W praktyce zostają nam do wyboru: standalone application, tzw. aplikacja okienkowa (dwie możliwości: pracująca zdalnie, lub całkowicie lokalna dystrybucja) lub web application, czyli dostęp poprzez przeglądarkę.

Web application - o ile ulubiona, to nie pozbawiona wad, m.in. skąpa ilość możliwych komponentów okienkowych w porównaniu z aplikacją okienkową, ale za to dająca "zdalny dostęp do aplikacji" stosunkowo za darmo

Pytanie, któro sobie stawiam, to czy GUI jako aspekt (concern, zagadnienie), da się zautomatyzować? Persistence już zrobiłem z PAT, ale co z GUI. Strzeżcie się, bo jest to w moich planach! ;)
Myślę o czymś takim jak NakedObjects, lub podobne.

Fault tolerance

Ta część jest ciekawa. Nic jeszcze nie mówiliśmy o żadnej bazie danych. Może nawet nie będzie takiej potrzeby. Proszę zauważyć, że wymieniłem jedynie trzy części produktu informatycznego: core logic, GUI, fault tolerance. Nic więcej. Core logic, to w zasadzie, na pierwszy rzut oka, bezwartościowy program, jako, że nie zapamiętuje swojego stanu. Nawet jeśli uda nam się dorobić interfejs użytkownika, to nic po takim programie, bo po "zamknięciu" nawet pyłek po nim nie zostanie.

Fault tolerance: tolerancja na błędy. Tłumaczę sobie to w taki sposób. "Nie zachowanie stanu aplikacji", to swego rodzaju błąd. Jak poradzić sobie z takim błędem? Wymienię kilka poziomów "tolerancji" na błędy:

Zapamiętanie stanu na żądanie

W momencie uruchomienia aplikacji wczytaj wszystkie dane (nie mówię skąd), a w momencie zakończenia aplikacji, lub komendy "Zapisz stan" zapisz stan aplikacji

Zapis każdej zmiany stanu aplikacji

To jest najpopularniejsza metoda na persistence. W momencie zmianu stanu aplikacji, np. poprzez złożenie nowego zamówienia w sklepie internetowym, wywołaj odpowiedni auaktualnienie bazy danych. W momencie potrzeby odczytu danych, odczytaj je z bazy danych.

Memory replication

A co jeśli zreplikujemy pamięć operacyjną i ktoś nam dostarczy przezroczysty dostęp do niej? Replikacja oznaczałaby, że nawet jeśli jakiś sposób nastąpi awaria komputera, na którym uruchomiona jest aplikacja, to aplikacja nadal będzie działała, dopóki będzie uruchomiony co najmniej jeden komputer.

Jest to całkiem dziwaczne i najbardziej niestandardowe podejście do persistence, a nawet do fault tolerance jakie mogę sobie wyobrazić, ale to zadziała. Zero obsługi zapisu danych. Po prostu nasza pierwszoroczna aplikacja działa sobie w nieskończoność.

(trzeba będzie jednak wprowadzić jakąś możliwość zapisu danych w trybie "zapisz wszystko"/"odczytaj wszystko", bo potrzebujemy uaktualniać działający program)

Tak czy inaczej, mam nadzieję, że persistence wyjdzie mi jako praca magisterska.. :)

PAT: Co to jest i po co? Więc po czasie używania oprogramowania Prevayler, nadszedł czas na zaimplementowanie w nim transakcji, co wymagałoby strasznie dużo roboty, zburzenia struktury świata obiektowego i obsługi dodatkowego kodu, czego nikt nie lubi. Powstało więc narzędzie, któro dostarcza niewidocznej warstwy danych, do core logic. To o czym marzyłem, to jak sobie wyobrażałem prosty kod stało się rzeczywistością. Proszę popatrzeć na kod przykładowej aplikacji napisanej z użyciem PAT. Czyś nie jest to ładne? :)

Z tego co wiem, PAT jest pierwszym na rynku, darmowym frameworkiem dostarczającym przezroczystą obsługę warstwy danych. Nazywam to póki co: AOP annotated library. Co z tego wyjdzie? Zobaczymy co czas przyniesie..

Miłym akcentem pozdrawiam,
Tomasz N.

September 27th, 2004