Kolejka zwykła a kolejka SEDA

Question

Będąc nowicjuszem w Apache Camel, niedawno przeglądałem jego długą listę komponentów i natknąłem się na ich obsługę komponentów SEDA queue.

Strona nie miała dla mnie większego sensu, więc wykonałem kilka wyszukiwań w Internecie dla terminu "kolejka SEDA" i otrzymałem artykuł Wikipedii here.

Po przeczytaniu tego artykułu nie mogę stwierdzić, jaka jest różnica między kolejką SEDA a normalną, "zwykłą" kolejką! Oba koncepcje obejmują oddzielenie systemów za pomocą asynchronicznych kolejek.

Z artykułu "SEDA" brzmi jak architektura, która polega na umieszczeniu kolejki pomiędzy poszczególnymi komponentami. Czy to jest poprawne?

Ale jeśli to tylko architektura, to dlaczego kolejka "SEDA" jest specjalnym komponentem Camache Apache?

Answer 1

Kolejki SEDA są jak zwykła kolejka (i jak powiedział Peter powyżej, w Camelu mają pulę wątków z nimi związaną jako częścią komponentu). SEDA to architektura. Komponent SEDA w Camel wykorzystuje kolejki w pamięci w procesie i jest oddzielnym komponentem, aby odróżnić je od innego składnika kolejki na wielbłądzie Apache, a mianowicie komponentu JMS.

Answer 2

SEDA oferuje odsprzężenie komponentów w ramach jednej trasy wielbłądzowej. Lub w tym przypadku w ramach jednego procesu. . Oznacza to, że ułatwia wykonywanie połączeń asynchronicznych z innymi komponentami ... jest to blokada blokująca pamięć. Z drugiej strony JMS służy do oddzielenia całego systemu .. JMS będzie mieć brokera zewnętrznym zaangażowanym .. SEDA willl wystarczy utworzyć oddzielny wątek z komponentu konsumentów

Answer 3

Seda jest skrótem oznaczającym wystawił Event Driven Architecture został zaprojektowany jako mechanizm regulujący przepływ pomiędzy różnymi fazami przetwarzania komunikatów. Chodzi o to, aby wygładzić wyjście sygnału z całego procesu, tak aby pasował do wejścia, Pozwala to wątkom konsumenckim, aby odciążyć pracę długich operacji na bakground, a tym samym uwolnić je do konsumpcji wiadomości. z transportu. Kiedy wymiana jest przekazywana do seda: endpoint, jest ona umieszczana w BlockingQueue. Lista istnieje w kontekście wielbłąda, co oznacza, że ​​ten typ punktu końcowego może łączyć tylko te trasy, które są w tym samym kontekście. Domyślnie kolejka jest nieograniczona, ale można to zmienić, ustawiając atrybut rozmiaru na identyfikatorze URI użytkownika.

Domyślnie pojedynczy wątek przypisany do punktu końcowego odczytuje listę i przetwarza ją przez trasę. Jak widać w przykładzie postępowania, możliwe jest zwiększenie liczby współpracujących Konsumentów, aby zapewnić, że wymiany są przetwarzane z tej listy w odpowiednim czasie.

Schemat SEDA najlepiej nadaje się do przetwarzania komunikatów InOnly, w których jedna trasa kończy przetwarzanie, a druga przechodzi w drugą, aby poradzić sobie z kolejną fazą. można poprosić o odpowiedź od seda: endpoint, wywołując ją, gdy wzorzec wymiany komunikatów jest InOut

Odniesienie. Apache Camel Developer's Cookbook