Zkušenosti s Apache Camel

Poslední půlrok jsem pracoval intenzivně na integračním řešení pro jednoho nového virtuálního operátora. Základním stavebním prvkem byl integrační framework Apache Camel. Rád bych se v tomto článku ohlédnul zpět a použití tohoto řešení trochu zhodnotil.

Úplně na začátku bych se zastavil u toho, proč vlastně Camel. Já jsem do projektu přišel na začátku implementace (nebyl jsem tedy součástí obchodních příprav) a musel jsem pracovat s tím, co už bylo slíbeno - buď Apache ServiceMix nebo Apache Camel jako hlavní součást ServiceMixu. ServiceMix je vlastně kompletní ESB řešení, které řeší základní vlastnosti jako stabilitu, škálovatelnost, flexibilitu atd., není tedy nic dalšího potřeba. Mě to ale přišlo hned na začátek příliš velké sousto (ServiceMix je poskládaný s dílčích řešení a s většinou jsem dosud žádné zkušenosti neměl), takže jsem si řekl, že použijeme jen routovací jádro (Apache Camel) a o vše ostatní (stabilitu, škálovatelnost, flexibilitu, ...) se postaráme sami. Pokud bych začínal na zelené louce, tak by mě to určitě více táhlo ke Spring Integration, protože rád a hodně využívám Spring projekty. Spring Integration je přímý konkurent Apache Camelu (stačí vygooglit "spring integration vs camel"), ale bohužel sám zatím nemohu říci, co je lepší, protože mi chybí větší zkušenost se Spring Integration.

Náš technologický stack vypadal následovně:

• Apache Camel
• Spring framework
• Spring Web Services
• Spring Security
• Hibernate
• PostgreSQL
• Apache Tomcat
• Apache HTTP server

Pozn. o architektuře řešení bych rád napsal v některém dalším článku.

Když jsme začínali s projektem, tak Camel byl ve verzi 2.9, když jsme projekt končili, tak jsme používali verzi 2.11.

Mám již 3 týdny od konce projektu, takže s lehkým odstupem času mě napadají tyto body, když se řekne Apache Camel:

• pro mě nezvyklá chybovost. Jak asi víte, mám rád projekty od Springu a u nich si člověk rychle zvykne na opravdu vysoký standard - vysoká kvalita kódu a nízká chybovost. Toto bohužel u Camelu úplně neplatí. Kvalita kódu a JavaDoc jsou určitě nadprůměrné, ale chybovost mi přišla celkem velká. Po nějakém čase člověk zjistí co funguje a co ne, takže v průběhu vývoje šla naše efektivita určitě hodně nahoru, ale na začátku jsme museli trochu hledat cesty, které fungují a které ne. Zase musím uznat, že pokud jsme nějakou chybu nahlásili, tak v dalším releasu byla opravená. 
• rozsáhlá podpora knihoven třetích stran. Pokud chcete v Camelu komunikovat nějakým protokolem nebo využít nějakou knihovnu třetí strany, pak je toto v Camelu řešeno přes komponenty a těch je v nabídce Camelu opravdu hodně.
• Spring WS vs. Apache CXF. Webové služby jsou základním komunikačním způsobem u integračních řešení, takže výběr této Camel komponenty byl stěžejní. Začal jsem s Apache CXF, protože na první pohled je vidět, že integrace obou knihoven je opravdu úzká. Ale bohužel mi časem došla trpělivost s CXF (omlouvám se, ale já prostě tuto knihovnu opravdu nemám rád) a přešel jsem na Spring WS. Bohužel některé potřebné věci jsme si museli napsat sami nebo jsme počkali na další verze Camelu, ale při pohledu zpět to vidím jako správně rozhodnutí.
• výborná podpora pro unit testy. Integrační řešení jsou specifická tím, že je nutné se pojit na spoustu externích systémů, které většinou nemáte vůbec pod svojí kontrolou. Proto je hodně důležité, když je možné pro potřeby unit testů se oproti externím systémům vymezit, což Camel umí hodně dobře. Navíc Camel nabízí opravdu flexibilní řešení, kdy si pro účely unit testů můžete originální routu upravit přesně podle svých potřeb.
• dostatek informací. Úspěšné řešení doprovází dostatek dostupných informací a to pro Camel určitě platí. Samotná dokumentace je obsáhlá a vše potřebné je tam k nalezení, diskuzní fórum je aktivní a na všechny mé dotazy se objevila odpověď celkem rychle. Já osobně jsem s Camelem začínal přečtením knížky Camel in Action. Knížka je sice v řadě oblastí zastaralá (myslím, že byla psána ve verzi 2.4), nicméně základní informace jsou pořád stejné, jen se mění a rozvijí jednotlivé Camel komponenty.
• komerční podpora a nástroje třetích stran. Při výběru nové technologie si člověk vždy chce nechat otevřená zadní vrátka pro případ, že vše nepůjde tak jak se očekávalo. Proto je vhodné vědět, že existuje i možnost komerční podpory ze strany FuseSource, což je firma, kterou nedávnou koupil RedHat. Kromě možné podpory nabízí FuseSource i své ESB a další zajímavé produkty, které lze s Camelem využít - Fuse IDE a Fuse Management Console. 
• routovací jádro. Samotný Apache Camel je pouze jen routovací jádro, které implementuje EIS vzory. Samotné moc nezabírá a je tedy ho možné využít v libovolných aplikacích pro dílčí úkoly.
• Java DSL vs. Spring XML konfigurace. Zápis integračních route je možné buď přímo v jazyce Java (Java DSL) a nebo využít Spring namespaces a route konfigurovat pomocí Spring XML. My jsme si vybrali Java DSL, protože nám to hned od začátku bylo bližší, ale teď nevím, zda bych to udělal znovu stejně. Pokud potřebuji volat z routy nějakou Java metodu, tak to nejčastěji volám přes referenci na beanu včetně zadání názvu metody jako řetězce. Mě tento přístup do Javy moc nesedí, takže bych to raději konfiguroval v XML, ale zase to má tu nevýhodu, že je to mnohem více upovídané, a že musím pořád přepínat mezi Javou a XML. Jinak by ale oba přístupy z pohledu funkcionality měly být zcela rovnocenné.

Apache Camel jsem si za intenzivní půlrok slušně ošahal, již vím co funguje a co ne a musím se přiznat, že jsem si Camel i celkem oblíbil.