ความแตกต่างระหว่าง Message Broker และ ESB

ฉันได้อ่านคำถาม / บทความต่างๆเกี่ยวกับ Message Brokers และ ESB แล้ว (แม้ใน stackoverflow) ยังไม่ทราบแน่ชัดว่า CLEAR แบ่งเขตความแตกต่างระหว่าง Message Broker และ ESB คืออะไร? ตอนนี้ฉันกำลังพยายามเปรียบเทียบผลิตภัณฑ์ Websphere Broker และ Mule ESB !!

ประการแรก Webshere Broker เป็น ESB หรือไม่? พวกผลิตภัณฑ์ IBM ของเราอ้างว่าเป็น ESB! (ฉันไม่แปลกใจเลย)

ข้อมูลที่ จำกัด ของฉันบอกฉันว่า Message Broker ทำงานในรูปแบบ HUB-SPOKE อย่างไรก็ตาม ESB ทำงานบนสถาปัตยกรรมบัส ตอนนี้มันหมายความว่าอะไรบนโลก? ฉันได้อ่านแล้วว่า HUB ล้มเหลว (ไม่สามารถใช้งานได้ฉันเดาว่า) นายหน้าก็ล้มเหลวโดยสิ้นเชิง ซึ่งไม่ใช่กรณีของ ESB (คนพวกนั้นพูด) สิ่งที่ฉันไม่เข้าใจในที่นี้คือ "จะเกิดอะไรขึ้นถ้ารถบัส" ล้มเหลว?

ตอนนี้สิ่งที่ปกติเกี่ยวกับ ESB และโบรกเกอร์ก็คือพวกเขามีการกำหนดเส้นทางการเปลี่ยนแปลงการจัดระเบียบและอื่น ๆ ดังนั้นหากทั้งสองคนให้สิ่งนี้ทำไมฉันถึงเลือกอย่างใดอย่างหนึ่ง

อีกประเด็นหนึ่งของความขัดแย้งคือเรื่องของการเปลี่ยนแปลง ESB ช่วยอำนวยความสะดวกในลักษณะที่แตกต่างออกไปเมื่อเทียบกับ Message Brokers หรือไม่? ฉันชอบความเข้าใจบางอย่างเกี่ยวกับเรื่องนี้จริงๆ

ตอนนี้พูดถึง HORIZONTAL scaling ใครทำได้ดีกว่าใคร หรือทั้งสองอย่างสามารถปรับขนาดได้เท่า ๆ กันในแง่ของความซับซ้อน (หรือปัจจัยอื่น ๆ ) แน่นอนต้นทุนที่ชาญฉลาด Webshpere Broker จะเรียกเก็บเงินจากคุณสำหรับแต่ละกล่อง (นับประสาอะไรกับ CPU แต่ละตัว) ฉันเชื่อว่าแม้แต่ MULE ESB เชิงพาณิชย์ก็ไม่ทำเช่นนั้น ทิ้งส่วนต้นทุนไว้แล้วผลกระทบของการปรับ ESB และการปรับขนาดของนายหน้าข้อความคืออะไร ฉันรู้ว่าคุณสามารถปรับขนาดได้ถึงระดับบริการใน ESB เป็นไปได้ใน Message Broker หรือไม่?

คุณสามารถใช้นายหน้าแปลงร่างได้โดยไม่ต้องใช้รถบริการและในทางกลับกัน ในแง่ของผลิตภัณฑ์ที่เฉพาะเจาะจงฉันไม่คิดว่าผลิตภัณฑ์ใดชิ้นหนึ่งเป็นผลิตภัณฑ์อย่างใดอย่างหนึ่งอย่างแท้จริงเนื่องจากวิธีการที่แต่ละผลิตภัณฑ์เสริมกัน ผลิตภัณฑ์บางอย่างแข็งแกร่งกว่าในด้านหนึ่งและอีกด้านหนึ่งแข็งแกร่งกว่า บางทีอาจต้องเลือกโดยพิจารณาจากฟังก์ชันที่ครอบคลุมปัญหาแต่ละปัญหาได้ดีที่สุด

