ระหว่างที่ผมกำลังเขียนหนังสือเล่มใหม่ ซึ่งได้มีการพูดถึงแนวคิดแบบ Component-oriented Architecture ก็ได้ฉุกคิดขึ้นมาว่า คงมีหลายๆคนที่สับสนกับแนวคิด Oriented แบบต่างๆ และมีข้อสงสัยเช่น Object-oriented Programming ต่างจาก Component-oriented Architecture อย่างไร เราควรใช้แบบไหนดี แล้ว Service-oriented Architecture หล่ะมันคืออะไร เป็นต้น ไหนจะตีกับเรื่องของ Design Patterns แบบต่างๆอีก ดังนั้นผมจึงตั้งใจเขียนบทความนี้ขึ้นมาเพื่ออธิบายความสัมพันธ์ของแนวคิดดังต่อไปนี้คือ

• Object-oriented Programming (OOP)
• Component-oriented Architecture (COA)
• Service-oriented Architecture (SOA)

ว่าแล้วก็ไปอ่านกันเลยครับ

คำว่า Oriented คืออะไรกัน?

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

• Object-based Programming
• Component-based Architecture
• Service-based Architecture

อ่าว งงไปกว่าเดิมอีก !!! ไม่ต้องงงครับ เดี๋ยวจะค่อยๆอธิบาย เพราะมันต้องมีตัวอย่างประกอบด้วยถึงจะเข้าใจ แต่เบื้องต้นคำว่า "based" ก็หมายถึง "อยู่บนพื้นฐาน" ดังนั้นการเขียนโปรแกรมแบบ OOP ก็คือการเขียนโปรแกรมที่อยู่บนพื้นฐานของออบเจกต์ (Object) เป็นต้นครับ

Object-oriented Programming (OOP)

แนวคิดพื้นฐานของการเขียนโปรแกรมในปัจจุบันคงหนีไม่พ้นแนวคิดแบบ OOP ซึ่งผมก็เคยเขียนถึงเรื่องนี้ไปแล้วในบทความ "Object-oriented Programming (OOP) คืออะไรกันแน่" ดังนั้นผมคงไม่อธิบายถึงแนวคิดนี้แบบละเอียดซ้ำอีก แต่จะขอสรุปทบทวนกันอีกรอบเพื่อความเข้าใจที่ตรงกันดังนี้ การเขียนโปรแกรมแบบ Object-Oriented ก็คือ การแบ่งโปรแกรมหรือแอพพลิเคชันออกเป็นออบเจกต์ย่อยๆ แต่ละออบเจกต์ทำหน้าที่หลักเพียงอย่างเดียวหรือมีเพียงบทบาทเดียว สุดท้ายทุกๆออบเจกต์ทำงานร่วมกันออกมาเป็นแอพพลิเคชันที่สมบูรณ์ ที่นี้เมื่อเราพัฒนาแอพพลิเคชันที่มีความซับซ้อนมากขึ้นหรือออกแบบให้รันในลักษณะของ Multi-tier/N-tier (ซึ่งใน Java เรียกมันว่า Enterprise Applications) เราจึงนำแนวคิดของ Component-oriented Architecture เข้ามาใช้

Component-oriented Architecture (COA)

