Component Object Model #1: What For?

เกริ่นนำ

    ผมพยายามนำเรื่องที่ทันสมัยหน่อย มาเขียนเล่าสู่กันฟัง มีหลายเรื่องที่คิดไว้ในใจ แต่พอนึกไปนึกมา มันก็ติด ถ้าขืนเขียนเรื่องพวกนั้น เกรงว่ามือใหม่จะจับต้นชนปลายไม่ถูก ผมเลยมานั่งนึกดูว่าต้องปูพื้นอะไรก่อน ถึงจะนำไปสู่เรื่องที่อยากเขียนได้ นึกไปนึกมา ก็เรื่อง COM นี่แหละครับ มันเป็นรากของ Microsoft เลยที่เดียว วันนี้ผมเลยจะจับเรื่องนี้มาเล่าสู่กันฟัง

    ปัญหาหนึ่งของการศึกษา COM นั่นก็คือมันมีความซับซ้อนมาก ผมต้องตีลังกาศึกษาอยู่นานพอสมควร เท่าที่อ่านหนังสือในท้องตลาด ปรากฏว่า มันมี 2 จำพวกครับ พวกแรกก็เป็นพวกเบาโหวง อ่านแล้วรู้สึกว่าไม่ได้อะไร ส่วนแบบที่ 2 ก็จะเป็นแบบเจาะลึก อ่านแล้วรู้สึกเหมือนกำลังปีนเขาอ่าน ไม่ใช่ดีครับ พออ่านจบแล้วก็มานั่งถามตัวเองว่า รู้ไปเยอะขนาดนั้นทำไม  ผมว่าเอาตรงกลางดีกว่า เอาแบบไม่ให้เบาหรือหนักจนเกินไปนัก มีเนื้อหาเพียงพอที่จะสามารถต่อยอดไปสู่สิ่งที่ทันสมัยกว่าได้ ก็น่าจะดี

    ในบทนี้ ผมคิดว่าการจะทำความเข้าใจมัน เราควรจะมาดูพัฒนาการของมัน มันออกแบบมาเพื่อแก้ไขอะไร อะไรคือตัวปัญหา ผมเชื่อว่าการศึกษาแนวนี้น่าจะได้ผลดีกว่า จะเขียนว่ามันเป็นอย่างไรแต่อย่างเดียว มันจะกลายเป็นท่องจำ ซึ่งเอาไปต่อยอดได้ลำบาก

 

กำเนิด COM

    ย้อนกลับไปปี 1988 ยุคนั้น Microsoft มี Windows แล้ว แต่ยังไม่ได้รับความนิยม ถ้าจำไม่ผิด เวลานั้นผมยังใช้ DOS อยู่ครับ ยุคนั้น Microsoft มี Technology ใหม่ล่าสุดที่ชื่อว่า OLE เป็น Technology ที่ให้ Application หนึ่งสามารถ Host อีก Application หนึ่งได้ เราคุ้นเคยกันดีครับ เช่น เอา Sheet ของ Excel ไปเป็นส่วนหนึ่งในเอกสารของ Word เป็นต้น

    OLE ในยุคนั้น มันก็ทำงานได้เหมือนยุคปัจจุบันครับ แต่อืดมาก แถมยังไม่ค่อย Stable ดังนั้น Microsoft จึงตัดสินใจสนับสนุนให้เกิด OLE version 2 เพื่อแก้ไขปัญหาดังกล่าว แต่ติดว่า ทีม OLE นั้นไม่มี Infrastructure ที่ดีเพียงพอ ทาง Microsoft จึงต้องนำเอาทีมอื่นมาสนับสนุน (ไม่ต้องแปลกใจครับ เท่าที่ผมรู้ทาง Microsoft ใช้วิธีทำงานแบบแข่งขัน แบ่งคนเป็นกลุ่มย่อย พัฒนาสิ่งต่างๆ ขึ้นมา แล้วค่อยมาเลือกที่หลังว่าจะนำไปใช้ใน Production หรือไม่ บ่อยครั้งที่พัฒนาสิ่งที่ซ้ำซ้อนกัน ไม่เป็นไรครับ เงินหนาทำได้อยู่แล้ว) โดยทางทีม OLE นั้น ตั้งเงื่อนไขสำหรับ Infrastucture ดังนี้

  1. ต้องเป็น Component Based

  2. ต้องเป็น Object Oriented

  3. ต้องไม่ยึดติดกับภาษาใดภาษาหนึ่ง

  4. ต้องทำให้ process คุยกันได้

    มี 2 ทีมครับ ที่ส่งผลงานเข้าประกวด ทีม COM ปัจจุบัน และทีม Network OLE สุดท้ายทีม COM ก็ชนะไปครับ OLE2 ก็เลยกำเนิดขึ้นภายใต้ Draft Spec ของ COM

    จากนั้นทีม COM ก็เรียบเรียงสิ่งต่างๆ จนสุดท้ายคลอดออกมาเป็น Spec อย่างเป็นทางการเมื่อปี 1993  ซึ่งแนวคิดของ COM มันครอบคลุมงานได้กว้างมาก มีการนำเอา COM มาประยุกต์ใช้งานสิ่งต่างๆ ที่นอกเหนือจาก OLE  จนในที่สุด COM ถือว่าเป็น Infrastructure ที่ทำให้โปรแกรมต่างๆ บน Windows คุยกันได้ Windows ทุกรุ่นจนถึงรุ่นปัจจุบัน ใช้ COM เป็น Infrastructure ในเกือบทุกส่วน อาจจะพูดได้ว่า ถ้าขาด COM ไปเสียหนึ่งอย่าง จะไม่มี Windows รุ่นไหนเลยในยุคปัจจุบันที่ทำงานได้

