| Topic 36 | Blackboards |
|---|
The writing is on the wall…
Daniel 5 (ref)
ลองจินตนาการถึงวิธีที่เหล่านักสืบอาจใช้ blackboard เพื่อช่วยกันประสานงานและคลี่คลายคดีฆาตกรรมดูครับ หัวหน้าสารวัตรเริ่มจากการตั้ง blackboard ขนาดใหญ่ไว้ในห้องประชุม แล้วเธอก็เขียนคำถามเพียงข้อเดียวลงไป:
H. Dumpty (ชาย, ไข่): อุบัติเหตุ? ฆาตกรรม?
Humpty ตกจากกำแพงเองจริงๆ หรือถูกผลักกันแน่? นักสืบแต่ละคนอาจมีส่วนร่วมในการไขปริศนาฆาตกรรมนี้ได้ด้วยการเพิ่มข้อเท็จจริง คำให้การของพยาน หลักฐานทางนิติวิทยาศาสตร์ต่างๆ และอื่นๆ เมื่อข้อมูลเริ่มพอกพูนขึ้น นักสืบอาจจะเริ่มสังเกตเห็นความเชื่อมโยงบางอย่าง และโพสต์ข้อสังเกตหรือข้อสันนิษฐานนั้นลงไปเช่นกัน กระบวนการนี้จะดำเนินต่อไปเรื่อยๆ ในทุกกะการทำงาน โดยมีผู้คนและเจ้าหน้าที่ที่แตกต่างกันมากมาย จนกว่าคดีจะถูกปิดลง ตัวอย่างของ blackboard จะแสดงให้เห็นใน the figure ครับ
Figure 2. มีใครบางคนพบความเชื่อมโยงระหว่างหนี้การพนันของ Humpty กับบันทึกการโทรศัพท์ บางทีเขาอาจกำลังถูกข่มขู่ทางโทรศัพท์อยู่ก็ได้
รูปภาพแสดง blackboard ที่มีเบาะแสของคดี Humpty Dumpty (ชาย, ไข่) จากรายละเอียดเหล่านี้ คดีอาจจะปิดลงได้ว่าเป็นทั้งอุบัติเหตุหรือฆาตกรรม โดยรายละเอียดประกอบด้วย: รูปถ่าย, ทหารของพระราชา, พยานบุคคล (รวบรวมโดยนักสืบ Holmes); เศษเปลือกไข่, หนี้การพนัน และกราฟฟิตี้บนผนัง (รวบรวมโดยนักสืบ Marple); บันทึกการโทรศัพท์และข้อมูลเกี่ยวกับข้ออ้างที่อยู่ของภรรยา (รวบรวมโดยนักสืบ Spade)
คุณสมบัติสำคัญบางประการของแนวทาง blackboard มีดังนี้ครับ:
-
นักสืบแต่ละคนไม่จำเป็นต้องรู้ถึงตัวตนของนักสืบคนอื่นๆ — พวกเขาคอยดูที่บอร์ดเพื่อหาข้อมูลใหม่ๆ และเพิ่มสิ่งที่ค้นพบลงไป
-
นักสืบอาจได้รับการฝึกฝนมาในสาขาที่แตกต่างกัน มีระดับการศึกษาและความเชี่ยวชาญที่ไม่เหมือนกัน และอาจไม่ได้ทำงานในพื้นที่เดียวกันด้วยซ้ำ สิ่งเดียวที่พวกเขามีร่วมกันคือความต้องการที่จะคลี่คลายคดีนี้
-
นักสืบแต่ละคนอาจเข้าๆ ออกๆ ตลอดระยะเวลาการสืบสวน และอาจทำงานคนละกะกันได้
-
ไม่มีข้อจำกัดว่าอะไรจะถูกนำไปวางไว้บน blackboard ได้บ้าง ไม่ว่าจะเป็นรูปถ่าย ข้อความ หลักฐานทางกายภาพ และอื่นๆ
นี่คือรูปแบบหนึ่งของ laissez faire concurrency ครับ นักสืบเหล่านี้เปรียบเสมือน processes, agents หรือ actors ที่เป็นอิสระต่อกัน บางคนเก็บข้อมูลลงบน blackboard บางคนนำข้อมูลออกมาจากบอร์ดเพื่อนำไปผสมผสานหรือประมวลผล แล้วค่อยนำข้อมูลที่ใหม่กว่ากลับไปใส่ไว้บนบอร์ด ในที่สุดบอร์ดนี้จะช่วยให้พวกเขาสรุปผลคดีได้
เดิมทีระบบ blackboard ที่ใช้คอมพิวเตอร์ถูกนำมาใช้ในงาน artificial intelligence ที่ต้องแก้ปัญหาใหญ่ๆ และซับซ้อน เช่น การจดจำเสียง (speech recognition) หรือระบบที่ใช้เหตุผลจากความรู้ (knowledge-based reasoning systems) เป็นต้น
หนึ่งในระบบ blackboard ยุคแรกๆ คือ Linda ของ David Gelernter ครับ ระบบนี้จะเก็บข้อเท็จจริงในรูปแบบของ typed tuples โดย applications สามารถเขียน tuple ใหม่ๆ ลงใน Linda และสอบถาม tuple ที่มีอยู่แล้วได้โดยใช้รูปแบบของ pattern matching
ต่อมาก็มีระบบที่มีลักษณะคล้าย blackboard แบบกระจายตัว (distributed) เช่น JavaSpaces และ T Spaces ระบบเหล่านี้ช่วยให้คุณสามารถเก็บ Java objects จริงๆ ที่ไม่ใช่แค่ข้อมูลไว้บน blackboard และดึงข้อมูลกลับมาได้ด้วยการจับคู่บางส่วนของ fields (ผ่าน templates และ wildcards) หรือค้นหาจาก subtypes ตัวอย่างเช่น สมมติว่าคุณมี type ที่ชื่อว่า Author ซึ่งเป็น subtype ของ Person คุณสามารถค้นหา blackboard ที่เก็บ object ประเภท Person ได้ด้วยการใช้ template ของ Author โดยกำหนดค่า lastName เป็น “Shakespeare'' คุณก็จะได้ Bill Shakespeare ที่เป็นนักเขียน (Author) แต่จะไม่ได้รับ Fred Shakespeare ที่เป็นคนสวน (gardener) ออกมาครับ
พวกเราเชื่อว่าสาเหตุที่ระบบเหล่านี้ไม่ได้รับความนิยมเท่าที่ควร ส่วนหนึ่งเป็นเพราะในตอนนั้นความจำเป็นในการประมวลผลแบบร่วมมือกันที่เกิดขึ้นพร้อมๆ กัน (concurrent cooperative processing) ยังไม่พัฒนามากพอครับ
A Blackboard in Action
สมมติว่าพวกเรากำลังเขียนโปรแกรมเพื่อรับและประมวลผลการขอสินเชื่อหรือเงินกู้ กฎหมายที่ควบคุมในเรื่องนี้มีความซับซ้อนอย่างน่าปวดหัว โดยทั้งรัฐบาลกลาง รัฐ และท้องถิ่นต่างก็มีส่วนเกี่ยวข้องด้วย ผู้ให้กู้ต้องพิสูจน์ได้ว่าได้เปิดเผยข้อมูลที่จำเป็น และต้องขอข้อมูลบางอย่าง แต่ในขณะเดียวกันก็ต้องห้ามถามคำถามบางข้อ และอื่นๆ อีกมากมายครับ
นอกจากความยุ่งเหยิงของกฎหมายที่ต้องบังคับใช้แล้ว พวกเรายังต้องเผชิญกับปัญหาดังต่อไปนี้อีกด้วย:
-
การตอบกลับสามารถมาถึงในลำดับใดก็ได้ ยกตัวอย่างเช่น การตรวจสอบเครดิต (credit check) หรือการค้นหาประวัติกรรมสิทธิ์ (title search) อาจใช้เวลานานมาก ในขณะที่ข้อมูลอย่างชื่อและที่อยู่อาจพร้อมใช้งานทันที
-
การรวบรวมข้อมูลอาจทำโดยผู้คนที่แตกต่างกัน กระจายอยู่ตามสำนักงานต่างๆ ในเขตเวลา (time zones) ที่ไม่เหมือนกัน
-
ข้อมูลบางอย่างอาจถูกรวบรวมโดยระบบอื่นโดยอัตโนมัติ ซึ่งข้อมูลเหล่านี้อาจส่งเข้ามาแบบ asynchronously ได้เช่นกัน
-
อย่างไรก็ตาม ข้อมูลบางอย่างยังคงต้องรอข้อมูลอื่นๆ ก่อน ตัวอย่างเช่น คุณอาจยังเริ่มตรวจสอบกรรมสิทธิ์รถยนต์ไม่ได้จนกว่าจะได้หลักฐานการเป็นเจ้าของหรือใบรับรองประกันภัย
-
การมาถึงของข้อมูลใหม่อาจทำให้เกิดคำถามหรือนโยบายใหม่ๆ เพิ่มขึ้นมา เช่น หากผลการตรวจเครดิตไม่ค่อยดีนัก คุณอาจต้องใช้แบบฟอร์มเพิ่มอีก 5 ชุด และอาจต้องใช้ผลตรวจเลือดด้วย (เปรียบเทียบความยุ่งยากน่ะครับ)
คุณอาจลองจัดการกับทุกสถานการณ์ที่เป็นไปได้โดยใช้ระบบ workflow ซึ่งระบบเหล่านี้มีอยู่มากมายครับ แต่มันอาจซับซ้อนและต้องใช้แรงจากนักพัฒนามหาศาล เมื่อกฎระเบียบเปลี่ยนไป workflow ก็ต้องถูกจัดระเบียบใหม่ด้วย ทั้งขั้นตอนการทำงานของคนและการแก้ code ที่เขียนแบบ hard-wired ไว้ครับ
การใช้ blackboard ร่วมกับ rules engine ที่รวบรวมข้อกำหนดทางกฎหมายไว้เป็นทางออกที่สวยงามสำหรับปัญหาพวกนี้เลยครับ ลำดับการมาถึงของข้อมูลจะไม่สำคัญอีกต่อไป: เมื่อมีการโพสต์ข้อเท็จจริงลงไป มันจะไปกระตุ้น (trigger) กฎที่เกี่ยวข้องได้ทันที การตอบกลับ (feedback) ก็จัดการได้ง่ายเช่นกัน เพราะผลลัพธ์จากกฎชุดใดๆ ก็ตามสามารถโพสต์กลับลงบน blackboard และไปกระตุ้นกฎข้ออื่นๆ ที่เกี่ยวข้องต่อได้อีกครับ
| Tip 60 | Use Blackboards to Coordinate Workflow |
|---|
Messaging Systems Can Be Like Blackboards
ในขณะที่พวกเรากำลังเขียนหนังสือฉบับพิมพ์ครั้งที่สองนี้อยู่ applications จำนวนมากถูกสร้างขึ้นจากบริการขนาดเล็กที่แยกออกจากกัน (small, decoupled services) โดยสื่อสารกันผ่านระบบ messaging บางรูปแบบ ระบบ messaging เหล่านี้ (เช่น Kafka และ NATS) ทำได้มากกว่าแค่การส่งข้อมูลจาก A ไป B ครับ โดยเฉพาะอย่างยิ่งพวกมันมีความสามารถเรื่อง persistence (ในรูปแบบของ event log) และสามารถดึงข้อความคืนมาผ่านรูปแบบของ pattern matching ได้ ซึ่งหมายความว่าคุณสามารถใช้พวกมันเป็นทั้งระบบ blackboard และ/หรือเป็น platform สำหรับรันเหล่า actors ได้ด้วยครับ
But It's Not That Simple…
แนวทางสถาปัตยกรรมแบบ actor และ/หรือ blackboard และ/หรือ microservice ช่วยขจัดปัญหาเรื่อง concurrency ชุดใหญ่ๆ ออกไปจาก applications ของคุณได้ครับ แต่ข้อดีนี้ก็มีสิ่งที่ต้องจ่าย แนวทางเหล่านี้ยากต่อการทำความเข้าใจ (harder to reason about) เพราะการทำงานส่วนใหญ่มันเป็นแบบอ้อมๆ (indirect) คุณจะพบว่ามันมีประโยชน์มากหากมี repository กลางที่เก็บรูปแบบข้อความและ/หรือ APIs ไว้ โดยเฉพาะอย่างยิ่งถ้า repository นั้นสามารถสร้าง code และเอกสารประกอบให้คุณได้โดยอัตโนมัติ นอกจากนี้คุณยังต้องการเครื่องมือที่ดีในการติดตาม (trace) ข้อความและข้อเท็จจริงต่างๆ ขณะที่มันเคลื่อนที่ผ่านระบบไป (เทคนิคที่มีประโยชน์คือการเพิ่ม trace id ที่ไม่ซ้ำกันเมื่อเริ่มฟังก์ชันทางธุรกิจ และส่งต่อ id นั้นไปยัง actors ทั้งหมดที่เกี่ยวข้อง คุณก็จะสามารถย้อนกลับไปดูสิ่งที่เกิดขึ้นจาก log files ได้ครับ)
สุดท้าย ระบบประเภทนี้อาจยุ่งยากในการติดตั้ง (deploy) และจัดการมากกว่า เพราะมีชิ้นส่วนที่เคลื่อนไหว (moving parts) เยอะขึ้น แต่ในทางกลับกัน มันก็ถูกชดเชยด้วยการที่ระบบมีความละเอียดมากขึ้น (granular) และสามารถอัปเดตได้ด้วยการเปลี่ยนเพียงแค่ actors บางตัว โดยไม่จำเป็นต้องเปลี่ยนทั้งระบบครับ
Related Sections Include
- Topic 28, _Decoupling_
- Topic 29, _Juggling the Real World_
- Topic 33, _Breaking Temporal Coupling_
- Topic 35, _Actors and Processes_
Exercises
Exercise 24 (possible answer)
ระบบรูปแบบ blackboard จะเหมาะสมกับ applications ต่อไปนี้หรือไม่? เพราะเหตุใด?
Image processing คุณต้องการมีกระบวนการแบบขนาน (parallel processes) จำนวนหนึ่งเพื่อดึงส่วนต่างๆ ของรูปภาพไปประมวลผล แล้วนำส่วนที่ทำเสร็จแล้วกลับมาวางที่เดิม
Group calendaring คุณมีผู้คนกระจายอยู่ทั่วโลกในเขตเวลา (time zones) ที่แตกต่างกัน และพูดคนละภาษา กำลังพยายามจัดตารางการประชุมร่วมกัน
Network monitoring tool ระบบจะรวบรวมสถิติประสิทธิภาพการทำงานและเก็บรวบรวมรายงานปัญหา ซึ่ง agents จะนำไปใช้เพื่อค้นหาปัญหาในระบบต่อไป
Challenges
- คุณได้ใช้งานระบบ blackboard ในชีวิตจริงบ้างไหมครับ เช่น กระดานฝากข้อความข้างตู้เย็น หรือ whiteboard ขนาดใหญ่ในที่ทำงาน? อะไรที่ทำให้มันมีประสิทธิภาพ? ข้อความที่ถูกเขียนขึ้นมามีรูปแบบที่สม่ำเสมอหรือไม่? และเรื่องรูปแบบมันสำคัญหรือเปล่าครับ?
Footnotes
[46] แม้ว่า UML จะค่อยๆ จางหายไป แต่แผนภาพหลายตัวของมันยังคงมีอยู่ไม่ทางใดก็ทางหนึ่ง รวมถึงแผนภาพกิจกรรม (activity diagram) ที่มีประโยชน์มาก สำหรับข้อมูลเพิ่มเติมเกี่ยวกับประเภทของแผนภาพ UML ทั้งหมด สามารถดูได้จาก UML Distilled: A Brief Guide to the Standard Object Modeling Language [Fow04] ครับ
[47] ชื่อ P และ V มาจากตัวอักษรตัวแรกของคำในภาษาดัตช์ อย่างไรก็ตามมีการถกเถียงกันว่ามาจากคำไหนกันแน่ โดย Edsger Dijkstra ผู้ประดิษฐ์เทคนิคนี้ได้เสนอทั้งคำว่า passering และ prolaag สำหรับ P ส่วน V นั้นคือ vrijgave และอาจจะเป็น verhogen ครับ
[48] https://github.com/ncthbrt/nact
[49] ในการที่จะรัน code นี้ คุณจำเป็นต้องใช้ wrapper functions ของพวกเราด้วยซึ่งไม่ได้แสดงไว้ที่นี่ คุณสามารถดาวน์โหลดได้จาก https://media.pragprog.com/titles/tpp20/code/concurrency/actors/index.js ครับ
Copyright © 2020 Pearson Education, Inc.