MuleSoft - ข้อมูลเบื้องต้นเกี่ยวกับ Mule ESB

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

การใช้ ESB

จุดสนใจหลักของสถาปัตยกรรม ESB คือการแยกระบบออกจากกันและอนุญาตให้สื่อสารกันได้อย่างมั่นคงและควบคุมได้ การใช้งาน ESB สามารถทำได้ด้วยความช่วยเหลือของ‘Bus’ และ ‘Adapter’ ด้วยวิธีต่อไปนี้ -

• แนวคิดของ“ บัส” ซึ่งทำได้ผ่านเซิร์ฟเวอร์รับส่งข้อความเช่น JMS หรือ AMQP ใช้เพื่อแยกแอปพลิเคชันที่แตกต่างกันออกจากกัน

• แนวคิดของ“ อะแดปเตอร์” ซึ่งรับผิดชอบในการสื่อสารกับแอปพลิเคชันแบ็กเอนด์และการแปลงข้อมูลจากรูปแบบแอปพลิเคชันเป็นรูปแบบบัสจะใช้ระหว่างแอปพลิเคชันและบัส

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

อะแด็ปเตอร์ยังสามารถดำเนินกิจกรรมอื่น ๆ เช่นการรักษาความปลอดภัยการตรวจสอบการจัดการข้อผิดพลาดและการจัดการเส้นทางข้อความ

หลักการชี้นำของ ESB

เราสามารถเรียกหลักการเหล่านี้ว่าหลักการรวมหลัก มีดังนี้ -

• Orchestration - การรวมบริการตั้งแต่สองบริการขึ้นไปเพื่อให้เกิดการซิงโครไนซ์ระหว่างข้อมูลและกระบวนการ

• Transformation - การแปลงข้อมูลจากรูปแบบบัญญัติเป็นรูปแบบเฉพาะของแอปพลิเคชัน

• Transportation - การจัดการการเจรจาโปรโตคอลระหว่างรูปแบบเช่น FTP, HTTP, JMS และอื่น ๆ

• Mediation - จัดหาอินเทอร์เฟซที่หลากหลายเพื่อรองรับบริการหลายเวอร์ชัน

• Non-functional consistency - จัดหากลไกในการจัดการธุรกรรมและความปลอดภัยด้วย

ความต้องการของ ESB

สถาปัตยกรรม ESB ช่วยให้เราสามารถรวมแอพพลิเคชั่นที่แตกต่างกันโดยที่แต่ละแอพพลิเคชั่นสามารถสื่อสารผ่านมันได้ ต่อไปนี้เป็นแนวทางบางประการเกี่ยวกับเวลาที่ควรใช้ ESB -

• Integrating two or more applications - การใช้สถาปัตยกรรม ESB มีประโยชน์เมื่อจำเป็นต้องผสานรวมบริการหรือแอปพลิเคชันตั้งแต่สองตัวขึ้นไป

• Integration of more applications in future - สมมติว่าหากเราต้องการเพิ่มบริการหรือแอพพลิเคชั่นเพิ่มเติมในอนาคตก็สามารถทำได้อย่างง่ายดายด้วยความช่วยเหลือของสถาปัตยกรรม ESB

• Using multiple protocols - ในกรณีที่เราจำเป็นต้องใช้หลายโปรโตคอลเช่น HTTP, FTP, JMS เป็นต้น ESB เป็นตัวเลือกที่เหมาะสม

• Message routing - เราสามารถใช้ ESB ในกรณีที่ต้องการการกำหนดเส้นทางข้อความตามเนื้อหาข้อความและพารามิเตอร์อื่น ๆ ที่คล้ายคลึงกัน

• Composition and consumption - ESB สามารถใช้ได้หากเราต้องการเผยแพร่บริการสำหรับการจัดองค์ประกอบและการบริโภค

การรวม P2P เทียบกับการรวม ESB

ด้วยจำนวนแอพพลิเคชั่นที่เพิ่มขึ้นคำถามใหญ่ต่อหน้านักพัฒนาคือจะเชื่อมต่อแอพพลิเคชั่นต่างๆได้อย่างไร? สถานการณ์ได้รับการจัดการโดยการเข้ารหัสการเชื่อมต่อระหว่างแอปพลิเคชันต่างๆ นี้เรียกว่าpoint-to-point integration.

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

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

สำหรับการจัดการการรวม ESB มีสององค์ประกอบดังต่อไปนี้ -

• Service Registry- Mule ESB มี Service Registry / Repository ซึ่งมีการเผยแพร่และลงทะเบียนบริการทั้งหมดที่เปิดเผยใน ESB ทำหน้าที่เป็นจุดค้นพบจากจุดที่สามารถใช้บริการและความสามารถของแอปพลิเคชันอื่น ๆ

• Centralized Administration - ตามความหมายของชื่อจะให้มุมมองของขั้นตอนการทำธุรกรรมของประสิทธิภาพของการโต้ตอบที่เกิดขึ้นภายใน ESB

ESB Functionality- โดยทั่วไปแล้วตัวย่อ VETRO จะใช้เพื่อสรุปการทำงานของ ESB มีดังต่อไปนี้ -

• V(ตรวจสอบความถูกต้อง) - ตามความหมายของชื่อมันจะตรวจสอบความถูกต้องของสคีมา ต้องใช้ตัวแยกวิเคราะห์ที่ตรวจสอบความถูกต้องและสคีมาที่ทันสมัย ตัวอย่างหนึ่งคือเอกสาร XML ที่ยืนยันถึงสคีมาที่เป็นปัจจุบัน

• E(Enrich) - เพิ่มข้อมูลเพิ่มเติมให้กับข้อความ วัตถุประสงค์คือเพื่อให้ข้อความมีความหมายและเป็นประโยชน์ต่อบริการเป้าหมายมากขึ้น

• T(Transform) - แปลงโครงสร้างข้อมูลเป็นรูปแบบที่ยอมรับหรือจากรูปแบบที่ยอมรับ ตัวอย่างเช่นการแปลงวันที่ / เวลาสกุลเงิน ฯลฯ

• R(การกำหนดเส้นทาง) - จะกำหนดเส้นทางข้อความและทำหน้าที่เป็นผู้เฝ้าประตูปลายทางของบริการ

• O(Operate) - งานหลักของฟังก์ชันนี้คือเรียกใช้บริการเป้าหมายหรือโต้ตอบกับแอปเป้าหมาย พวกเขาทำงานที่แบ็กเอนด์

รูปแบบ VETRO ให้ความยืดหยุ่นโดยรวมในการรวมและทำให้มั่นใจได้ว่าจะมีการกำหนดเส้นทางเฉพาะข้อมูลที่สอดคล้องกันและผ่านการตรวจสอบแล้วทั่วทั้ง ESB

Mule ESB คืออะไร?

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

• ฉบับชุมชน
• Enterprise Edition

ข้อได้เปรียบของ Mule ESB คือเราสามารถอัปเกรดจากชุมชน Mule ESB เป็น Mule ESB enterprise ได้อย่างง่ายดายเนื่องจากทั้งสองรุ่นสร้างขึ้นจากฐานรหัสทั่วไป

คุณสมบัติและความสามารถของ Mule ESB

คุณสมบัติต่อไปนี้ถูกครอบครองโดย Mule ESB -

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