ทำความเข้าใจกับ XML เว็บเซอร์วิส (Web Services) และ SOA

XML และ Web Services ภาษากลางสำหรับการแลกเปลี่ยนข้อมูล

ปัจจุบันโปรแกรมคอมพิวเตอร์ถูกแยกออกเป็นหลายรูปแบบ หลายประเภท แต่ละประเภทก็มีเครื่องมือและภาษาโปรแกรมในการสร้างขึ้นมาเป็นของตนเอง ถ้าเราลองแยกกลุ่มโปรแกรมคอมพิวเตอร์ตามเครื่องมือหรือภาษาโปรแกรมยอดนิยมที่ใช้ในการพัฒนาโปรแกรม ปัจจุบันอาจจะแบ่งออกมาได้เป็น 3 ค่ายใหญ่ๆ ได้แก่ Java, .NET และพวก Opensource อื่นๆ พวก Opensource อื่นๆในที่นี้หมายความรวมถึงกลุ่มเล็กกลุ่มน้อยที่ใช้ภาษาโปรแกรมเฉพาะทางเพื่อทำงานที่มีลักษณะเฉพาะเป็นตนเอง เช่น ภาษา PHP ที่เหมาะสำหรับการทำเว็บ หรือภาษา Python ที่มีประสิทธิภาพสูงในงานวิศวกรรม เป็นต้น

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

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

แม้ว่า XML และ Web Services จะเกิดขึ้นมาได้เกือบ 10 ปีแล้วก็ตาม แต่การนำมาใช้เชื่อมต่อระบบเข้าด้วยกันอย่างแท้จริงในหน่วยงานต่างๆ ก็ยังคงเป็นไปอย่างค่อยเป็นไป จากเท่าที่สำรวจดู เหตุผลก็เนื่องจากในหลายหน่วยงานยังอยู่ระหว่างการเรียนรู้ และค่อยๆนำไปทดแทนเทคโนโลยีดั้งเดิมที่ใช้งานอยู่ และถึงกระนั้นก็ตามคาดว่าในอนาคตข้างหน้า เราจะพบว่าระบบสารสนเทศส่วนใหญ่จะมีส่วนเชื่อมต่อที่เป็น Web Services ประกอบเข้าเป็นส่วนหนึ่งของระบบด้วยเกือบทุกระบบ

เอกสารฉบับนี้เหมาะสำหรับผู้ที่อยู่ระหว่างการเริ่มต้นใช้งาน XML และ Web Services เพื่อแลกเปลี่ยนข้อมูลระหว่างระบบสารสนเทศที่ผลิตมาจากต่างค่ายต่างแพลตฟอร์ม โดยจะพาท่านผู้อ่านเดินไปทีละขั้นเพื่อให้เห็นภาพอย่างครบวงจรว่าเราสามารถแลกเปลี่ยนข้อมูลกันด้วยวิธี XML และ Web Services ได้อย่างไร หากท่านผู้อ่านเป็นผู้ที่เคยมีประสบการณ์ด้านคอมพิวเตอร์มาแล้วอย่างโชกโชน แต่ยังไม่เคยศึกษาด้าน XML และ Web Services เอกสารฉบับนี้จะช่วยให้ท่านเข้าใจวิธีการแบบ Web Services ได้อย่างง่ายดาย ถือว่าเป็นความรู้เพิ่มเติมสำหรับท่าน แต่หากท่านผู้อ่านเป็นผู้ที่เคยประสบกับความยากลำบากในการแลกเปลี่ยนข้อมูลระหว่างระบบสารสนเทศ รวมทั้งเคยพยายามใช้ XML หรือ Web Services แล้วติดปัญหาเนื่องจากไม่เข้าใจชิ้นส่วนแต่ละชิ้นอย่างถ่องแท้ ต้องขอบอกว่าเอกสารฉบับนี้น่าจะช่วยให้ท่านทลายกำแพงอุปสรรคเหล่านั้น และสามารถกำหนดกลยุทธ์ในการแลกเปลี่ยนข้อมูลที่จะเกิดขึ้นในอนาคตได้อย่างไม่ผิดพลาด

กรณีศึกษาระบบห้องสมุด

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

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

จากตัวอย่างข้างต้น แสดงให้เห็นว่าระบบอื่นจะต้องเชื่อมต่อเข้ามาเอาข้อมูลสถานะการยืม-คืนหนังสือ จากระบบห้องสมุด ซึ่งถ้าเป็นการเชื่อมโยงระบบแบบดั้งเดิมที่ไม่ใช่ XML หรือ Web Services ลักษณะเช่นนี้จะต้องพูดคุยกันหลายฝ่าย ทั้งฝ่ายไอทีที่รับผิดชอบงานทะเบียนและฝ่ายไอทีที่เป็นผู้รับผิดชอบระบบห้องสมุด หากเป็นองค์กรขนาดใหญ่เรื่องอาจจะยุ่งยากมากขึ้นอีก เพราะระบบไอทีทั้งหลายถูกพัฒนาขึ้นโดยผู้ผลิตหลายรายที่เข้ามารับจ้างผลิตให้ ซึ่งท่านจะเห็นแล้วว่า แค่เราต้องการสถานะการยืมคืนจากห้องสมุด ทำไมเรื่องที่ดูเหมือนจะง่ายเช่นนี้ จึงกลับกลายเป็นเรื่องยุ่งยากทันทีถ้าหากเป็นองค์กรขนาดใหญ่ที่มีระบบไอทีหลากหลาย

การประชุมเพื่อขอแลกเปลี่ยนข้อมูล

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

การแลกเปลี่ยนข้อมูลด้วยวิธีการ XML และ Web Services จะช่วยลดปัญหาข้างต้นนี้ได้อย่างชัดเจน เนื่องจากสิ่งที่นักเทคนิค จำเป็นต้องพูดคุยกันเพื่อขอแลกเปลี่ยนข้อมูลมีเพียง 2 ประเด็น เท่านั้น คือ 1) ข้อมูลแบบไหน (XML Schema) และ 2) กระบวนการอะไร (Operation)

หากยกตัวอย่างระบบห้องสมุดข้างต้น สมมุติว่าปัจจุบันระบบห้องสมุดเป็นระบบที่สร้างขึ้นจากแพลตฟอร์ม Microsoft .NET ส่วนระบบงานทะเบียนเป็นระบบที่สร้างขึ้นจากแพลตฟอร์ม Java และเพื่อให้เห็นชัดเจนยิ่งขึ้นไปอีกว่าวิธีการแบบ XML และ Web Services ไม่ได้อ้างอิงค่ายใดค่ายหนึ่ง เราจะขอสมมุติว่ามีกลุ่มที่สามที่ต้องการข้อมูลนี้ด้วย คือกองกิจการนักศึกษา ซึ่งรับผิดชอบหน้าเว็บประจำตัวนักศึกษา จะต้องนำข้อมูลการยืม-คืนหนังสือ ไปแสดงผลที่หน้าเว็บประจำตัวนักศึกษาด้วย โดยปัจจุบันฝ่ายไอทีของกองกิจการนักศึกษา สร้างหน้าเว็บด้วยแพลตฟอร์ม PHP เพราะฉะนั้นภาพการเชื่อมต่อระบบที่เกิดขึ้นจะเป็นดังนี้

รูปภาพ 1 ตัวอย่างการขอข้อมูลข้ามระบบที่ต่างแพลตฟอร์ม

จากภาพข้างต้นเราจะเห็นว่า ผู้ที่เป็นฝ่ายให้ข้อมูลก็คือระบบห้องสมุด ส่วนผู้ที่เป็นคนนำข้อมูลไปใช้ก็คือ ระบบทะเบียน และ กองกิจการนักศึกษา ซึ่งในโลกของ SOA (Service-Oriented Architecture) เราจะเรียกฝ่ายที่ให้ข้อมูลว่าเป็น Service Provider และฝ่ายที่เป็นผู้ขอข้อมูลไปใช้ว่าเป็น Service Consumer ดังนั้นในที่นี้ ระบบห้องสมุดจึงเป็น Service Provider ส่วนระบบลงทะเบียนและกองกิจการนักศึกษา ก็จะเป็น Service Consumer นั่นเอง

หากเราไม่ใช้วิธีการแบบ XML และ Web Services การขอข้อมูลเช่นในภาพข้างต้นจะประสบปัญหายุ่งยากหลายอย่างอันเนื่องมาจากความแตกต่างของแพลตฟอร์ม เพราะจะเห็นว่าทั้ง 3 ระบบดำเนินการอยู่บนแพลตฟอร์มที่แตกต่างกัน สิ่งที่เป็นปัญหาใหญ่ที่อาจจะพบก็คือ ทั้งฝ่ายผู้ให้ข้อมูลและผู้ขอข้อมูลจะต้องยอมรับร่วมกันใน 2 เรื่อง คือ 1) รูปแบบข้อมูล (Data Model) ต้องเข้าใจตรงกัน และ 2) วิธีการรับ-ส่งข้อมูล (Communication Protocol) ที่จะใช้ร่วมกัน

รูปภาพ 2 ปัญหาด้านเทคนิคที่ต้องตกลงร่วมกัน เมื่อจำเป็นต้องแลกเปลี่ยนข้อมูลข้ามระบบ

จากตัวอย่างข้างต้นเราจะเห็นแล้วว่า ไม่ว่าจะเลือกใช้วิธีการส่งข้อมูลแบบไหน หรือจะใช้เนื้อหาข้อมูลเป็นเช่นไร แต่การแลกเปลี่ยนข้อมูลจะสำเร็จได้ก็ต่อเมื่อนักเทคนิคทั้งสองฝ่ายยอมใช้วิธีการเดียวกันในการส่งและการรับข้อมูล

ในตัวอย่างข้างต้น หากนักเทคนิคของระบบทะเบียนถนัด Java และพยายามจะใช้วิธีการ RMI/IIOP ในการสื่อสารข้อมูล แต่ทางนักเทคนิคของระบบห้องสมุดถนัด .NET และต้องการใช้วิธีการ COM+ ในการสื่อสารข้อมูล หากเป็นเช่นนี้ก็จะทำให้แลกเปลี่ยนข้อมูลกันไม่ได้ เพราะทั้งสองฝ่ายใช้เทคนิคที่แตกต่างกัน ซึ่งถ้าท่านพบว่าการประชุมเพื่อแลกเปลี่ยนข้อมูลเริ่มกลายเป็นความขัดแย้งด้านเทคนิคแล้วละก็ วิธีการ XML และ Web Services จะกลายเป็นทางออกที่ดีที่สุดในการแก้ปัญหาเช่นนี้

ทางออกร่วมกันที่เป็นแบบ XML และ Web Services

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

