�ݺ�ߣ

Editor's Notes

1. Zanim zaczniemy pracę parę słów na temat rzeczy które podczas tej prezentacji będą używane. OSGi (Open Service Gateway) – nie jest nowością. W maju tego roku minie 10 lat od wydania pierwszej wersji specyfikacji. Najświeższa wersja OSGi to 4.1 wydana w 2007roku. W zeszłym roku pojawił się draft wersji 4.2 która jest ukłonem w stronę enterprise. ServiceMix nie jest aż tak stary jak OSGi nie mniej swoje lata już ma. Wersja 3.1 w 2007 roku wyszła z inkubatora i stała się projektem fundacji Apache. Wersja 4.0 została wydana w marcu 2009. Karaf jest podprojektem Apache Felix. Pierwotnie była to część ServiceMix 4 jednak została ona przeniesiona do projektu bliższego OSGi. ActiveMQ jest implementacją specyfikacji JMS w wersji 1.0 oraz 1.1, wersja 4.0 została wydana w roku 2006 obecnie trwają prace nad ActiveMQ 6.0. CXF jest połączeniem kilku projektów, między innymi XFire, CXF z inkubatora wyszło w 2008. Obecnie zespół CXF dostarcza również referencyjną implementację distributed OSGi. Camel początkowo był podprojektem ActiveMQ jednak ze względu na duża dynamikę jak i coraz większą objętość stał został samodzielnym projektem. Ostatnia wersja projektu ukazała się na początku tego roku. Blueprint jest pojęciem świeżym i ściśle się wiąże z popularyzacją OSGi w świecie aplikacji klasy enterprise. Jest to tak naprawdę rozwinięcie idei Dependency Injection w świecie OSGi. Nieoceniony jest tutaj wkład twórców Spring-DM.
2. Celem tej prezentacji jest oprócz suchego, teoretycznego opisu projektów przedstawienie architektury proponowanego rozwiązania a także opis przykładowej implementacji.
3. Każdy z projektów który został wymieniony w agendzie ma swoją rolę. W przypadku realizowanego scenariusza rola ServiceMix-a jest nieco zmarginalizowana. Nie jest on wykorzystywany jako implementacja JBI a dostawca artefaktów OSGi które są potrzebne do uruchomienia projektów. Dzięki ActiveMQ będziemy symulować komunikację z zewnętrznym systemem. CXF posłuży do uruchomienia przykładowego web service. Największa ilość kodu będzie powiązana z Camelem, który będzie używany nie tylko do routingu komunikatów ale także do uruchamiania usług.
4. Powyższy rysunek przedstawia architekturę opartą o JBI o którą był opart ServiceMix 3. W ServiceMix 4 podział na powyższe komponenty został zachowany, z tym że element JBI Messaging Infrastructure został w całości zastąpiony przez projekt ServiceMix NMR – czyli Normalized Message Router który jest mniej sformalizowany niż message bus w JBI. Między innymi nie wymaga używania przestrzeni nazw do nazywania usług.
5. Na tym rysunku widać dodatkowy element – JBI System Management w ServiceMix 4 obszar ten został wydelegowany do Karafa.
6. Powyższy rysunek przedstawia najważniejsze obszary dla Karafa, wokół których projekt jest skupiony. Część usług takich jak logowanie pochodzi z projektu OPS4J, a takie jak blueprint ściśle wiążą się z Apache Geronimo. Jako framework OSGi może być używany zarówno Felix jak i Equinox (licencja EPL jest kompatybilna z ASF 2.0).
7. Architektura ActiveMQ jest bardziej zwarta niż pozostałych projektów ponieważ jest to "tylko" broker JMS. Oczywiście oferuje on możliwość połączenia się poprzez protokoły inne niż binarny jakkolwiek co by nie mówić – głównym zadaniem ActiveMQ jest obsługa JMS. Rzeczy takie jak STOMP, HTTP są przydatne przy próbie połączenia z klientami innymi niż pisane w Javie. Architekturę CXF pominiemy ponieważ nie będzie ona istotna w naszym dzisiejszym scenariuszu.
8. Za to kluczową rolę w naszym zadaniu będzie odgrywał Camel – stąd nad nim zatrzymamy się na dłużej. Na rysunki widzimy kilka komponentów – JMS, HTTP oraz File czyli te najprostsze. Po prawej znajdują się procesory które wzbogacają funkcjonalność Camela. Komponenty w Camelu pełnią rolę binding componentów z ServiceMixa podczas gdy procesory można by określić czymś w rodzaju service engine – operują one na przesłanych komunikatach, jakkolwiek mogą również je rozdzielać, scalać, wzbogacać, przycinać i tak dalej.
9. Komponent tworzy endpoint. Endpoint tworzy instancję Consumera, Producera oraz Exchange, który z kolei tworzy Message.