Light? heavy?

Sporo już powiedziano o relacji pomiędzy Spring a EJB. Jedni twierdzili, że to konkurencyjne rozwiązania, inni zgodzili się, że wzajemnie się uzupełniają. Moje prywatne zdanie jest takie, że Spring wyrósł na obrzydzeniu do EJB2.x i jego podstawowymi zaletami były: nieinwazyjność, lekkość, elastyczność i coś co nazywam sobie lepkością czyli umiejętność integracji i "przylepiania się" do istniejących rozwiązań. Pojawienie się EJB3 trochę rozmyło granice. Oto bowiem dostaliśmy eleganckie rozwiązanie korporacyjne z niezależną od kontenera częścią do trwałego przechowywania danych i innymi bajerami. Co prawda całość była nieco w tyle, za rozwiązaniami z community, ale aura standardu słodziła niedogodności. W takiej sytuacji moim zdaniem pomiędzy Spring a EJB istniały 2 zasadnicze:

• EJB wymaga osobnego kontenera, Spring nie
• jeśli używasz EJB to bierzesz całą technologię, cało wielgachną maszynerię którą oferuje, w Springu bierzesz tyle ile potrzebujesz
  

Ostatecznie każde z nich znalazło swoją niszę i dobrze się tam miało. Szczególnie punkt nr 2 stanowił o przewadze Spring w systemach działających na jednej maszynie, nie wymagających rozproszonych transakcji, asynchroniczności, itd., itd. Bardzo podoba mi się w Sunie to, że uczy konsekwentnie się uczy. Uczy się diabelnie dużo od społeczności OpenSource, czego efektem było właśnie rzeczone EJB3. Wydarzyły się też dwie ważne rzeczy, które rzucają nowe światło na relację Spring - EJB. Po pierwsze Interface21 vel SpringFramework vel. SpringSource dostało kupę forsy od inwestora (słyszałem o $10mln). Sprawiło to, że chcąc używać Springa za darmo będziemy korzystać tylko z głównych wydań bez późniejszych poprawek, aż do kolejnego wydania głównego...chyba, że opłacimy subskrypcję:) Trochę głupio, ale trudno mieć im za złe, że chcą zarobić pieniądze na swojej pracy. Sęk w tym, że będąc najpierw projektem OO naruszyli pewną barierę psychologiczną. Bardzo Springowi pomagało bycie darmową "alternatywą" dla EJB, do tego użyteczną i świetnie napisaną. To było coś w stylu Robin Hooda - w tej roli bezinteresowny Spring Framework, a z przeciwnej strony Szeryf z Nottingham - czyli EJB Samo Zło. I w całej sytuacji najlepsze jest to, że Robin wybudował sobie własny zamek i ściąga jeszcze większą daninę niż Szeryf, walcząc zażarcie o każdą piędź Lasu Sherwood. Po drugie: Przeglądając nowości w JEE6 i EJB3.1 jeszcze bardziej podoba mi się kierunek, w którym Sun zmierza. Moją uwagę zwróciła koncepcja profili, której ideą jest, aby można było użyć tylko taką cześć platformy, która jest akurat potrzebna. Czyli można będzie odchudzić sobie korporacyjną Javę np. z asynchroniczności i rozproszonych transakcji jeśli zajdzie taka potrzeba. Ja tu widzę światełko w tunelu do zapewnienia tej użytecznej możliwości, którą posiada Spring czyli: bierzesz tyle ile potrzebujesz. Jest więcej ciekawych (bardzo ciekawych: żeby zwrócić uwagę na adnotację @Singleton i specyfikację WebBeans) rzeczy w EJB3.1, ażeby się nie powtarzać zamieszczam na końcu linki do artykułów. Jak to dalej będzie ze EJB i Springiem? Może JEE6 albo JEE7 da nam wszystko czego potrzebujemy? A może jakiś nowy pomysł SprigSource okaże się tak rewolucyjny, że zdeklasuje alternatywy na długie lata? A może jeszcze inaczej? Któż to może wiedzieć w czasach kryzysu:) Literatura http://blog.dywicki.pl/2008/09/28/spring-commercial-source-replaces-open-source/ http://springinpractice.wordpress.com/2008/12/02/new-stuff-in-spring-30/ http://springinpractice.wordpress.com/2008/12/03/new-stuff-in-spring-30-part-2/ http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-1 http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31 http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31-3 http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-Part4