นายหน้าอาจมี "บล็อกเลโก้" ในตัวที่ดีกว่าสำหรับการสร้างห่วงโซ่การเปลี่ยนแปลงมากกว่าผลิตภัณฑ์ ESB นายหน้ากดเข้าสู่บริการเนื่องจาก ESB อาจถูกบดขยี้ภายใต้ภาระงานและไม่ได้ขนาดที่ดีหรืออาจขาดการบันทึกและเครื่องมือที่มีประสิทธิภาพสำหรับจัดการกับวารสาร

ESB บางตัวอนุญาตให้ย้อนกลับการอัปเดตฐานข้อมูลและคิวที่จะเล่นซ้ำในแอปพลิเคชันที่ได้รับการแก้ไขเมื่อมีการค้นพบและแก้ไขข้อผิดพลาดร้ายแรงในตรรกะ ฉันไม่คิดว่าโบรกเกอร์ส่วนใหญ่จะรวมการสนับสนุนธุรกรรมในระดับนั้นเข้าด้วยกัน เพื่อให้สามารถใช้งานได้กับ "ธุรกรรม" ทั้งหมดของคุณเกือบจะต้องเป็นกิจกรรมทางธุรกิจ (การขายการต่ออายุการเปลี่ยนความเป็นเจ้าของ ฯลฯ ) แทนที่จะเป็น "การอัปเดตฐานข้อมูล" ของ RPCish

ข้อจำกัดความรับผิดชอบ: ฉันเป็นที่ปรึกษาของ IBM และเชี่ยวชาญด้าน WebSphere ESB ความคิดเห็นนี้ไม่เหลืออยู่ในความสามารถอย่างเป็นทางการใด ๆ

ESB เป็นรูปแบบหรือแนวคิดทางสถาปัตยกรรมมากกว่าผลิตภัณฑ์ - โดยทั่วไปแล้วเป็นวิธีการเชื่อมต่อแบบหลวมทางวิศวกรรมตามบริการ นิยามของมันคือการต่อสู้และไม่ได้ตั้งอยู่ในหิน โดยทั่วไป ESB เป็นชุดของบริการที่ไม่เกี่ยวข้อง (ในแง่เทคนิค) - พวกเขาเปิดเผยอินเทอร์เฟซและใช้งานจากบริการอื่น ๆ โดยทั่วไปจะไม่มีฮับและสถาปัตยกรรมแบบพูดที่เกี่ยวข้องแม้ว่าจะมี

IBM ทำตลาดทั้ง WebSphere Message Broker และ WebSphere ESB เป็นผลิตภัณฑ์ที่ช่วยให้สร้าง ESB ได้ง่าย (พร้อมกับอุปกรณ์ฮาร์ดแวร์ DataPower) พวกเขามีรากฐานทางเทคโนโลยีที่แตกต่างกัน แต่มีจุดประสงค์บางอย่างที่ทับซ้อนกัน นอกจากนี้ไม่ได้หมายความว่าคุณไม่สามารถสร้าง ESB ด้วยสิ่งอื่น ๆ อีกมากมายที่ไม่ได้ระบุว่าเป็น 'ผลิตภัณฑ์ ESB'

นั่นไม่ได้ตอบทุกคำถามของคุณ แต่หวังว่าจะตอบโจทย์ในส่วนของ IBM

ความแตกต่างระหว่าง Message Broker และ ESB (Enterprise Service Bus) ส่วนใหญ่คือคำว่า 'bus'

สำหรับฉัน Message Broker เป็นกระบวนการหนึ่ง (ใหญ่ตามปกติ) ที่แปลงข้อมูลจากโครงสร้างหนึ่งไปเป็นโครงสร้างอื่นหรือปรับเปลี่ยนเนื้อหา

