เกริ่นนำ
SOA หรือ Service-Oriented Architecture เป็น ‘แนวคิด’ ทางสถาปัตยกรรมซอฟต์แวร์เชิงบริการ โดยมีพื้นฐานอยู่บนสถาปัตยกรรมซอฟต์แวร์ (จากนี้จะขอเรียกสั้น ๆ ว่า ‘architecture’) แบบ Enterprise Architecture ที่มีการประมวลผลลักษณะ Distributed Computing
SOA ก็คือการสร้างเลเยอร์ (architectural layer) มาครอบระบบฯ และทรัพยากรไอทีขององค์กรที่มีอยู่ และที่จะเกิดขึ้นในอนาคต… ทั้งหมดหรือเกือบทั้งหมด โดยเลเยอร์นี้เรียกว่าชั้นบริการ (service layer) ด้วยเหตุผลเพื่อให้เกิดการเชื่อมโยงติดต่อ (integrate) กับระบบฯ และทรัพยากรไอทีต่าง ๆ ที่ชั้นบริการนี้ ลดความซับซ้อนยุ่งเหยิงที่มีมาในอดีต การจัดการ transaction, security, การแปลง (adapt) ของการ call ระหว่างระบบที่ต่างแพลตฟอร์มกัน, การทำ data exchange, การจัดการเครือข่าย ฯลฯ เหล่านี้จะได้รับ ‘การปรับปรุง’
แต่หากมองอีกด้านหนึ่งของประเด็นข้างต้น นี่หมายถึงอะไร? มีนัยสำคัญใดซ่อนอยู่? ลองมองข้ามประเด็นด้านเทคโนโลยีและคุณประโยชน์ของ SOA ออกไปก่อน… นี่อาจเป็นช่องทางที่ก่อให้เกิดการผูกขาดทางการค้าใช่หรือไม่? หากโซลูชั่นของผู้ค้ารายใดได้ถูกนำมาใช้ในองค์กรนั้น และมีการใช้กลยุทธ์ ‘Vendor Lock-In’ ขึ้นอย่างแยบยล หรือจะเปิดเผยโฉ่งฉ่างก็ตาม โดยมีการออกแบบอินเตอร์เฟซที่สลับซับซ้อน ซ่อนเงื่อน มี ‘API เปิดเผย’ จำนวนหนึ่ง นี่อาจเข้าข่ายการเป็น ‘มาตรฐานปิด’ ก็ได้ แม้ผู้ค้าจะออกแถลงว่าตนใช้มาตรฐานเปิด เช่น พัฒนาต่อยอดมาจากโอเพ่นซอร์ส ใช้ Java ใช้เว็บเซอร์วิส เป็นต้น แต่ในฐานะ architect และคนในวงการ architect ต่างก็รู้ ๆ กันอยู่ ว่าเราสามารถทำให้ ‘ปิดในส่วนที่อยากปิด และเปิดในส่วนที่อยากเปิด’ ได้
องค์กรอาจถูกแนะนำ (บังคับทางอ้อม) ให้ปรับปรุง:
- ระบบ security เช่นอนาคตจะได้รองรับ single sign-on, digital certificate และติดตั้งระบบ intrusion detection system (IDS) จะได้ปัองกับแฮกเกอร์และการโจรกรรมข้อมูล (หว่านล้อมโดยพูดให้ฟังดูน่ากลัว) ฯลฯ
- การจัดการ transaction เช่น เมื่อดึงการจัดการ transaction ขึ้นมาที่เลเยอร์บนแล้ว เพื่อจะได้ติดตาม (monitor) การทำงานของ transaction ได้สะดวกต้องมี transaction monitor server ฯลฯ
- การจัดการ business process เช่น เพื่อให้เห็นภาพโดยง่าย ทำ model ได้ง่าย ติดตาม (monitor) และจัดการได้ง่ายต้องมีเครื่องมือด้าน business process modeling, business process management ฯลฯ
- การติดต่อกับ service ต่าง ๆ เช่น เพื่อให้พัฒนาส่วนแสดงผล (presentation) ได้ง่าย ยืดหยุ่น ปรับปรุงง่าย ไม่ต้องเขียนโค้ดมาก เพิ่มเติมต่อยอดได้ง่าย และรองรับ WEB 2.0 โดยต้องใช้ portal ฯลฯ
- การ map ระหว่าง service กับระบบฯ ต่าง ๆ ที่มีหลายแพตฟอร์มทำได้ง่ายขึ้นด้วยการใช้ adapter และต้องมี Enterprise Service Bus (ESB) และมี adapter ที่มีความสามารถและ ‘แปลง’ ให้ทำงานร่วมกับแพลตฟอร์มต่าง ๆ ได้มากมาย
- การจัดการ service registry เช่น เพื่อประสิทธิภาพและความปลอดภัย ต้องเก็บไว้ใน directory server โดยทำงานบนโปรโตคอล LDAP ฯลฯ
- การจัดการ messaging เช่น เพื่อให้มีความน่าเชื่อถือ (reliability) สูงสำหรับการ call โดยเฉพาะการ call แบบ asynchronous ต้องใช้ message queue server ฯลฯ
- การโฮสต์แอพพลิเคชั่น (พวกพ่อค้าคงลืมไปว่า SOA ไม่มีแนวคิดด้านแอพพลิเคชั่นแล้ว) เช่น การติดตั้ง (deploy) แอพพลิเคชั่น และการจัดการต่าง ๆ ต้องใช้ application server และหากต้องการให้รองรับ scalability ต้องมี web server แยกต่างหาก ฯลฯ
- การจัดการ fault tolerance เช่น งานมีความสำคัญ มี transaction สำคัญและไม่ต้องการให้เกิดความเสียหาย ผิดพลาด หรือหากเกิดขึ้นก็สามารถกู้คืนได้ และต้องการรองรับ load สูง ๆ ได้ ต้องทำ load balance, clustering, hot swap, cold swap, active redundancy, passive redundancy, shadow processing, state resychronization, backup and recovery (พูดหว่านล้อมใช้ศัพท์ให้ดูยาก ๆ ไว้) ดังนั้นต้องมีเครื่องเซิร์ฟเวอร์เพิ่มเติม และมีอุปกรณ์ด้าน cluster และ mass storage รวมถึงต้องอัพเกรดระบบเน็ตเวิร์กและอุปกรณ์เน็ตเวิร์ก ฯลฯ
- ฯลฯ
