W
Early draft of OSGi Service Platform Release 4.2 specification now available Adrian Colyer przedstawił jedną ze zmian dotyczącą nazewnictwa pakunków OSGi w
RFC 124 "A Component Model for OSGi", który stanie się specyfikacją komponentów OSGi i jakie to pociąga za sobą zmiany w samym
Spring Dynamic Modules (Spring-DM). W/g Adriana zmian na skalę rewolucji nie będzie, a jedynie zmiana/mapowanie nazwy znacznika
bean (podstawowy znacznik konfiguracyjny w Springu, nie tylko DM) na
component i tyle. Reszta to po prostu Spring-DM (stąd dla samego Adriana nie będzie rewolucji, a dla wielu właśnie wdrożenie Spring-DM pod skrzydła specyfikacji nią jak najbardziej jest). Znamienny jest sposób przedstawiania roli Spring-DM w samej specyfikacji. Przypomina mi to peany jakie pisała o sobie grupa Hibernate i jej wpływie na specyfikację JPA oraz grupie JBoss Seam na specyfikację WebBeans. Czyżbym był przewrażliwiony? Obserwując wykorzystanie JPA w projektach daje się zauważyć, że dla wielu JPA to faktycznie Hibernate (a szczególnie jego część Criteria API). Mimo mojego dzisiejszego minorowego nastroju odnośnie RFC 124 i Spring-DM wierzę w dobre intencje wszystkich wymienionych grup i już nie mogę doczekać się popróbowania z platformą referencyjną dla RFC 124 (aka RFC124 RI). Jeśli ma to uprościć tworzenie aplikacji korporacyjnych, to dlaczegóżby nie skorzystać z niego?! Samo OSGi ma wiele do zaoferowania na poziomie uproszczenia architektury aplikacji, gdzie duży nacisk kładzie się na odseparowanie deklaracji (interfejsy usług) od realizacji (implementacja usług), więc czym więcej OSGi w naszych rozwiązaniach, tym lepiej (nota bene, to samo możnaby również napisać o Spring Framework). I nie mógłbym nie wspomnieć o niezwykłym podobieństwie specyfikacji
Service Component Architecture (SCA) do RFC 124. Mógłbym napisać, że są łudząco podobne, ale jest to jedynie moje przeczucie nie podparte lekturą RFC 124. A może ktoś z czytelników już się z nim zapoznał i zechciałby przedstawić swój punkt widzenia? Zachęcam do opublikowania go na swoim blogu, tutaj, albo w...
JAVA exPress Grzegorza Dudy.
Upór Grzegorza w stworzeniu czegoś namacalnego i wartościowego dla społeczności javowej znalazł swój finał w pierwszym numerze niezależnego, niekomercyjnego, itp. czasopisma o tematyce javowej -
JAVA exPress Numer 1 (1) Sierpień 2008, w którym znajdziemy "Hello World!" maszynisty Grzegorza, 5 artykułów, w tym 2 przewodnie, o tytułach, w których liczba słów "kolejowych" odpowiada "javowym" i...a co ja będę się rozpisywał. Zainteresowany/-a?! Pobierz darmowy numer JAVA exPress ze
strony czasopisma (uwaga na rozróżnienie słów
gazeta vs
czasopisma - gdzieś ktoś o tym wspominał na jednej z grup javowych po publikacji JAVA exPress, ale nie mogę tego teraz znaleźć).
A wracając do OSGi i jego specyfikacji to Craig Walls (autor książek o Spring Framework - Spring in Action dostępnej również w
Bibliotece Warszawskiego JUGa) wyraził swoje wątpliwości odnośnie wpływu OSGi na Spring-DM, albo...na odwrót? -
Spring and OSGi R4.2. Jako stały użytkownik Springa (mowa o Craigu), jak i OSGi w wykonaniu Spring-DM zdaje sobie sprawę z podobieństw między Spring a OSGi. Nawet stworzył ciekawy akronim, który oddaje trend
konwergencji między OSGi i Java EE -
OS-JEE-i, a może powinno się dodać i Springa -
OSprin-JEE-i? ;-) Na szczęście nasze aplikacje na pewno nie ucierpią, a znacznie łatwiej będzie tworzyć dynamiczne systemy, gdzie przez "dynamiczność" rozumiem możliwość zmiany funkcjonalności aplikacji bez konieczności jej zatrzymywania.
Na dokładkę nie mógłbym nie wspomnieć o
Richard S Hall (Apache Felix) Joins Sun, co pozwala przypuszczać, że w ofercie Suna również OSGi nie zabraknie. W kontekście RFC 124 natrafić można na pracę Richard'a -
Beanome : A Component Model for the OSGi Framework. Cóż za zbieg okoliczności w kontekście Spring-DM i jego roli na RFC 124 (!) Dodając do tego OSGi w GlassFish v3 wygląda, że coś z tych doświadczeń OS-JEE-i-owych znajdziemy również już niedługo w ofercie wszystkich dostawców serwerów aplikacyjnych Java EE. Na odświeżenie spojrzenia o roli usług i OSGi, który wręcz wymusza ich tworzenie w naszych aplikacjach warto zapoznać się z
Why Services are Important oraz
OSGi - A Component of the Next Generation Platform?. Chwila lektury, a o ile poszerza się nasz horyzont programistyczny.
I dla tych zainteresowanych dokładniejszym spojrzeniem współprzewodniczącego
OSGi EEG na prace nad OSGi V4.2 i zmianami zapraszam do lektury
Early Draft OSGi V4.2 Docs Available. W nim dowiadujemy się o wspomnianym na początku
the Spring-DM inspired component model design (RFC 124). Jeśli uważasz, że kierunek jaki obrała grupa OSGi EEG jest niewłaściwy, albo nieprecyzyjny, albo...tu wpisz jakikolwiek z powodów, dla których warto wyrazić swoją opinię...przyłączam się do apelu Eric'a, pobrania dokumentu
OSGi V4.2 Early Draft i wyrażenia siebie. Może być na swoim blogu, tutaj, w JAVA exPress bądź na stronie OSGi EEG. Możliwości jest na prawdę wiele.
Nie długo trwa, abym przekonał się, że rola Spring-DM nie będzie wyłącznie pomocnicza, a raczej główna, gdyż jak napisał Costin Leau (za
How Spring DM (greatly) influenced the upcoming OSGi 4.2):
Spring-DM will become the RI. We haven't sorted out the technical details, but it's likely it's going to be platform agnostic so one could just take out the implementation and use whatever 4.2 platform it likes.
Uzupełnieniem lektury z pewnością będzie (technicznie)
Some thought on the OSGi R4.2 early draft oraz (strategicznie)
Eclipse Swordfish SOA runtime mixes SCA, JBI and OSGi, gdzie można zapoznać się z zależnościami między SOA, SCA, JBI, OSGi, Java EE, Spring Framework, Eclipse i jeszcze wielu innych akronimów oraz produktów je realizujących (aż trudno uwierzyć, że aż tak tłoczno jest wokół OSGi). Ciekawostką może być wycinek, w którym podkreśla się rolę OSGi względem wad Java EE oraz Springa:
He rates Java EE 5 as too heavyweight and complex with static deployment descriptors. Spring, on the other hand, does not allow dynamic deployment or reconfiguration, and lacks support for "true modularization," he said.oraz
It's dynamic. It's easy to use. It is mature. We believe that OSGi gets momentum in the future and will diminish JEE and Spring.czy w końcu:
SCA provides a common programming model and a common description format. JBI provides a common messaging model. OSGi provides a common deployment model and a common runtime component model.I na zakończenie serii linków (sznurków?) odnośnie OSGi i jego wpływu na nasze i innych rozwiązania -
Plugins 2.0: a heads-up z Attlasianu - producenta m.in. Confluence Wiki. Wygląda na to, że OSGi będzie warstwą realizującą mechanizm wtyczek w Confluence (!) Skoro wtyczki to plugins, a tu już tylko krok "myślowy" do OSGi (za sprawą Eclipse). Czy ma znaczenie, jaką rolę posiada wtyczka? Wtyczka to rozszerzenie podstawowego produktu, więc czy to IDE czy serwer aplikacyjny, wtyczka może wprowadzić dużo pożądanej funkcjonalności...w tracie działania aplikacji. Pozostaje tylko czekać, kiedy pojawią się projekty w Polsce oparte bezpośrednio na OSGi. Pamiętam pewną lubelską firmę programistyczną, która podczas JAVArsovii 2008 wypytywała mnie o rolę OSGi w tworzeniu aplikacji webowych (widoczność sesji, itp.) i niestety nie było wtedy wiele czasu na dyskusje. A szkoda! Ciekawym ile z tych planów się zmaterializowało?!
Więcej o OSGi na tegorocznym
Java Developers Day (JDD) 2008 16. października 2008 w
Krakowie, gdzie podjąłem się zadania przedstawienia go w różnych realizacjach. Otrzymałem 1h na prezentację i to zaraz przed gwiazdą wieczoru Nealem Fordem, więc spodziewam się Was tam wszystkich zobaczyć i rozpoznamy nasze rozpoznanie tematu OSGi ;-) Fajnie byłoby "strzelić" jakieś nagranie z naszej dyskusji (podkreślam słowo dyskusji). Zapraszam!
