Dziś na wydziale MiMUW odbyła się konferencja „USOS w Javie”. Wziąłem w niej udział z dwóch powodów. Po pierwsze jako, że zmieniam pracę to muszę jakoś opędzić urlop. Po drugie byłem ciekawy co spece od USOS chcą osiągnąć i jakie mają pomysły.

Poglądowo

W spotkaniu chodziło o przedstawienie osobom odpowiedzialnym za USOS pewnego stosu technologicznego, na którym należało by oprzeć nowy moduł systemu.

Czym jest USOS?

USOS jest to mówiąc w dużym skrócie mieszanka ERPW i CRMW oraz narzędzi specyficznych dla zarządzania uczelnią. Składa się on z kilku modułów. Na konferencji skupiliśmy się na trzech z nich USOS, USOS-web i USOS-UL.
Pierwszy to „USOS właściwy”, czyli baza danych wraz z interfejsem biznesowym do zarządzania uczelnią. Całość postawiona na Oracle + Oracle Forms. Duże to jak cholera (ponad 300 formularzy) i coraz trudniejsze w utrzymaniu.
Drugi to interfejs web, przez który studenci mogą sobie zobaczyć np. plan zajęć czy pobrać materiały. Tu króluje php i mysql. Z głównym systemem integracja polega na cyklicznej synchronizacji baz danych. Oznacza to, że USOS-web może nie mieć aktualnych danych. Podobnie danych może nie mieć USOS główny.
Trzeci element to moduł na który klną wszyscy studenci. Jest on odpowiedzialny za rejestrację na lektoraty i WF. Dwa razy do roku mamy tu DDoS

Pomysły

Generalnie idea jest taka by napisać wszystko z wykorzystaniem Springa i jego modułów do biznesu, a GWT/Vaadin/JS jako warstwy widoku. W ogólnym ujęciu serwer aplikacji wystawiał by zestaw usług opartych o REST oraz pozwalał na ich uruchamianie via aplikacja web.
W toku dyskusji został podniesiony problem aplikacja web kontra aplikacja desktopowa. Jednak Jacek Laskowski elegancko spacyfikował towarzystwo stwierdzając, że każda aplikacja oparta o wołanie usług po http to aplikacja web. Zgadzam się z nim w pełni, a jedyne co można tu dodać to rozróżnienie na klienta www i klienta desktopowego.

Debata

Generalnie przyszło nam zmierzyć się z dość trudnym tematem… interfejsu użyszkodnika. Większość czasu poświęciliśmy na próby odpowiedzenia czy UI ma być w GWT czy w Vaadin. Moim zdaniem była to ciekawa, ale nie wnosząca nic do tematu pogawędka. Niepokoi mnie to, że praktycznie nie poruszono tematów związanych z backendem. Przyjęto, że używamy Springa i koniec. Wtrącenie na temat EJB zostało ucięte już na samym początku. Szkoda.

Moja propozycja

Podsumowując całość mam taką propozycję.

Po pierwsze skupić się na napisaniu dobrego backendu. Wykorzystać do tego Springa i to nie ze względu na kontener IoC, ale ze względu na dużą ilość modułów pozwalających na integrację z potrzebnymi nam technologiami. Beany springowe powinny być dostępne tylko i wyłącznie jako usługi oparte o REST. Całość należy wdrożyć na TomEE, czyli specjalnej wersji Tomcata, która jest zgodna z webprofilem JEE6. Dlaczego tak? Ponieważ z jednej strony mamy lekkiego Tomcata, który w zupełności wystarczy do uruchomienia aplikacji w Springu. Ma on też możliwość clustrowania, a że całość będzie bezstanowym wołaniem usług to można będzie w razie konieczności zestawić cluster dynamicznie dostosowujący swoją wielkość do obciążenia. Z drugiej strony TomEE posiada wszystko co powinien mieć typowy serwer aplikacji zatem jeżeli będziemy chcieli uruchomić na nim jakieś usługi EE to też nie będzie problemu. Tu ważna rzeczy. Obecnie trwają już prace nad przejściem z Oracle Reports na BIRT.
Jak wspomniałem Springa wybieramy ze względu na moduły. Kontener IoC jest tu drugorzędnym problemem i jeżeli miałbym się kierować tylko i wyłącznie nim jako kryterium wyboru to bym wybrał Guice. Jest prostsze. Tu interesują nas moduły

  • Security – wiadomo
  • CXF integration- czyli obsługa webservice po REST z wykorzystaniem Apache CXF.
  • batch – narzędzia do przetwarzania wsadowego.
  • Dynamic modules – jako platformę OSGi

Co dalej… Jacek rzucił pięknym tekstem:

Aplikacja webowa jako referencyjna implementacja klienta REST

Zgodnie z tym podejściem inny zespół powinien otrzymać API aplikacji USOS i rozpocząć deweloperkę klienta web opartego o wołanie usług. Aplikacja web oraz główna aplikacja powinny zostać całkowicie od siebie odseparowane. Ma to dwa duże plusy. Po pierwsze pozwala wyrzucić poza core-aplikację wszystko co związane z obsługą sesji HTTP. Dzięki temu upraszczamy znacząco implementację. Po drugie aplikacja ma spójny interfejs REST-only dzięki czemu deweloperzy nie muszą martwić się „czy ruszy na kliencie”. Po prostu wystawiają usługę z jasno zdefiniowanym interfejsem. Samą aplikację web napisałbym z zwykorzystaniem Vaadin ponieważ jest to proste i łatwe w użyciu narzędzie.

Na dokładkę dodałbym trochę dupereli typu zbudowanie środowiska deweloperskiego wykorzystującego serwer CI, raportowanie jakości kodu, jakieś automatyczne wyszukiwanie problemów. Zarówno statycznych (findbug) jak i dynamiczne (patrz praca Patrycji Wegrzynowicz). Pewno coś jeszcze by się znalazło.

Nie poruszam tu problemu bazy danych, ponieważ na chwilę obecną i tak system musi korzystać z już istniejącej bazy, a w przyszłości może wydarzyć się jeszcze wiele różnych rzeczy, które mogą wpłynąć na wybór w tym zakresie.