แนวคิดการพัฒนาแอพพลิเคชัน (หรือระบบ) แบบ COA คือ การแบ่งแอพพลิเคชันออกเป็นองค์ประกอบย่อยๆหรือก็คือ Components ย่อยๆนั่นเอง ซึ่งการแบ่ง Components นั้น เราจะแบ่งตามชนิดของเทคโนโลยี ยกตัวอย่างเช่น ระบบธนาคารอาจประกอบไปด้วย Components ต่างๆมากมาย ได้แก่ Component เว็บ เพื่อรองรับการทำธุรกรรมผ่านเว็บ, Component ของการประมวลผลหรือ Business Component เพื่อใช้ในการประมวลผลธุรกรรมต่างๆ, Component เว็บเซอร์วิสเพื่อใช้ในการแลกเปลี่ยนข้อมูลระหว่างธนาคาร ดังแสดงในรูปที่ 1 เป็นต้น ทั้งนี้ทั้งนั้นที่เราแบ่งแอพพลิเคชันออกเป็น Components ย่อยๆ ก็เพื่อที่เราจะสามารถนำมันกลับมาใช้ได้ใหม่ หรือเพื่อให้มีการเปลี่ยนแปลงแก้ไขได้ง่ายขึ้นเช่น ไม่ว่าเราจะทำธุรกรรมผ่านแอพพลิเคชันที่เคาน์เตอร์สาขาหรือผ่านตู้เอทีเอ็มหรือแม้แต่ผ่านเว็บ การประมวลผลก็เป็นหน้าที่ของ Business Component เท่านั้น ทำให้เมื่อมีการเปลี่ยนแปลงวิธีการประมวลผลใหม่ เราเพียงแก้ไขที่ Business Component นี้เท่านั้น Components อื่นอย่างเช่น Component เว็บเป็นเพียงแค่ Component สำหรับแสดงผลบนเว็บเท่านั้น เป็นต้น

จากตัวอย่างที่ผมยกขึ้นมาจะเห็นได้ว่าเป็นแอพพลิเคชันเชิงระบบ คือมีการ Deploy แต่ละ Component บน Tiers ต่างๆ อันที่จริงแล้วแม้ว่าจะเป็นเดสก์ท็อปแอพพลิเคชันอย่างเช่น Photoshop ก็ใช้แนวคิดนี้ได้เช่นกัน กล่าวคือพัฒนาฟีเจอร์ต่างๆในลักษณะของ Components เพื่อให้สามารถเพิ่มลดเปลี่ยนแปลงฟีเจอร์ต่างๆได้ง่ายขึ้น เป็นต้น ทีนี้ในทางปฏิบัติการพัฒนาแต่ละ Component ก็ขึ้นอยู่กับแต่ละ Programming Platform แล้วว่ามีไลบรารีหรือ APIs อะไรให้เราเลือกใช้บ้าง และรองรับงานประเภทนั้นๆหรือไม่ ยกตัวอย่างเช่น ใน Java เราสามารถใช้ Servlet/JSP ซึ่งเป็นส่วนหนึ่งของ Java EE เพื่อพัฒนา Component เว็บได้ เป็นต้น

รูปที่ 1: ตัวอย่างการแบ่ง Components ในระบบธนาคาร

OOP vs COA vs Design Patterns

เอ แล้ว OOP กับ COA เราจะเลือกแบบไหนดี? จะแบ่งแอพพลิเคชันเป็นออบเจกต์หรือแบ่งเป็น Components ดี? ถ้าพัฒนาแอพพลิเคชันเล็กๆเราก็ใช้แบบ OOP ใช่มั้ย ถ้าแอพพลิเคชันมีขนาดใหญ่เราก็ใช้แบบ COA หรือเปล่า? ผิดครับ ย้ำว่าผิดครับ ถึงแม้ว่าเราจะพัฒนาด้วยแนวคิดแบบ COA โดยแบ่งแอพพลิเคชันออกเป็น Components ย่อยๆ แต่ทว่าภายใน Components นั้นๆ เราก็แบ่งมันออกเป็นออบเจกต์ย่อยๆอีกที คงไม่มีใครเขียน Component ทั้ง Component ขึ้นมาด้วยไฟล์ๆเดียวหรือด้วยออบเจกต์ๆเดียวหรอกจริงมั้ยครับ ยกตัวอย่างเช่น ภายใน Component เว็บก็ประกอบไปด้วยออบเจกต์ต่างๆมากมายที่ทำหน้าที่เกี่ยวกับเว็บ จึงมารวมกันเป็น Component เดียวกันได้ แต่ทว่าแต่ละออบเจกต์ก็มีรายละเอียดหรือจุดมุ่งหมายที่แตกต่างกันไป จึงทำให้สามารถแยกออกเป็นออบเจกต์ย่อยๆได้ เป็นต้น สรุปก็คือเราใช้มันทั้งสองแนวคิดไปพร้อมๆกัน คือ COA มาเป็นส่วนเสริมให้กับ OOP เมื่อแอพพลิเคชันมีความซับซ้อนมากขึ้น