ESB คือตัวกลางที่เน้นข้อความ (MOM) พร้อมบริการเพิ่มเติมซึ่งหนึ่งในนั้นอาจเป็น Message Broker ดังนั้น ESB จึงสามารถรวม Message Broker เป็นหนึ่งในองค์ประกอบได้ รถบัสประกอบด้วยกระบวนการมากกว่าหนึ่งกระบวนการมิฉะนั้นฉันจะไม่เรียกมันว่า 'รถบัส' ลักษณะของบัสคือมีส่วนประกอบหลายอย่างที่ให้บริการงานที่แตกต่างกันแต่ละส่วนสื่อสารผ่าน MOM และยึดตาม 'รูปแบบข้อมูลทั่วไป' บางรูปแบบ บัสจะประกอบด้วย: แอปพลิเคชันที่ส่งข้อมูลไปยัง MOM, อะแดปเตอร์ฐานข้อมูล, โบรกเกอร์ข้อความ, สะพาน MOM เป็นต้น

แยกเป็นบิตค่อยเป็นค่อยไป แต่แตกต่างที่ใหญ่ที่สุดระหว่างสถาปัตยกรรมข้อความนายหน้าและรถประจำทางเป็นที่ของเมล็ด หากงานของคุณคือการรวมแอปพลิเคชัน A, B, .. , Z และฐานข้อมูลสองสามฐานข้อมูลคุณสามารถทำได้โดยใช้ Message Broker ขนาดใหญ่เพียงตัวเดียวที่เชื่อมต่อแต่ละคนและทุกคน หรือด้วย ESB ที่มีส่วนประกอบขนาดเล็กจำนวนมากเข้ามาแทนที่งานเล็ก ๆ น้อย ๆ ตัวอย่างเช่นอะแดปเตอร์ตัวหนึ่งเชื่อมต่อกับ A อีกตัวหนึ่งไปยัง B (แต่ไม่ได้ทำการแปลง) จากนั้นแต่ละตัวจะส่งข้อมูลของพวกเขาไปยังนายหน้าข้อความหนึ่ง (หรือมากกว่า) ซึ่งแต่ละตัวควรเก็บไว้ให้ง่ายที่สุด - เช่นไม่ ต้องรู้เกี่ยวกับโมเดลข้อมูลของ 'A' หรือ 'B' ESB ที่ดีควรมีนิยามข้อมูลทั่วไปบนบัสโดยแยกออกจาก 'ความแตกต่าง' ของแต่ละแอปพลิเคชัน

การแปลง: ESB ไม่ได้ช่วยในการเปลี่ยนแปลงเว้นแต่จะมาพร้อมกับ Message Broker แต่ ESB ที่ดีควรมี Message Broker ด้วย นายหน้าข้อความควรเป็นผู้เชี่ยวชาญด้านการเปลี่ยนแปลงของรถบัสของคุณ แต่ไม่มีอะไรอื่น

การปรับขนาดแนวนอน: หากคุณมีเพียง 3 สิ่งที่ต้องเชื่อมต่อ (ตอนนี้และตลอดไป) อาจไม่คุ้มค่ากับความพยายามที่จะได้ ESB แบบเต็มรูปแบบ นายหน้าข้อความมีข้อได้เปรียบในการเป็นเพียงกระบวนการใหญ่ขั้นตอนเดียว คุณสามารถกำหนดค่าทุกอย่างในนั้นและมีตำแหน่งศูนย์กลางสำหรับการแมปข้อมูลการกรองและการกำหนดเส้นทางทั้งหมดของคุณ

แต่ถ้าคุณมีแอปพลิเคชั่น 30 ตัวในการเชื่อมต่อ Message Broker คนหนึ่งอาจจะหยุดชะงัก แน่นอนว่าคุณสามารถซื้ออินสแตนซ์เพิ่มขึ้นเรียกใช้งานซ้ำซ้อน ฯลฯ แต่คุณควรเปลี่ยนกลยุทธ์เป็นงานแบบ 'โลคัลไลซ์' อะแด็ปเตอร์ของแต่ละแอปพลิเคชัน (อาจเป็นอินสแตนซ์ Message Broker เล็ก ๆ หนึ่งรายการต่อหนึ่งรายการ) ควรสามารถสร้างและ / หรือรับโมเดลข้อมูลทั่วไปที่เป็นนามธรรม (เช่น XML พร้อม XSD ที่ใช้ร่วมกัน) นอกจากนี้ยังอาจมี Message Broker กลางสำหรับงานการเปลี่ยนแปลง แต่อินสแตนซ์นั้นควรไม่ทราบถึงโมเดลข้อมูล A หรือ B ดังนั้น ESB ควรย้ายการประมวลผลไปยังองค์ประกอบของผู้เชี่ยวชาญแทนที่จะเก็บทุกอย่างไว้ที่ส่วนกลาง

