Właśnie opublikowałem kolejny artykuł Definiowanie komponentów usługowych z OSGi Declarative Services podsumowujący moje dotychczasowe dokonania (pseudo)naukowe w obszarze OSGi R4 Declarative Services.
Jest to specyfikacja komponentów usługowych w OSGi - część specyfikacji OSGi Service Platform Service Compendium wydanie 4, wersja 4.2 opisana w rozdziale 112. Declarative Services Specification. Na niecałych 50 stronach można zapoznać się z deklaratywną rejestracją usług na platformie OSGi.
OSGi Declarative Services zdejmuje z barków programisty utrzymywanie kodu, który wymagany był przez użycie OSGi w warstwie usługowej. W tonie zdejmowania obowiązków z barków programisty i parającym się OSGi zdecydowanie ulżono (nie wliczając w to poznania nowej specyfikacji). Już na etapie mojego skromnego doświadczenia w obszarze OSGi jestem w stanie zauważyć prostotę OSGi przy użyciu OSGi Declarative Services. To nic innego jak kolejna warstwa na warstwie usługowej OSGi.
Artykuł stanowi przyczułek do dalszych doświadczeń poznawania OSGi wierząc, że podsumowaniem będzie kompletna aplikacja desktopowa (najpierw) oraz korporacyjna (później). Liczę również na odzew osób, które już parają się OSGi, czy też po prostu są zaintrygowane możliwościami OSGi, czy w końcu rozważają ich poznanie. Więcej nas, to ciekawsze dyskusje, a to na pewno przyczynia się do łatwiejszej nauki i wejścia w świat dynamicznych aplikacji.
Ostatnie konferencje w Polsce, wliczając minioną Confiturę 2011, nie pozostawiają złudzeń, że nie jest to szeroko rozpowszechniony temat u nas. Zastanawia mnie dlaczego?! W końcu era OSGi na poziomie serwerów aplikacyjnych już nastała, a nierzadko, ale wciąż ze przyciszonym głosem, mówi się o niej w obszarze szkieletów aplikacyjnych, np. OSGi integration for Grails applications. Marsz ku OSGi idzie jednak niezwykle powoli (może faktycznie wysiłek w stworzenie działającego rozwiązania nie przynosi aż takich zysków?).
Zapraszam do lektury mojego nowego artykułu Definiowanie komponentów usługowych z OSGi Declarative Services i udziału w dyskusji o wartości OSGi w naszych aplikacjach. Zechciałby mnie ktoś łaskawy wyprowadzić z przekonania, że warto inwestować swój czas w OSGi i okolice?
No to Jacku podyskutujmy w takim razie, OSGi na poziomie serwera aplikacyjnego - dla mnie ok, tutaj jest sporo elementów gdzie to się sprawdzi, ale na poziomie aplikacji - zastanawiasz się, czemu ten temat taki "cichy", to zacznijmy od odpowiedzi - gdzie widziałbyś ich zastosowanie w przeciętnej aplikacji na początek powiedzmy web?
OdpowiedzUsuńWspaniale, że ktoś podjął się tematu!
OdpowiedzUsuńAplikacja webowa to w zasadzie nic innego jak aplikacja desktopowa, czy dowolna inna aplikacja. Ot, po prostu inny interfejs dostępowy i gdyby zapomnieć o tej warstwie, bez względu na rodzaj aplikacji mamy do czynienia z pewnymi funkcjami oferowanymi przez nie. Nic nadzwyczajnego w rozumowaniu, jak przyznasz zapewne.
Jak w każdej aplikacji, również webowej, mamy do czynienia z oferowaniem, czy korzystaniem z usług. I tu widzę zastosowanie dla dowolnego szkieletu, który wspiera zarządzanie usługami, wręcz je wymusza, bo innego sposobu komunikacji między funkcjami nie ma. To jest OSGi w warstwie usługowej.
Jak w każdej aplikacji, również webowej, mamy do czynienia z zależnościami, zwykle dystrybuowanych w ramach plików jar - od kilku do kilkunastu, czy kilkudziesięciu. W Javie jar to zwykła paczka i może wręcz się zdarzyć, że pakiet jest rozdzielony między nimi. OSGi wspiera zarządzanie zależnościami na poziomie pakunków (pliki jar) oraz pakietów javowych, włącznie z ich wersjonowaniem na poziomie warstwy pakunków.
Pozostaje jeszcze możliwość dynamicznego włączania/wyłączania funkcji, które OSGi oferuje w ramach warstwy zarządzania cyklem rozwojowym pakunków.
Wersjonowanie, usługi, mechanizm widoczności pakietów (import/export), to właśnie OSGi.
A czy to się przydaje w aplikacjach webowych? Sądzę, że tak. Pracuję nad rozwiązaniem, które ukaże moc OSGi właśnie w kontekście aplikacji webowych, gdzie będę włączał/wyłączał dynamicznie jej funkcje, co nie jest dostępne w jakimkolwiek znanym mi rozwiązaniu, poza OSGi.
Zechciałbyś mi pomóc w stworzeniu prototypu takiej aplikacji? Możnaby wyjść od założenia, że wszystko, co oferuje aplikacja to usługi RESTowe, które oferowane są przez pakunki OSGi. Jest usługa, jest realizowana dana cecha aplikacji. Nie ma, to nie jest. Brakuje mi kilku kawałków układanki, ale na pewnym poziomie jestem w stanie sobie to niezwykle dobrze wyobrazić funkcjonujące sprawnie.
To co piszesz czyli takie włączanie i wyłączanie w pewnym ograniczonym zakresie zrobiliśmy kiedyś w Spring :) Natomiast co do takich odseparowanych usług jest trochę ograniczeń, które zmniejszają ich zastosowanie. Co do wspomagania - mam OSGi na liście do poznania ale przez następny miesiąc trochę jestem "uwalony" a trochę się urlopuję :) ale potem w sumie czemu nie :)
OdpowiedzUsuńJeśli Spring, to Spring-DM, a obecnie Eclipse Gemini. OSGi da się "zrobić" ze zwykłą Javą, ale pytanie, czy lepiej robić warstwę niebiznesową, pośrednią, jeśli płacący żądają biznesowej?
OdpowiedzUsuńPisząc Spring miałem na myśli Spring Framework, po prostu pewne rzeczy o których wspomniałeś da się w pewnym zakresie zrobić bez udziału OSGi. Co do pisania - z punktu widzenia biznesu - im więcej gotowca tym lepiej :)
OdpowiedzUsuńJa również nie miałem złudzeń, że Twój Spring to Spring Framework. Przez myśl nie przeszło mi nic innego :)
OdpowiedzUsuńSkoro stworzono Spring-DM na bazie Spring, to dałoby się...jeszcze raz, inaczej pewnie. Pytanie, czy starczyłoby Ci/nam/im zapału, aby przebrnąć przez wszystkie szczegóły implementacyjne, aby zarządzanie pakunkami ala OSGi było tak proste jak jest obecnie dostępne w OSGi.
Jestem zdania, że warto pokusić się o stworzenie własnego rozwiązania, bo może być 1) bardziej dopasowane do potrzeb, przez to potencjalnie sprawniejsze od pierwowzoru, 2) bardziej wyrafinowane funkcjonalnie, ale 1) zwykle nie ma czasu na poświęcenie się tematowi, 2) wiedza dziedzinowa niewielka. Stąd uważam, że należy próbować, ale mnie osobiście wiążą wspomniane punkty.