กว่าจะมาเป็น COM

    COM ไม่ได้สร้างมาจากสิ่งว่างเปล่า COM นำเอาจุดอ่อนของ Technology ในสมัยนั้น มาปรับปรุงแก้ไข จนสามารถรองรับความต้องการใหม่ๆ ได้ เราจะมาย้อนดูที่มาที่ไปของ COM มาดูกันว่า COM เป็น COM ในทุกวันนี้ได้อย่างไร ผมจะเน้นตรงที่ ทีมงานของ COM นั้น ทำอะไรบ้างจนสามารถรองรับความต้องการของทีม OLE

เริ่มกันที่ C++

    ถึงแม้ว่าข้อกำหนดของ OLE นั้น infrastructure จะต้องไม่ขึ้นอยู่กับภาษา แต่การที่ไม่ยึดอะไรเลย มันคงยากในการปฏิบัติ ทีม COM จึงเลือกภาษาหนึ่งเป็นหลัก ซึ่งไม่น่าแปลกใจที่เลือก C++ มันเร็ว และสามารถตอบสนองงานระดับ OS ได้เป็นอย่างดี

รองรับเรื่องความเป็นอิสระต่อภาษา

    การที่สร้าง Infrastructure เป็นอิสระต่อภาษาได้นั้น เราทราบกันดีครับ ต้องทำระดับ compiled Code เมื่อภาษาใดก็ตาม คอมไพล์แล้ว จะไม่เหลือความเป็นภาษานั้น (บน .NET เรารู้กันดีอยู่แล้ว) แต่ก็ยังมีปัญหาครับ ถ้าคอมไพล์ code ของเราในภาษาหนึ่ง เรียกใช้คอมไพล์ code ในอีกภาษา เรียกได้ครับ แต่ต้องใช้มาตรฐานตัวรับและตัวส่งที่เหมือนกัน เช่น การเรียงลำดับ parameter และ การกำหนดชนิดตัวแปรต้องเป็นแนวเดียวกัน นั่นเป็นเหตุผลที่ทำให้ภาษาต่างๆ คุยกันไม่ได้ เพราะใช้กันคนละมาตรฐาน C ก็มีการเรียงลำดับแบบ C ส่วน Pascal ก็มีเป็นแบบของตัวเอง หรือแม้แต่ String ในภาษา C กับ String ในภาษา Pascal ก็มีวิธีเก็บไม่เหมือนกัน ทำให้เชื่อมกันไม่ได้ครับ

    ถึงแม้ว่าจะเป็นภาษาเดียวกันก็ตาม เช่น C++ มันก็ไม่สามารถที่จะเชื่อมกันได้ เพราะแต่ละบริษัท ก็มักนิยมเพิ่มลูกเล่นบางอย่างใส่เข้าไป ต่างคนต่างทำเอง เลยเข้ากันไม่ได้

 