ฉันเพิ่งอ่านบทความนี้โดย Udi Dahan เมื่อไม่กี่วันก่อนซึ่งอาจทำให้คุณมีมุมมองที่ชัดเจนยิ่งขึ้นว่าสิ่งที่ฉันรู้สึกว่าเป็นความแตกต่างพื้นฐานอย่างหนึ่ง

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

พิเศษ:

กฎที่ว่าสามารถมีผู้เผยแพร่เพียงรายเดียวสำหรับประเภทเหตุการณ์ที่กำหนดเป็นหนึ่งในสิ่งที่ทำให้รถเมล์แตกต่างจากโบรกเกอร์แม้ว่าทั้งสองอย่างจะทำให้คุณมีสมาชิกได้หลายคน

...

น่าเสียดายที่มีเทคโนโลยีรูปแบบนายหน้ามากมายที่วางตลาดภายใต้แบนเนอร์ของ Enterprise Service Bus แม้ว่าผลิตภัณฑ์บางอย่างจะมีความสามารถในการปรับใช้ทั้งแบบรวมศูนย์และแบบกระจาย (บางครั้งเรียกว่าโหมด "รวมศูนย์" หรือ "ฝังตัว") แต่หลายผลิตภัณฑ์ไม่บังคับใช้กฎ "ปลายทางการเผยแพร่เดียวต่อประเภทเหตุการณ์"

หากไม่มีข้อ จำกัด นี้ก็ง่ายเกินไปที่จะทำผิดพลาด

หวังว่าจะช่วยได้

Enterprise Service Bus ให้ค่าหลักสามค่าแก่ธุรกิจ:

1. การกำหนดเส้นทางธุรกรรมตามบริบทหรือเนื้อหา
2. การแปลงจากโดเมนข้อความหนึ่งหรือส่งไปยังโดเมนข้อความหรือการขนส่งอื่น
3. การเชื่อมต่อบริการหลายต่อหลายบริการ

ESB ให้บริการที่มีการเชื่อมต่อแบบหลวม ๆ อนุญาตให้สร้างบริการขึ้นใหม่ในบริบทของแอปพลิเคชันที่แตกต่างไปจากเดิมอย่างสิ้นเชิงเมื่อเทียบกับบริการที่ได้รับการคาดการณ์หรือพัฒนาขึ้นเป็นครั้งแรกและส่งเสริมการนำแอปพลิเคชันกลับมาใช้ใหม่โดยไม่จำเป็นต้องเขียนโปรแกรมใหม่ WebSphere Message Broker (หรือปัจจุบันเรียกว่า IBM Integration Bus) เป็นตัวอย่างเฉพาะของ Enterprise Service Bus สำหรับตัวอย่างความเรียบง่ายของโค้ดที่นำมาซึ่งพลังอันยิ่งใหญ่ในไม่กี่บรรทัดคุณสามารถดูโพสต์ของฉันได้ที่นี่: http://soabus.org/viewtopic.php?f=3&t=13 http://soabus.org/viewtopic.php?f=3&t=13โครงสร้างพื้นฐานภายในรันไทม์ IIB เรียกว่าLogical Message Tree(LMT) ทุกสิ่งที่นักพัฒนาต้องการทำคือการดำเนินการบางอย่างใน LMT ESQL เป็นภาษาที่มีประสิทธิภาพสูงสุดที่นักพัฒนาสามารถใช้เพื่อดำเนินการเหล่านี้บน LMT แม้ว่าจะรองรับภาษาอื่น ๆ อีกมากมาย (เช่น Java, PHP, Python เป็นต้น) ไม่มีผลิตภัณฑ์อื่นใดที่ใกล้เคียงกับประสิทธิภาพและความง่ายในการพัฒนา ESB แอ็พพลิเคชันมากกว่า IBM Integration Bus เนื่องจาก 90 เปอร์เซ็นต์ของการเข้ารหัสของแอ็พพลิเคชันเหล่านี้ทำได้โดยการลากและวางโหนดลงบนพาเลท ซึ่งทำให้นักพัฒนา Message Flow ทำได้เพียง 10 เปอร์เซ็นต์เท่านั้น อย่างไรก็ตาม WebSphere ESB ได้ถูกยกเลิกโดย IBM และผลิตภัณฑ์คู่แข่งจำนวนมากไปยัง IBM Integration Bus ไม่ได้เห็นการพัฒนาใหม่ใด ๆ มาเป็นเวลาหลายปีแล้ว สามารถดูรายการข้อเสนอผลิตภัณฑ์ ESB ต่างๆได้ที่ soabus.org

