Mam raczej wykaz zastrzeżeń do każdej z alternatyw.
(Vaadin - prawie OK
Smart-GWT - odpada
Ext GWT - może być jako uzupełnienie czystego GWT aczkolwiek szkoda pieniędzy na licencje developerskie, czyste GWT - w tym kierunku chyba pójdę).

Moje preferencje różnią się cokolwiek od potrzeb USOSa. Potrzebuję czegoś, na czym mogą pracować równocześnie dziesiątki tysięcy użytkowników przy znaczących ograniczeniach na przepustowość sieci, moc i ilość serwerów J2EE. Vaadin niestety wydaje mi się będzie ograniczał użytkowników ze słabymi połączeniami internetowymi i będzie obciążał mi serwery. Poza tym ma jedną wadę, która podobno będzie usunięta dopiero w 4 kwartale 2012. Nie jestem jednak przekonany, że uda się im to zrobić całkowicie i do końca. Chodzi o problem synchronizacji stanu Interfejsu użytkownika i modelu tego stanu na serwerze. Może być tak, że użytkownik widzi stany przejściowe pomiędzy poszczególnymi etapami wyświetlania kontrolek. To w przypadku wolnych łączy (i czasami szybkich też) może prowadzić do prezentacji użytkownikowi ekranu w niespójnym stanie. Vaadin chce z tym zawalczyć poprzez mechanizm podobny do transakcji. dev.vaadin.com/wiki/Vaadin7/Features/SharedStateAndRPC. Gdyby tej jednej Vady :-) Vaadin nie miał to wydawałby mi się idealnym rozwiązaniem dla USOSa. No i przy słabej przepustowości częstym zjawiskiem będzie opóźniona reakcja UI na działania użytkownika co może prowadzić do ponawiania przez użytkownika działań, które już są w toku. Ach ta asynchroniczność!

To ja coś odpowiem - to wszystko co Pan napisał jest prawdą, do aplikacji dla dziesiątek tysięcy użytkowników Vaadin zapewne się nie nadaje. Trzyma wszystko po stronie serwera, byle kliknięcie guzika lub przesortowanie tabelki generuje komunikację klient-serwer. Tylko że w przypadku USOS to nie jest żaden problem, bo ile USOS ma max klientów? Na UW więcej niż 500? Nie sądzę, ale może czasem. Z taką ilością userów poradzi sobie prosty serwer. Gdzie jest używany USOS? W 99,9% na komputerach w dziekanatach, gdzie jest dobre łącze do serwera i nie będzie zauważalnego laga. Ja nie jestem zwolennikiem Vaddina, ponieważ:
1) kiepsko się integruje ze Springiem
2) brak mu dobrego (bo jakiś tam jest, ale kiepski) graficznego edytora GUI lub chociaż bindera do XML (czegoś w stylu MS-owego XAML-a). Bez tego obawiam się powstawania kodu w stylu "spaghetti", gdzie logika aplikacji będzie pomieszana z kodem kontrolującym layout.

Moim zdaniem Vaadin nadaje się i do aplikacji z większą ilością użytkowników. Wszystko zależy od charakteru tej aplikacji. Moja kontroluje każde naciśnięcie klawisza na TextBoxie i polega głównie na masowym wprowadzaniu danych więc tu Vaadin radzi sobie kiepsko. Zgadzam się z tym, że USOSa to ograniczenie nie dotyczy. Jak chodzi o integrację ze Springiem to chyba nie ma takiej konieczności. W Vaadinie jest takie coś jak SQLContainer. Wydaje mi się, że jest to rozwiązanie bliskie pojęciowo dla programistów Oracle Forms. Dobrze jest, gdy framework sam narzuca rozdzielenie logiki i prezentacji i tu prawdopodobnie jest jakiś problem. Nie używałem Vaadina, jednak zrobił na mnie dobre wrażenie. Opieram się co prawda na pobieżnym zapoznaniu. Wydaje mi się, że nie nadaje się do moich celów. Natomiast jest moim zdaniem poważnym kandydatem do napisania w nim USOSa. Wszystkie te frameworki nie dają prostego rozwiązania problemów z asynchroniczną ich naturą. Pewnie trzeba coś tam dopisać.

W kwestii Springa - chodzi mi o wstrzeliwanie zależności (dependency injection), a nie spring-jdbc. Coś takiego + fajny framework webowy z separacją logika/layout byłby fajnym rozwiązaniem. Vaadin dobrze się integruje z innym frameworkiem do DI, czyli Guice. Ale tego nie znam, więc ciężko mi coś powiedzieć. A w kwestii komunikacji z bazą danych, to pewnie chcielibyśmy JPA, do którego w Vaadinie jest JPAContainer. Taka kombinacja bardzo ułatwia obsługę wszelkich CRUD-ów, minimalizuje pisanie zapytań i obsługę update/delete.