เนื่องจากปัจจุบัน ทุกแพลตฟอร์มต่างก็จัดเตรียมเครื่องมือสำหรับ XML และ Web Services ไว้ให้กับนักพัฒนาระบบอยู่แล้ว เช่น นักเทคนิคที่ดูแลระบบทะเบียนด้วยภาษา Java จะทราบว่า Java สามารถส่งข้อมูลให้กับ Web Services ได้ด้วย JAX-RPC หรือ JAX-WS และสามารถเล่นกับข้อมูล XML ที่เข้ามาได้ด้วย JAXP

ส่วนนักเทคนิคที่ดูแลระบบห้องสมุดด้วย .NET ก็อาจจะรู้ว่า .NET สามารถสร้างเว็บเซอร์วิส ได้ง่ายๆโดยการใส่แอททริบิวท์ [Web Method] เข้าไปที่หัวฟังก์ชัน เป็นต้น ส่วนทางด้านกองกิจการนักศึกษา ที่ปัจจุบันสร้างหน้าเว็บด้วย PHP อยู่ก็สามารถใช้คลาสที่ชื่อว่า SOAPClient ที่มีอยู่ใน PHP อยู่แล้ว ดึงข้อมูลจาก Web Services ไปแสดงผลที่หน้าเว็บได้

รูปภาพ 3 การแลกเปลี่ยนข้อมูลด้วยวิธีการ XML และ Web Services ที่ได้รับการสนับสนุนจากแพลตฟอร์มใหญ่ทั้ง 3 แพลตฟอร์ม

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

1.       รูปแบบข้อมูลที่ต้องการ

·      โดยเขียนกำหนดไว้ในเอกสารที่เรียกว่า XML Schema Definition (XSD) และ

2.       ฟังก์ชันในการแลกเปลี่ยนข้อมูลที่ต้องการ

·      ว่าต้องการให้มีฟังก์ชันอะไรบ้าง โดยเขียนกำหนดไว้ในเอกสารที่เรียกว่า Web Services Description Language (WSDL)

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

รูปภาพ 4 ตัวอย่างลำดับการประชุมเพื่อแลกเปลี่ยนข้อมูลแบบ XML และ Web Services ของนักเทคนิคทั้ง 3 ฝ่ายที่ได้ผลลัพธ์เป็นรูปธรรม

และผลลัพธ์ที่เกิดขึ้นจากการประชุมเพื่อแลกเปลี่ยนข้อมูลก็คือไฟล์ XSD และ WSDL ที่จะใช้เป็นมาตรฐานร่วมกัน ทั้ง 2 ไฟล์นี้จะถูกวางไว้บนอินทราเน็ต (หรืออินเตอร์เน็ต) ณ ตำแหน่งที่ทั้ง 3 ฝ่ายจะสามารถมาดาวน์โหลดไปใช้งานได้ แต่โดยส่วนใหญ่แล้วระบบที่เป็นผู้ให้บริการจะเป็นผู้จัดเตรียมและวางไฟล์ทั้ง 2 ตัวนี้ไว้ให้ ในที่นี้ระบบผู้ให้บริการคือระบบห้องสมุด ดังนั้น ผู้ดูแลระบบห้องสมุดอาจจะวางไฟล์ทั้ง 2 ไฟล์นี้ไว้ให้เช่นนี้

รูปภาพ 5 ตัวอย่างการวางไฟล์ XSD และ WSDL ไว้บนอินทราเน็ตเพื่อให้ใช้เป็นมาตรฐานร่วมกัน

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

ในเอกสารฉบับนี้จะใช้ตัวอย่างระบบห้องสมุดข้างต้น โดยสมมุติว่าหลังจากประชุมเสร็จแล้ว นักเทคนิคทั้ง 3 ฝ่ายได้เขียนไฟล์ XSD และไฟล์ WSDL ขึ้นมาเป็นไฟล์ชื่อว่า library.xsd และ library.wsdl ตามลำดับ โดยภายในไฟล์ทั้งสองไฟล์นี้ จะมีรายละเอียดที่เราจะใช้ศึกษาร่วมกันในหัวข้อถัดไป

ขอใช้บริการอะไรได้บ้าง คำตอบอยู่ในไฟล์ WSDL

ไฟล์ WSDL (Web Services Description Language) เป็นไฟล์ที่เป็นหัวใจสำคัญที่สุดของ Web Services ถ้าเปรียบเทียบกับเวลาเราไปสั่งอาหารที่ร้านอาหาร ถ้าเราไม่คุ้นเคยกับร้านนั้นมาก่อน เราจะขอเมนูอาหารมาดูว่าร้านนั้นสามารถทำอาหารอะไรให้เรารับประทานได้บ้างหลังจากนั้นจึงเลือกสั่งอาหารตามที่มีอยู่ในเมนู สำหรับในโลกของ SOA ไฟล์ WSDL ก็เป็นเช่นเดียวกับเมนูอาหารนั่นเอง โดยไฟล์ WSDL จะช่วยให้ผู้ขอใช้บริการรู้ได้ว่า ผู้ให้บริการสามารถทำอะไรให้ได้บ้าง และขอใช้บริการตามที่มีให้เลือกอยู่ในไฟล์ WSDL

จากกรณีศึกษาระบบห้องสมุด สมมุติว่าหลังจากการประชุมร่วมกันแล้ว เราได้ไฟล์ library.wsdl ออกมาเป็นเช่นในซอร์สโค้ดต่อไปนี้ ผู้อ่านที่พึ่งเข้าสู่โลกของ SOA อย่าพึ่งตกใจกับรายละเอียดจำนวนมากที่ปรากฏในไฟล์ WSDL นี้เพราะแท้ที่จริงแล้วสิ่งที่เราต้องการรู้จากไฟล์นี้มีเพียงแค่ มันมีอะไรให้ใช้บ้าง ดังนั้นจึงเข้าใจได้ไม่ยาก แต่ในเอกสารฉบับนี้ต้องการให้เห็นภาพเต็มที่สมบูรณ์ จึงคัดลอกทั้งหมดของไฟล์มาให้ดู

ซอร์สโค้ด 1 ไฟล์ library.wsdl

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://www.examples.ac.th/library/service" xmlns:lib="http://www.example.ac.th/library/info" targetNamespace="http://www.examples.ac.th/library/service">

    <wsdl:types>

       <xs:schema>

           <xs:import namespace="http://www.example.ac.th/library/info" schemaLocation="library.xsd"/>

       </xs:schema>

    </wsdl:types>

    <wsdl:message name="getBorrowingStatusRequest">

       <wsdl:part name="parameter" element="lib:getBorrowingStatus"/>

    </wsdl:message>

    <wsdl:message name="getBorrowingStatusResponse">

       <wsdl:part name="parameter" element="lib:borrowingStatus"/>

    </wsdl:message>

    <wsdl:message name="getBorrowingDetailsRequest">

       <wsdl:part name="parameter" element="lib:getBorrowingDetails"/>

    </wsdl:message>

    <wsdl:message name="getBorrowingDetailsResponse">

        <wsdl:part name="parameter" element="lib:borrowingDetails"/>

    </wsdl:message>

    <wsdl:portType name="LibrarySystem">

       <wsdl:operation name="getBorrowingStatus">

           <wsdl:input message="tns:getBorrowingStatusRequest"/>

           <wsdl:output message="tns:getBorrowingStatusResponse"/>

       </wsdl:operation>

       <wsdl:operation name="getBorrowingDetails">

           <wsdl:input message="tns:getBorrowingDetailsRequest"/>

           <wsdl:output message="tns:getBorrowingDetailsResponse"/>

       </wsdl:operation>

    </wsdl:portType>

    <wsdl:binding name="LibraryServiceBinding" type="tns:LibrarySystem">

       <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

       <wsdl:operation name="getBorrowingStatus">

           <soap:operation soapAction="http://www.example.ac.th/library#getBorrowingStatus"/>

           <wsdl:input>

              <soap:body use="literal"/>

           </wsdl:input>

           <wsdl:output>

              <soap:body use="literal"/>

           </wsdl:output>

       </wsdl:operation>

       <wsdl:operation name="getBorrowingDetails">

           <soap:operation soapAction="urn:http://www.example.ac.th/library#getBorrowingDetails"/>

           <wsdl:input>

              <soap:body use="literal"/>

           </wsdl:input>

           <wsdl:output>

              <soap:body use="literal"/>

           </wsdl:output>

       </wsdl:operation>

    </wsdl:binding>

    <wsdl:service name="LibraryService">

       <wsdl:port name="LibraryPort" binding="tns:LibraryServiceBinding">

           <soap:address location="http://www.example.ac.th/library"/>

       </wsdl:port>

    </wsdl:service>

</wsdl:definitions>

ไฟล์ library.wsdl ข้างต้นนี้แม้ว่าจะมีรายละเอียดมากมาย ซึ่งหากเปรียบไปแล้วก็เหมือนกับเมนูอาหารที่มีแต่ชื่ออาหารที่เราไม่รู้จัก แต่สำหรับผู้ที่เคยสั่งอาหารเดิมๆรับประทาน จะรู้อยู่แล้วว่าเราไม่จำเป็นต้องรู้จักอาหารทุกชนิดในเมนู เพียงแค่พอรู้ว่ามีอาหารที่เราต้องการหรือไม่ หากมีก็จะได้สั่งอาหารนั้นทานได้ ดังนั้นหากผู้อ่านติดตามไปอีกเพียงไม่กี่หัวข้อ ก็จะเข้าใจว่าในไฟล์นี้เขียนอะไรไว้

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

Web Services เปิดให้บริการอยู่ที่ไหน

ก่อนอื่นขอให้ท่านอย่าพึ่งสนใจรายละเอียดมากมายในไฟล์ WSDL และดูตามไปทีละส่วน โดยส่วนแรกสุดคือแท็กที่เขียนว่า service และ location ซึ่งจะปรากฏที่ด้านล่างของไฟล์ WSDL ดังนี้

รูปภาพ 6 การดูตำแหน่งที่ Web Services เปิดให้บริการจากไฟล์ WSDL

เราจะเห็นว่าที่ location จะบอกไว้อย่างชัดเจนว่าปัจจุบัน Web Services ที่ชื่อว่า LibraryService ตัวนี้ กำลังเปิดให้บริการอยู่ที่ http://www.example.ac.th/library ซึ่งก็หมายความว่าหากเราส่งข้อมูลที่ถูกต้องเข้าไปที่ตำแหน่ง URL นี้ ก็ย่อมจะได้รับผลลัพธ์ตอบกลับมา

จะขอใช้บริการอะไรได้บ้าง

หากเราอยากทราบว่า Web Services ตัวนี้ให้บริการอะไรได้บ้าง เราไล่ดูขึ้นมาที่แท็ก operation ที่อยู่ในแท็ก binding ดังนี้

รูปภาพ 7 การดูว่า Web Services ให้บริการอะไรได้บ้าง โดยดูที่ operation ในไฟล์ WSDL