ตั้งแต่นั้นมา IBM ได้เปลี่ยนชื่อข้อเสนอ ESB ดังนั้นฉันจะไม่เข้าไปในชื่อหรือผู้ขาย

ESB ช่วยให้ข้อมูลทางธุรกิจไหลไปมาระหว่างแอปพลิเคชันที่แตกต่างกันในแพลตฟอร์มฮาร์ดแวร์และซอฟต์แวร์ต่างๆ ESB เป็นเลเยอร์มิดเดิลแวร์ที่มีลอจิกการเชื่อมต่อแอพพลิเคชั่นและตรรกะทางธุรกิจน้อยที่สุดถึงไม่มี สิ่งนี้ช่วยให้แอปพลิเคชันสามารถทำสิ่งที่ทำได้ดีที่สุดโดยไม่ต้องกังวลเกี่ยวกับการฝังลอจิกการเชื่อมต่อใด ๆ เกี่ยวกับวิธีการโต้ตอบกับแอปพลิเคชัน N จำนวนอื่นที่ต้องการข้อมูลจากแอปพลิเคชัน สถาปัตยกรรม ESB พยายามแก้ปัญหาสปาเก็ตตี้ในองค์กร

ESB และ Message Broker เป็นคำพ้องความหมายซึ่งกันและกันอย่างไรก็ตามจากคำตอบด้านบนได้เน้นว่ารูปแบบนายหน้าข้อความเป็นส่วนหนึ่งของโดเมน ESB ที่ใหญ่กว่า ตัวอักษร "B" ใน ESB นั้นคล้ายคลึงกับบัส (ฮาร์ดแวร์) ในสถาปัตยกรรมคอมพิวเตอร์ บัสบนแผงวงจรหลักหรือในคอมพิวเตอร์จะเชื่อมต่อส่วนประกอบต่างๆสำหรับการทำงานของคอมพิวเตอร์ ESB เป็นบัสที่ใช้ซอฟต์แวร์ที่เชื่อมต่อบริการต่างๆในองค์กร Hub and Spoke เป็นหนึ่งในรูปแบบที่รองรับโดยสถาปัตยกรรม ESB ในโลกเสาหินผู้ขายแต่ละรายมีสถาปัตยกรรมการปรับใช้ความพร้อมใช้งานสูงของตนเองเพื่อให้แน่ใจว่า ESB พร้อมใช้งาน ข้อเสนอล่าสุดของผู้จำหน่าย ESB ใด ๆ อยู่ในรูปแบบการปรับใช้ตามไมโครเซอร์วิสหรือโฮสต์ในระบบคลาวด์ของตนเองที่เรียกว่า iPAAS ดังนั้นจึงมั่นใจได้ว่า Bus จะไม่ล้มเหลวหรือล้มเหลวชั่วคราวด้วยการรักษาตัวเองตามโมเดลการปรับใช้ที่คุณเลือก ด้วยการใช้งานแบบไมโครเซอร์วิสหรือ iPAAS ขณะนี้ ESB มีความสามารถในการปรับขนาดอัตโนมัติ (แนวนอนหรือแนวตั้ง) พร้อมคุณสมบัติที่แตกต่างกันไปตามผู้จำหน่ายที่เลือก

สำหรับความสามารถระดับสูงที่ ESB มีให้คุณสามารถไปที่ลิงค์ต่อไปนี้ => https://en.wikipedia.org/wiki/Enterprise_service_bus