MuleSoft - โครงการล่อ

แรงจูงใจที่อยู่เบื้องหลังโครงการล่อคือ -

• เพื่อทำให้สิ่งต่างๆง่ายขึ้นสำหรับโปรแกรมเมอร์

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

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

ประวัติศาสตร์

มุมมองทางประวัติศาสตร์ของโครงการล่อมีดังนี้ -

โครงการ SourceForge

โครงการ Mule เริ่มต้นในฐานะโครงการ SourceForge ในเดือนเมษายน พ.ศ. 2546 และหลังจากนั้น 2 ปีก็มีการเผยแพร่เวอร์ชันแรกและย้ายไปที่ CodeHaus Universal Message Object (UMO) API เป็นหัวใจหลักของสถาปัตยกรรม แนวคิดเบื้องหลัง UMO API คือการรวมตรรกะในขณะที่แยกพวกมันออกจากการขนส่งพื้นฐาน

เวอร์ชัน 1.0.6

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

เวอร์ชัน 2.0 (การยอมรับ Spring 2)

Spring 2 เป็นเฟรมเวิร์กการกำหนดค่าและการเดินสายไฟใน Mule 2 แต่ได้รับการพิสูจน์แล้วว่าเป็นการลากเส้นที่สำคัญเนื่องจากขาดการแสดงออกของการกำหนดค่า XML ที่จำเป็น ปัญหานี้ได้รับการแก้ไขเมื่อมีการนำการกำหนดค่าตาม XML Schema มาใช้ใน Spring 2

สร้างด้วย Maven

การปรับปรุงที่ใหญ่ที่สุดที่ทำให้การใช้งาน Mule ง่ายขึ้นทั้งในช่วงเวลาการพัฒนาและการปรับใช้คือการใช้ Maven จากเวอร์ชัน 1.3 เริ่มสร้างด้วย Maven

MuleSource

ในปี 2549 MuleSource ได้รวม“ เพื่อช่วยสนับสนุนและเปิดใช้งานชุมชนที่เติบโตอย่างรวดเร็วโดยใช้ Mule ในแอปพลิเคชันระดับองค์กรที่มีภารกิจสำคัญ” ได้รับการพิสูจน์แล้วว่าเป็นก้าวสำคัญของโครงการล่อ

คู่แข่งของ Mule ESB

ต่อไปนี้เป็นคู่แข่งสำคัญของ Mule ESB -

• WSO2 ESB
• Oracle Service Bus
• WebSphere Message Broker
• แพลตฟอร์ม Aurea CX
• Fiorano ESB
• WebSphere DataPower Gateway
• กรอบกระบวนการธุรกิจในวันทำงาน
• Talend Enterprise Service Bus
• JBoss Enterprise Service Bus
• iWay ผู้จัดการฝ่ายบริการ

แนวคิดหลักของ Mule

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

สำหรับสิ่งนี้เราจำเป็นต้องเข้าใจสถาปัตยกรรมของมันรวมถึงการสร้างบล็อค

สถาปัตยกรรม

สถาปัตยกรรมของ Mule ESB มีสามชั้น ได้แก่ เลเยอร์การขนส่งเลเยอร์การรวมและเลเยอร์แอปพลิเคชันดังแสดงในแผนภาพต่อไปนี้ -

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

การพัฒนาส่วนประกอบบริการ

งานนี้เกี่ยวข้องกับการพัฒนาหรือการใช้ POJO ที่มีอยู่หรือ Spring Beans อีกครั้ง POJO เป็นคลาสที่มีแอตทริบิวต์ที่สร้างเมธอด get and set ตัวเชื่อมต่อระบบคลาวด์ ในทางกลับกัน Spring Beans มีตรรกะทางธุรกิจเพื่อเสริมสร้างข้อความ

การจัดระเบียบบริการ

โดยพื้นฐานแล้วงานนี้จัดเตรียมสื่อกลางการบริการที่เกี่ยวข้องกับการกำหนดค่าตัวประมวลผลข้อความเราเตอร์หม้อแปลงและตัวกรอง

บูรณาการ

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

การก่อสร้างตึก

การกำหนดค่า Mule มีโครงสร้างพื้นฐานต่อไปนี้ -

ถั่วสปริง

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

ตัวแทน

โดยพื้นฐานแล้วเป็นบริการที่สร้างขึ้นใน Anypoint Studio ก่อน Mule Studio เอเจนต์ถูกสร้างขึ้นเมื่อคุณเริ่มเซิร์ฟเวอร์และจะถูกทำลายเมื่อคุณหยุดเซิร์ฟเวอร์

