Pisanie aplikacji zgodnie z J2EE szybko stawało się jednak coraz trudniejsze, chociażby dlatego, że tak naprawdę J2EE pozostawiało w wielu kwestiach szerokie pole manewru, nie precyzując, jak niektóre elementy są realizowane. Było to szczególnie widoczne przy przejściu od specyfikacji J2EE 1.2 do 1.3 - nagle okazało się, że chcąc oferować kompletną platformę producenci musieli dodać rozszerzenia, z powodu których "automatyczna" przenośność stawała się niemożliwa. W pewnym okresie IBM i BEA publikowały tysiącstronicowe instrukcje w rodzaju "jak przenieść komponenty z platformy X".

Drugi problem przyniosło życie. Specyfikacja J2EE, a zwłaszcza EJB, czyli Enterprise Java Beans, gdy zaczęła być sprawdzana w praktyce przez programistów, pokazała swoje drugie oblicze. Zamiast przynieść realny zysk w produktywności, narzucała sztuczne, niepotrzebne w wielu systemach ramy, które po prostu przeszkadzały w efektywnej pracy. Dowodem w tej sprawie jest historia rozwiązań firmy JBoss, które bardzo długo nie były zgodne z J2EE, a jednak zyskały sporą popularność. Obecnie JBoss ma już certyfikat i skutecznie konkuruje z wielkimi - IBM i BEA.

Równocześnie dzięki rozwojowi open source okazało się, że aby pisać wielowarstwowe, skalowalne aplikacje w Javie serwer aplikacyjny wcale nie jest niezbędny. Często wystarczy prosty pojemnik na JSP/serwlety typu Tomcat, albo implementacja interfejsu Struts lub Tapestry. Analogicznie, jako model obiektów biznesowych można wykorzystać Spring, a przechowywanie stanu i zapisanie obiektu w bazie zlecić Hibernate - bibliotece kompleksowo rozwiązującej problem mapowania obiektowo-relacyjnego.

Z punktu widzenia aplikacji mamy wszystkie niezbędne elementy infrastruktury - skalowalność (będąca jednym z ważniejszych argumentów za J2EE) zależy tu od bazy, na której operuje Hibernate i jego mechanizmu cache. Technologie te można oczywiście łączyć z J2EE, ale podnosi się coraz więcej głosów, że w większości "zwykłych" systemów narzut związany z serwerem aplikacyjnym jest zbyt duży, a Struts jest prostszy w użyciu. IBM i BEA Systems dostrzegają trendy ucieczki od J2EE w sytuacjach, gdy nie są niezbędne i dostosowują się do nich. BEA Web Logic pozwala na uruchamianie aplikacji stosujących standardowe (w sensie JCP) zestawy technologii, jak i te, które używają komponenty standardowe (w sensie open source).

Coś na kształt .Net

W połowie grudnia 2005 r. BEA, IBM, Oracle, SAP, Siebel, IONA ogłosili rozpoczęcie wspólnych prac nad stworzeniem modelu programowania niezależnego od języka. Modelu, który będzie przeznaczony do tworzenia aplikacji w modelu SOA. Równocześnie uważni obserwatorzy mogą zauważyć, że IBM i BEA zaczęły w pewnym sensie opóźniać prace JCP (np. nad Java Integration Framework; JSR 208). Coraz wyraźniej widać ścisłą współpracę tych dwu firm nad nowym modelem SCA - Service Component Architecture i Service Data Objects, które częściowo też realizowane są w ramach JCP.

W pracach nad nowym modelem przewiduje się użycie Javy, ale z założenia model ma działać tak jak CLI w .Net Microsoftu, czyli ma być niezależny od języka programowania. Ze wstępnej specyfikacji wynika, że ten model będzie realizował mechanizmy podobne do tych zawartych w Windows Communication Foundation (Indigo) oraz LINQ. Obecnie w pracach wspominane jest stare dobre C++ oraz... PHP (na szczęście w wersji co najmniej 5). Natomiast nie jest jasno określona relacja pomiędzy SCA/SDO a stosem J2EE.

Na marginesie warto dodać, że równocześnie IBM i Oracle publikują coraz więcej artykułów pokazujących, jak użyć ich bazy danych wraz z PHP. Pojawiają się nawet stwierdzenia, że są rozwiązania, w których takie połączenie w zupełności wystarczy. Może to dać dużo do myślenia, biorąc pod uwagę, że mówią to, bądź co bądź, producenci serwerów aplikacyjnych Java, którzy dotychczas twierdzili, że w zasadzie tylko rozwiązania J2EE mają sens.