จากภาพเนื้อหาบางส่วนในไฟล์ library.wsdl ข้างต้นนี้บอกให้ เรารู้ว่า LibraryService มีบริการให้เราเพียงแค่ 2 อย่างเท่านั้นคือ getBorrowingStatus และ getBorrowingDetails ซึ่งวิธีการที่จะสั่งให้กระบวนการทั้ง 2 อย่างนี้ทำงานให้เรานั้น เราจะต้องส่งข้อมูลที่เป็น XML แบบ SOAP เข้าไปที่ตำแหน่ง location ที่ระบุไว้

ตอนนี้ท่านผู้อ่านยังไม่ต้องกังวลว่า XML แบบ SOAP นี้คืออะไร เพราะในหัวข้อถัดไปจะแสดงตัวอย่างให้เห็น และคาดว่าผู้อ่านสามารถเข้าใจได้ไม่ยากนัก

จะต้องแลกเปลี่ยนข้อมูลอะไรบ้าง

ในแต่ละกระบวนการของ Web Services จะบอกให้รู้ว่ามันต้องการข้อมูลอะไร (Input) และหากกระบวนการทำงานเสร็จสิ้น มันจะส่งผลลัพธ์กลับมาเป็นข้อมูลอะไร (Output) โดยในไฟล์ WSDL จะเขียนบอกไว้อย่างชัดเจนที่บริเวณแท็ก operation ภายใต้แท็ก portType ดังต่อไปนี้

รูปภาพ 8 การสังเกตที่ message ของ input และ output ทำให้รู้ว่าหากต้องการขอใช้บริการต้อง ส่ง-รับ ข้อมูลอะไร

เมื่อมาถึงขั้นตอนนี้หากท่านผู้อ่านเข้าใจทั้งเรื่องของ service, location, operation และ input, output แล้ว ท่านจะพบว่าแท้ที่จริงในไฟล์ WSDL ก็เป็นเช่นเดียวกับการออกแบบระบบไอทีแบบดั้งเดิมที่เคยทำกันมา

เพียงแต่การออกแบบระบบไอทีแบบดั้งเดิมนั้นเรามักจะเขียนบรรยายฟังก์ชันงานของระบบไว้อย่างไม่เป็นรูปแบบมาตรฐาน เช่น บางทีมงานเขียนเป็นตารางใส่ไว้ในไฟล์ MS Word หรือบางทีมก็เขียนเป็นภาพไดอะแกรมใส่ไว้ในไฟล์ Visio ซึ่งทำให้ระบบภายนอกที่จะเชื่อมต่อเข้ามาในภายหลัง ไม่สามารถสำรวจและทำความเข้าใจได้ว่าระบบเรามีบริการอะไรอยู่บ้าง แต่สำหรับในโลกของ SOA แล้ว เพียงแค่เราได้ไฟล์ WSDL มา เราก็สามารถทราบได้ทันทีว่าระบบไอทีของเค้าสามารถให้บริการอะไรกับเราได้บ้าง

รายละเอียดด้านข้อมูล

ในหัวข้อที่ผ่านเราไล่ติดตามดูแท็ก operation ที่อยู่ในไฟล์ WSDL จนทำให้ทราบว่า Web Services นั้นมีบริการอะไรให้ใช้ แต่ในระดับรายละเอียดแล้ว การจะใช้บริการเหล่านั้นได้ จำเป็นต้องส่งข้อมูลที่ตรงตามรูปแบบที่ผู้ให้บริการกำหนดไว้เท่านั้น ดังนั้นในไฟล์ WSDL จึงมีอีก 2 ส่วนที่เรายังไม่ได้ดูกัน นั่นก็คือแท็ก message และแท็ก types ซึ่งทั้ง 2 ส่วนนี้ เป็นตัวกำหนดรูปแบบข้อมูลที่จะใช้ในการแลกเปลี่ยน โดยจะไปดึงเอาไฟล์ XML Schema Definition (XSD) มาใช้งานร่วมกันด้วย

จากรูปภาพ 8 สังเกตว่ากระบวนการ getBorrowingStatus ต้องการรับ input เป็น message ชื่อว่า getBorrowingStatusRequest คำถามก็คือ แล้วเราจะรู้ได้อย่างไรว่า message ตัวนี้มีหน้าตา XML เป็นยังไง คำตอบก็คือ ให้เราไล่ขึ้นไปดูที่แท็ก message ที่มีชื่อว่า getBorrowingStatusRequest และดูต่อเนื่องไปตามลำดับเช่น ดังที่ปรากฏในภาพต่อไปนี้

รูปภาพ 9 การวิเคราะห์ว่า operation ของ Web Services ต้องการข้อมูล XML ที่มีรูปแบบเป็นอย่างไร

ถ้าไล่ดูไปตามลำดับลูกศรที่ปรากกในรูปภาพ 9 จะเห็นว่า message ที่ชื่อว่า getBorrowingStatusRequest  ประกอบด้วย element ที่ชื่อว่า getBorrowingStatus และหากเราไปเปิดไฟล์ library.xsd ตามหาอีลีเมนต์ที่ชื่อว่า getBorrowingStatus จนพบ จะทำให้เราสามารถร่างโครงร่างของแท็ก XML ที่ใช้ส่งข้อมูลได้ดังนี้

รูปภาพ 10 การวิเคราะห์ XML Schema เพื่อให้ทราบถึงรูปแบบข้อมูล XML ที่จะส่งให้กับ Web Services

จากตัวอย่างนี้ ท่านจะเห็นแล้วว่า element และ type ที่เขียนอยู่ในไฟล์ XML Schema จะเป็นตัวกำหนดโครงร่างของแท็ก XML ที่จะเกิดขึ้นว่าจะมีหน้าตาเป็นอย่างไร ในที่นี้เมื่อสำรวจที่ element ที่ชื่อว่า getBorrowingStatus และ element ที่ชื่อว่า borrowingStatus จะทำให้เรารู้ว่าหากต้องการขอใช้กระบวนการ getBorrowingStatus ของตัว LibraryService จะต้องแลกเปลี่ยนข้อมูล XML ที่มีรูปแบบดังนี้

รูปภาพ 11 การวิเคราะห์ element และ type ใน XML Schema ทำให้ทราบ input และ output ของ Web Services

ในภาพข้างต้นแสดงให้เห็นว่า ระบบทะเบียนส่ง XML แท็ก <getBorrowingStatus> ไปพร้อมกับรหัสนักศึกษา เมื่อระบบห้องสมุดได้รับแท็กนี้มา จะเข้าใจได้ทันทีว่าต้องการให้ตรวจสอบสถานะการยืมหนังสือของนักศึกษาที่ตรงกับรหัสนักศึกษาที่ส่งมาให้ และส่งผลลัพธ์กลับไปเป็นสถานะ true หรือ false ด้วยแท็ก <overdue> ที่อยู่ในแท็ก <borrowingStatus>

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

อย่าลืมใส่ซองจดหมาย (Envelope)

จากการวิเคราะห์แท็ก element และ type ในไฟล์ XSD ทำให้เรารู้ว่าจะส่งข้อมูล XML อะไร และจะได้รับข้อมูล XML อะไรกลับมาจาก Web Services แต่หากจะส่งข้อมูลจริงๆ เราจะต้องไม่ลืมเอาข้อมูล XML นี้ใส่เข้าไปในแท็ก <Body> ของ SOAP เสียก่อน

เนื่องจาก SOAP (Simple Object Access Protocol) ถูกใช้เป็นมาตรฐานกลางในการสื่อสารข้อมูลกับ Web Services ดังนั้นเราไม่สามารถส่ง XML เปิดผนึกเช่นในรูปภาพ 11 ตรงเข้าไปให้กับ Web Services ได้ แต่เราจะต้องนำ XML ใส่เข้าไปในซองจดหมายของ SOAP เสียก่อนดังนี้

รูปภาพ 12 การนำข้อมูล XML ส่งไปกับโปรโตคอล SOAP โดยใส่เข้าไปในแท็ก <Body> ของ <Envelope>

ที่เรียกว่าซองจดหมายก็เพราะว่า เมื่อปลายทางได้รับข้อมูล Envelope มาแล้ว เค้าจะต้องเปิดซอง โดยนำข้อมูล XML เฉพาะที่อยู่ตรงกลางแท็ก <Body> เท่านั้นไปใช้งาน

ส่วนข้อมูล XML ที่อยู่ในแท็ก <Header> นั้นส่วนใหญ่จะใช้สำหรับควบคุมการสื่อสารให้มีประสิทธิภาพสูงขึ้นเท่านั้น โดยไม่เกี่ยวข้องอะไรกับข้อมูลที่เราต้องการจากผู้ให้บริการ

แพลตฟอร์มอะไรก็ขอใช้บริการจาก Web Services ได้

ท่านจะเห็นแล้วว่าเพียงแค่ผู้ขอใช้บริการสามารถส่งข้อมูล XML ใส่ซองจดหมายแบบ SOAP ไปยังผู้ให้บริการได้ถูกต้องตรงตามที่กำหนดไว้ในไฟล์ WSDL และไฟล์ XSD ผู้ให้บริการก็จะดำเนินการให้ตามกระบวนการที่ร้องขอมา และส่งผลลัพธ์ตอบกลับมาเป็น XML โดยเก็บอยู่ในซองจดหมายแบบ SOAP เช่นเดียวกัน

ด้วยวิธีการแลกเปลี่ยนข้อมูลที่เป็น XML เช่นนี้ ทำให้ Web Services กลายเป็นมาตรฐานเปิด ที่ไม่ว่าโปรแกรมประเภทใดก็ตามที่สามารถส่งข้อมูลตัวอักษร (Text) ผ่านเน็ตเวิร์คได้ ก็ถือว่ามีความสามารถเพียงพอแล้วที่จะขอใช้บริการจาก Web Services ได้ โดยไม่ถูกจำกัดด้วยเรื่องเทคโนโลยีชั้นสูง และนี่คือเหตุผลว่าทำไมปัจจุบันจึงมีเครื่องมือที่สนับสนุนการทำงานกับ Web Services ในทุกแพลตฟอร์ม เพราะทุกแพลตฟอร์มย่อมสามารถทำงานกับข้อมูลตัวอักษรได้เกือบทั้งหมด

ชื่ออีลีเมนต์ และความหมายข้อมูล

อย่างไรก็ตามยังมีผู้ที่เข้าใจคลาดเคลื่อนอีกมาก ว่าสถาปัตยกรรมแบบ SOA จะช่วยให้ระบบสารสนเทศเชื่อมโยงถึงกันได้อย่างอัตโนมัติ ในความเป็นจริงนั้น SOA ช่วยให้เกิดรูปแบบการแลกเปลี่ยนข้อมูลที่เป็นอัตโนมัติได้จริง แต่ในทางปฏิบัติแล้วการแลกเปลี่ยนข้อมูลนั้นจะสัมฤทธิ์ผลจริงหรือไม่ ขึ้นอยู่กับว่าผู้ขอบริการและผู้ให้บริการเข้าใจความหมายของข้อมูลตรงกัน

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

