ESB คืออะไรและมีประโยชน์อย่างไร?

ในงานก่อนหน้านี้มีการพูดถึง "Enterprise Service Bus" (ESB) มากมาย ฉันอ่านบางส่วนของหนังสือแนวความคิดเกี่ยวกับเรื่องนี้ แต่ไม่เคยเข้าใจจริงๆว่าคุณจะนำไปใช้ / บูรณาการอย่างไรให้เป็นรูปธรรม ฉันคุ้นเคยกับ SOA / queuing / directory services / etc แต่ฉันไม่เข้าใจว่า ESB คืออะไร

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

คำอธิบายหรือลิงก์ไปยังตัวอย่างที่ดีจะได้รับการชื่นชมอย่างมาก ขอบคุณ.

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

ซึ่งอาจรวมถึงการไกล่เกลี่ยเพื่อกระทบยอดโปรโตคอลข้อมูลและการโต้ตอบที่เข้ากันไม่ได้

แนวคิดของรถบัสกลางที่ทุกอย่างผ่านไปเปิดโอกาสให้มีชั้นนามธรรมเพิ่มเติม การใช้มาตรฐานอุตสาหกรรมเพื่อ "เสียบ" แอปพลิเคชันไคลเอนต์และอื่น ๆ เข้ากับบัสนี้ทำให้การเชื่อมต่อบริการใหม่แหล่งข้อมูลไคลเอนต์ที่มีความต้องการแตกต่างกันทำได้ค่อนข้างง่าย

การใช้งานจริง

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

ความคล้ายคลึงกับอินเทอร์เน็ต

บัสสื่อสารขนาดใหญ่หนึ่งบัสที่มีการใช้งานและข้อมูลที่แตกต่างกันอย่างกว้างขวาง แต่ทั้งหมดใช้โปรโตคอลมาตรฐาน

ในความเป็นจริงเราสามารถเขียนตัวเชื่อมต่อ HTTP เป็น FTP ที่อนุญาตให้เบราว์เซอร์เข้าถึงไซต์ FTP โดยไม่ต้องเรียกใช้ไคลเอนต์ FTP

Mashups

Mashups แสดงให้เห็นถึงการใช้งานที่น่าสนใจ - ใช้ข้อมูลเส้นทางรถประจำทางจากหน่วยงานในซานฟรานซิสโกแผนที่จาก Google และตำแหน่งของซูชิบาร์จาก yahoo พร้อมการให้คะแนนและเรียกใช้ข้อความค้นหาง่ายๆที่ให้ซูชิบาร์ที่ใกล้ที่สุดโดยให้น้ำหนักกับคุณเพื่อให้คุณเป็น ยินดีที่จะเดินทางต่อไปอีกเล็กน้อยเพื่อบาร์ที่ดีกว่า

บริการที่แตกต่างกันโดยสิ้นเชิงไม่สามารถใช้ร่วมกันได้ด้วยตัวเอง แต่ใช้ตัวเชื่อมต่อมาตรฐาน (เช่นท่อ yahoo) สามารถดึงเข้าด้วยกันเป็นส่วนที่เหนียวและเป็นประโยชน์

- อดัม

ข้อจำกัดความรับผิดชอบ: ฉันทำงานให้กับ IBM และปรึกษาเกี่ยวกับ WebSphere ESB ซึ่งเป็นผลิตภัณฑ์ของ IBM ที่ออกแบบมาเพื่อสร้าง ESB ด้วย ต่อไปนี้เป็นความคิดเห็นของฉันและไม่จำเป็นต้องสะท้อนถึงจุดยืนของ IBM

ESB เป็นสิ่งที่แตกต่างกันสำหรับคนอื่น ๆ

สำหรับฉัน ESB เป็นเทคโนโลยีใด ๆ ที่คุณสามารถแทรกลงใน SOA (Service-Oriented Architecture) ช่วยให้คุณสามารถเชื่อมต่อระบบที่แตกต่างกันเข้าด้วยกัน มันมักจะทำหน้าที่ของการแปลงโปรโตคอลการแก้ไขข้อความการกำหนดเส้นทางการบันทึกทำหน้าที่เป็นเกตเวย์ความปลอดภัยและอื่น ๆ ตัวอย่างเช่นคุณอาจใช้ ESB เพื่อแสดงบริการที่ก่อนหน้านี้มีให้บริการในรูปแบบ Web Service เป็นบริการที่ใช้ JMS เช่นกัน

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

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

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

