ในสถาปัตยกรรมซอฟต์แวร์รูปแบบการส่งข้อความ (messaging pattern)คือรูปแบบทางสถาปัตยกรรมที่อธิบายวิธีการเชื่อมต่อและสื่อสารระหว่างสองส่วนที่แตกต่างกันของแอปพลิเคชัน หรือระบบที่แตกต่างกัน แนวคิดของการส่งข้อความมีหลายแง่มุม ซึ่งสามารถแบ่งออกเป็นหมวดหมู่ดังต่อไปนี้: การส่งข้อความผ่านอุปกรณ์ฮาร์ดแวร์ (โทรคมนาคม เครือข่ายคอมพิวเตอร์ IoT เป็นต้น) และการแลกเปลี่ยนข้อมูลผ่านซอฟต์แวร์ (รูปแบบการแลกเปลี่ยนข้อมูลที่แตกต่างกันและความสามารถของซอฟต์แวร์ในการแลกเปลี่ยนข้อมูลดังกล่าว) แม้จะมีความแตกต่างกันในบริบท แต่ทั้งสองหมวดหมู่ก็มีลักษณะร่วมกันในการแลกเปลี่ยนข้อมูล

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

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

อีกทางเลือกหนึ่ง ในเครือข่ายคอมพิวเตอร์ เรามี โปรโตคอลเครือข่าย UDPซึ่งใช้กับรูปแบบการส่งข้อความทางเดียว^{[ 1 ]}โดยที่ฝ่ายส่งไม่สนใจว่าข้อความจะไปถึงฝ่ายรับหรือไม่ และไม่ได้คาดหวังว่าฝ่ายรับใด ๆ จะสร้างข้อความ "ตอบกลับ"

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

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

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

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

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

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

คำว่ารูปแบบการแลกเปลี่ยนข้อความมีความหมายขยายออกไปภายในโปรโตคอลการเข้าถึงวัตถุอย่างง่าย ( SOAP ) ^{[ 2 ] [ 3 ]}ประเภท MEP ของ SOAP ประกอบด้วย:

1. ขาเข้าอย่างเดียว (In-Only) : นี่เทียบเท่ากับ การ สื่อสารทางเดียวการแลกเปลี่ยนข้อความแบบทางเดียวมาตรฐานที่ผู้บริโภคส่งข้อความไปยังผู้ให้บริการโดยที่ผู้ให้บริการไม่ส่งการตอบกลับใดๆ
2. รูปแบบการรับส่งข้อความทางเดียวที่เชื่อถือได้ (Robust In-Only) : รูปแบบนี้ใช้สำหรับการแลกเปลี่ยนข้อความทางเดียวที่เชื่อถือได้ ผู้รับข้อความเริ่มต้นด้วยข้อความหนึ่งข้อความ และผู้ให้บริการจะตอบกลับด้วยสถานะ หากการตอบกลับเป็นสถานะ การแลกเปลี่ยนจะเสร็จสมบูรณ์ แต่หากการตอบกลับเป็นข้อผิดพลาด ผู้รับข้อความจะต้องตอบกลับด้วยสถานะเช่นกัน
3. ขาเข้า-ขาออก : นี่เทียบเท่ากับการร้องขอ-ตอบกลับเป็นการแลกเปลี่ยนข้อความสองทางมาตรฐาน โดยผู้บริโภคเริ่มต้นด้วยข้อความ ผู้ให้บริการตอบกลับด้วยข้อความหรือข้อผิดพลาด และผู้บริโภคตอบกลับด้วยสถานะ
4. In-Optional-Out : การแลกเปลี่ยนข้อความแบบสองทางมาตรฐาน โดยการตอบกลับของผู้ให้บริการนั้นเป็นทางเลือก
5. โหมดส่งออกอย่างเดียว (Out-Only) : ตรงข้ามกับโหมดรับอย่างเดียว (In-Only) โดยหลักๆ แล้วรองรับการแจ้งเตือนเหตุการณ์ ไม่สามารถส่งข้อความแสดงข้อผิดพลาดได้
6. รูปแบบ ส่งออกอย่างเดียวที่ทนทาน : คล้ายกับรูปแบบส่งออกอย่างเดียว แต่สามารถทำให้เกิดข้อความแสดงข้อผิดพลาดได้ ข้อความส่งออกจะเป็นตัวเริ่มต้นการส่งข้อมูล
7. Out-In : ตรงกันข้ามกับ In-Out ผู้ให้บริการเป็นผู้ส่งคำขอและเริ่มต้นการแลกเปลี่ยน
8. Out-Optional-In : รูปแบบตรงกันข้ามกับ In-Optional-Out บริการนี้สร้างข้อความขาออก ส่วนข้อความขาเข้าเป็นตัวเลือก (Optional-in)

