poczta: biuro@apilia.pl

Framework

Na framework webowy wybraliśmy Wicketa. Lekki komponentowy framework wyróżniający się z olbrzymiej gamy frameworków przede wszystkim jedną cechą – stanowością. Aplikacja Wicketowa składa się z drzewa komponenetów, które odpowiadają na akcje jakimi są żądania sieciowe. W uproszczeniu można porównać Wicketa do javowego Swinga – mamy tutaj komponent strony, do którego dodajemy inne komponenty itd. Dzięki temu Wicket oferuje reużywalność kodu. Dużą zaletą Wicketa jest to, że korzysta on z XHTMLowych szablonów, dzięki czemu mogliśmy w dużym stopniu rozdzielić prace na programistyczne i designerskie – zespół zajmujący się wyglądem portalu mógł w prosty sposób dokonywać zmian w wyglądzie stron nie zagłębiając się w kwestie implementacyjne.

Po około dwóch latach prac nad portalem wybór Wicketa uznaliśmy za bardzo trafiony. Łatwość tworzenia własnych komponentów pozwoliła nam napisać wiele elementów, które wykorzystywane są w całym portalu. Pozwoliło to na oszczędzenie czasu, a powstałym kodem bardzo łatwo się zarządza. Dodatkowo Wicket wspiera wiele funkcjonalności, na których nam zależało. W aplilacji można bez dodatkowego nakładu pracy poruszać się używając przeglądarkowych przycisków “wstecz” i “dalej”. W pełni zintegrowana z Wicketem implementacja AJAXa umożliwiła łatwe zaimplementowanie skomplikowanej walidacji AJAXowej oraz pozwoliła usprawnić wiele kluczowych elementów systemu, jak np. stronicowanie, odsługę dynamicznych formularzy czy asynchroniczne wywoływanie usług.

Wbrew obawom Wicket jest bardzo wydajnym frameworkiem i oferuje narzędzia wspomagające optymalizację. Jedynym mocno obciążającym system elementem jest page mapa – wicket serializuje całe strony i zapisuje je z wybraną strategią. Na szczęście istnieje wiele rozwiązań pomagających zoptymalizować ten element aplikacji.

Wydajność

W systemach bankowych, gdzie jednocześnie na portal bankowy logują się duże liczby użytkowników, często z systemu pobierane są wielokrotnie te same dane. Aby poradzić sobie z tym problemem wprowadziliśmy mechanizm cacheowania. Użyliśmy do tego aspektów javowych oraz anotacji by dodać tą funkcjonalność nie zmieniając jednocześnieistniejącej warstwy dostępu do usług. Jako bibliotekę do przechowywania danych wybraliśmy JBoss cache’a, który pozwala na hierarchiczne zapamiętywanie informacji. Pozwoliło to nam w prosty sposób podzielić, które informacje mają być cachowane dla całej aplikacji, a które dla poszczególnych użytkowników. Anotując czas życia i scope cache’a (per użytkownik czy per aplikacja) możemy dowolnie regulować zachowanie danych przechowywanych w pamięci.

Często chcemy przechować w cache’u dane tylko do momentu wystąpienia ściśle określonej akcji. Za pomocą prostej anotacji możemy określić, że dana usługa może wpłynąć na dane zawarte w cache’u więc wówczas czyścimy odpowiednie wpisy. W prosty sposób ograniczyło to nadmiarowe wywołania usług. Ważne, aby przy implementacji takiego mechanizmu logować hit ratio – może się bowiem okazać, że niektóre usługi niepotrzebnie cache’ujemy, co skutkuje zbędnym zużyciem pamięci nie dając nam nic w zamian.

Bezpieczeństwo

W systemach bankowych bezpieczeństwo jest wyjątkowo krytyczne. Wyjątkowo ważne jest też, aby użytkownik zdawał sobie sprawę z tego, że jego pieniądze i dane finansowe sa bezpieczne. Dlatego projektując portal należy zadbać o to, aby był odporny na takie ataki jak session fixaction (czyli ustawianie SID przez innego użytkownika co pozwala na “kradzież” sesji) czy cross site scripting. Należy też zadbać o bezpieczeństwo wewnętrzne wysyłanych danych, dlatego np. PIN użytkownika jest szyfrowany jeszcze po stronie klienta.

Często użytkownicy mniej zaawansowani technicznie padają ofiarą oszustów skutkiem naiwności i braku przestrzegania elementarnych praktyk. Wystarczyłoby, żeby każdy użytkownik sprawdził przed podaniem wrażliwych danych certyfikat strony na którą trafił. Niełatwo jednak nauczyć tego wszystkich użytkowników. Dlatego wprowadziliśmy dodatkowe zabezpieczenie przemawiające bardziej do szarego użytkownika – obrazek na stronie logowania. Po podaniu swojego loginu użytkownik trafia na stronę, na której powinien podać hasło. Na tej stronie prezentowany jest obrazek, który użytkownik może wybrać po zalogowaniu się do serwisu. Jest to proste, ale wizualnie bardzo proste do spostrzeżenia.

Oczywiście nie zastąpi to w żadnym stopniu certyfikatu strony, ale jest dodatkowym elementem utrudniającym dokonywanie fraudów na mniej świadomych użytkownikach. Jest to tylko jeden przykład małej funkcjonalności spośród wielu które zostały zaimplementowane podczas prac nad serwisem. Więcej na ten temat będzie można przeczytać w przyszłości.

Jako Apilia istniejemy od dwóch lat, ale historia firmy sięga dalej.  Założyciele spółki poznali się na studiach i już wtedy podjęli decyzję o wspólnym starcie w branży informatycznej. Ze względu na łatwość założenia i prowadzenia przedsiębiorstwa pod szyldem działalności gospodarczej zdecydowali się na taką formę współpracy. Po kilku latach pracy jako formalnie osobne podmioty nadszedł czas na połączenie się pod jedną marką.

Chociaż formalnie Apilia to osobne przedsiębiorstwo to stoją za nią ciągle Ci sami ludzie. Dlatego też w zakładce referencje odnajdą Państwo również nasze referencje sprzed założenia spółki.