IMHO ควรใช้การสร้างอินเทอร์เฟซเฉพาะจำนวนเล็กน้อยโดยทั่วไปจะใช้บริการเว็บระหว่างระบบที่ต้องการเท่านั้น

โดยพื้นฐานแล้วเป็นวิธีแนวคิดในการออกแบบระบบ - บริษัท ซอฟต์แวร์พยายามขายคุณให้มากขึ้นโดยติดสติกเกอร์ 'ESB' ไว้และผู้จัดการชอบเพราะ ESB ดูดีจาก 'ระดับที่สูงขึ้น'

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

ตัวอย่าง: สมมติว่าคุณต้องการเชื่อมต่อแอปพลิเคชัน A กับแอปพลิเคชัน B ในมิดเดิลแวร์ที่เน้นข้อความมาตรฐานลองใช้ JMS คุณพูดคุยกับเพื่อนร่วมงานของคุณที่ทำงานเกี่ยวกับแอปพลิเคชัน B ตกลงในหัวข้อประเภทข้อความและฟิลด์แล้วส่ง (รหัสหลอก): sendJms ("TRADE.MSFT", {MapMessage trader = "pete" price = 101.4 vol = 100})

หากคุณทำสิ่งเดียวกันในสถาปัตยกรรมที่มุ่งเน้นการบริการคุณต้อง

1. ติดตั้งซอฟต์แวร์เพิ่มเติม
2. เรียนรู้แนวคิดใหม่ ๆ มากมาย
3. กำหนดคอมโพเนนต์ Java ใหม่ของคุณในคู่มือผู้ดูแลระบบของ ESB
4. ใช้อินเทอร์เฟซบางอย่างที่ควบคุมโดย ESB
5. sendJms (getDestination (), {MapMessage trader = "pete" price = 101.4 vol = 100}) - สังเกตว่าปลายทางถูกฉีดจาก ESB

ครั้งแรกมันอาจจะเจ็บหน่อย แต่ฉันเดาว่าคุณคงชินเหมือนกับที่คุณเคยชินกับ EJB ;-)

คุณสามารถพูดได้ว่าระบบ MOM 'ไม่ได้พิมพ์' (โครงสร้างแบบไดนามิก) ในขณะที่ ESB ถูก 'พิมพ์' (โครงสร้างคงที่) การแลกเปลี่ยนระหว่างการส่งข้อความดิบกับ ESB นั้นคล้ายกับตัวเลือกที่ไม่ได้พิมพ์ / พิมพ์อื่น ๆ :

• REST กับ SOAP
• XML ที่ไม่ผ่านการตรวจสอบเทียบกับ XML ที่ตรวจสอบด้วย XSD
• Groovy กับ Java
• ภาษาที่ตีความเทียบกับภาษาที่รวบรวม

สำหรับโปรเจ็กต์ขนาดเล็กมันเป็นการดีที่จะแฮชฟังก์ชันการทำงานอย่างรวดเร็ว (เช่น Groovy code) แต่สำหรับโปรเจ็กต์ขนาดใหญ่ควรมีดีบักเกอร์ (เช่น Java) เพื่อเตือนล่วงหน้าเมื่อสิ่งต่างๆพังและมีมาตรฐานสำหรับคนก่อนกระทำกับ โครงการ.

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

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

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

ฉันคิดว่าชัดเจนที่สุดเท่าที่จะทำได้ ... หวังว่าจะช่วยได้

ดูงานนำเสนอของฉัน " Spoiled for Choice - วิธีเลือก ESB ที่เหมาะสม "

ฉันอธิบายว่าเมื่อใดควรใช้ ESB, Integration Suite หรือเพียงแค่ Integration Framework (เช่น Apache Camel) ฉันยังพูดถึงความแตกต่างระหว่างโอเพ่นซอร์สและ ESB ที่เป็นกรรมสิทธิ์

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

อย่างไรก็ตามมันค่อนข้างแพงซับซ้อนและไม่สะดวกในการบำรุงรักษาและขยายซึ่งทำให้เป็นตัวเลือกเทคโนโลยีที่ไม่ดีในฐานะเครื่องมือวัตถุประสงค์ทั่วไปสำหรับการปรับขนาดแอปพลิเคชันของคุณ