ภายใต้เงื่อนไขใดที่ผู้ใช้จะชื่นชอบแอปที่พูดคุยผ่านคิวข้อความแทนที่จะใช้บริการบนเว็บ (ฉันแค่หมายถึง XML หรือ JSON หรือ YAML หรืออะไรก็ตามผ่าน HTTP ที่นี่ไม่ใช่ประเภทเฉพาะ)
ฉันต้องพูดคุยระหว่างสองแอพในเครือข่ายท้องถิ่น หนึ่งจะเป็นเว็บแอปและต้องขอคำสั่งในแอปอื่น การร้องขอคือสิ่งต่าง ๆ เช่นการสร้างผู้ใช้การย้ายไฟล์ไปรอบ ๆ และการสร้างไดเรกทอรี ภายใต้เงื่อนไขใดที่ฉันต้องการให้ XML Web Services (หรือตรง TCP หรือบางอย่าง) เพื่อใช้คิวข้อความ
เว็บแอพคือ Ruby on Rails แต่ฉันคิดว่าคำถามนั้นกว้างกว่านั้น
คำตอบ:
เมื่อคุณใช้บริการเว็บคุณมีไคลเอนต์และเซิร์ฟเวอร์:
เมื่อคุณใช้คิวข้อความเช่น RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo คุณคาดหวังผลลัพธ์ที่แตกต่างกันและมีความผิดพลาดมากกว่า:
Message Queues มีคุณสมบัติมากขึ้น แต่นี่เป็นกฎง่ายๆในการตัดสินใจว่าคุณต้องการจัดการกับเงื่อนไขข้อผิดพลาดด้วยตนเองหรือปล่อยให้อยู่ในคิวข้อความ
มีงานวิจัยล่าสุดจำนวนพอสมควรเมื่อพิจารณาว่าการโทร REST HTTP สามารถแทนที่แนวคิดคิวข้อความได้อย่างไร
หากคุณแนะนำแนวคิดของกระบวนการและงานในฐานะทรัพยากรความต้องการเลเยอร์การส่งข้อความกลางจะเริ่มหายไป
Ex:
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
งานสามารถมีหลายขั้นตอนในการเริ่มต้นและกระบวนการสามารถคืนสถานะเมื่อโพลหรือ POST ไปยัง URL ที่เรียกกลับเมื่อเสร็จสมบูรณ์
สิ่งนี้ง่ายมากและมีประสิทธิภาพมากเมื่อคุณทราบว่าตอนนี้คุณสามารถสมัครรับฟีด rss / atom ของกระบวนการและงานทั้งหมดที่รันอยู่โดยไม่มีเลเยอร์กลางใด ๆ ระบบการจัดคิวใด ๆ จะต้องมีส่วนหน้าของเว็บอยู่บ้างและแนวคิดนี้สร้างขึ้นโดยไม่มีโค้ดที่กำหนดเองอีกเลเยอร์
ทรัพยากรของคุณมีอยู่จนกว่าคุณจะลบพวกเขาซึ่งหมายความว่าคุณสามารถดูข้อมูลประวัติหลังจากกระบวนการและงานเสร็จสมบูรณ์
คุณได้สร้างในการค้นหาบริการแม้กระทั่งสำหรับงานที่มีหลายขั้นตอนโดยไม่มีโปรโตคอลที่ซับซ้อนเป็นพิเศษ
GET /task/name
- returns form with required fields
POST (URL provided form's "action" attribute)
การค้นพบบริการของคุณเป็นรูปแบบ HTML ซึ่งเป็นรูปแบบที่เป็นสากลและมนุษย์สามารถอ่านได้
โฟลว์ทั้งหมดสามารถใช้โดยโปรแกรมหรือโดยมนุษย์โดยใช้เครื่องมือที่ได้รับการยอมรับในระดับสากล มันเป็นไคลเอนต์ขับเคลื่อนและสงบดังนั้น เครื่องมือทุกอย่างที่สร้างขึ้นสำหรับเว็บสามารถขับเคลื่อนกระบวนการทางธุรกิจของคุณ คุณยังคงมีแชนเนลข้อความสำรองโดย POSTing แบบอะซิงโครนัสกับอาร์เรย์ของเซิร์ฟเวอร์บันทึกแยกต่างหาก
หลังจากที่คุณพิจารณามาระยะหนึ่งแล้วคุณก็จะนั่งลงและเริ่มตระหนักว่า REST อาจกำจัดความต้องการคิวการส่งข้อความและ ESB ไปด้วยกัน
คิวข้อความเหมาะสำหรับคำร้องขอซึ่งอาจใช้เวลานานในการประมวลผล คำขอถูกเข้าคิวและสามารถประมวลผลออฟไลน์ได้โดยไม่ปิดกั้นไคลเอนต์ หากลูกค้าจำเป็นต้องได้รับแจ้งการเสร็จสิ้นคุณสามารถกำหนดวิธีให้ลูกค้าตรวจสอบสถานะของการร้องขอเป็นระยะ
คิวข้อความยังช่วยให้คุณปรับขนาดได้ดีขึ้นเมื่อเวลาผ่านไป ช่วยเพิ่มความสามารถของคุณในการรับมือกับกิจกรรมที่หนักหน่วงเนื่องจากการประมวลผลที่แท้จริงสามารถกระจายข้ามเวลาได้
โปรดทราบว่าคิวข้อความและบริการบนเว็บเป็นแนวคิดมุมฉากนั่นคือพวกเขาไม่ได้เป็นเอกสิทธิ์เฉพาะบุคคลร่วมกัน เช่นคุณสามารถใช้บริการบนเว็บ XML ซึ่งทำหน้าที่เป็นส่วนต่อประสานกับคิวข้อความ ฉันคิดว่าความแตกต่างที่คุณมองหาคือ Message Queues เทียบกับ Request / Response ซึ่งหลังคือเมื่อคำขอถูกประมวลผลพร้อมกัน
คิวข้อความแบบอะซิงโครนัสและสามารถลองซ้ำหลายครั้งหากการส่งล้มเหลว ใช้คิวข้อความหากผู้ร้องขอไม่จำเป็นต้องรอการตอบกลับ
วลี "บริการบนเว็บ" ทำให้ฉันคิดถึงการโทรแบบซิงโครนัสไปยังคอมโพเนนต์แบบกระจายผ่าน HTTP ใช้บริการเว็บหากผู้ร้องขอต้องการการตอบกลับ
โดยทั่วไปฉันคิดว่าคุณต้องการบริการเว็บสำหรับงานการบล็อก (งานนี้ต้องทำให้เสร็จก่อนที่เราจะเรียกใช้โค้ดเพิ่มเติม) และคิวข้อความสำหรับงานที่ไม่ได้บล็อก (อาจใช้เวลาสักครู่ แต่เราไม่ต้องการ ไม่ต้องรอ)