ในการแลกเปลี่ยนข้อมูลที่มีผู้เกี่ยวข้องไม่มากนัก เช่นในระบบห้องสมุดข้างต้นนี้ เรามีเพียง 3 กลุ่มงานเท่านั้นที่มาเกี่ยวข้องกัน ดังนั้นการควบคุมให้เกิดความเข้าใจตรงกันสามารถทำได้ง่ายโดยการจัดประชุมและบอกกล่าวให้ทุกฝ่ายรับทราบอย่างชัดเจน แต่ในองค์การขนาดใหญ่ที่มีหน่วยงานจำนวนมาก การจัดประชุมเพื่อทำให้เข้าใจความหมายของข้อมูลตรงกันบ่อยครั้งคงจะเป็นเรื่องที่สิ้นเปลืองงบประมาณอย่างมาก

ในโลกของ SOA จึงพยายามแนะนำให้ผู้ที่จะประยุกต์ใช้ SOA ในองค์การขนาดใหญ่วางกรอบความหมายของข้อมูลร่วมกันไว้ตั้งแต่เริ่มต้น โดยคัดเลือกเอาเฉพาะข้อมูลที่ใช้ดำเนินงานร่วมกัน (เรียกว่า Common Semantic Information) มาตั้งชื่อให้มีเพียงชื่อเดียวที่เข้าใจตรงกันทั้งองค์การ ซึ่งหากทุกหน่วยงานในองค์การนำเอาชื่อเหล่านี้ไปใช้ตั้งชื่ออีลีเมนต์ จะทำให้ได้ชื่อแท็ก XML ที่สอดคล้องกลมกลืนกันทั่วทั้งองค์การและทำให้การแลกเปลี่ยนข้อมูลระหว่างหน่วยงานที่จะเกิดขึ้นในอนาคตสามารถเกิดขึ้นได้อย่างรวดเร็วเนื่องจากไม่ต้องทำความเข้าใจใหม่ทุกครั้ง

มีบริการอะไร ที่ไหนบ้าง

ให้ท่านลองนึกถึงโลกของ SOA ที่มีผู้ให้บริการ Web Services อยู่มากมายหลากหลายประเภท ทั้งให้บริการแปลภาษา ให้บริการตรวจสอบสภาพจราจร ให้บริการข้อมูลพยากรณ์อากาศ ให้ข้อมูลย้อนหลังประวัติการศึกษา ให้ตรวจสอบผลการสอบเข้าศึกษาต่อ และให้บริการอื่นๆอีกมากมาย ถ้าไม่นับหน่วยงานอื่น เอาแค่ในหน่วยงานของเราเองก็ได้ ซึ่งในอนาคตอันใกล้นี้หากระบบไอทีทุกระบบที่นำมาใช้มีจุดเชื่อมต่อที่เป็นแบบ Web Services ทุกระบบ นั่นก็คือเรามีบริการสารพัดอย่างอยู่เต็มไปหมด แต่ไม่สามารถรู้ได้ว่ามีบริการอะไรบ้างเพราะไม่มีจุดศูนย์กลางที่เป็นผู้รวบรวมและทำทะเบียนของ Web Services ไว้ให้สืบค้น

ในโลกของ SOA รายชื่อผู้ให้บริการจะถูกเก็บรวบรวมไว้ที่ระบบศูนย์กลาง ที่เรียกว่าเป็น Service Registry และหากใครต้องการทราบว่าในชุมชนนี้มี Web Services อะไรบ้าง ก็จะสามารถมาสืบค้นเอาจาก Service Registry ได้ โดยการสืบค้นจะต้องใช้วิธีการ UDDI (Universal Document Discovery Integration) ที่เป็นมาตรฐานของ W3C

หากท่านนึกภาพ UDDI ไม่ออก ให้ลองนึกถึงสมุดโทรศัพท์หน้าเหลืองที่รวบรวมเบอร์โทรศัพท์ของร้านค้าต่างๆเอาไว้ ลูกค้าที่ต้องการหาซื้อสินค้าหรือบริการ ก็จะเปิดหาเอาจากสมุดหน้าเหลือง เมื่อได้เบอร์โทรศัพท์แล้วจึงโทรไปติดต่อที่ร้านค้าและเริ่มต้นการซื้อขาย หากเปรียบเทียบกับสมุดหน้าเหลือง Web Services ก็คือร้านค้า ส่วนตำแหน่งของไฟล์ WSDL ที่เก็บไว้ก็คือ เบอร์โทรศัพท์นั่นเอง

ยกตัวอย่างกรณีของระบบห้องสมุดที่กล่าวมาข้างต้น สมมุติว่าหากในมหาวิทยาลัยมีการติดตั้งระบบ Service Registry ไว้ และกำหนดเป็นนโยบายร่วมกันเอาไว้ว่า Web Services ทุกตัวที่หน่วยงานภายในสร้างขึ้นจะต้องนำมาลงทะเบียนไว้ที่ Service Registry ตัวนี้ ซึ่งสามารถอธิบายเป็นภาพได้ดังนี้

รูปภาพ 13 การรวบรวมตำแหน่ง WSDL ของ Web Services ไว้ที่ Service Registry

จากภาพข้างต้นจะเห็นว่าหน้าที่ของ Service Registry เป็นเพียงแค่นายทะเบียนที่ทำหน้าที่รวบรวมตำแหน่งของไฟล์ WSDL และ Web Services เอาไว้ที่จุดเดียวกัน หากต้องการทราบว่าในชุมชนนั้นมีบริการอะไรอยู่บ้าง ก็สามารถมาสืบค้นเอาจาก Service Registry ได้ และเมื่อทราบแล้วว่า Web Services ที่ต้องการนั้นมีไฟล์ WSDL วางไว้ที่ไหน ก็ให้ไปดาวน์โหลดไฟล์ WSDL มาเพื่อใช้ขอบริการจาก Web Services ที่ต้องการต่อไป

ในโลกของ SOA เรามี UDDI เป็นวิธีการมาตรฐานที่ใช้ลงทะเบียนและใช้สืบค้นไปที่ Service Registry ซึ่งวิธีการแบบ UDDI นี้จะเป็นเช่นเดียวกันกับ Web Services ทั่วๆไปที่เราเรียนรู้ผ่านมาแล้ว โดยมองว่า Service Registry เองก็เป็น Web Services ตัวหนึ่งที่ให้บริการด้านการรวบรวมข้อมูล

ดังนั้นวิธีการของ UDDI จึงมีไฟล์ uddi.wsdl ที่เป็นมาตรฐานอยู่แล้ว รวมทั้งมีกระบวนการที่จะให้สั่งงานตัว Service Registry ด้วย ตัวอย่างเช่น หากต้องการลงทะเบียน Web Services เราจะใช้กระบวนการที่ชื่อว่า save_service หรือหากต้องการสืบค้น Web Services ก็จะใช้กระบวนการที่ชื่อว่า find_service เป็นต้น

รูปภาพ 14 ตัวอย่างบางส่วนข้อมูลแบบ UDDI เพื่อลงทะเบียนและสืบค้นกับ Service Registry

จุดอ่อนของระบบ UDDI ก็คือ ระบบ UDDI ยังมีลักษณะเป็นเชิงเทคนิคอยู่มาก จึงเหมาะสำหรับให้ระบบคอมพิวเตอร์ด้วยกันเข้ามาสืบค้น แต่ไม่เหมาะสำหรับผู้ใช้ที่เป็นคนใช้ผ่านหน้าเว็บ ซึ่งหากต้องการนำ UDDI มาใช้เป็นระบบสารบัญกลางของ Web Services และให้ผู้ใช้ที่เป็นบุคคลทั่วไปเข้ามาสืบค้น เราจะต้องนำ UDDI มาสร้างส่วนติดต่อกับผู้ใช้ เช่น แบบฟอร์มลงทะเบียน และ หน้าเว็บสำหรับแสดงรายการสืบค้น เพื่อให้ผู้ใช้สามารถใช้งานได้ง่ายและสะดวกขึ้น

รูปภาพ 15 ระบบ Web Services Helper System ช่วยให้สามารถเปิดดูรายละเอียดใน Repository ได้ง่าย

Web Services Helper System

แม้ว่า Web Services จะเป็นวิธีการแลกเปลี่ยนข้อมูลที่เป็นมาตรฐานเปิดที่ทุกแพลตฟอร์มทำงานร่วมกันได้ แต่เราจะพบว่าปัจจุบันการใช้งาน Web Services เพื่อแลกเปลี่ยนข้อมูลกันอย่างจริงจังในระหว่างหน่วยงานต่างๆยังไม่ได้ก้าวไปไกลมากนัก จากประสบการณ์ของผู้เขียนพบว่า สามารถสรุปปัญหาที่เป็นอุปสรรคสำคัญได้ 2 เรื่องคือ

·      ปัญหาด้านเทคนิค (Technical Problem) และ

·      ปัญหาด้านนโยบาย และ ระเบียบข้อบังคับ (Rule and Regulation Constraints)

ปัญหาด้านเทคนิคที่พบส่วนใหญ่ สืบเนื่องมาจากวิธีการ XML และ Web Services ยังเป็นความรู้ใหม่ที่ต้องการการศึกษาและทดลองปฏิบัติ ปัจจุบันจึงยังอยู่ในช่วงที่นักพัฒนาระบบส่วนใหญ่กำลังศึกษาเทคโนโลยีและเครื่องมือเกี่ยวกับ Web Services ในแพลตฟอร์มที่ตนเองถนัด

ส่วนปัญหาในด้านนโยบายและและระเบียบข้อบังคับ เนื่องจากหลายหน่วยงานเห็นว่า Web Services เป็นช่องทางให้บริการที่ยากต่อการควบคุมการเข้าใช้ เพราะผู้ที่เชื่อมต่อมาใช้งานเป็นระบบคอมพิวเตอร์ของผู้ขอใช้บริการโดยตรง ดังนั้น หน่วยงานส่วนใหญ่จึงมักจะเป็นกังวลหากจะเปิดให้ผู้ใช้ สามารถเข้าใช้งาน Web Services ของหน่วยงานตนเองได้

กระทรวงเทคโนโลยีและการสื่อสารได้ริเริ่มพัฒนาระบบ Web Services Helper System ขึ้นเพื่อเป็นแนวทางในการบรรเทาอุปสรรคดังกล่าวข้างต้น เพื่อลดอุปสรรคทางด้านเทคนิค ระบบ Web Services Helper System จะเป็นเครื่องมือช่วยในการวิเคราะห์ Web Services ช่วยในการลงทะเบียนและสืบค้น Web Services นอกจากนี้ยังเป็นชุมชนออนไลน์ที่รวบรวมความรู้เกี่ยวกับการพัฒนา Web Services ในหน่วยงานภาครัฐอีกด้วย และเพื่อลดอุปสรรคทางด้านระเบียบข้อบังคับ ระบบ Web Services Helper System จะช่วยให้หน่วยงานผู้ให้บริการ Web Services สามารถตั้งเงื่อนไขข้อกำหนดและควบคุมการเข้าใช้บริการ Web Services ของตนเองได้อีกด้วย

