>> โดยปกติแล้วเมื่อ client สมมติว่าเป็น browser ติดต่อกับ server มันจะส่ง request มาก่อน เมื่อ server รับทราบความต้องการนั้นๆก็จะส่ง response กลับไปให้ แล้วสิ้นสุดการติดต่อระหว่างกัน เป็นเช่นนี้ทุกครั้งตลอดระยะเวลาการสื่อสาร หากความต้องการข้อมูลมีความถี่มากขึ้น เป็นไปได้ที่ server ไม่อาจตอบสนองกับทุก request เหล่านั้นได้ทัน นี่จึงกลายเป็นเหตุผลที่ว่าสำหรับข้อมูลที่ต้องการ real-time อย่างจริงจังจะทำให้เกิดขึ้นได้อย่างไร? (ปกติร้องข้อมากเข้าเซิร์ฟก็จะล่ม)
>> วิธีการก็คือให้ server เป็นผู้ส่งข้อมูลให้ client เสียเอง (กล่าวคือไม่อนุญาตให้ client ส่ง request เข้ามาอีก) นั่นยังหมายความว่า client กับ server จะต้องเชื่อมต่อระหว่างกันอยู่เสมอ กลไกลนี้ถูกเรียกว่า Server-Sent Events (SSE) โดยการเชื่อมต่อใดๆจะถูกสร้างก็ต่อเมื่อ client ติดต่อเข้ามาหา server ก่อน และเป็นการเชื่อมต่อเพียงครั้งแรกและครั้งเดียวเท่านั้น จนกว่าการเชื่อมต่อดังกล่าวจะถูกปฏิเสธโดย client หรือ server จึงจะถือว่าการสื่อสารสิ้นสุดลงครับ
>> เขาบอกว่า (หนังสือบอกมา) เมื่อ client ส่งสัญญาณการติดต่อมาหา server ผ่าน EventSource ซึ่ง server พร้อมที่จะพยักหน้ารับหรือรับฟัง EventSource นี้อยู่ตลอดช่วงชีวิตของมัน เมื่อมันได้รับ EventSource มันจะสร้างการเชื่อมต่อใหม่ขึ้น และบริหารจัดการหน่วยความจำนี้ภายในคิว (queue) หลังจากนั้นจึงเริ่มส่ง event ให้ client ตาม business logic ที่กำหนดไว้ เรียกการสื่อสารลักษณะนี้ว่า การเชื่อมต่อทิศทางเดียว (unidirectional connection) คือจาก server สู่ client ครับ
>> ทีนี้มาดูทาง client บ้าง หลังจากที่มันถูกตอบรับการเชื่อมต่อ ตัวมันเองก็พร้อมที่จะรับฟัง event (ในนี้มีข้อมูลที่มันต้องการอยู่) และเมื่อไรก็ตามที่เกิด event ใหม่ ณ ฝั่ง server เจ้า event ก็จะถูก broadcast เพื่อส่งมาให้ client เป็นเช่นนี้ตลอดระยะการสื่อสารระหว่างกันครับ
>> แน่นอนว่าต้องเป็น browser ที่เข้าใจ HTML5 นะจ๊ะ ถึงจะสร้าง EventSource ได้
>> โดยทั่วไปแล้ว HTML5 จะใช้ภาษาจาวาสคริปต์เป็นตัวรับฟัง event ใหม่ๆที่ถูกส่งเข้ามาผ่านฟังก์ชัน onmessage แต่สำหรับ Jersey client ที่เราสนใจอยู่นี้ (เขียนด้วยภาษาจาวาเน๊อะ) จะมีเมธอด onEvent ที่ทำงานลักษณะเดียวกัน
>> เมื่อให้ client ติดต่อกับ server เป็นที่เรียบร้อยแล้วและเตรียมพร้อมจะส่ง event, server จะสร้างสิ่งที่เรียกว่า OutboundEvent ขึ้นมารับผิดชอบ event เจ้ากรรมที่กำลังจะส่งออกไป โดยจะต้องนำมา serialized (ถูกทำให้เป็น stream) ผ่าน OutboundEventWriter เสียก่อน ตอนนี้นี่เองที่เราสามารถกำหนดรูปแบบหรือ media type ให้กับข้อมูลที่อยู่ภายใน OutboundEvent ได้
>> เมื่อ event ที่อยู่ในรูปแบบ stream เดินทางมาถึง client, InboundEvent มีหน้าที่รับผิดชอบโดยตรงเพื่อรับ event ดังกล่าว ก่อนจะนำไป deserialized ผ่าน InboundEventReader, ข้อมูลจึงจะสามารถแสดงบน browser ได้
- รูปจาก https://www.safaribooksonline.com/library/view/developing-restful-web/9781783288298/ch05s02.html
รออ่านต่อค่ะ ขอบคุณมากค่ะที่แชร์บทความดีๆ
ตอบลบ