รองรับเรื่อง Object Oriented ในระดับ Binary

    เรื่องนี้เป็นเรื่องยุ่งเหมือนกันครับ เพราะภาษา C++ ถึงแม้ว่า ภายนอกจะยอมให้ผู้ใช้เขียนโปรแกรมเป็น Object Oriented แต่ภายใน compiled code แล้วไม่มีความเป็น Object Oriented ทำสำคัญก็คือไม่มีเรื่องของ Encapsulation การเข้าถึงข้อมูล public private protected นั้นไม่มีระบุใน compiled code เรื่องดังกล่าวผู้ที่ตรวจสอบคือตัว Compiler เท่านั้นครับ ดังนั้น compiled code ของ C++ จึงสอบไม่ผ่านข้อนี้ครับ

    จะไปว่าภาษา C++ ออกแบบไม่ดีคงไม่ได้ เพราะต้นแบบของภาษา C++ นั้น การออกแบบเน้นไปเพื่อทำงานบนเครื่องเดียว ทุกสิ่งทุกอย่าง ถูก คอมไพล์ไปเป็น .exe ตัวเดียว ดังนั้นการมาจัดการอะไรวุ่นวายมากมาย ก็จะทำให้โปรแกรมทำงานช้าลง ซึ่งไม่ควรทำครับในเวลานั้น แต่วันที่ออกแบบ COM โลกเริ่มเปลี่ยนไปอีกแบบ เครื่องเราเร็วขึ้น หน่วยความจำมากขึ้น จุดเด่นของภาษา C++ เริ่มเด่นน้อยลง  สรุปได้ว่าในยุคนั้นยึงคงมีปัญหานี้อยู่ครับ

ต้องเป็น Component Based

    ถ้า Code ของโปรแกรมรวมกันอยู่ใน .exe ตัวเดียว มันคงไม่เพียงพอแน่ สำหรับโลกยุคปัจจุบัน แม้แต่ในยุคที่เริ่มคิดค้น COM นั้น Technology มันก็ก้าวไกลเกินนั้นเยอะแล้วครับ มีการคิดค้น การ Link Program แบบ Dynamic คือ Library ต่างๆ แทนที่จะต้องมารวมตัวกันใน .exe เพียงตัวเดียว เราก็สามารถที่จะเก็บไว้ในที่ .dll แล้วโปรแกรมไหนที่ต้องการเรียกใช้ มาดึงไปใช้เวลารันครับ COM จึงเอาแนวคิดของ .dll มาปัดฝุ่น โดยการนำเอา compiled code ที่เป็นแบบ Object Oriented มาใส่แทนการเก็บเป็นแบบ procedure ธรรมดา แต่จะทำได้อย่างไรก็มาดูกันต่อในบทต่อไปครับ

    แต่ตอนนี้ผมขอเริ่มที่ปัญหาของ C++ ก่อน ก็อย่างที่บอกครับ ว่าภาษา C++ ถูกออกแบบมาสำหรับการทำงานบนเครื่องเดียว ทุกอย่างต้องรวมตัวกันเป็น .exe ตัวเดียว (แต่ในชีวิตจริง แต่ละผู้ผลิตก็เสริมเพิ่มเติมความสามารถเอาเอง ทำให้เก่งขึ้น แต่นั่นก็ไม่ใช่มาตรฐานอยู่ดี) คราวนี้สมมุติว่า ถ้าผมสามารถแบ่งโปรแกรมออกเป็น 2 components ซึ่งแยกกันไปคนละแฟ้มได้ ส่วนแรกที่เป็น .exe จะต้องเรียกส่วนที่ 2 (อาจจะเป็น .dll) ก็ได้ ดูไม่น่าจะมีปัญหาอะไร ผมขอจำลองเหตุการณ์ในอดีตด้วย Source Code ตัวนี้ก็แล้วกัน

test1.cpp

#include <iostream>

class MyClass
{
public:
    int num1;
};

main()
{
    MyClass *m = new MyClass();    
    m->num1 = 10;
    std::cout << m->num1;
}

    นี่เป็น Source Code C++ ธรรมดาครับ ผมสมมุติว่า class MyClass ถูกแยกเป็น .dll ส่วน main() นั้นอยู่ใน .exe  ผมลองคอมไพล์ Code นี้จริงๆ (แต่เป็นแบบรวมแฟ้มเดียว) ด้วย Borland C++ 5.6 ผลลัพธ์เฉพาะบรรทัดที่ มีคำสั่ง new จะได้ Code ที่เป็น Assembly ดังนี้ครับ