Muszę zadbać o to aby wredni użytkownicy nie mogli wejść poprzez manipulacje na kliencie na encje, do których nie mają uprawnień. To zdaje się w przypadku Vaadina jest załatwione "out-of-the-box". A jak jest w innych persistence frameworks? W przypadku USOSa to chyba nie będzie problem, a w moim jest istotny. Muszę takie próby włamań odrzucać i rejestrować.

Nie wiem jak to zrobić na poziomie encji, prędzej definiuje się zasady dostepu na poziomie interfejsów. Do tego są gotowe frameworki, np. spring-security albo Shiro. Załatwiają autoryzację, autentykację w aplikacji i dosyć szczegółową kontrolę dostępu - np. w przypadku spring-security można zaadnotować metody danego interfejsu, a w adnotacji wpisać wyrażenie odnoszące się do roli, albo oczekiwanych parametrów metody. Jeśli użytkownik coś psuje, to regułka w adnotacji "załapie", wywołanie metody skończy się wyjątkiem, który można zalogować.

public interface BankService {

    @Secured("IS_AUTHENTICATED_ADMIN")
    public Account readAccount(Long id);

    @Secured("IS_AUTHENTICATED_ADMIN")
    public Account[] findAccounts();

    @Secured("ROLE_TELLER")
    public Account post(Account account, double amount);
  }

tak, ale to nie załatwia włamań na poziomie encji. To znaczy nie zabezpiecza przed podmianą id'ów. Chyba zrobię to szyfrowaniem lub hashowaniem. Id wysłany na klienta będzie opatrzony hashem na poziomie sesji.

Nie bardzo rozumiem, jak użytkownik miałby uzyskać dostęp do encji?

Ano użytkownik może sobie podmienić na kliencie id encji (bo gdzieś on siedzi na kliencie ). Może sobie właczyć Firebuga, puścić jakiś skrypt, podedytoweać HTML albo coś takiego i wtedy bieda! ORM weźmie tego id'a i zupdateuje , usunie lub sobie odświeży wiersz.

Skoro tak zrobił, to znaczy, że tak chciał a skoro chciał i miał uprawnienia, to znaczy, że powinno to tak zadziałać.

Ja myślę, że to chodzi o taki przypadek, że przykładowo Pan przekazuje identyfikator osoby, który później w drodze powrotnej jest wykorzystywany do zrobienia update na bazie. I jeśli jakiś zły człowiek sobie w firebugu dłubnie ten idek, to źle napisana aplikacja się nie zorientuje i pozwoli uaktualnić inną osobę. Ale na taką sytuacje spring-security również się nada - trzeba wpisać w adnotacji kontrolę, czy dana osoba ma prawo do uaktualnienia obiektu o idku X. To łatwo sprawdzić, bo w sesji po stronie serwera są nienaruszone dane, ew. mozna dopisać z boku klasę która wykona sprawdzenie i potem ją wykorzystać w zapisanym w adnotacji wyrażeniu.

O to właśnie chodzi, Pani w dziekanacie tego nie zrobi ale "klient", który jest kretem zatrudnionym przez konkurencję bardzo chętnie, bo mu za to płacą i to niemało bo mają czym płacić.

Na przykład można zrobić tak: Jeśli numery idów są kolejne to przejechać się od 1 do n i usunąć wszystkie wiersze z tablicy lub wpisać obraźliwy tekst pod adresem prezydenta Burundi w polu opis.

Nie rozumiem powodów szybkiego odrzucenia Smart-GWT i Ext GWT. Koszt Ext GWT dla zespołu 5 osobowego to 1555$ a pewnie tyle na początek wystarczy. Jeśli komponenty Ext GWT spełniają oczekiwania, to czemu nie zapłacić ich twórcom za możliwość ich używania? Można również rozwijać USOS w modelu OpenSource i dla produktów na licencji GPL lub innej akceptowalnej przez twórców Ext GWT jest za darmo. Jest wiele innych aplikacji dystrybuowanych w taki sam sposób - jira, jprofiler, jrebel - może to jest powód za przemyśleniem, czy USOS nie powinien być open source. Żadna uczelnia bez supportu i tak nie wdroży USOS, a niektóre chętnie zapłacą za rozwój konkretnej funkcjonalności a licencje na potrzebne oprogramowanie będą za darmo.