แล้วที่นี้เจ้า Design Patterns แบบต่างๆหล่ะ มันอยู่ส่วนไหน มีความสัมพันธ์กับ OOP/COA อย่างไร? Design Patterns นี่เปรียบเสมือนการประยุกต์ใช้ OOP/COA ในทางปฏิบัติ เป็นเหมือนกับรูปแบบสำเร็จรูปที่มีการออกแบบและคิดค้นไว้แล้ว เราสามารถนำไปปรับใช้ให้เหมาะสมกับแอพพลิเคชันของเราได้เลย เรียกได้ว่าหากไม่รู้จะออกแบบออบเจกต์อย่างไร ก็ให้ออกแบบตาม Design Patterns นั่นเอง แต่ต้องบอกอย่างนี้ด้วยครับว่า Design Patterns มันก็มีทั้งที่เป็นแบบระดับ OOP กับที่เป็นแบบระดับ COA มองในเชิงโครงสร้างครับ ยกตัวอย่างเช่น Singleton Pattern มันก็จัดอยู่ในระดับของ OOP คือมันใช้ประยุกต์กับระดับออบเจกต์, MVC มันก็ยังคงอยู่ในระดับของออบเจกต์อีกเช่นกัน กล่าวคือเราออกแบบให้ออบเจกต์มีหน้าที่เป็น Model หรือ View หรือ Controller ครับ, ส่วน Business Delegate Pattern นี่จัดเป็นระดับของ COA เป็นต้น หากใครเคยได้ยิน Gang of Four (GoF) Design Patterns นั่นก็เป็นรูปแบบที่เอามาประยุกต์กับการออกแบบ OOP ได้ ส่วน J2EE Design Patterns ก็เอามาประยุกต์กับ COA นั่นเอง ส่วนใครไม่ใช้ Java ก็เอาแนวคิดไปประยุกต์ได้ครับ หรือแต่ละ Programming Platform เขาก็มี Design Patterns ที่อ้างอิงกันอยู่ ลองไปหาๆอ่านดูครับ (ผมเจอหนังสือ Design Patterns ของแต่ละภาษาเยอะมาก) สรุปแล้วเรานำเอา Design Patterns แบบต่างๆมาประยุกต์ออกแบบให้กับแนวคิดของ OOP/COA ตามความเหมาะสมนั่นเอง

แล้ว Service-oriented Architecture (SOA) มาจากไหนอีกหล่ะเนี่ย

อย่าเพิ่งตกใจไปครับ แนวคิดแบบ SOA นี่เป็นแนวคิดที่ออกตามมาภายหลัง SOA มีแนวคิดว่า ให้มองทุกอย่างเป็น Service การแบ่งระบบก็ให้แบ่งเป็นหรือตาม Service ด้วยเช่นกัน และในแนวคิดนี้การรันระบบใดๆก็ตาม มันจะมีอยู่สองมุมด้วยกันคือ i) มุมของ Service Provider และ ii) มุมของ Service Requester จากชื่อก็บอกอยู่แล้วนะครับว่า ฝั่งหนึ่งเป็นผู้เรียกใช้ Service อีกฝั่งเป็นผู้ประมวลผล แนวคิดนี้มองว่าหากระบบใดๆสามารถออกแบบด้วยแนวคิดแบบ SOA ได้ ทุกระบบก็จะสามารถทำงานร่วมกันได้โดยไม่สนใจว่าจะพัฒนาด้วย Programming Platforms ใดเลย โอ้ !!! ส่ง Request มา เดี๋ยวประมวลผลแล้วส่ง Response กลับไปให้ Cool :) ในทางปฏิบัติ SOA ถูกขับเคลื่อนด้วยเทคโนโลยี Web Services เพราะ Web Services คือเทคโนโลยีหรือโปรโตคอลที่ทำให้เราแลกเปลี่ยนข้อมูลหรือ Request/Response กันได้ด้วยมาตราฐานกลางไม่ผูกมัดกับ Programming Platform ใด Platform หนึ่ง ซึ่งผมขอไม่พูดถึงรายละเอียดของ Web Services นะครับ

