Message Queue - Web Hizmetleri mi? [kapalı]

Hangi koşullar altında bir uygulama web hizmetleri yerine bir mesaj kuyruğu ile konuşmayı tercih eder (sadece XML veya JSON veya YAML veya burada HTTP üzerinden ne olursa olsun, belirli bir tür değil)?

Yerel bir ağdaki iki uygulama arasında konuşmam gerekiyor. Biri bir web uygulaması olacak ve başka bir uygulamada (farklı donanımlarda çalışan) komut istemek zorunda kalacak. İstekler, kullanıcı oluşturma, dosyaları taşıma ve dizin oluşturma gibi şeylerdir. Hangi koşullar altında XML Web Hizmetlerini (veya düz TCP veya başka bir şey) Message queue kullanmayı tercih ederim?

Web uygulaması Ruby on Rails, ancak sorunun bundan daha geniş olduğunu düşünüyorum.

Bir web hizmeti kullandığınızda bir istemciniz ve bir sunucunuz vardır:

1. Sunucu başarısız olursa, istemcinin hatayı işlemek için sorumluluk alması gerekir.
2. Sunucu tekrar çalışırken istemci yeniden göndermekten sorumludur.
3. Sunucu çağrıyı yanıtlar ve istemci başarısız olursa işlem kaybedilir.
4. Çekişmeniz yok, yani milyon istemci bir saniyede bir sunucuda bir web hizmetini çağırırsa, büyük olasılıkla sunucunuz kapanacaktır.
5. Sunucudan hemen bir yanıt bekleyebilirsiniz, ancak eşzamansız çağrıları da yönetebilirsiniz.

RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo gibi bir mesaj kuyruğu kullandığınızda farklı ve daha fazla hataya dayanıklı sonuçlar beklersiniz:

1. Sunucu başarısız olursa, kuyruk mesajı saklar (isteğe bağlı olarak, makine kapatılsa bile).
2. Sunucu tekrar çalışırken, bekleyen iletiyi alır.
3. Sunucu çağrıyı yanıtlarsa ve istemci başarısız olursa, istemci yanıtı kabul etmediyse ileti kalıcıdır.
4. Çekişmeniz var, sunucu tarafından kaç isteğin işleneceğine karar verebilirsiniz (bunun yerine çalışanı arayın).
5. Anında eşzamanlı bir yanıt beklemezsiniz, ancak eşzamanlı çağrıları uygulayabilir / simüle edebilirsiniz.

Message Queues çok daha fazla özelliğe sahiptir, ancak bu, hata koşullarını kendiniz halletmek mi yoksa mesaj kuyruğuna bırakmak mı istediğinize karar vermek için bazı temel kurallardır.

REST HTTP çağrılarının mesaj kuyruğu kavramının yerini nasıl alabileceğini dikkate alan son zamanlarda oldukça fazla araştırma yapılmıştır.

Bir süreç ve görev kavramını kaynak olarak tanıtırsanız, orta mesajlaşma katmanı ihtiyacı buharlaşmaya başlar.

Ör:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Bir görevin başlatma için birden fazla adımı olabilir ve bir işlem sorgulandığında durumu döndürebilir veya tamamlandığında geri arama URL'sine POST gönderebilir.

Bu çok basittir ve artık herhangi bir orta katman olmadan çalışan tüm işlemlerin ve görevlerin bir rss / atom beslemesine abone olabileceğinizi fark ettiğinizde oldukça güçlü hale gelir. Herhangi bir kuyruk sistemi yine de bir tür web ön uç gerektirecek ve bu kavram başka bir özel kod katmanı olmadan inşa etti.

Kaynaklarınız siz silene kadar var olur, yani işlem ve görev tamamlandıktan çok sonra geçmiş bilgilerini görüntüleyebilirsiniz.

Ekstra karmaşık protokoller olmadan birden fazla adımı olan bir görev için bile yerleşik hizmet keşfi yaptınız.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Hizmet keşfiniz bir HTML formudur - evrensel ve insan tarafından okunabilir bir biçim.

Tüm akış, evrensel olarak kabul edilen araçlar kullanılarak programlı olarak veya bir insan tarafından kullanılabilir. Bu bir müşteri odaklı ve bu nedenle RESTful. Web için oluşturulan her araç iş süreçlerinizi yönlendirebilir. Yine de ayrı bir günlük sunucusu dizisine eşzamansız POST yaparak alternatif mesaj kanallarınız var.

Bir süre düşündükten sonra arkanıza yaslanın ve REST'in bir mesajlaşma kuyruğu ve ESB'ye olan ihtiyacı tamamen ortadan kaldırabileceğini anlamaya başlıyorsunuz.

http://www.infoq.com/presentations/BPM-with-REST

İleti kuyrukları, işlenmesi uzun sürebilecek istekler için idealdir. İstekler kuyruğa alınır ve istemciyi engellemeden çevrimdışı olarak işlenebilir. İstemciye tamamlandığının bildirilmesi gerekiyorsa, istemcinin isteğin durumunu düzenli aralıklarla kontrol etmesini sağlayabilirsiniz.

Mesaj kuyrukları, zaman içinde daha iyi ölçeklendirmenize de olanak tanır. Gerçek işlem zaman içinde dağıtılabileceğinden, ağır aktivite patlamaları ile başa çıkma yeteneğinizi geliştirir.

İleti kuyruklarının ve web hizmetlerinin dikey kavramlar olduğunu, yani birbirlerini dışlamadıklarını unutmayın. Örneğin, mesaj kuyruğuna arayüz görevi gören XML tabanlı bir web servisine sahip olabilirsiniz. Aradığın ayrımın İstek / Yanıt'a karşı Mesaj Kuyrukları olduğunu, ikincisi talebin senkronize olarak işlendiği zamandır.

İleti kuyrukları eşzamansızdır ve dağıtım başarısız olursa birkaç kez yeniden deneyebilir. İstekte bulunanın yanıt beklemesi gerekmiyorsa bir ileti kuyruğu kullanın.

"Web hizmetleri" ifadesi, HTTP üzerinden dağıtılmış bir bileşene yapılan eşzamanlı çağrıları düşündürüyor. İstekte bulunan kişinin geri yanıt vermesi gerekiyorsa web hizmetlerini kullanın.

Genel olarak, engelleme görevi için bir web hizmeti (daha fazla kod çalıştırmadan önce bu görevlerin tamamlanması gerekir) ve engellemeyen bir görev için bir ileti kuyruğu (oldukça zaman alabilir, ancak beklemenize gerek yok).