Jedyne czego brakuje GWT to zestaw dobrych kontrolek przydatnych w projektach biznesowych - rozwiązaniem zdaje się być właśnie Ext GWT i Smart-GWT. Moim zdaniem nie trzeba decyzji podejmować w oparciu o to, czy coś jest za darmo, czy nie - tylko czy warto tego używać, czy nie a później zastanawiać się, czy warto zapłacić. Czas pracy jednego programisty przez miesiąc, czy dwa jest wart więcej, niż licencja za produkt. Jeśli czas wytworzenia komponentów, które są w Ext-GWT a są potrzebne w USOS przekroczy ten czas, to znaczy, że warto kupować. Jeśli koszt rozbijemy na 10 lat, bo takiej długości jest cykl życia USOSa, to licencja kosztuje 2,5$/osobo-miesiąc.

Nie wiem jak sprawa wygląda na innych uniwersytetach, ale u nas praktycznie wszędzie sieć jest dystrybuowana za pomocą wysokiej przepustowości szkieletu i rozprowadzana lokalnie za pomocą urządzeń dostępowych o przepustowości 100Mbit co nie jest zauważalne przez użytkownika jako dodatkowe opóźnienie. Są narzędzia do pomiaru czasu odpowiedzi i powodów dla których ten czas jest właśnie taki - z moich obserwacji wynika, że nasze aplikacje najwięcej czasu poświęcają na komunikację z bazą danych a przetwarzanie i transfer danych są zaniedbywalne.

Moim zdaniem głównym powodem dla którego USOS odnosi sukcesy nie jest technologia, tylko dobra analiza i znajomość domeny. Większość trudności podczas wdrożeń modułów USOS wcale nie jest związana z zastosowaną technologią, tylko z czymś zupełnie innym (jako przykład podam innowacyjny technologicznie i bardzo estetycznie wykonany SRS). Jeśli architektura pozwoli wymienić dowolnie mały komponent to nawet jeśli wybierzemy źle, to koszt naprawy będzie akceptowalny. Jestem zdania, że to, że decyzja o zmianie jeszcze nie zapadła jest większym błędem, niż wybranie nie do końca optymalnej technologii.

Jeśli zastosujemy popularny stos technologiczny, to łatwo będzie znaleźć specjalistów, uzyskać pomoc w sieci, dobrać narzędzia, znaleźć porady dotyczące integracji z innymi produktami. GWT + CXF(REST) + Spring + JPA + Hibernate + Oracle to bardzo popularny stos i można śmiało powiedzieć, że nie jest on nadmiernie skomplikowany. Gdybym jednak musiał go upraszczać dalej, to bym zrezygnował z GWT na rzecz czystego JavaScript + jakiś framework typu jQuery, czy YUI.

Bardzo podoba mi się architektura rozwiązań takich jak Eclipse, czy NetBeans - duży produkt jako złożenie małych modułów. Nikt chyba nie zna i nie rozumie wszystkich części, ale jeśli jakaś działa źle, to łatwo ją wymienić na inną - działającą lepiej, wyglądającą bardziej atrakcyjnie i współpracującą na takich samych zasadach jak poprzednia.

Nikt przecież jeszcze niczego nie odrzuca. Wybór Ext GwT nie wyklucza zastosowania czystego GWT. Natomiast Vaadin i SmartGWT mają tą cechę, że się nie dadzą pogodzić z kontrolkami GWT. Ext GWT przechodzi gruntowną renowację. Wersja 2.2 ma kilka niezgodności z obecnym stanem GWT. Koszt Ext GWT nie jest istotnie powalający. Stosujemy jednak taką praktykę, że kupujemy zawsze produkt z supportem. Patch'owane wersje Ext-GWT można dostać tylko z licencją płatną. Nie wiem ile kosztuje support roczny, czy aby przypadkiem nie blisko ceny licencji?

Co najbardziej mnie zastanawia w tych Ajaxowych technologiach jest problem z synchronizacją, który autorzy frameworków na początku ignorują, który jednak po latach się czka np: /turbomanage.wordpress.com/2010/07/16/dispatchqueue/, dev.vaadin.com/wiki/Vaadin7/Features/SharedStateAndRPC. Jak chodzi o technologie czysto Javascriptowe no to miałbym jednak troszkę obaw bo lubię jednak jak mój kod sprawdzi kompilator.

Z kolei gdyby nie było ograniczeń finansowych oraz (tym bardziej) zapowiadanego przez Oracle końca supportu dla Oracle Forms w ogóle to zostałbym przy tej technologii w wersji Forms11. Tylko być może wziąłbym ją troszkę zmodernizował, bo Formsy zrobiły się bardziej zintegrowane z przeglądarkami. Ostatecznie w USA największe systemy bankowe chodzą na hierarchicznej bazie IMS. Nikt tego nie zmienia z powodu tego, że IMS jest "przestarzały". Lepiej mieć "przestarzały" niż niedopracowany.

©Janina Mincer-Daszkiewicz