push ebp
mov ebp,esp
push 4
call @$bnew$qui
pop ecx

    บรรทัด push 4 นี่คือขนาดของ class MyClass นั่นเอง ภายในมี int  1 ตัว จึงเก็บ 4 bytes จากนั้นก็เรียก function @$bnew$gui  ถ้าใครเคยเขียนโปรแกรมภาษา Assembly จะรู้ได้ทันทีครับ ว่านี้เป็นการส่งพารามิเตอร์ไปให้ฟังก์ชัน @$bnew$gui  ภายในฟังก์ชันนี้ทำอะไรหรือครับ มันก็เพียงเรียกใช้ฟังก์ชัน malloc() เพื่อจองเนื้อที่นั่นเอง ดังนั้นมันจึงจองเนื้อที่ 4 bytes ครับสำหรับ Object ตัวนี้

    แล้วมันมีปัญหาอะไร? ถ้าลำพังทำงานบนเครื่องคอมพิวเตอร์ตัวเดียวก็คงไม่มีปัญหา  แต่ถ้า แยกเป็น 2 ตัวอย่างที่กล่าวไว้ข้างบน จะเห็นว่า code ส่วนที่มีการ new นี้ เป็น Code ที่อยู่ในโปรแกรมหลักที่เป็น .exe มันทำการสร้าง Object ของ MyClass ที่อยู่ใน Component อีกตัวหนึ่ง ปัญหาก็คือ มันเป็นคนกำหนดเลยว่าขนาด Object ใหม่ที่ได้นั้นต้องมีขนาด 4 bytes ซึ่งถ้า MyClass เปลี่ยนแปลง ขนาดเปลี่ยนแปลง แต่ .exe ยังคงคิดว่ามันเป็น 4 bytes อยู่เสมอ แบบนี้รวนแน่ครับ

    ในขั้นต้นนี้ เรามาลองคิดกันเล่นๆ ดูว่า ถ้าเราจะแก้ปัญหานี้ เราจะแก้อย่างไร คิดไม่ยาก (แต่เวลาทำจริงยากหรือเปล่าเป็นอีกเรื่องหนึ่ง) แทนที่เราจะส่ง Parameter เป็นตัวเลข เราก็ส่งเป็นชื่อ Class ที่เราต้องการสร้าง แล้วให้ต้ว Component ไปจัดการเอาเอง จะสร้างขนาดเท่าไหร่ก็ไม่สน สุดท้ายส่ง pointer มาแล้วกันเพื่อบ่งว่า Object นั้นอยู่ตรงไหน

    ดูดีกว่าวิธีแล้วใช่ไหมครับ? แต่วิธีนี้ก็ยังมีปัญหาเยอะอยู่ดี ซึ่งเราคงเรียนกันในบทต่อๆ ไปครับ

  