ท่านผู้อ่านที่สนใจเข้าใช้งานระบบ Web Services Helper System สามารถเปิดดูได้จาก http://wshelper.mict.go.th ซึ่งจะปรากฏหน้าแรกของเว็บไซต์คล้ายดังภาพต่อไปนี้

รูปภาพ 16 การแสดงผลที่หน้าแรกของเว็บไซต์ Web Services Helper System

Web Services Helper System ช่วยวิเคราะห์ WSDL และ XSD

การวิเคราะห์ไฟล์ WSDL และ XSD ด้วยตนเองเป็นเรื่องค่อนข้างยุ่งยาก แม้ว่านักเทคนิคจะสามารถทำความเข้าใจได้ แต่ก็เสียเวลานานทำให้ไม่สะดวกในการใช้งาน Web Services

ระบบ Web Services Helper System พยายามช่วยให้นักพัฒนา Web Services สามารถเห็นภาพรวมของ Web Services ได้อย่างรวดเร็ว โดยเพียงแค่นำตำแหน่งไฟล์ WSDL ที่ผู้ให้บริการกำหนดไว้ ใส่เข้าไปในช่อง URL ของกรอบ “สำรวจและทดสอบเว็บเซอร์วิส” แล้วกดปุ่ม “ตกลง” ระบบ Web Services Helper System จะช่วยวิเคราะห์และวาดไดอะแกรมของ Web Services ให้ ซึ่งจะทำให้เราเห็นว่า Web Services ตัวนั้นประกอบด้วยกระบวนการอะไร และต้องการข้อมูล XML แบบไหน

รูปภาพ 17 การวิเคราะห์ส่วนประกอบของ Web Services โดยใช้ระบบ Web Services Helper System

ภาพที่ปรากฏให้เห็นในไดอะแกรม นอกจากจะช่วยทำให้ทราบว่าภายใน Web Services มีกระบวนการอะไรแล้ว หากผู้ใช้ต้องการจะรู้ว่าต้องส่งข้อมูล XML ไปรูปแบบไหนถึงจะถูกต้อง ก็สามารถคลิกที่ลิงค์ “ทดสอบ” เพื่อขอทดสอบกระบวนการแต่ละตัวที่อยู่ใน Web Services ได้โดยง่าย

รูปภาพ 18 การใช้ลิงค์ “ทดสอบ” ของระบบ Web Services Helper System เพื่อดูรูปแบบข้อมูล XML

การวิเคราะห์ข้อมูล XML ที่มีโครงสร้างสลับซับซ้อน ด้วยตนเองจากไฟล์ XSD นั้นเป็นเรื่องยุ่งยากและมักจะพบข้อผิดพลาดอยู่เสมอ ซึ่งระบบ Web Services Helper System ช่วยให้นักพัฒนาโปรแกรมเห็นภาพโครงสร้างข้อมูล XML ได้ในรูปแบบไดอะแกรมที่ง่ายต่อการทำความเข้าใจ เช่น ในตัวอย่างระบบห้องสมุดเราจะพบกระบวนการที่ชื่อว่า getBorrowingDetails โดยรูปแบบข้อมูล XML ที่ตอบกลับมาจะค่อนข้างซับซ้อนและมีอีลีเมนต์หลายตัว หากเราให้ Web Services Helper System ช่วย ก็เพียงแค่เปิดดูจากไดอะแกรมเท่านั้น

รูปภาพ 19 การเปิดดูโครงสร้างข้อมูล XML ที่ประกอบด้วยอีลีเมนต์ย่อยหลายตัว

Web Services Helper System ช่วยควบคุมการเข้าใช้ Web Services

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

              แต่เราจะพบว่า ปัจจุบันแพลตฟอร์มที่ใช้ในการสร้าง Web Services ทุกแพลตฟอร์มยังไม่มีส่วนควบคุมการเข้าใช้งานของผู้ใช้ที่เป็นลักษณะสำเร็จรูปพร้อมใช้งาน ทำให้กลายเป็นภาระของนักพัฒนาระบบไอทีที่คิดจะเปิดช่องทางการเชื่อมต่อแบบ Web Services ต้องพัฒนาส่วนควบคุมการเข้าใช้ Web Services เพิ่มเติมกันเอง

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

              กระทรวง ICT เล็งเห็นถึงอุปสรรคแล้วว่าหากไม่มีระบบควบคุมการเข้าใช้ Web Services และปล่อยให้นักพัฒนาระบบไอทีของหน่วยงานภาครัฐไปพัฒนา หรือจัดหามาใช้กันเอง อาจจะทำให้เกิดความล่าช้าต่อการพัฒนาวิธีการแลกเปลี่ยนข้อมูลด้วย Web Services ดังนั้นกระทรวง ICT จึงจัดทำระบบควบคุมการเข้าใช้ Web Services ขึ้นและรวมอยู่เป็นบริการอย่างหนึ่งในเว็บไซต์ Web Services Helper System ซึ่งหากผู้อ่านสนใจที่จะใช้บริการ สามารถสมัครเป็นสมาชิกเว็บไซต์ได้ที่ http://wshelper.mict.go.th

              หากท่านเป็นสมาชิกเว็บไซต์ Web Services Helper System และต้องการให้ระบบช่วยควบคุมการเข้าใช้ Web Services ของท่าน ก็สามารถทำได้โดยคลิกลิงค์ “ลงทะเบียนเว็บเซอร์วิส” ที่ปรากฏที่กรอบเว็บเซอร์วิสที่หน้าแรกของเว็บไซต์ หลังจากนั้นก็เพียงแต่นำตำแหน่งไฟล์ WSDL ของ Web Services ท่านมาใส่แล้วดำเนินการไปตามขั้นตอนการลงทะเบียน จนกระทั่งเสร็จสิ้น

              เมื่อผ่านการลงทะเบียน Web Services แล้ว หากมีสมาชิกท่านอื่นแวะเข้ามาเยี่ยมชมที่เว็บไซต์ Web Services Helper System และสนใจจะขอใช้บริการ Web Services ของท่าน เค้าจะคลิกที่ลิงค์ “ขอใช้บริการ” และส่งคำขอใช้บริการ Web Services มาให้ท่านอนุญาตก่อนจึงจะสามารถเข้าใช้งาน Web Services ได้

รูปภาพ 20 การเปิดดูรายละเอียดคำรองขอใช้บริการเว็บเซอร์วิส เพื่อพิจารณาว่าจะอนุญาตให้ใช้งานหรือไม่

การอนุญาตให้ผู้ขอใช้บริการ สามารถเข้าใช้ Web Services ได้นั้น ผู้เป็นเจ้าของ Web Services สามารถจะกำหนดให้ใช้งานได้อย่างไม่มีข้อจำกัด หรือจะกำหนดเงื่อนไขควบคุมให้ใช้งานได้เฉพาะภายในขอบเขตที่กำหนดก็ได้ ตัวอย่างเงื่อนไขที่สามารถกำหนดได้ เช่น จำนวนครั้งที่อนุญาตให้เชื่อมต่อเพื่อใช้งาน วันที่หมดอายุ ช่วงเวลาที่ให้เชื่อมต่อมาใช้งานได้ หรือจะกำหนดให้ใช้ได้เพียงบางกระบวนการเท่านั้น เป็นต้น

รูปภาพ 21 การกำหนดเงื่อนไขเพื่อควบคุมการเข้าใช้บริการ Web Services ให้อยู่ในขอบเขตที่ยอมรับได้

เมื่อได้รับอนุญาตจากผู้ให้บริการแล้ว สมาชิกผู้ขอใช้บริการจะพบสิทธิบัตร (License) พร้อมตำแหน่งที่เปิดให้บริการ Web Services หรือเงื่อนไขข้อกำหนดอื่นๆที่ผู้ให้บริการกำหนดไว้

รูปภาพ 22 การเปิดดูสิทธิบัตร หลังจากได้รับอนุญาตจากผู้ให้บริการ ให้สามารถเชื่อมต่อและเข้าใช้งาน Web Services ได้

หลังจากนั้นผู้ขอใช้บริการจะสามารถเข้าใช้บริการ Web Services ได้ตามตำแหน่ง URL ที่ปรากฏในสิทธิบัตร และจะอยู่ภายใต้การควบคุมดูแลของระบบ Web Services Helper System เพื่อให้เป็นไปตามข้อกำหนดที่ผู้ให้บริการจัดไว้

Web Services Helper System เป็นเพียงยามเฝ้าประตูเท่านั้น 

ผู้อ่านอาจจะเห็นประโยชน์ของระบบ Web Services Helper System แล้ว แต่เพื่อให้เข้าใจหน้าที่ของระบบ Web Services Helper System มากขึ้น เราอาจจะนึกเปรียบเทียบระบบได้กับยามเฝ้าประตูที่ทำหน้าที่เฝ้าประตูทางเข้าสู่ Web Services ของท่าน และยินยอมให้ผู้ที่มาเยือนเข้ามาได้ก็ต่อเมื่อเค้ายอมทำตามข้อกำหนดเท่านั้น เช่น ยามเฝ้าประตูอาจจะไม่ยอมให้ท่านเข้าสำนักงานหากท่านไม่ติดป้ายพนักงาน เป็นต้น เช่นเดียวกันกับระบบ Web Services Helper System ก็อาจจะไม่ยอมให้ท่านเข้าใช้ Web Services ได้หากท่านไม่ทำตามเงื่อนไขที่ผู้ให้บริการกำหนดไว้

              หากท่านเป็นผู้คุ้นเคยกับสถาปัตยกรรมไอทีระดับองค์กร ที่ประกอบขึ้นจากระบบไอทีหลากหลายหน้าที่ ท่านจะเห็นว่าระบบ Web Services Helper System มีหน้าที่เป็นเพียงผู้คุมกฏเท่านั้น โดยไม่มีหน้าที่จัดเก็บหรือค้นคืนข้อมูลที่ผู้ให้บริการ Web Services แลกเปลี่ยนกันกับผู้ขอใช้บริการ แต่ระบบ Web Services Helper System จะช่วยให้การแลกเปลี่ยนข้อมูลมีความน่าเชื่อถือสูงขึ้น เนื่องจากผ่านการติดตามควบคุมดูแลอย่างรัดกุมโดยระบบ

รูปภาพ 23 หน้าที่ของระบบ Web Services Helper System

แม้ว่าระบบ Web Services Helper System จะทำหน้าที่คล้ายกับระบบ Firewall ก็ตาม แต่สิ่งที่แตกต่างก็คือ ระบบ Web Services Helper System เป็นการให้บริการแบบช่วยเหลือกันเองภายในชุมชนออนไลน์ ซึ่งการตัดสินใจว่าให้เข้าใช้บริการหรือไม่นั้นเป็นสิทธิของผู้ให้บริการ Web Services และสามารถยกเลิกสิทธิบัตรที่อนุญาตไปแล้วได้ทุกเมื่อ ดังนั้นจึงแตกต่างจากระบบ Firewall ที่มุ่งเน้นการรักษาความปลอดภัยเชิงลึก ซึ่งต้องอาศัยผู้ดูแลระบบเครือข่ายเป็นผู้จัดการกำหนดค่าของ Firewall

