We wrześniu ubiegłego roku uruchomiłem nową inicjatywę w postaci bloga SpringDeveloper.pl. Chciałem stworzyć miejsce, gdzie będę mógł tłumaczyć podstawowe oraz zaawansowane zagadnienia związane właśnie ze Springiem. Przyczyną do takiego ruchu były prowadzone przeze mnie rekrutacje w obecnej firmie. Niestety wielu deweloperów, z którymi miałem przyjemność rozmawiać, nie znało fundamentalnych mechanizów rządzących tym frameworkiem. Zasmucony takim biegiem spraw postanowiłem coś z tym zrobić. Kupiłem więc domenę, napisałem 3 artykuły i uruchomiłem machinerię. Jednak nie działała ona zbyt długo. Z racji mnogości inicjatyw i prowadzenia dwóch blogów musiałem z jednego z nich zrezygnować. Wybór padł właśnie na SpringDeveloper.pl.

Leżał on nieruszany aż do teraz. Zdecydowałem, że przeniosę stamtąd artykuły na tego bloga. SpringDeveloper.pl po prostu zniknie. Ja natomiast będę miał jedno, centralne miejsce, gdzie będę zamieszczał posty z różnej tematyki, w tym również ze Springa. Także zapraszam Cię dalej do krótkiego przedstawienia czym w ogóle jest Spring.

Czym w ogóle jest Spring?

Najczęściej deweloperzy używają określenia Spring w celu określenia całej gamy dostępnych modułów w ramach tego projektu. Trzeba przyznać, że jest to dosyć trafne określenie. Tymczasem warto jednak pamiętać o podwalinie kryjącej się za tym wszystkim. A jest nią Spring Framework. To on jest rdzeniem całej idei stojącej za tym obszernym przedsięwzięciem.

Dla uproszczenia, Spring Framework należy rozgraniczyć na dwa moduły. Ich podział wynika z funkcjonalności jakie się za nimi kryją. Do pierwszego z nich zaliczamy: konfigurację modelu aplikacji, kontener zależności czy też mechanizm Dependency Injection. Drugi natomiast zawiera w sobie obsługę różnych rodzajów architektury aplikacji: messaging, transakcje, zapis do bazy danych czy żądania HTTP.

Krótka historia Springa

Kiedy w 2002 roku chodziłem do pierwszych klas podstawówki to w świecie IT główną platformą do tworzenia aplikacji w Javie była J2EE 1.3 połączona z technologią EJB 2.0. Nieszczęśliwie dla twórców okazało się, że to połączenie nie zostało dobrze przyjęte przez ówczesnych programistów. Zaczęli więc wyczekiwać czegoś mniej “problematycznego”. I tak nastał rok 2003. Trzech panów - Rod Johnson, Juergen Hoeller i Yann Caroff - stworzyło pierwszą wersję projektu Spring. Trafili ze swoim projektem w rynek idealnie. Już w 2005 roku osiągnął on zawrotną liczbę pobrań wynoszącą 400 tysięcy. Wszystko więc wskazywało na to, że Spring będzie istotnym graczem w świecie Javy. Czas pokazał, że faktycznie tak się stało.

Należy w tym miejscu mocno zaznaczyć, że Spring tak naprawdę jest raczej uzupełnieniem/nakładką dla Javy EE niż jej rywalem. Wynika to z faktu, że oparł się on na specyfikacji dostarczonej przez platformę od Sun Microsystems (obecnie Oracle). Tutaj przy okazji dam małe sprostowanie. Aktualnie nie ma już Java EE. Przemianowała się ona na Jakarta EE z powodów czysto biznesowych. Wpływ na to miała zmiana zarządcy specyfikacji Java EE z Oracle na Eclipse Foundation. Wracając od głównego wątku. Twórcy Spring podeszli do sprawy pragmatycznie i nie oparli się w 100% na zewnętrznej specyfikacji. Z ostrożnością wybrali tylko kilka jej elementów, z którymi się zintegrowali:

  • Servlet API (JSR 340)
  • WebSocket API (JSR 356)
  • Concurrency Utilities (JSR 236)
  • JSON Binding API (JSR 367)
  • Bean Validation (JSR 303)
  • JPA (JSR 338)
  • JMS (JSR 914)
  • JTA/JCA do koordynacji transakcji jeśli jest to konieczne

Spring Framework również wspiera Dependency Injection (JSR 330) oraz Common Annotations (JSR 250). Jednak w stosunku do tych dwóch elementów specyfikacji deweloperzy mają pełną swobodę wyboru. Mogą oprzeć się o Java EE/Jakarta EE albo użyć mechanizmów dostarczonych przez Springa.

Decyzje architektoniczne podjęte przez twórców Springa

Podczas nauki Springa warto zapoznać się z ideami jakie stały za jego powstaniem. Oto kilka najważniejszych z nich:

  • pozwolenie na wybór providerów na każdym etapie aplikacji – np. zmiana dostawcy bazy danych odbywa się poprzez zmianę konfiguracji, bez ingerencji w kod
  • brak wskazania jak dana rzecz powinna zostać wykonana – jedną czynność można wykonać na wiele sposobów
  • utrzymanie wstecznej kompatybilności – brak wielu przełomowych zmian na przestrzeni wersji
  • troska o API – tworzenie intuicyjnego API
  • wysokie wymagania co do jakości kodu – utrzymanie dokumentacji na wysokim poziomie, czysty kod oraz brak cyklicznych zależności

Podsumowanie

Ten artykuł dostarczył nam informacji na temat historii Springa oraz podjętych decyzji co do jego architektury. Nie chciałem Cię w nim zanudzić dużą ilością szczegółów. Jednak uważam, że ogólna wiedza o narzędziu, z którego się korzysta na co dzień, jest mile widziana, a czasem nawet niezbędna. W kolejnym wpisie dotyczącym tego frameworka zagłębimy się w pojęcie kontenera zależności, czyli uderzymy w samo serce Springa. Także do zobaczenia już niedługo!