ตัวเชื่อมต่อ

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

การกำหนดค่าส่วนกลาง

ตามความหมายของชื่อ Building Block นี้ใช้เพื่อตั้งค่าคุณสมบัติส่วนกลางและการตั้งค่า

Global Endpoints

สามารถใช้ในแท็บ Global Elements ซึ่งสามารถใช้ได้กี่ครั้งในโฟลว์ -

Global Message Processor

ตามความหมายของชื่อจะสังเกตหรือปรับเปลี่ยนข้อความหรือโฟลว์ของข้อความ หม้อแปลงและตัวกรองเป็นตัวอย่างของ Global Message Processor

Transformers- งานหลักของหม้อแปลงคือการแปลงข้อมูลจากรูปแบบหนึ่งไปเป็นอีกรูปแบบหนึ่ง สามารถกำหนดได้ทั่วโลกและสามารถใช้ได้ในหลายโฟลว์

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

โมเดล

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

Services- บริการเป็นสิ่งที่ห่อหุ้มตรรกะทางธุรกิจหรือส่วนประกอบของเรา นอกจากนี้ยังกำหนดค่าเราเตอร์ปลายทางหม้อแปลงและตัวกรองเฉพาะสำหรับบริการนั้น ๆ

Endpoints- อาจถูกกำหนดให้เป็นวัตถุที่บริการจะรับข้อความขาเข้า (รับ) และขาออก (ส่ง) บริการเชื่อมต่อผ่านจุดสิ้นสุด

ไหล

ตัวประมวลผลข้อความใช้โฟลว์เพื่อกำหนดโฟลว์ข้อความระหว่างแหล่งที่มาและเป้าหมาย

โครงสร้างข้อความล่อ

ข้อความ Mule ซึ่งรวมอยู่ภายใต้ Mule Message Object เป็นข้อมูลที่ส่งผ่านแอปพลิเคชันผ่าน Muleflow ข้อความของ Structure Mule แสดงในแผนภาพต่อไปนี้ -

ดังที่เห็นในแผนภาพด้านบน Mule Message ประกอบด้วยสองส่วนหลัก -

หัวข้อ

ไม่มีอะไรนอกจากข้อมูลเมตาของข้อความซึ่งแสดงเพิ่มเติมจากคุณสมบัติสองประการต่อไปนี้ -

Inbound Properties- นี่คือคุณสมบัติที่กำหนดโดยแหล่งที่มาของข้อความโดยอัตโนมัติ ผู้ใช้ไม่สามารถจัดการหรือตั้งค่าได้ โดยธรรมชาติคุณสมบัติขาเข้าไม่เปลี่ยนรูป

Outbound Properties- คุณสมบัติเหล่านี้คือคุณสมบัติที่มีข้อมูลเมตาเช่นคุณสมบัติขาเข้าและสามารถตั้งค่าได้ในระหว่างขั้นตอน พวกเขาสามารถตั้งค่าโดยอัตโนมัติโดย Mule หรือด้วยตนเองโดยผู้ใช้ โดยธรรมชาติคุณสมบัติขาออกสามารถเปลี่ยนแปลงได้

คุณสมบัติขาออกกลายเป็นคุณสมบัติขาเข้าเมื่อข้อความผ่านจากจุดสิ้นสุดขาออกของโฟลว์หนึ่งไปยังปลายทางขาเข้าของโฟลว์อื่นผ่านการขนส่ง

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

น้ำหนักบรรทุก

ข้อความทางธุรกิจจริงที่ดำเนินการโดยวัตถุข้อความเรียกว่า payload

ตัวแปร

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

Flow variables - ตัวแปรเหล่านี้ใช้กับโฟลว์ที่มีอยู่เท่านั้น

Session variables - ตัวแปรเหล่านี้ใช้กับโฟลว์ทั้งหมดภายในแอปพลิเคชันเดียวกัน

Record variables - ตัวแปรเหล่านี้ใช้กับระเบียนที่ประมวลผลเป็นส่วนหนึ่งของชุดงานเท่านั้น

ไฟล์แนบและน้ำหนักบรรทุกพิเศษ

ต่อไปนี้เป็นข้อมูลเมตาเพิ่มเติมเกี่ยวกับส่วนของข้อความซึ่งไม่จำเป็นต้องปรากฏทุกครั้งในวัตถุข้อความ