อ้าว แล้ว SOA มันจะมาตีกับ COA อีกมั้ยหล่ะ? ไม่ครับ มาเสริมเข้าไปครับ ผมยกตัวอย่างอย่างนี้ เวลาเรามองด้วย SOA เรามองเป็น Service เช่น ธนาคาร A ต้องการทำธุรกรรมกับธนาคาร B แต่ทั้งสองต่างพัฒนาด้วย Programming Platforms ที่แตกต่างกัน แต่หากเราออกแบบด้วย SOA เราก็มองว่าทั้งสองธนาคารต้องสามารถ Request/Response กันได้ ทีนี้การจะทำ Service ขึ้นมาแต่ละ Service Module นั้น แน่นอนว่ามันต้องประกอบไปด้วยหลายๆ Components นั่นเอง ดังนั้นหากเรามีการออกแบบระบบด้วย COA เวลาเราจะออกแบบ Service ขึ้นมาสักตัวหนึ่ง เราก็นำเอา Components ที่มีอยู่เดิมมาใช้งานได้ เป็นต้น รูปที่ 2 แสดงความสัมพันธ์ของ OOP, COA, และ SOA ในความเป็นจริงแล้ว SOA ไม่จำเป็นต้องเกี่ยวข้องกับการรันระบบระหว่างบริษัทหรือต้องใช้ Web Services เสมอไป เราสามารถออกแบบให้ระบบภายในบริษัทมีความเป็น Services ได้เช่น บริษัทของเรามี Services ให้กับลูกค้าหลากหลายชนิด แต่ละ Services ก็ไปนำเอา Components ที่มีมาเป็นส่วนประกอบของ Services ต่างๆได้ เป็นต้น หากเราประยุกต์ใช้ถึงระดับ SOA ก็แสดงว่า Component โดยตัวมันเองยังไม่สามารถใช้งานเป็นรูปธรรมได้ หากแต่ถูกออกแบบไว้ให้นำไปประกอบใช้เป็น Services ต่างๆนั่นเอง และหาก Services ต่างๆใช้ Programming Platform เดียวกัน ก็ไม่จำเป็นต้องใช้เทคโนโลยี Web Services ก็ได้ หรือจะใช้อันนี้ต้องไปวิเคราะห์ปัจจัยอื่นๆกันอีกที

รูปที่ 2: ความสัมพันธ์ของ OOP, COA, และ SOA

สรุปปิดท้าย

ผมขอสรุปปิดท้ายบทความดังนี้ OOP เป็นเสมือนจุดเริ่มต้นของการเขียนโปรแกรม เรียกได้ว่าเป็นแนวคิดพื้นฐานหลักเลยก็ว่าได้ เราแบ่งแอพพลิเคชันออกเป็นออบเจกต์ย่อยๆ และเมื่อแอพพลิเคชันเรามีความซับซ้อนมากขึ้น มีการ Deploy ในลักษณะของ Multi-tier เราจึงจัดกลุ่มของออบเจกต์ที่สอดคล้องกันให้อยู่ในรูปของ Components ซึ่งก็คือแนวคิดของ COA และเมื่อเรานำ Components ไปใช้ เราอาจผสมรวม Components เข้าด้วยกันในลักษณะของ Services ได้ ซึ่งก็คือแนวคิดของ SOA ไม่เพียงเท่านี้เรายังมีเทคโนโลยีหรือแนวคิดที่สามารถนำมาประยุกต์ใช้กับ SOA ได้อีก อาทิเช่น Enterprise Service Bus (ESB), Business Process Execution Language (BPEL) เป็นต้น ลองไปหาอ่านศึกษาเพิ่มเติมกันดูนะครับ