ต้องสามารถคุยกันข้าม Process กันได้

    เรื่องนี้ถือว่าเป็นเรื่องสำคัญของ OLE เลยที่เดียว มิฉะนั้น การเชื่อมโยงระหว่าง Word กับ Excel หรืออื่นๆ จะเกิดขึ้นไม่ได้ เรื่องการคุยกันข้าม Process (interprocess communication) ก็มีมานานแล้วในยุค UNIX ถ้าว่ากันไปแล้ว UNIX นั้นมี Technology สูงกว่า บน DOS มาก เพราะ DOS ทำงานทีละ Process เท่านั้น แต่สำหรับ UNIX แล้ว เราสามารถทำงานหลายๆ process ในเวลาเดียวกัน ในยุคที่ผมใช้ Linux บน 486 ผมรู้สึกเลยครับว่า เครื่องผมมันเก่งขึ้นมากเมื่อเทียบกับ DOS

    พอมาถึง Windows แนวคิดเรื่องการทำงานพร้อมๆ กัน ก็กลับมาอีก มาถึงวันนี้เราคงเห็นเรื่องการทำงานหลายงานพร้อมกันบน Windows เป็นเรื่องธรรมดา (ธรรมดาบน OS อื่นๆ ในยุคปัจจุบันเช่นกัน) ดังนั้น Microsoft จึงจำเป็นต้องมี Infrastructure สำหรับการคุยกันข้าม Process ซึ่งมาลงตัวกันที่ COM นั่นแหละครับ

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

    การทำงานข้ามเครื่องไม่ใช่เป็นของใหม่เลยครับ แม้แต่ในยุคสมัยนั้น ถ้าเรามองไปทางฝั่ง UNIX  ปรัชญาการออกแบบ UNIX ตั้งแต่เริ่มแรกนั้นเน้นที่มันทำงานข้ามเครื่องอยู่แล้ว ซึ่งการทำงานข้ามเครื่องของ UNIX (ในยุคนั้น) ที่นิยมก็มี 2 แบบครับ

    1) Socket

        การเขียนโปรแกรมโดยใช้ Socket ของ TCP/IP เราคงคุ้นเคยกันดีอยู่แล้ว แต่มาทบทวนกันหน่อยจะได้เปรียบเทียบได้  Socket เป็นระบบเปิด มองในมุมหนึ่งมันคือช่องทางการสื่อสาร ที่เชื่อมเครื่อง 2 เครื่องเข้าด้วยกัน โดยที่ตัวที่เป็น Server นั้น ต้องมีการระบุช่องการสื่อสาร ที่เรียกว่า Port เป็นหมายเลขครับ เมื่อตัว Client ต้องการติดต่อกับ Server ก็ต้องมีการกำหนด เครื่อง Server พร้อมเบอร์ Port ที่ต้องการ เมื่อเชื่อมกันแล้ว จากนั้นจะคุยอะไรกันทั้ง 2 ฝ่าย ก็เป็นหน้าที่ของผู้เขียนโปรแกรมต้องกำหนดเองแล้วครับ จะรับจะส่งอะไรก็ได้ ในการเขียนโปรแกรมแบบ Socket นี้ ความยากคงไม่ได้อยู่ที่วิธีติดต่อ ผมว่ามันยากตรงที่ออกแบบรหัสต่างๆ ให้ทั้ง 2 ฝ่ายใช้

    2) Remote Procedure Call (RPC)

    ถ้าผมจำไม่ผิด Sun เป็นเจ้าแรกที่คิดค้น RPC ในมุมมองของคนออกแบบ RPC นั้น มองว่า การที่จะให้เครื่อง 2 เครื่องคุยกันได้นั้น ถ้าใช้ Socket บางทีมันดูยุ่งยากเกินไป ไหนจะต้องเตรียมการติดต่อ ไหนต้องออกแบบรหัสในการสื่อสาร และอื่นๆ อีก ซึ่งยุ่งยากมากสำหรับโปรแกรมเมอร์ ทำไมเราไม่ทำอะไรให้ง่ายเข้า ทำให้โปรแกรมเมอร์รู้สึกว่า การเรียกโปรแกรมข้ามเครื่องนั้น ก็เป็นเพียงแค่เรียกใช้ procedure ธรรมดาเท่านั้น ไม่มีอะไรซับซ้อน แต่แท้ที่จริงแล้วผู้ที่รัน procedure ตัวนั้นไม่ใช่เครื่องเรา แต่หากเป็นเครื่อง Server ถ้าว่าการทางเทคนิคแล้วละก็ ตัว RPC ก็อาศัย Socket เป็นทางผ่านนั่นเอง แต่โปรแกรมเมอร์ไม่จำเป็นต้องรู้อะไรเกี่ยวกับ Socket เลยครับ

    สิ่งที่ COM จะทำในยุคนั้น จะสูงกว่า RPC อยู่ขั้นหนึ่งครับ เราอาจจะเรียกว่า Remote Object Call ก็ไม่น่าจะผิดนัก แทนที่จะเรียกใช้ในระดับ procedure ก็เขากำลังสร้าง Infrastructure แบบ Object Oriented อยู่นี่ครับ การทำงานข้ามเครื่องก็เลยเป็น เข้าลักษณะการเรียกใช้งาน Object ข้ามเครื่อง (ถ้าใครคุ้นกับ Web Service ก็คงเริ่มรู้สึกแล้วว่า มันก็เรื่องเดียวกันกับ Web Service นั่นเอง)

    แต่การเรียกใช้ Object ข้ามเครื่องนั้น ก็ยังไม่ได้ทำไปเพื่อตอบสนองอะไรอย่างชัดเจนนัก เพราะจริงๆ แล้ว การเชื่อมโยงข้ามโปรแกรมบนเครื่องเดียวกันสำคัญกว่า เราจะเอา Sheet ของ Excel โอนข้ามไปใน Word ได้อย่างไร นั่นคือเป้าหมายหลักของ COM ในยุคนั้นครับ

    ย้อนกลับมา C++ ที่ทีมของ COM เอามาเป็นต้นแบบ เราจะเห็นปัญหาครับ ปัญหาก็มาจากรากเดียวกันกันข้างต้น คือ compiled code ของ C++ นั้น เน้นที่ความเร็ว ดังนั้น Client จึงเป็นผู้ที่จับแพะชนแกะทำทุกอย่าง ไม่มีการแบ่งข้อต่ออย่างชัดเจนนัก  เรามาลองดูตัวอย่างกันครับ จะได้เห็นภาพ

