Czy integracja ESB (ServiceMix/Mule) Warto Curve uczenia?

Question

Czekam na integrację ESB z istniejącym produktem opartym na Java/Maven. W szczególności patrzę na ServiceMix i Mule. Produkt połączy się z kilkoma różnymi usługami, w tym pocztą elektroniczną, mechanizmem kwarcowym, RESTful usługami sieciowymi za pośrednictwem HTTP, SMS i IM. Szybko rzuciłem okiem na dokumentację, a dwie opcje wydają się być dość ciężkie i dość złożone. Wydaje się, że jest to podręcznikowy przykład wykorzystania ESB, ale nie chcę poświęcać dużo czasu na naukę jednego lub drugiego systemu.

Tak jak powiedziałem, mam już aplikację internetową zbudowaną przez Mavena i liczyłem na integrację jednego z systemów, który byłby dość prosty, nawet na coś tak prostego, jak wysłanie e-maila, ale wygląda na to, że dodanie spowoduje wciągnięcie pół świata pod względem słoików i byłoby trudno osadzić w istniejącym produkcie.

Czy warto spróbować skorzystać z jednej z tych opcji? Czy istnieje prosty sposób na zintegrowanie ich z istniejącą aplikacją bez całkowitej jej restrukturyzacji? Czy są inne, lżejsze opcje wagi? Czy są jakieś aspekty, które powinienem rozważyć, aby ich wykorzystanie było opłacalne?

Answer 1

Mule jest dość prosty w użyciu, jeśli chodzi o łączenie usług z XML i ma mnóstwo przykładów wideo, które okazały się bardzo pomocne.

ESB mają być przyszłością i jak pan mówi - wasz wydaje się jak podręcznikowy przykład tego, gdzie z niego korzystać.

Postaram się odpowiedzieć na wszystkie pytania:

Czy warto próbuje ciągnąć w jednej z tych opcji? Myślę, że jest to pytanie, które należy zadać sobie samemu - co próbujesz osiągnąć? jeśli próbujesz ułatwić implementację, prawdopodobnie zajmie to tyle czasu za pomocą czystego kodu lub ESB, co przy całej konfiguracji. Jeśli myślisz o zrobieniu tego jako ćwiczenie do nauki, może być warto.

Czy istnieje prosty sposób na zintegrowanie ich z istniejącą aplikacją bez całkowitej jej restrukturyzacji? Krótka odpowiedź nie. Będziesz potrzebował re-inżynierii do integracji z większością bibliotek/frameworków firm trzecich.

Czy są inne, lżejsze opcje wagi? Muł jest naprawdę bardzo prosty. Możesz używać MQ do obsługi HTTP, SMS i IM. Prawdopodobnie ActiveMQ lub RabbitMQ.

Czy są pewne aspekty, które powinienem rozważyć, aby ich wykorzystanie było opłacalne? Tak, ESB są przeznaczone dla przedsiębiorstw, w których nowe usługi są często dodawane i konfiguracja prawdopodobnie ulegnie zmianie. Posiadanie wszystkiego w XML czyni tę zmianę nieco łatwiejszą. Jeśli więc tworzysz jednorazowy program, może to nie być właściwa droga. Ale jeśli dodamy więcej później i stale łączymy różne usługi, może to być najlepsza trasa.

Answer 2

Ross Mason, twórca projektu Mule napisał naprawdę dobry artykuł na ten temat, To ESB or Not to ESB. Poleciłem rzucić okiem na to. Możesz również sprawdzić wersję Mule iBeans, która oferuje znacznie prostszy model, jeśli budujesz go jako aplikację internetową i chcesz tylko dokonać niewielkiej integracji i nie jesteś zainteresowany mediacją.

Answer 3

Możesz również przyjrzeć się frameworkowi Apache Camel, który jest naprawdę potężny we wszystkich potrzebach integracji, o których wspomniałeś, bez kar za pełny wybuch ESB.

Answer 4

Radzę nie tracić cennego czasu z MULE. Moje dotychczasowe doświadczenie nie jest dobre. Nie użyłbym go do żadnego krytycznego systemu. To daleko od bycia dojrzałym produktem. Poza tym usługi RESTful zdecydowanie obiecują dużo prostoty i mają rzeczywiste zastosowania.

Answer 5

Powiedziałbym, że warto inwestować, jeśli masz więcej niż dwie aplikacje lub bazy danych, które muszą ze sobą rozmawiać ORAZ używają więcej niż jednego protokołu komunikacyjnego. Lub, jeśli spodziewasz się, że ta sytuacja będzie prawdą w przyszłości. Wygląda na to, że twoje wymagania na pewno pasują do tego.

Inną sytuacją, która sugerowałaby korzystanie z magistrali ESB lub co najmniej jednej magistrali komunikatów, byłaby sytuacja, w której oczekuje się, że jedna lub więcej aplikacji będzie ewoluować niezależnie od innych. Na przykład jeden jest w fazie aktywnego rozwoju, a inni nie. ESB może izolować stabilne systemy od zmian w aktywnie opracowywanych systemach, eliminując potrzebę ciągłej aktualizacji wszystkiego.

Prawdziwa władza ESB polega na tym, że aplikacje mogą delegować wszystkie decyzje dotyczące sposobu komunikowania się i komu komunikować się z ESB i pozwolić temu komponentowi wziąć pełną odpowiedzialność za te aspekty. Wszystkie inne komponenty zostają odizolowane od siebie i nie trzeba się o siebie martwić, znacznie redukując problemy z połączeniami zależności.

Jeśli chodzi o krzywą uczenia się, stwierdziłem, że Mule ESB jest dość proste do opanowania i na pewno będzie znacznie mniejszą krzywą uczenia się, która będzie próbowała nauczyć się wszystkich wymaganych API, aby porozmawiać z wieloma usługami, które próbujesz połączyć się z.