JMS Kuyruk Böl. Kurumsal Entegrasyon. Apache Camel

Question

Bazı iletileri JMS Kuyruğuna koyan bir üçüncü taraf uygulamasına sahibim. Ayrıca iletileri bu sıradan okuyan bir uygulama var. İletinin türüne bağlı olarak bu iletiyi DB'ye kaydediyorum veya üçüncü taraf hizmetine gönderiyorum. Ayrıca, üçüncü tarafa aşırı yüklenmemesi için ikinci sınır başına bazı sabit çağrıları aşmamalıyız.

Şu anda bu kullanım durumu için aklıma iki çözüm geldi.

Birincisi, üçüncü şahsın bazı özel başlıklar göndermesini istemek, böylece JMS tüketicisi JMS Seçici'yi kullanarak iletileri filtreleyebilsin. Dolayısıyla, bu durumda iki tüketici oluşturabiliriz, birincisi mesajları okuyabilecek ve bunları DB'ye kaydedebilecek, ikincisi ise belirli bir yükte üçüncü tarafa mesaj göndermek için bazı kısıtlama/yoklama mekanizmasını kullanacaktır. . Ancak bu yaklaşım benim için çalışmaz çünkü üçüncü şahısların bu özel başlıkların eklenmesini bekler. Camel böyle bir şey:

from("jms:queue?selector=firstSelector") 
    .bean(dbSaver); 

from("jms:queue?selector=secondSelector") 
    .throttle(10) 
    .bean(httpClient); 

ikincisi başka iki JMS Kuyrukları ve bu sıralar arasında ileti bölecek bir işlemci yaratmaktır. Daha sonra ilk çözümdeki gibi aynı mantığı gider. Bununla birlikte, bu, 2 ekstra JMS sıralarının eklenmesi gerektiği anlamına gelir. Camel In: Ayrıca

from("jms:parentQueue") 
    .choice() 
     .when(body().contains(...)) 
      .to("jms:fistChildQueue") 
     .otherwise() 
      .to("jms:secondChildQueue") 
    .end() 

from("jms:fistChildQueue") 
    .bean(dbSaver); 

from("jms:secondChildQueue") 
    .throttle(10) 
    .bean(httpClient); 

, yerine JMS Kuyruklar iki bellek içi sıraları kullanmanın düşünüyordum. Ancak, bu durumda, JMS Kuyrukta çok sayıda mesaj olacaksa, bellekle ilgili sorunlara kolayca girebiliriz.

Bu kullanım durumu için mimari bir tasarım önerilebilir mi? Camel Route stilinde görmek harika olurdu.

Answer 1

1. DB'ye akış için bir kuyruğa gerçekten ihtiyacınız var mı? İlk rotada fasülye (dbSaver) olabilir veya jms tüketen bir rota yerine "doğrudan" bir rotaya aktarabilirsiniz. Bu şekilde, üç yerine iki sıra var.

2. İkinci bir yaklaşım: DB üzerinde denetiminiz varsa, ikinci bir ileti türünü farklı bir tabloya yazabilirsiniz. Ardından, bir sql-tüketici kayıtlar için anket yapabilir ve bunları tüketirken silebilir ve bunları http servisine iletebilir. Ancak, tablo bir "kendi Q'nuzu yuvarlayın" gibi davranıyor. Muhtemelen az geri ödeme için daha fazla iş, belki de ikinci bir sıra daha iyidir.

3. Son olarak, aynı Kuyruğu yeniden kullanıp kullanamayacağınızı merak ediyorum. Aynı sıraya yazmanıza izin verecek bir seçenek görüyorum. Bir başlık ekleyebilir ve belirli bir mesajı yazabilirsiniz. Bu kafa karıştırıcı olabilir ve bir böcek sonsuz bir döngü oluşturabilir.

Zaten JPA kullanıyorsanız, bu deve-jpa bileşenini kullanarak biraz daha kolay yapılabilir. Tüketici olarak, davranır ve kayıtları siler (varsayılan davranış). SQL/JDBC bileşenlerinin kutunun dışında bir şey olduğunu düşünmüyorum.