Web Services Helper System ช่วยสืบค้น Web Services

ระบบ Web Services Helper System ช่วยรวบรวมรายชื่อ Web Services ของผู้ให้บริการทุกคนที่เป็นสมาชิกกับเว็บไซต์เอาไว้ และหากมีผู้สนใจขอใช้บริการก็จะมาสืบค้นผ่านทางหน้าเว็บของระบบ Web Services Helper System การสืบค้นสามารถค้นหาแบบง่ายได้โดยใช้คำค้น ระบบจะไปสืบค้นจาก ชื่อ รายละเอียด และ หมวดหมู่ ของ Web Services หากพบที่ตรงกับคำค้นก็จะนำผลลัพธ์มาแสดงให้เห็น

รูปภาพ 24 การสืบค้น Web Services ที่มีผู้นำมาลงทะเบียนไว้

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

Web Services Helper System ช่วยเชื่อมต่อ Web Services ได้ทั้ง Java .NET และ PHP

แม้ว่า XML และ Web Services จะเป็นมาตรฐานเปิดที่ทุกแพลตฟอร์มสามารถนำไปใช้งานได้ แต่ในทางเทคนิคแล้วพบว่าแต่ละแพลตฟอร์มมีวิธีการเขียนโปรแกรมเพื่อใช้งาน XML และ Web Services แตกต่างกันไป ตัวอย่างเช่น วิธีการเขียนโปรแกรมเพื่ออ่านข้อมูลจากเอกสาร XML ในภาษายอดนิยมทั้ง 3 ภาษา จะแตกต่างกันดังนี้

// ภาษา Java

Document doc = documentBuilder.parse(“test.xml”);

// ภาษา C# .NET

XmlDocument doc = new XmlDocument();

doc.LoadXml(“test.xml”);

// ภาษา PHP

$doc = DOMDocument::load(“test.xml”);

ด้วยสาเหตุจากวิธีการเขียนโปรแกรมที่แตกต่างกันเช่นนี้ ทำให้ในปัจจุบันนักพัฒนาโปรแกรมที่ต้องการใช้งาน Web Services ต้องใช้ระยะเวลาในการศึกษาเพื่อนำมาใช้กับระบบไอทีของตนเอง ระบบ Web Services Helper System พยายามช่วยลดอุปสรรคในด้านความแตกต่างระหว่างภาษาโปรแกรม โดยช่วยสร้างโปรแกรมเชื่อมต่อ Web Services ที่ตรงกับแพลตฟอร์มที่ท่านถนัดได้ทั้ง 3 ภาษา

รูปภาพ 25 การให้ความช่วยเหลือกับนักพัฒนาระบบไอที ด้วยการสร้างโปรแกรมเชื่อมต่อ Web Services

สมาชิกของเว็บไซต์ Web Services Helper System ที่สนใจสร้างโปรแกรมเชื่อมต่อ Web Services สามารถคลิกที่ลิงค์ “สร้างโปรแกรมเชื่อมต่อ” ได้จากรายการ Web Services ที่ปรากฏให้เห็นที่หน้าเว็บ หรือจากการสืบค้น อย่างไรก็ตามหากยังไม่ได้รับอนุญาตจากผู้ให้บริการ Web Services ระบบจะแสดงแบบฟอร์มคำขอเพื่อให้ดำเนินการขออนุญาตให้สำเร็จเสียก่อนจึงจะสามารถนำสิทธิบัตรมาสร้างโปรแกรมเชื่อมต่อ Web Services และใช้งานได้

ตัวอย่างของโปรแกรมเชื่อมต่อที่สร้างขึ้นจากระบบ Web Services Helper System ในรูปแบบของ Window Form Application และสามารถทำงานได้กับทั้ง 3 ภาษา เป็นดังนี้

รูปภาพ 26 การสร้างโปรแกรมเชื่อมต่อ Web Services ผ่านระบบ Web Services Helper System

Web Services Helper System ช่วยให้เกิดการแลกเปลี่ยนความรู้ด้าน Web Services

เนื่องจากวิธีการแลกเปลี่ยนข้อมูลแบบ XML และ Web Services เป็นความรู้แขนงใหม่ ซึ่งการนำความรู้ใหม่เช่นนี้มาใช้งานมักจะเกิดปัญหาติดขัดในระยะแรกอยู่เสมอ ระบบ Web Services Helper System สามารถช่วยลดอุปสรรคนี้ได้โดยทำหน้าที่เป็นเว็บไซต์ชุมชนออนไลน์ เพื่อให้สมาชิกได้มาแลกเปลี่ยนความรู้และประสบการณ์ในการทำงานด้าน XML และ Web Services ส่งผลให้สมาชิกท่านอื่นที่ติดปัญหาขัดข้องทางเทคนิค สามารถแก้ปัญหาที่พบบ่อยได้โดยอาศัยเนื้อหากระทู้ หรือ บทความ ที่สมาชิกเว็บไซต์ช่วยกันใส่เข้ามาในชุมชนออนไลน์ จึงถือได้ว่าเว็บไซต์ Web Services Helper System เป็นฐานความรู้อย่างหนึ่งให้กับกลุ่มคนด้าน Web Services ในระยะยาวอีกด้วย

รูปภาพ 27 เว็บไซต์ Web Services Helper System เป็นแหล่งรวมเนื้อหาสาระด้าน XML และ Web Services

Web Services Helper System ช่วยให้การแลกเปลี่ยนข้อมูลมีความปลอดภัยสูง

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

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

การแลกเปลี่ยนข้อมูลด้วยวิธีการแบบ XML และ Web Services ผ่านทางระบบ Web Services Helper System จะช่วยยกระดับความมั่นคงปลอดภัยของข้อมูลให้ท่านได้เนื่องจาก ระบบ Web Services Helper System ถูกติดตั้งอยู่บนเครือข่าย GIN (Government Information Network) ที่ได้รับการยอมรับว่ามีการควบคุมดูแลเรื่องความมั่นคงปลอดภัยอย่างรัดกุมแน่นหนา

นอกจากนี้หากผู้ให้บริการต้องการเพิ่มระดับความปลอดภัยข้อมูลให้สูงยิ่งขึ้นก็สามารถทำได้โดยขอให้ระบบ Web Services Helper System ตรวจสอบการลงลายเซ็นต์อิเล็คทรอนิกส์ หรือ เข้ารหัสข้อมูล XML ด้วยกุญแจลับ ซึ่งจะส่งผลให้ผู้อื่นที่ได้ข้อมูล XML ไปในระหว่างการแลกเปลี่ยนข้อมูล ไม่สามารถเปิดดู แก้ไข หรือนำข้อมูลเหล่านั้นไปใช้งานได้

รูปภาพ 28 การรักษาความปลอดภัยข้อมูลระหว่างการแลกเปลี่ยนด้วยวิธี WS-Security

ระบบ Web Services Helper System ใช้วิธีการเข้ารหัสข้อมูลแบบ AES (Advance Encryption Standard) ด้วยกุญแจลับขนาด 128 บิตซึ่งเป็นการรักษาความปลอดภัยข้อมูลที่ในปัจจุบันได้รับการยอมรับว่ามีความปลอดภัยสูง นอกจากนี้จะเห็นว่ากรรมวิธี WS-Security เป็นมาตรฐานเปิดที่ทุกแพลตฟอร์มให้การสนับสนุน และเริ่มมีการนำมาใช้กันอย่างแพร่หลาย

              อย่างไรก็ตามการสร้างลายเซ็นต์อิเล็คทรอนิกส์และการเข้ารหัสข้อมูล XML เช่นในภาพข้างต้นนี้เป็นกรรมวิธีที่สิ้นเปลืองทรัพยากรคอมพิวเตอร์สูงและทำให้การสื่อสารช้าลงกว่าปกติ ระบบ Web Services Helper System จึงให้ไว้เป็นทางเลือกที่ผู้ให้บริการสามารถตัดสินใจด้วยตนเองว่าจะใช้หรือไม่ก็ได้

ร้อยเรียง Web Services ให้เป็นกระบวนการธุรกิจ (Business Process)

ในโลกของ SOA การสร้างบริการออนไลน์ขนาดใหญ่ทำได้โดยการรวบรวมบริการเล็กๆอันหลากหลายให้เข้ามาทำงานร่วมกันอย่างเป็นระบบ หากสามารถต่อเรียงบริการเข้าด้วยกันได้อย่างเป็นกระบวนการจะทำให้เกิดการบริการที่เป็นอัตโนมัติครบวงจร โดยข้อมูลที่จำเป็นต่อการดำเนินงานจะถูกส่งต่อไหลเวียนทั้งถึงกันทุกฝ่าย ส่งผลให้ประสิทธิภาพงานโดยรวมสูงขึ้นเป็นอย่างมาก

              ในองค์การขนาดใหญ่ที่มีหน่วยงานย่อยเป็นจำนวนมาก แต่ละหน่วยงานจะพยายามทำหน้าที่ของตนเองให้สำเร็จลุล่วงตามตัวชี้วัดที่ตั้งไว้ ซึ่งความสำเร็จเล็กๆน้อยๆเหล่านี้จะเป็นแรงผลักดันให้องค์การบรรลุเป้าหมายโดยรวมของทั้งองค์การ ท่านผู้อ่านย่อมเข้าใจดีถึงหลักการเบื้องต้นในการบริหารงานเช่นนี้อยู่แล้ว และอาจจะสงสัยว่าหลักการที่ว่านี้ไปเกี่ยวข้องอะไรกับ Web Services และ SOA

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