Rubinowe lekarstwo

Jednak nie tylko w obrębie samych bibliotek można szukać rozwiązania pozwalającego uprościć implementację projektu. W wielu obszarach można znaleźć nietypowe języki, które pozwolą w bardzo elegancki sposób rozwiązać dany problem. Takim pierwszym przykładem jest Perl. Jeżeli potrzebujemy przekształcać teksty, Perl jest naprawdę wymarzonym narzędziem. A ponieważ dynamiczne strony WWW często po prostu składają jakieś informacje w jeden dokument pobierając je z "zaplecza", to właśnie w Perlu pisanych jest dużo skryptów CGI.

Niedawno zakończone zostały prace nad wersją 1.0 środowiska Ruby On Rails (ROR). Jest to tak naprawdę pewien framework wyspecjalizowany w tworzeniu aplikacji WWW, oparty na składni języka Ruby. Autorzy tego rozwiązania podkreślają, że nie interesuje ich "poprawność akademicka" tego co tworzą. ROR ma być rozwiązaniem, które pozwoli szybko stworzyć standardowe 80% kodu przeciętnej aplikacji WWW. Sens w tym wielki, bo ten właśnie etap pracy programistę "czystego JSP" przyprawia o największy ból głowy. Dla porównania, programista używający rozwiązania typu Beehieve (czy ASP .Net) robi to samo w kilka minut.

Autorzy Ruby on Rails przyznają, że jedną z przyczyn popularności PHP jest to, że szybko można osiągnąć jakiś efekt. Ale utrzymywanie kodu PHP, zarządzanie zmianami itp. jest znacznie bardziej skomplikowane. Ruby On Rails ma zapewnić elastyczność PHP przy równoczesnym ułatwieniu tworzenia rozwiązań o dobrej architekturze i eleganckim kodzie, nadających się do łatwego utrzymania w przyszłości.

To, czy aplikacje można stworzyć szybko, czy nie, zależy także od środowiska IDE, ale w sumie w niewielkim stopniu. RAD - Rapid Application Development to jest raczej pewna grupa cech - zarówno IDE, jak i samego języka. No bo co z tego, że w IDE dostępne są narzędzia do projektowania stron JSP, które pozwalają "narysować" formatkę, ustawić właściwości itp., jeżeli w wyniku takiej operacji powstanie kilkaset linii kodu Javy i skrypty, które będą niemal zupełnie nieczytelne dla człowieka? Używając Ruby on Rails, czy "zaprzęgając" do pracy Struts może się okazać, że wystarczy 5 linijek kodu, by osiągnąć podobną funkcjonalność. Jako IDE może być użyty dowolny edytor tekstowy, ponieważ cały program jest stosunkowo krótki.

Problem wyniesiony ze szkoły

Stosowanie niestandardowych rozwiązań ma oczywiście pewien mankament. Jeżeli zespół tworzy aplikacje, wykorzystując "standardowe" technologie - C/C++, Javę, .Net, nie występują problemy ze znalezieniem doświadczonego programisty. W przypadku rozwiązań mieszanych, gdzie chcemy użyć chociażby nietypowej biblioteki - mogą być problemy ze znalezieniem "zastępcy", który byłby w stanie kontynuować pracę.

Problem częściowo wynika ze sposobu kształcenia programistów. Jeżeli w programie edukacji pojawiają się laboratoria z programowania obiektowego - to są to ćwiczenia z konkretnego języka, a nie ze sposobu realizacji algorytmu w sposób obiektowy. Z jednej strony to dobrze - uczelnie dostrzegły, że studenci powinni znać nowe technologie, bo dzięki temu mają mniejsze problemy ze znalezieniem pracy. Z drugiej strony, nie pokazują studentom dostatecznie wyraźnie, że ten sam projekt funkcjonalny można zrealizować w różnych językach.

Nie warto zamykać się w jednym określonym "stosie" języka i jego standardowych bibliotek. Czasami eksperymenty, mimo że kosztowne, mogą z czasem przynieść bardzo wymierne skutki, np. skracając znacznie czas potrzebny na tworzenie aplikacji.

Jeżeli z jakichś powodów projekt trzeba pisać w "danej odgórnie" technologii, to wypada sprawdzić, czy można choćby sięgnąć po mniej standardowe narzędzia, a nie zawsze uruchamiać kod w pojemnikach EJB na serwerze aplikacyjnym tylko dlatego, że "już jest dostępna infrastruktura".