![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],Open Source integration tools](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Open Source integration tools
Ähnlich wie Open Source integration tools (20)
Open Source integration tools
- 1. Open Source integration tools Apache ServiceMix, Camel oraz ActiveMQ
- 5. Architektura ServiceMix 3 Open Source integration tools Źródło: Dokumentacja Open ESB
- 6. Architektura ServiceMix 3 cd Open Source integration tools Źródło: Dokumentacja Open ESB
- 7. Architektura Karaf Open Source integration tools Open Source Expert Źródło: Dokumentacja Karaf
- 8. Architektura ActiveMQ Open Source integration tools Open Source Expert Źródło: Dokumentacja ActiveMQ
- 9. Architektura Camel Open Source integration tools Open Source Expert Źródło: Dokumentacja Camel
- 10. Architektura Camel cd Open Source integration tools Open Source Expert
Hinweis der Redaktion
- 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.
- Celem tej prezentacji jest oprócz suchego, teoretycznego opisu projektów przedstawienie architektury proponowanego rozwiązania a także opis przykładowej implementacji.
- 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.
- 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.
- Na tym rysunku widać dodatkowy element – JBI System Management w ServiceMix 4 obszar ten został wydelegowany do Karafa.
- 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).
- 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.
- 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.
- Komponent tworzy endpoint. Endpoint tworzy instancję Consumera, Producera oraz Exchange, który z kolei tworzy Message.