ไลบรารี คิวข้อความ ØMQ มี ซ็อกเก็ตที่เรียกว่า(ซึ่งเป็นการขยายความทั่วไปของ ซ็อกเก็ต IPและUnix แบบ ดั้งเดิม ) ซึ่งต้องระบุรูปแบบการส่งข้อความที่จะใช้ และได้รับการปรับให้เหมาะสมสำหรับแต่ละรูปแบบ รูปแบบพื้นฐานของ ØMQ คือ: ^{[ 4 ]}

• การร้องขอและการตอบกลับเชื่อมต่อกลุ่มของไคลเอ็นต์กับกลุ่มของบริการ นี่คือ รูปแบบ การเรียกใช้กระบวนการระยะไกลและการกระจายงาน
• ระบบเผยแพร่-สมัครรับข้อมูล (Publish–subscribe)เชื่อมต่อกลุ่มผู้เผยแพร่กับกลุ่มผู้สมัครรับข้อมูล นี่คือรูปแบบการกระจายข้อมูลรูปแบบหนึ่ง
• รูปแบบ Push-pullเชื่อมต่อโหนดต่างๆ ใน รูปแบบ การกระจายออก /การรวมเข้า ซึ่งสามารถมีหลายขั้นตอนและวงวนได้ นี่คือรูปแบบการกระจายและการรวบรวมงานแบบขนาน
• การเชื่อมต่อ แบบพิเศษ (Exclusive pair)คือการเชื่อมต่อซ็อกเก็ตสองตัวเข้าด้วยกันในรูปแบบคู่พิเศษ นี่เป็นรูปแบบระดับต่ำสำหรับกรณีการใช้งานขั้นสูงเฉพาะบางอย่าง

แต่ละรูปแบบจะกำหนดโครงสร้างเครือข่าย เฉพาะ การร้องขอ-ตอบกลับจะกำหนดสิ่งที่เรียกว่า "service bus" การเผยแพร่-สมัครรับข้อมูลจะกำหนด "data distribution tree" การผลักดัน-ดึงจะกำหนด "parallelised pipeline" รูปแบบทั้งหมดได้รับการออกแบบโดยเจตนาให้สามารถปรับขนาดได้อย่างไม่จำกัดและสามารถใช้งานได้ในระดับอินเทอร์เน็ต^{[ 5 ]}

โปรโตคอลRESTเป็นโปรโตคอลการส่งข้อความที่สร้างขึ้นบนพื้นฐานของโปรโตคอล HTTPและใช้ รูปแบบการแลกเปลี่ยนข้อความแบบ ขอและตอบ เช่นเดียวกัน ในขณะที่เป้าหมายหลักของ HTTP คือการส่งเว็บเพจและไฟล์ผ่านทางอินเทอร์เน็ตไปยังผู้ใช้ปลายทางที่เป็นมนุษย์ โปรโตคอล RESTส่วนใหญ่ใช้สำหรับการสื่อสารระหว่างระบบซอฟต์แวร์ต่างๆ และมีบทบาทสำคัญใน รูปแบบสถาปัตยกรรมซอฟต์แวร์แบบ ไมโครเซอร์วิสคุณสมบัติที่โดดเด่นอย่างหนึ่งของโปรโตคอล REST คือความสามารถในการแสดงข้อมูลในรูปแบบอื่นๆ ได้มากมาย (โดยทั่วไปคือJSONและ XML) และมีตัวอธิบายเมตาเดต้าเพิ่มเติมสำหรับข้อความที่แสดง ตัวอธิบายเมตาเดต้าเป็นไปตามมาตรฐาน HTTP โดยแสดงเป็นส่วนหัวของ HTTP (ซึ่งได้รับการกำหนดมาตรฐานโดยโปรโตคอล HTTP พื้นฐาน) ดังนั้นจึงสามารถใช้เป็นคำแนะนำสำหรับฝ่ายรับในการตีความข้อมูลในข้อความได้ ด้วยเหตุนี้ REST จึงช่วยปรับปรุงการพัฒนาซอฟต์แวร์ที่สามารถสื่อสารกับระบบซอฟต์แวร์อื่นได้อย่างมาก เนื่องจากนักพัฒนาจำเป็นต้องทราบเพียงรูปแบบระดับสูงของข้อมูลในข้อความ (โมเดล JSON หรือ XML) เท่านั้น โดยปกติแล้ว การสื่อสารผ่านโปรโตคอล HTTP จะดำเนินการโดยไลบรารีซอฟต์แวร์หรือเฟรมเวิร์ก

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

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

• รูปแบบการส่งข้อความในสถาปัตยกรรมเชิงบริการ
• รูปแบบการบูรณาการระดับองค์กร - แคตตาล็อกรูปแบบ