รูปภาพ 29 กระบวนการธุรกิจที่มอบคุณค่าให้กับองค์การ (ตามแนวคิด Value-Chain ของ Micheal E. Porter)

              ในโลกของ SOA จะเรียกกระบวนงานที่สนับสนุน และส่งผลทำให้องค์การบรรลุเป้าหมายว่าเป็น กระบวนการธุรกิจ (Business Process) โดยแต่ละกระบวนการจะประกอบด้วยกิจกรรมย่อยๆที่ต้องทำไปตามขั้นตอนแบบแผนที่เป็นเอกลักษณ์ขององค์การนั้น ที่เรียกว่าเป็นเอกลักษณ์ก็เพราะว่ากิจกรรมที่จะต้องทำเพื่อให้บรรลุเป้าของแต่ละองค์การ ย่อมเป็นไปตาม ความรู้ความสามารถของกลุ่มงานย่อยๆที่อยู่ในองค์การนั้น ผนวกกับวัฒนธรรมองค์การที่มีรูปแบบเฉพาะของตนเอง จึงสุดที่องค์การอื่นจะลอกเลียนแบบกันได้  

              เนื่องจากปัจจุบันเราได้ก้าวเข้าสู่ยุคไอทีเต็มรูปแบบแล้ว ดังนั้นกิจกรรมย่อยที่อยู่ในกระบวนการธุรกิจไม่จำเป็นต้องกระทำโดยบุคคล (Human) ที่เป็นมนุษย์เสมอไป กิจกรรมสามารถทำให้ลุล่วงได้โดยอาจจะใช้ คน เครื่องจักร ระบบไอที หรือทำงานร่วมกันก็ได้ ด้วยเหตุผลนี้ในโลกของ SOA จึงมองว่ากิจกรรมเหล่านี้แท้ที่จริงแล้วก็คือการบริการ (Service) ที่ผู้ให้บริการ อาจจะเป็นได้ทั้งคน หรือ ระบบไอที เป็นผู้ดำเนินการให้และมอบผลลัพธ์ที่มีคุณค่า สามารถนำไปใช้เป็นอินพุตให้กับกิจกรรมที่ต่อเนื่องกันไปในกระบวนการธุรกิจ

              ตามแนวคิดของ SOA ไม่ได้มองว่าการบริการจะต้องเป็นคนหรือคอมพิวเตอร์ แต่ในโลกไอทีปัจจุบัน การบริการทางไอทีที่สามารถนำมาเชื่อมต่อเข้าด้วยกันได้อย่างอิสระก็คือ Web Services นั่นเอง ดังนั้นผู้ประยุกต์ใช้แนวคิด SOA จึงเห็นตรงกันว่ากิจกรรมที่อยู่ในกระบวนการธุรกิจควรจะทำให้ออกมาอยู่ในรูปของ Web Services ที่มีข้อมูลเข้าและมีผลลัพธ์ชัดเจน โดยผลลัพธ์สามารถนำไปใส่ให้กับ Web Services ตัวอื่นแล้วทำให้กิจกรรมต่อเนื่องกันไปจนบรรลุเป้าหมายสุดท้ายของกระบวนการ

                และหากได้รับการออกแบบมาอย่างดีเพียงพอแล้ว การปรับกระบวนการและกลยุทธ์ในการบริหารองค์การในอนาคต อาจจะเป็นเพียงแค่การนำเอา Web Services ที่สามารถทำงานได้ในแต่ละเรื่องมาร้อยเรียงต่อเข้าด้วยกันใหม่ เพื่อให้ได้กระบวนการที่ตรงตามความต้องการขององค์การ และส่งผลให้ในระยะยาวองค์การสามารถลดต้นทุนการจัดซื้อจัดจ้างพัฒนาระบบไอทีไปได้มาก เนื่องจาก กิจกรรมที่เดิมได้ทำไว้เป็น Web Services อยู่แล้ว จะไม่ถูกทำขึ้นมาใหม่แต่จะนำของเดิมมาต่อเรียงเข้ากับกระบวนการใหม่ได้ทันที

              การนำเอา Web Services มาต่อเรียงเข้าด้วยกันให้เป็นกระบวนการธุรกิจนั้น ปัจจุบันสามารถทำได้จริง โดยใช้เครื่องมือที่เรียกว่า BPEL (Business Process Execution Language) ซึ่งเป็นมาตรฐานที่ผู้ผลิตระบบไอทีรายใหญ่เกือบทุกค่ายให้การยอมรับ เช่น IBM, Microsoft, Oracle และ Sun เป็นต้น และโปรแกรมที่ทำหน้าที่ควบคุมกระบวนการให้เป็นไปตามที่กำหนดไว้ใน BPEL ก็คือ BPEL Engine (หรือบางทีเรียกว่า Process Engine) โปรแกรมตัวนี้จะมีหน้าที่ถ่ายโอนผลลัพธ์จาก Web Services ตัวหนึ่งให้วิ่งต่อไปยัง Web Services อีกตัวหนึ่งตามกระบวนการที่จัดวางไว้

รูปภาพ 30 ความสัมพันธ์ระหว่าง Web Services กับ Business Process และ BPEL Engine

ปัจจุบันหลายหน่วยงานเล็งเห็นแล้วว่าการพัฒนาระบบไอทีขึ้นมาใหม่ทุกครั้งเมื่อกระบวนการบริหารมีการเปลี่ยนแปลงนั้น ทำให้ล่าช้าและสิ้นเปลืองงบประมาณไปเป็นจำนวนมาก หลายหน่วยงานเริ่มนำเอา SOA เข้ามาใช้เป็นกลยุทธ์ในการปรับระบบไอทีและการบริหารให้สอดคล้องกลมกลืนกันได้ในระยะยาว แต่ทั้งนี้หน่วยงานที่จะประสบผลสำเร็จในการประยุกต์ใช้ SOA นั้นจะต้องเข้าใจกระบวนการธุรกิจ วิสัยทัศน์ และ เป้าหมายองค์กร ของตนเองอย่างถ่องแท้ และสามารถบอกได้ถึงกิจกรรมและการบริการที่เป็นหัวใจสำคัญขององค์กร ถึงจะสามารถสร้าง Web Services ที่มีคุณค่าและนำมาใช้ในกระบวนการธุรกิจได้อย่างแท้จริง

สถาปัตยกรรม SOA

ท่านจะเห็นว่า SOA เป็นระบบการให้บริการขนาดใหญ่ที่เกิดขึ้นจากการเชื่อมโยงการบริการจากระบบไอทีหลากหลายระบบที่มีอยู่เข้าด้วยกัน จนสามารถทำงานร่วมกันและให้ผลลัพธ์ที่ตรงกับเป้าหมายที่องค์การวางแผนไว้ ดังนั้นเมื่อพูดถึงสถาปัตยกรรมแบบ SOA วิศกรด้านไอทีจึงไม่ควรมีมุมมองที่แคบเฉพาะเพียงแค่ระบบไอทีระบบใดระบบหนึ่งเท่านั้น แต่จะต้องมองในภาพรวมที่ครอบคลุมตลอดทั่วทั้งองค์การ โดยสิ่งที่จะเป็นตัวกำหนดว่าควรจะมีการให้บริการ หรือมี Web Services อะไรเกิดขึ้นในโลกของ SOA นั้นก็คือ กระบวนการธุรกิจ (Business Process) ที่เป็นเอกลักษณ์ขององค์การเรานั่นเอง

              แม้ว่า XML และ Web Services จะเป็นมาตรฐานที่กำหนดขึ้นอย่างชัดเจนแต่ SOA ไม่ใช่มาตรฐานที่มีการบังคับไว้อย่างชัดเจนว่าจะต้องประกอบด้วยส่วนผสมอะไรบ้าง ในปัจจุบัน SOA เป็นเพียงแค่แนวคิดในการนำเอาระบบไอทีที่มีอยู่แล้ว (หรือที่จะเกิดขึ้นใหม่ในอนาคต) เข้ามารวมกันในรูปแบบของการเชื่อมโยงการบริการเท่านั้น

ดังนั้นสถาปัตยกรรมแบบ SOA จึงเป็นแนวคิดในการจัดวางองค์ประกอบให้เหมาะสมเพื่อจะได้ช่วยลดปัญหาที่จะเกิดขึ้นในระยะยาว หากในอนาคตองค์การมีการบริการที่เป็น Web Services จำนวนมาก ต่อไปนี้เป็นตัวอย่างของสถาปัตยกรรม SOA ที่แบ่งลำดับชั้นไว้ 4 ระดับ

รูปภาพ 31 สถาปัตยกรรม SOA ที่แบ่งออกเป็น 4 ระดับชั้น

หากมองจากด้านล่างไปสู่ด้านบน จะเห็นว่าระดับล่างสุดที่เรียกว่าเป็น Resource Layer นั้นหมายถึงทรัพยากรทั้งหมดที่องค์การเรามีอยู่ ไม่ว่าจะเป็น คน ทุน เครื่องจักร วัตถุดิบ ระบบไอที และ ความรู้ ทั้งหมดจะถูกนำมาใช้เพื่อทำให้เกิดการบริการที่มีคุณค่า และการบริการที่มีคุณค่าต่อองค์การจะถูกรวบรวมไว้ที่ Service Layer ซึ่งการบริการต่างๆที่ชั้นนี้จะพร้อมสำหรับนำไปใช้ในกิจกรรมการดำเนินงาน ตามกระบวนการธุรกิจขององค์การ นั่นก็คือการบริการกลายเป็นไปส่วนหนึ่งในกิจกรรมของกระบวนการที่ชั้น Process Layer นั่นเอง

              สำหรับชั้น Access Layer นั้นหมายถึงจุดที่บุคคลต้องเข้ามาเกี่ยวข้องกับกระบวนการ ซึ่งส่วนใหญ่จะหมายถึงการปฏิบัติงานไปตามภาระหน้าที่และบทบาทที่วางไว้ ซึ่งจะทำให้กิจกรรมลุล่วงและกระบวนการก้าวเคลื่อนไปจนกระทั่งเสร็จสิ้น

              ท่านจะเห็นแล้วว่ามุมมองของ SOA ไม่ได้เป็นเชิงเทคนิคหรือระบบไอทีที่สลับซับซ้อน SOA ไม่ได้มุ่งเน้นว่ากิจกรรมที่ทำนั้นจะต้องสำเร็จโดยใช้คนหรือโปรแกรมคอมพิวเตอร์ แต่ SOA ใช้แนวคิดเชิงธุรกิจและกลยุทธ์การบริหารองค์การมาเป็นหัวใจในการผลักดันระบบไอที เนื่องจากในอดีตที่ผ่านมา การออกแบบระบบไอทีไม่ได้มองภาพรวมองค์การว่ามีกระบวนการธุรกิจโดยรวมเป็นเช่นไร ทำให้ระบบไอทีจำนวนมากล้าสมัยหรือด้อยค่าไปทันทีเมื่อองค์การปรับเปลี่ยนกลยุทธ์ในการบริหาร แต่ SOA แตกต่างจากแนวคิดการวางระบบไอทีเดิมๆที่แยกกันอยู่ระบบใครระบบมัน โดย SOA เพิ่มชั้นของ Service Layer และ Process Layer เข้าไปเพื่อให้ระบบไอทีเหล่านั้นตอบโจทย์ให้กับองค์การให้ได้ว่ามันให้บริการอะไร และทำให้หลายๆกิจกรรมสามารถมาใช้บริการเหล่านี้ร่วมกันได้

เครื่องมือพื้นฐานในการทำ SOA

เครื่องมือที่สำคัญในการสร้างให้เกิดสถาปัตยกรรม SOA แบ่งออกเป็น 2 อย่าง คือเครื่องมือในทางเทคนิค กับเครื่องมือทางการบริหาร เครื่องมือในทางเทคนิคก็คือ สิ่งที่จะมาช่วยสร้าง Web Services ช่วยสร้างและรัน Business Process รวมทั้งช่วยเชื่อมโยงระบบไอทีเดิมที่มีอยู่แล้วให้เข้าสู่ Service Layer ได้โดยสะดวก

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