test1.cpp

#include <iostream>

class MyClass
{
public:
    int num1;
};

main()
{
    MyClass *m = new MyClass();    
    m->num1 = 10;
    std::cout << m->num1;
}

ถ้าดูเฉพาะบรรทัด MyClass *m = new MyClass() จะได้ Code ที่ Compiled ดังนี้ครับ

push ebp
mov ebp,esp
push 4
call @$bnew$qui
pop ecx

    Code ภาษา Aseembly  นี้ ได้มาจาก Borland C++ 5.6 ถ้าใช้คอมไพเลอร์ตัวอื่นก็คงทำนองนี้ Code นี้มีอะไรน่าสนใจหรือ? ลองดูนะครับ ที่บรรทัด push 4 นี่คือขนาดของ class MyClass นั่นเอง ภายในมี int  1 ตัว จึงเก็บ 4 bytes จากนั้นก็เรียก function @$bnew$gui  ถ้าใครเคยเขียนโปรแกรมภาษา Assembly จะรู้ได้ทันทีครับ ว่านี้เป็นการส่งพารามิเตอร์ไปให้ฟังก์ชัน @$bnew$gui  ภายในฟังก์ชันนี้ทำอะไรหรือครับ มันก็เพียงเรียกใช้ฟังก์ชัน malloc() เพื่อจองเนื้อที่นั่นเอง ดังนั้นมันจึงจองเนื้อที่ 4 bytes ครับสำหรับ Object ตัวนี้

    แล้วมันมีปัญหาอะไร? ถ้าลำพังทำงานบนเครื่องคอมพิวเตอร์ตัวเดียวก็คงไม่มีปัญหา แต่ถ้าต้องเรียกข้ามเครื่อง หรือจะเครื่องเดียวกันแต่เป็นคนละโปรแกรมก็ตาม โปรแกรมจะถูกแยกออกเป็น 2 ส่วน ส่วนที่เป็น Client และส่วนที่เป็น Server ซึ่งต่างคนก็มีการคอมไพล์อิสระ ถ้าในรุ่นแรกเรารู้ว่า Code ที่ฝั่ง Server นั้น ขนาดของ Object นั้น ต้องจองเนื้อที่ 1000 bytes ในโปรแกรมก็ไม่มีปัญหา push 1000 ใส่เข้าไป แต่ถ้ามีการปรับปรุง class นั้น ทำให้ object ใหญ่ขึ้น เป็น 1200 แต่โปรแกรมฝั่ง Client คุณไม่ได้คอมไพล์ใหม่ มันก็ยังคงคิดว่า เป็น 1000 ซึ่งส่งผลให้ทำงานรวนแน่ครับ

ทิ้งท้าย

    เราเห็นปัญหาที่ท้าทายทีมของ COM แล้ว ในบทต่อๆ ไป เราจะมาเรียนรู้หน้าตาของ COM ว่ามันเป็นอย่างไร แล้วมันจะแก้ไขปัญหาที่กล่าวมาข้างต้นได้อย่างไรบ้าง แต่ผมขอบทแทรก ในบทหน้านี้ก่อน อยากจะคุยถึงเรื่อง Remote Procedure Call ของ UNIX เพราะไม่ว่า COM COM+ CORBA RMI หรือแม้กระทั่ง Web Services ก็ล้วนแล้วแต่นำเอาแนวคิดของ Remote Procedure Call ไปต่อยอดทั้งสิ้น

 

Supoj

31/JUL/02