ในที่นี้จะขอยกตัวอย่างการจัดหาเครื่องมือทางด้าน SOA เพื่อช่วยให้เกิดสถาปัตยกรรม SOA ขึ้นได้ในระยะยาว โดยหลักๆแล้วจะได้แก่เครื่องมือขั้นพื้นฐาน 2 ตัวคือ ESB (Enterprise Service Bus) และ Process Engine

รูปภาพ 32 ตัวอย่างการวางเครื่องมือพื้นฐานด้าน SOA เช่น Enterprise Service Bus และ Process Engine

เครื่องมือพื้นฐาน 2 ตัวนี้ จะทำหน้าที่เชื่อมโยงระบบไอทีเข้าด้วยกัน เปรียบเสมือนกับระบบหมุนเวียนโลหิต และระบบประสาทในร่างกายมนุษย์นั่นเอง แต่หากจะเปรียบเทียบแล้ว Enterprise Service Bus ทำหน้าที่ระดับล่างโดยทำให้ข้อมูลจากระบบไอทีดั้งเดิมที่มีอยู่เข้ามาไหลเวียนรวมกันหรืออาจจะแปลงให้กลายเป็นรูปแบบ XML ได้ทันที การใช้ Enterprise Service Bus จะช่วยลดปัญหาการเชื่อมโยงการบริการแบบจุดต่อจุด (Point-to-Point) ที่อาจจะเกิดอย่างไร้ระเบียบแบบแผนในอนาคต

              สำหรับ Process Engine หรือ BPEL Engine จะทำหน้าที่เชื่อมต่อการบริการ และมองในลักษณะการบริหารงานองค์การ ไม่ได้มองในแบบของระบบไอที ดังนั้น Process Engine จะควบคุมให้กิจกรรมเดินก้าวหน้าไปตามกระบวนการที่กำหนดไว้ และนำข้อมูลที่เกิดขึ้นจากกิจกรรมก่อนหน้าส่งต่อให้กับกิจกรรมถัดไป จนกระทั่งเสร็จสิ้น

              ในความเป็นจริงท่านจะพบว่าเครื่องมือทั้ง 2 ตัวคือ ESB และ Process Engine เป็นเพียงแค่เครื่องมือที่จะช่วยทำให้ระบบไอที และ Web Services ประสานงานร่วมกันได้อย่างเป็นแบบแผน และลดความยุ่งเหยิงในอนาคต แต่ไม่ใช่เครื่องมือแบบสูตรสำเร็จที่จะทำให้เกิดสถาปัตยกรรม SOA ขึ้นอย่างทันทีทันใด ผู้ที่จะตอบโจทย์ได้ว่าควรจะมี Process และ Services อะไรบ้างนั้นยังคงเป็นตัวท่านและองค์กรของท่านเองเท่านั้น

              ปัจจุบันหลายหน่วยงานนำเอาแนวคิดของ SOA มาเป็นกลยุทธ์หลัก เนื่องจากเล็งเห็นแล้วว่า การลงทุนสร้างระบบไอทีแบบเดิมๆโดยไม่มีการวิเคราะห์กระบวนการที่สอดคล้องกับองค์การเสียก่อน จะทำให้เกิดการลงทุนสร้างระบบไอทีซ้ำแล้วซ้ำเล่า แต่สุดท้ายไม่ได้ระบบที่ยืดหยุ่นและปรับตัวได้ตามสภาพแวดล้อมขององค์การ ผู้ที่เล็งเห็นประโยชน์ในระยะยาวจะพยายามปรับเปลี่ยนให้ระบบไอทีกลายเป็นการบริการที่มีคุณค่า และนำมาใช้ร่วมกันในกิจกรรมต่างๆขององค์การ ซึ่งจะทำให้เกิดประโยชน์สูงและลดการลงทุนพัฒนาระบบไอทีได้ในระยะยาว

หน่วยงานรัฐของไทยก้าวไกลด้วยบริการออนไลน์

ปัจจุบันหน่วยงานรัฐของไทยได้ตื่นตัวและเร่งเพิ่มประสิทธิภาพการให้บริการ ทั้งการให้บริการประชาชน และการให้บริการหน่วยงานรัฐด้วยกันเอง หลายหน่วยงานได้นำเอาเทคโนโลยีการแลกเปลี่ยนข้อมูลแบบ XML และ Web Services มาใช้เชื่อมโยงระบบไอทีให้สามารถทำงานร่วมกันได้อย่างสอดคล้องกลมกลืน ส่งผลให้กิจกรรมที่ต้องประสานงานระหว่างหน่วยงานมีความรวดเร็วและแม่นยำสูง

ตัวอย่างของหน่วยงานรัฐที่นำเอาวิธีการแบบ XML และ Web Services มาใช้กับการแลกเปลี่ยนข้อมูลมีมากมายหลายหน่วยงานในที่นี้จะขอยกตัวอย่างหน่วยงานที่ท่านคุ้นเคยกันดีอยู่แล้ว เช่น กรมสรรพากร สำนักงานประกันสังคม และ กรมศุลกากร ซึ่งเป็นหน่วยงานสำคัญที่ได้นำเอาไอทีมาใช้ในองค์กรจนเป็นที่กล่าวขาน และได้รับการนำไปเป็นแบบอย่างที่ดีให้กับอีกหลายๆหน่วยงานภาครัฐ

กรมสรรพากรได้เริ่มศึกษาแนวทางการเชื่อมโยงระบบไอที การแลกเปลี่ยนข้อมูลแบบ XML และการให้บริการออนไลน์ในแบบ Web Services มานานเกือบสิบปี จึงถือว่าเป็นหน่วยแรกๆที่บุกเบิกและนำเอาเทคโนโลยีเหล่านี้มาใช้ปฏิวัติระบบการดำเนินการงาน ตัวอย่างที่เห็นเด่นชัดเช่นหากท่านเปิดเว็บไปที่ http://www.rd.go.th/service/ ท่านจะพบรายชื่อ Web Services ที่ปัจจุบันกรมสรรพากรเปิดให้บริการอยู่

รูปภาพ 33 รายชื่อ Web Services ที่กรมสรรพากรเปิดให้บริการ

              กรมศุลกากรได้ลงทุนปรับปรุงระบบไอทีให้ทันสมัยก้าวหน้า อีกทั้งยังนำเอาวิธีการแลกเปลี่ยนข้อมูลแบบ XML และ Web Services มาใช้ควบคุมไปกับกระบวนการนำเข้าและส่งออก ทำให้ปัจจุบันกระบวนการนำเข้าและส่งออกสินค้าที่ผ่านกรมศุลกากรมีประสิทธิภาพสูงเนื่องจากไม่จำเป็นต้องรอข้อมูลที่เป็นเอกสารกระดาษอีกต่อไป แต่จะได้รับข้อมูลอิเล็คทรอนิกส์มาจากหน่วยงานค้างเคียงที่เกี่ยวข้องโดยอัตโนมัติ

              กรมศุลกากรเป็นผู้ผลักดันและประยุกต์ใช้กรรมวิธีการแลกเปลี่ยนข้อมูลแบบ ebXML (e-Business XML) ซึ่งเป็นมาตรฐานการแลกเปลี่ยนข้อมูลแบบ XML ที่มีความมั่นคงปลอดภัยสูงรูปแบบหนึ่ง ทำให้สามารถติดตามและตรวจสอบเอกสารอิเล็คทรอนิกส์ที่ผู้นำเข้า-ส่งออก ยื่นเรื่องขอนำเข้าส่งออกไว้ตามหน่วยงานราชการที่เกี่ยวข้องได้ตลอดทั่วทั้งกระบวนการ หากท่านเป็นผู้หนึ่งที่สนใจด้านการแลกเปลี่ยนข้อมูลแบบ ebXML และระบบ Paperless ท่านสามารถเข้าเว็บไซต์ที่กรมศุลกากรได้จัดทำไว้ที่ตำแหน่ง http://www.betongcustoms.com/index.php?lay=show&ac=article&Id=419322&Ntype=3 ดังภาพต่อไปนี้

รูปภาพ 34 เว็บไซต์ของกรมศุลกากรที่อนุญาตให้ดาวน์โหลดเอกสารที่เกี่ยวกับการแลกเปลี่ยนข้อมูลผ่านระบบ Paperless

              สำนักงานประกันสังคมถือได้ว่าเป็นหน่วยงานรัฐอีกแห่งที่พัฒนาระบบไอทีให้มีขีดความสามารถสูงจน สามารถเชื่อมโยงและแลกเปลี่ยนข้อมูลกับหน่วยงานอื่นข้างเคียงได้อย่างอัตโนมัติ โดยใช้วิธีการแบบ XML และ Web Services อีกทั้งเล็งเห็นถึงประโยชน์ของ SOA ที่จะเกิดขึ้นในระยะยาวจึงมุ่งพัฒนาระบบงานประกันสังคมให้กลายเป็นกระบวนการธุรกิจที่มีความยืดหยุ่นสูงตามแนวคิดของ SOA ซึ่งคาดว่าในอนาคตเราจะเห็นระบบงานประกันสังคมที่มีประสิทธิภาพสูงเชื่อมโยงใยกับภาครัฐ โรงพยาบาล ศูนย์การแพทย์และสาธารณสุข และหน่วยงานอื่นๆอีกมากมาย ส่งผลให้ผู้ประกันตนได้รับความสะดวกสบายในการใช้บริการและติดตามสถานะได้อย่างรวดเร็วแม่นยำทั่วถึงกันในทุกจุดบริการ

รูปภาพ 35 เว็บไซต์ของสำนักงานประกันสังคมแสดงให้เห็นถึงการบริการออนไลน์ที่ก้าวหน้า

นอกจากหน่วยงานรัฐที่กล่าวถึงทั้ง 3 หน่วยข้างต้นนี้แล้ว ปัจจุบันหน่วยงานรัฐอื่นอีกมากมายได้นำเอาไอทีมาใช้พัฒนาองค์การ จนกระทั่งหลายหน่วยงานมีศักยภาพเพียงพอสำหรับการเชื่อมโยงและแลกเปลี่ยนข้อมูลด้วยวิธีการ Web Services แล้ว เพียงแต่ยังขาดคนกลางที่จะมาช่วยส่งเสริมกระตุ้นให้เกิดการแลกเปลี่ยนความรู้ความเข้าใจ อีกทั้งช่วยควบคุมดูแลให้เกิดการแลกเปลี่ยนข้อมูลที่มั่นคงปลอดภัยน่าเชื่อถือ จึงเป็นเหตุผลที่กระทรวง ICT จัดตั้งเว็บไซต์ Web Services Helper System นี้ขึ้นด้วยความมุ่งหวังเป็นอย่างยิ่งว่าเว็บไซต์แห่งนี้จะกลายเป็นเครื่องมือหนึ่งที่ส่งเสริมให้ระบบราชการไทยก้าวไกลและก้าวหน้าไปสู่รัฐบาลอิเล็คทรอนิกส์ตามเป้าหมายที่วางไว้