Transcript 4. การดำเนินการ (ต่อ)

Optimizing Web Service messaging
performance in mobile computing
Sangyoon Oh*, Geoffrey C. Fox
What is Mobile computing ???
• Mobile computing ปัญญาประดิษฐ์แบบพกพา
คือ การนาเครื อข่ายคอมพิวเตอร์ และโทรศัพท์ไร้สายมาเชื่อมโยงกัน
ทาให้สามารถใช้โทรศัพท์ไร้สายติดต่อทางานร่ วมกับระบบคอมพิวเตอร์
ได้ มีช่วงการพัฒนา 3 ระดับ กล่าวคือ
What is Mobile computing ???
• ในเฟสแรก เป็ นการทาคอมพิวเตอร์ ให้เล็กลงเพื่อง่ายต่อการพกพา เป็ น
ยุคของ Mobile devices เริ่ มจากคอมพิวเตอร์ Laptop แล้วก็พฒั นาให้มี
ขนาดเล็กลงเรื่ อย ๆ จนกลายมาเป็ น PDA (Personal Digital Assistants)
ในปัจจุบนั
สามารถดาวน์โหลด(หรื ออัพโหลด)สารสนเทศจากเครื่ อง Desktop
Computer ได้ ผ่านกระบวนการที่รู้จกั กันทัว่ ไปว่า “Synchronization”
(เรี ยกสั้นๆว่า Sync)
What is Mobile computing ???
• ในเฟสที่สอง เปลี่ยนจากการ ใช้สายนาสัญญาณ มาเป็ นแบบไร้สาย
หรื อ wireless communication media.
• ในเฟสที่สาม เป็ นการรวมกันของสองเฟสแรก กล่าวได้วา่ เป็ นการใช้
Mobile devices ในสภาพแวดล้อมแบบไร้สาย (ซึ่งหมายถึง wireless
mobile computing นัน่ เอง)
What is Mobile computing ???
คุณสมบัติหลักๆ ที่ส่งผลให้ Mobile computing มีคุณสมบัติที่แตกต่างจาก
computing แบบอื่น ๆ คือ mobility และ broad reach
• Mobility (ความหมายโดยอ้อมคือ portability) หมายถึงผูใ้ ช้สามารถถือ
mobile device ติดตัวไปได้
• Broad reach หมายถึง สามารถติดต่อได้ตลอดเวลา
บทคัดย่ อ
เนื่องจาก ปัจจุบนั มีเว็บบริ การเกี่ยวกับการส่ งข้อความ สนทนา หรื อ
ข้อความแลกเปลี่ยนกันมากมาย และเป็ นที่มาของการเพิ่มขึ้นของการ ส่ ง
ข้อความแบบ streaming message คือการส่ งข้อความ ที่แสดงผลเป็ น
multimedia
ในที่น้ ี จะอธิบาย เกี่ยวกับการ ออกแบบ และคิดค้นแนวทางใหม่ เพื่อเพิ่ม
ประสิ ทธิภาพ ในการแลกเปลี่ยนข้อความ ดังกล่าว ซึ่งมีทรัพยากรอย่าง
จากัด บน โทรศัพท์เคลื่อนที่ และ ใน XML-based SOAP จะมีส่วนที่ไม่
จาเป็ น เช่น Overhead ของ Mobile Application
บทคัดย่ อ
ดังนั้น เพื่อให้สามารถแยกข้อมูล ออกจาก Syntax ออกเราจึงต้องใช้
streaming message โดยข้อมูลที่เหมือนกัน จะใช้พ้นื ที่ ในการจัดเก็บ
เดียวกัน โดยใช้งานร่ วมกัน คือ metadata
ทาให้รวดเร็ ว และดีกว่าเดิม
จากผลการทดลอง จะแสดงให้เห็นว่า มันมีประสิ ทธิภาพที่ดีกว่าเว็บบริ การ
แบบเดิม ทั้งเรื่ องของข้อความสนทนา และการแลกเปลี่ยน ข้อความแบบ
streaming message
1.บทนำ
• Web Service ตามสถาปัตยกรรมแบบ SOA ได้เป็ นส่ วนสาคัญของ
Grid computing ซึ่งหมายถึง เครื อข่ายที่เชื่อมโยงกันและมีการกระจาย
ทรัพยากรซึ่งกันและกัน ใช้งานร่ วมกัน จึงเปรี ยบเสมือนเป็ นการสื่ อสารกัน
แต่ในปัจจุบนั XML-based SOAP มีปัญหาเรื่ องการใช้ทรัพยากร หรื อ คาที่
ฟุ่ มเฟื อย เราจึงต้องแก้ปัญหาเหล่านี้ เพื่อให้ เข้ากับโทรศัพท์มือถือ ที่มีความ
จากัดในด้านต่างๆ เช่น การประมวลผล แบตเตอรี่ ที่จากัด และการเชื่อมต่อ
อินเตอร์เน็ต ที่ล่าช้า สิ่ งเหล่านี้ เป็ นเหตุสาคัญต่อประสิ ทธิภาพของการส่ ง
ข้อความ
1.บทนำ(ต่ อ)
และเนื่องด้วย SOAP ใช้ทรัพยากรจานวนมาก เช่น จานวนจุดทศนิยม
หรื อข้อมูลต่างๆ จะต้องถูกแปลงจากเดิมไปเป็ น ในรู ปแบบของ SOAP
ซึ่งเป็ นการประมวลผลขั้นสูง ที่ไม่เหมาะกับทรัพยากรที่มจี ากัดของ
โทรศัพท์มือถือ อีกทั้ง จานวน tags ของ syntax XML ที่เพิ่มมากขึ้น
ทาให้เกิดปัญหาของการจากัดการใช้งานบนโทรศัพท์มือถือ
มากขึ้นไปด้วย
1.บทนำ(ต่ อ)
มีการวิจยั เพื่อค้นหาวิธีแก้ไข ของประสิ ทธิภาพการทางานของระบบมือถือ
แต่เพียงแก้ได้แค่ผลลัพธ์ แต่ไม่ได้แก้ปัญหาที่ตวั ระบบ ในบทความนี้ เราจะ
กล่าวถึงการ สถาปัตยกรรมแบบใหม่ ที่เพิ่มประสิ ทธิภาพของการบริ การส่ ง
ข้อความบนมือถือให้ดีข้ ึน โดยสร้างสถาปัตยกรรมแบบยืดหยุน่ (HHFR) โดย
ใช้พ้นื ที่เก็บข้อมูล metadata แบบ Dynamic ซึ่งจะช่วยให้การส่ งข้อความและ
การแสดงผล สมบูรณ์มากยิง่ ขึ้น
ในที่น้ ี มีเนื้อหาหลัก 4 ส่ วน คือ ส่ วนที่2 จะเป็ นเบื้องหลังการทางาน ส่ วนที่ 3
คือการออกแบบสถาปัตยกรรม HHFR ส่ วนที่ 4 จะแสดงถึงรายละเอียด ของ
การดาเนินงานในระบบ
2.ที่มำ
จากการรายงานขอบเขตขององค์กร W3C ต้องการที่จะลดขนาดของการ
สื่ อสารแบบ XML จึงมีการประชุมเพื่อ ต้องการศึกษา กระบวนการบีบ
อัดเอกสาร XML และวิเคราะห์ส่วนสาคัญๆก่อนการส่ งข้อมูล และต้อง
ระบุความต้องการหรื อจุดประสงค์ของ XML ยกตัวอย่างเช่น
• ดาเนินการแบบสากล ที่สามารถใช้ได้ทวั่ ไป
• สร้างผลลัพธ์ที่หลากหลาย และไม่เกินขอบเขตของ Application
• ลดระยะเวลาของการประมวลผลข้อมูล และเวลาในการทาการซ่อน
ข้อมูล
• มีการแจ้งเตือนกลับมา หากระบบไม่สามารถเข้าใจในรู ปแบบของ
XML/SOAP
2.ที่มำ (ต่ อ)
เราจะแบ่งส่ วนที่คล้ายกันของ Grid/Web Service ที่สื่อสารตามรู ปแบบเดียวกัน
• อย่างแรก ส่ วนใหญ่ขอ้ เสนอของ XML จะมีลกั ษณะพิเศษของ W3C ที่มี
จุดมุ่งหมายที่จะสร้างข้อจากัดของตนเอง ไปยัง XML Massage มันควรจะมี
วิธีที่ดีกว่านี้ ที่ทาให้ การประมวลผลเร็ วขึ้น และขนาดของ Packet ของ
ข้อมูลเล็กลง และส่ วนที่คล้ายคลึงกัน ของข้อมูลในหมวดนั้นๆ จะแทนที่
คาศัพท์ที่ใช้บ่อย ด้วย index
ตัวอย่างข้อมูลที่เป็ นหมวดเดียวกันคือ การบีบอัด XML Schema-based(XSBC)
และ XML Infoset Encoding (XBIS)
2.ที่มำ (ต่ อ)
• อย่างที่สองมีขอ้ จากัดที่ไม่ใช่ของมันเอง ดังเช่นสถาปัตยกรรม HHFR ที่จะ
กล่าวดังต่อไปนี้
หมวดหมู่สุดท้าย ที่นาข้อความมาบีบอัด ซึ่งการบีบอัดจะช่วยลดขนาดของ
เอกสารแต่เพิ่มเวลาของการทางาน พอๆ กับ XML – Specific Compression
เช่น XMill ซึ่งจะดีกว่าการบีบอัดแบบธรรมดา แบบพวก Gzip แต่มนั ก็ไม่ได้
ทาให้ประสิ ทธิภาพดีมาก เพราะมันจะเพิม่ ขั้นตอนของการประมวลผล ซึ่ง
หากมี Compression ก็ตอ้ งมี Decompression ด้วยเช่นกัน
2.ที่มำ (ต่ อ)
• The Global Grid Forum’s Data Description Language (DFDL) มันจะ
กล่าวถึงข้อตกลงของภาษา หรื อคาบรรยายเอกสารหรื อรู ปแบบข้อมูลแบบ
Grid Computing สถาปัตยกรรม DFDL จะประกอบไปด้วยขั้นตอนพื้นฐาน
3 ส่ วน คือ
1) ชั้นล่างสุ ด (Mapping)
2) ชั้นกลาง (Abstract data Model)
3) ชั้นล่าง (API)
2.ที่มำ (ต่ อ)
ซึ่งชั้น mapping มันจะทาการจับคู่ระหว่าง ตัวแทนข้อมูลกับหัวข้อมูล
เช่น มันจะนิยามรู ปแบบตัวเลขสาหรับข้อมูล ไม่วา่ จะขนาดใด หรื อรู ปแบบ
ซับซ้อน เช่น Array แต่ model ชั้นนี้ ก็จะนิยามโครงสร้างข้อมูลขึ้นเอง
สิ่ งที่นิยามคล้ายกัน คือ จะมุ่งเน้นไปที่การนาเสนอ Massage ที่ดีกว่า และมี
ประสิ ทธิภาพที่ดีกว่าขึ้น
และสถาปัตยกรรม HHFR มีขอบเขตของงานทั้งหมดนั้น จะใช้เว็บบริ การ
ด้านฐานข้อมูล เพื่อลดขนาดของ Massage และเพื่อสนับสนุนการ
แลกเปลี่ยนข้อความ แบบ Streaming อีกด้วย
3. กำรออกแบบสถำปัตยกรรม
สถาปัตยกรรมซอฟท์แวร์แบบใหม่ ที่มีชื่อว่าThe Handheld Flexible
Representation หรื อ HHFR นั้น ถูกออกแบบมาสาหรับช่วยให้การสื่ อสาร
ข้อมูล หรื อการแลกเปลี่ยน message ได้มากขึ้น เร็ วขึ้น และดีข้ ึนกว่าเดิม
บน mobile web services
•
HHFR จะทาการแยกmessage content ออกจาก SOAP message
ที่อยูใ่ นเครื่ องหมาย Angle-Bracket ( [ - ] ) และจะทางานอยูใ่ นend point หรื อ
ฝั่งผูส้ ่ งและฝั่งผูร้ ับของการสื่ อสาร (ทั้งสองฝ่ าย)
•
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.1 พูดถึงกำรออกแบบ
ส่ วนสาคัญที่ถูกออกแบบมาในสถาปัตยกรรมนี้ เช่น การทาให้ขนาดของ
ตัวแทนของข้อมูล (end point) มีขนาดเล็กลง เพราะข้อเสี ยของ
XML Syntax คือ มีความยาวมากเกินไป
HHFR จะจัดหาวิธีการติดต่อสื่ อสาร เพื่อแลกเปลี่ยน SOAP message กัน
ของทั้งสองฝ่ าย โดยจะแยก XML Syntax ของ SOAP message และ
SOAP message contents ออกมา
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.1 พูดถึงกำรออกแบบ
ส่ วนประกอบของSOAP โดยทัว่ ไป ทาให้เกิดปัญหาคอขวด(bottlenect) หรื อ
ทาให้เกิดการติดขัดของข้อมูลมากขึ้น เพราะข้อมูลมีปริ มาณมากบนระบบ
เครื อข่ายไร้สาย
โครงสร้างข้อมูลและประเภทของSOAP body ที่ถูกแยกออกมา จะเริ่ มทาการ
สื่ อสารกันในช่วงเริ่ มต้นของการ stream
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.1 พูดถึงกำรออกแบบ
- การกาหนดเป้ าหมายการเดินทางของmessage
HHFR จะทางานได้ดีที่สุดสาหรับ web services เมื่อปลายทางทั้งสองแลก
เปลี่ยน stream message กัน message ในstream จะแชร์โครงสร้างแลกประเภท
ของ information ของSOAP body และheader ของ message ส่ วนใหญ่ จะไม่
เปลี่ยนแปลงใน stream session เพราะฉะนั้น โครงสร้างและประเภท จะอยูใ่ น
รู ปแบบของ XML Schema และheader สามารถถูกส่ งได้เพียงครั้งเดียวเท่านั้น
และส่ วนที่เหลือของmessage ที่อยูใ่ น stream ก็จะมีเพียง payload เท่านั้น
(payload คือสิ่ งที่ถูกบรรทุกอยูข่ องการรับส่ งข้อมูล) ซึ่งการ stream ของ
message สามารถทาได้โดยเริ่ มจากการไม่ปิดกั้นการส่ งmessage
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.1 พูดถึงกำรออกแบบ
- ใช้ Context-Store เป็ นที่เก็บ
ในสถาปัตยกรรม HHFR ส่ วนของContext-store จะเก็บ static data
จากmessage stream ซึ่งเก็บSOAP headerที่ไม่ได้ผา่ นการเปลี่ยนแปลงมาก่อน
XML Schema เป็ นตัวแทนของข้อมูล และลักษณะพิเศษของ stream คือการจัด
เก็บในช่วง negotiation stage (ช่วงการสื่ อสารเจรจา) โดยทาการบันทึกตัวSOAP
header และตัวแทนข้อมูล ไปเก็บไว้ใน context store ซึ่งอยูใ่ นรู ปแบบที่มีความ
เหมาะสม เพราะสถาปัตยกรรม HHFR จะลดขนาดของ message ลง
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.1 พูดถึงกำรออกแบบ
• - ทางานร่ วมกับสถาปัตยกรรม Web service
ต่างจากวิธีการแก้ปัญหาอื่นๆ เพราะสถาปัตยกรรมนี้ โดยรวมแล้ว ไม่ได้
เปลี่ยนแปลงในเรื่ องของการทางานร่ วมกัน ตาม มาตรฐาน ของ web service
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.2 กำรแยกตัวแทนข้ อมูล
แนวคิดสาคัญของสถาปัตยกรรม HHFR อย่างหนึ่ง คือการมีตวั แทนข้อมูล
ที่เหมาะสม และขณะที่กาลังทาการติดต่อสื่ อสารกันของทั้ง 2 ฝ่ าย จะไม่
ทาให้ความสามารถในการทางานร่ วมกันได้เสี ยไป เพราะเราออกแบบ
HHFR ให้มนั ทาการจัดหาตัวแทนข้อมูลที่มีความเหมาะสมกับ
สภาพแวดล้อมของการสื่ อสารXML และ SOAP Infoset
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.2 กำรแยกตัวแทนข้ อมูล
สิ่ งแรกสาหรับการจะนามาอธิบาย SOAP Infoset ในสถาปัตยกรรมนี้ ก็คือ
XMLInfoset ตั้งแต่ SOAP เป็ น XML Based language และข้อจากัด
ล่าสุ ด ในversion1.2 คือ ใช้ XML Infoset ซึ่งรายละเอียดของ XML
Infoset คือการช่วยทาให้ภาษาอื่นๆเข้ามาเป็ นส่ วนหนึ่งของ XML และ
ยังช่วยในเรื่ องของข้อจากัดในการนา Application ไปออกแบบ และ
พัฒนาต่อ ซึ่งการจัดรู ปแบบของข้อมูลที่มี XML APIs รู ปแบบที่กาหนด
ไว้โดน XML Infoset จะไม่ผกู ติดไว้กบั XML API ใดๆ อย่างเช่น
Document Object Model(DOM) , Simple API for XML (SAX) , และ
XML PULL Parser (XPP)เป็ นต้น ดังนั้น การพัฒนา Application จะเป็ น
อิสระตามข้อกาหนดของ XML Infoset
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• 3.2 กำรแยกตัวแทนข้ อมูล
ในสถาปัตยกรรมของเรา เราได้กาหนดให้รูปแบบข้อมูลเป็ น SOAP Infoset
ดังนั้น สถาปัตยกรรม HHFR สามารถแยกตัวแทน -XML/SOAP syntax
และ SOAPmessage content โดนไม่ตอ้ งเสี ย message contents ใดๆ
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• Binary Representation of SOAP
Binary representation เป็ นตัวเลือกที่สาคัญตัวหนึ่ง ในการปรับปรุ ง
ประสิ ทธิภาพโดยรวมของสถาปัตยกรรม HHFR ซึ่งมีหลายอย่าง อย่างแรก
คือมันจะช่วยลดขนาดของการแลกเปลี่ยน message โดยการดึงส่ วนของ
SOAP syntax (พวกวงเล็บ [ ] )ที่มีมากเกินไปออกไป ทาให้สามารถลด
ขนาดลงไปได้สูงสุ ดถึง10เท่า เมื่อโครงสร้างเอกสารนั้นมีความซ้ าซ้อน
มาก โดยอย่างง่ายที่สุดก็คือ พวก single textสามารถลดขนาดตัวมันเองได้
ครึ่ งหนึ่ง ดังนั้น จึงเป็ นการดีที่เราสามารถลดขนาดของเอกสาร เพื่อการ
แลกเปลี่ยนกันได้
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• Binary Representation of SOAP
อย่างไรก็ตาม มันก็มีความจาเป็ นอย่างมากอยูด่ ี
เพราะในระแบบ mobile computing ยังมีการจากัดของ bandwidth อยู่
สุ ดท้ายนี้ ประโยชน์ขอ้ อื่นๆของ Binary representation ของ SOAP message
ในสถาปัตยกรรม HHFR คือ สามารถแยกแต่ละ message ออกมาได้
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• Message handling
soap message มีองค์ประกอบภายนอกมากที่สุด soap envelope ใน
เอกสาร XML ประกอบด้วย header และ body ซึ่งบรรจุโปรแกรม หรื อ
ข้อมูลอยู่ เช่น คาแนะนาในการแยก , ข้อมูลความปลอดภัย , และการ
กาหนดเส้นทาง/ข้อมูลความน่าเชื่อถือ การจัดการสถาปัตยกรรม
3. กำรออกแบบสถำปัตยกรรม(ต่ อ)
• Context store
หนึ่งในองค์ประกอบที่สาคัญของสถาปัตยกรรม HHFR คือ context store
โดยcontext store ทาให้สามารถค้นหา context information จากการ
สื่ อสารของ SOAP message ได้
4. กำรดำเนินกำร
• การทดลองเพื่อแสดงให้เห็นถึงประสิ ทธิภาพของสถาปัตยกรรม HHFR
และเราได้ดาเนินการตามแบบแผนของ Mobile Web Service โดยมี
โครงสร้างพื้นฐานตั้งอยูบ่ นสถาปัตยกรรม ซึ่งสถาปัตยกรรม HHFR
ประกอบไปด้วย HHFR Schema และ Processor ที่มีช่องทางการ
ติดต่อสื่ อสารที่รวดเร็ วประกอบกับมีการทางานที่ยดื หยุน่ มาเป็ นตัว
ดาเนินการแทน แล้วยังมีการจัดเก็บข้อมูลไว้ที่ Context-store
4. กำรดำเนินกำร (ต่ อ)
• ขั้นตอนโดยพื้นฐานสามารถทาได้ดงั นี้
1.) ปลายทางของ HHFR-capable จะส่ งการเจรจาต่อรองที่เป็ นคาร้องขอ
ไปยังปลายทางที่ได้เตรี ยมไว้ ซึ่งการร้องขอนี้เป็ นแบบ SOAP message
ประกอบกับลักษณะเฉพาะ แล้วส่ งไปยังช่วงต่อไป
2.)ในการเจรจาต่อรอง message ของ ปลายทาง service client ที่เป็ นผูเ้ ริ่ ม
ส่ งข้อมูลเพื่อไปอ้างถึงการเขียน HHFR Schema ซึ่งจะมีการอธิบาย
เพิม่ เติมในหัวข้อที่ 4.2 และระบบบริ การลูกค้าปลายทาง จะเป็ นผู ้
โต้ตอบโดยการส่ งข้อมูลที่เป็ นผลลัพธ์ออกไป
4. กำรดำเนินกำร (ต่ อ)
• ขั้นตอนโดยพื้นฐานสามารถทาได้ดงั นี้
3.) ทั้งสองปลายทางจะมีช่องทางอื่นในการขนย้าย สาหรับการแลกเปลี่ยน
message โดยจะมีการส่ งต่อข้อความอย่างต่อเนื่อง ซึ่ง message จะส่ งต่อ
ข้อมูลอยูใ่ นระบบโดยมีการเจรจาเป็ นตัวดาเนินงาน
4.) ส่ วนของ message ที่ซ้ าหรื อไม่มีการเปลี่ยนแปลงจะทาให้การเก็บ
ข้อมูลกลายเป็ นแบบ dynamic นัน่ หมายถึง เมื่อไม่มีขอ้ มูลใหม่เข้ามา ก็
จะส่ งผลให้ เกิดช่องว่างระหว่าง Context-store ทาให้ขอ้ มูลมีการ
หมุนเวียนได้คล่องตัวมากขึ้น
4. กำรดำเนินกำร (ต่ อ)
• โดยจะมุ่งเน้นไปที่การตรวจสอบหาค่าที่เหมาะสมของการ
แลกเปลี่ยน message โดยพยายามจัดการกับปัญหาที่มีอยู่ และไป
ดาเนินการพร้อมทั้งแทรกหัวข้อที่เราสนใจนอกเหนือจากเรื่ องที่เรา
ศึกษา และ SOAP ที่เป็ นตัวชี้แจง สาหรับการเคลื่อนที่ในสภาวะ
แวดล้อมต่างๆ และแหล่งเก็บข้อมูลของ metadata ซึ่งภาพรวมสามารถดู
ได้จากภาพที่ 3
4. กำรดำเนินกำร (ต่ อ)
รูปภำพที่ 3 ภำพรวมของกำรดำเนินกำรขั้นพืน้ ฐำน
4. กำรดำเนินกำร (ต่ อ)
4.1 รูปแบบกำรเจรจำต่ อรอง (Negotiation scheme)
โดยปกติของ HHFR session จะมีระยะเวลาเริ่ มต้นในการเจรจาต่อรอง
เพื่อแลกเปลี่ยนการต่อรองระหว่างสองปลายทางด้วย SOAP message
โดยการออกแบบระยะเวลาในการเจรจาต่อรองเป็ นสิ่ งที่สาคัญมาก เพื่อ
นาไปสู่การสร้างลักษณะเฉพาะดังต่อไปนี้
4. กำรดำเนินกำร (ต่ อ)
4.1 รูปแบบกำรเจรจำต่ อรอง (Negotiation scheme)
• ในระยะเวลาระหว่างการโต้ตอบกับระบบ Service ปลายทาง จะมี
ลักษณะเฉพาะ นัน่ ก็คือแนะนาวิธีในการริ เริ่ มการเจรจาต่อรองและการ
ได้รับการยืนยันจากระบบ Service ปลายทาง ซึ่งในส่ วนของ Prototype
จะมีการดาเนินการโดยขั้นตอนการเริ่ มต้นอย่างง่ายๆ
• เมื่อเริ่ มมีการส่ งคาร้อง SOAP ไปยังระบบ intended ปลายทางแล้วการ
เจรจาต่อรองจะสิ้ นสุ ดลงเมื่อมีการได้รับการโต้ตอบจาก Service
4. กำรดำเนินกำร (ต่ อ)
4.1 รู ปแบบกำรเจรจำต่ อรอง
• ส่ วนขั้นตอนในการเจรจาต่อรองจะมีความแตกต่างกันว่าระบบ Service
ปลายทางสามาระทา HHFR-capable ได้หรื อไม่ เพราะการเจรจาต่อรอง
จะดาเนินการผ่านขั้นตอน SOAP protocol โดยวิธีการนี้จะสามารถ
ทางานร่ วมกันกับระบบ Service ปลายทาง (การตอบกลับการเจรจา
ต่อรอง – the negotiation responder) เพื่อที่จะปฏิเสธ HHFR session
และใช้ SOAP เป็ นพื้นฐานในการติดต่อสื่ อสารกับ Web service โดย
ลูกค้า (SOAP เริ่ มต้น – the SOAP initiator) จะกลับไปใช้รูปแบบการส่ ง
ข้อมูลแบบเดิมถ้าหากได้รับ SOAP fault หรื อ SOAP error ซึ่ง
หมายความว่าการตอบสนองของ Service มีความไม่เหมาะสม (การ
ส่ งออก - exported) กับกระบวนการนี้ และ SOAP ไม่สามารถเข้าใจ
message ของการเจรจาต่อรองนี้ได้
4. กำรดำเนินกำร (ต่ อ)
4.2 HHFR: อธิบำยภำษำของข้ อมูล
• ข้อมูลที่ไม่ใช่ XML- แยก ข้อความและข้อมูล XML - ข้อความ SOAP
หรื อการดาเนินการที่ตอ้ งการใดๆ เรากาหนด DFDL-style เป็ นภาษาใน
การบรรยายข้อมูล HHFR Schema ซึ่งมันเป็ นเซตย่อยของ XSDกับสิ่ ง
เพิม่ เติมเข้าไปบางอย่าง ,สถาปัตยกรรมของ HHFR schema คล้ายกับ
DFDL: HHFR Schema อธิบายรู ปแบบข้อมูล, Schema Processor
(DSParser) สร้างแบบจาลองข้อมูล HHFR และStreamer แปลงเนื้อหา
ข้อมูลและนาเสนอรู ปแบบข้อมูลที่ตอ้ งการ
4. กำรดำเนินกำร (ต่ อ)
4.2 HHFR: อธิบำยภำษำของข้ อมูล
• HHFR Schema กาหนดเซตย่อยขององค์ประกอบ XSD: การกาหนด
ประเภทแบบง่าย , ประเภทองค์ประกอบความหมายที่ซบั ซ้อน,
ประกาศ element , และประกาศ แอตทริ บิวต์ HHFR schema กาหนด
จานวน จากัด รู ปแบบง่ายๆในตัว.XML schema พวก string, int, byte,
float, Boolean. ปัจจุบนั ของ HHFR Schema ไม่สนับสนุน UserDefined symple Type องค์ประกอบของ HHFR Schema สามารถมี
เนื้อหาที่หลากหลาย แต่ไม่สามารถมีเนื้อหาที่มีองค์ประกอบเดียวหรื อ
เนื้อหาที่วา่ งเปล่า ดังนั้นเราจึงประกาศcomplexType element โดยไม่
ต้องรวมแอตทริ บิวต์ ดังตัวอย่างต่อไปนี้:
4. กำรดำเนินกำร (ต่ อ)
4.2 HHFR: อธิบำยภำษำของข้ อมูล
4. กำรดำเนินกำร (ต่ อ)
4.2 HHFR: อธิบำยภำษำของข้ อมูล
• การประมวลผล HHFR Schema เกี่ยวข้องกับหลายโมดูล แสดงในรู ปที่ 4
HHFR Schema processor, DSParser, ได้รับ HHFR Schema, ซึ่งมีอยูใ่ น
การเจรจาต่อรองร้องขอและข้อความตอบกลับของSOAP ดูในรู ปที่ 4
ขั้นตอน ที่1 เป็ น input และสร้างข้อมูลภายในแบบจาลอง HHFR ขณะที่
output ดูในขั้นตอน 2 ที่ภาพ ความสัมพันธ์ระหว่างHHFR Schema และ
HHFR data model มีความคล้ายคลึงกับความสัมพันธ์ระหว่างเอกสาร
XML และ Java DOM Object
4. กำรดำเนินกำร (ต่ อ)
4.2 HHFR: อธิบำยภำษำของข้ อมูล
• หลังจาก2ขั้นตอน , HHFR ตอนเริ่ มรันเป็ นตัวเลือกของการ
ส่ งต่อที่รวดเร็ ว ซึ่งจะกล่าวถึงในต่อไปนี้
องค์ประกอบและการประมวลผลข้อมูลผ่าน Streamer
Streamer เป็ น interpret-style stub object ซึ่งเป็ นสไตล์การ
ออกแบบที่นิยมมาก เมื่อเทียบกับ compiled-style stub มี
ประสิ ทธิ ภาพมากกว่า ซึ่งเป็ นที่นิยมจานวนมากในclient และการ
ใช้งาน RPC server interpret-style stub มีความยืดหยุน่ และเป็ น
การดาเนินงาน เพื่อนาเข้าข้อมูล แบบDynamic
4. กำรดำเนินกำร (ต่ อ)
4.2 HHFR: อธิบำยภำษำของข้ อมูล
จากการป้ อนข้อมูล stub(ส่ วนที่ยงั เหลืออยู)่ ไม่จาเป็ นต้องถูก re-complied
เพื่อเป็ นการดาเนินการแทนข้อมูลที่ต่างกัน , อ่านและเขียน แพ็กเก็ต
ข้อความ stub(ส่ วนที่ยงั เหลืออยู)่ ผ่าน switch statement; packetข้อความ
เป็ นตัวแทนหน่วยหนึ่งของข้อความที่ตอ้ งการ , ในPrototype แทน
binary เป็ นลาดับของไบต์ เป็ นรู ปแบบการแสดงเริ่ มต้นสาหรับแพ็คเก็ต
ข้อความ
4. กำรดำเนินกำร (ต่ อ)
รู ปที่ 4. HHFR schema processing and interactions between related modules.
4. กำรดำเนินกำร (ต่ อ)
4.3 Data Streaming
• Data Streaming เป็ นคุณลักษณะต้นแบบที่สาคัญของ HHFR Prototype
และมันช่วยให้ระบบมือถือแลกเปลี่ยนข้อความบนเครื อข่ายไร้สายได้
อย่างมีประสิ ทธิภาพ ด้วยวิธี Streaming การแลกเปลี่ยนข้อความแบบ
เครื อข่ายไร้สายอาจมีปัญหา อย่างเช่น ใช้เวลาค่อนข้างสูงและการ
เชื่อมต่อช้า ปัญหาดังกล่าวจึงควรหาแนวทางเพื่อให้มนั ยืดหยุน่ ลด
ระยะเวลาส่ งข้อความและลดการใช้ bandwidth
4. กำรดำเนินกำร (ต่ อ)
4.3 Data Streaming
• ช่องทางการสื่ อสารที่รวดเร็ วของ HHFR Prototype จัดหาให้แบบไม่
ประสานเวลาและเป็ นทางเลือกที่เหมาะสม ใช้ HTTPอัตโนมัติ ใน
การสื่ อสาร ตามที่ได้อธิบาย, การเจรจาต่อรอง การตอบสนองจากการ
ให้บริ การจะต้องมีจุดสิ้ นสุ ด (IP และหมายเลขพอร์ต) การสื่ อสารจะเริ่ ม
โดย service client
4. กำรดำเนินกำร (ต่ อ)
4.3 Data Streaming
• ช่องการสื่ อสารที่รวดเร็ วสาหรับชั้น TCP จะแสดงในรู ปที่ 5 ด้านผู ้
ให้บริ การ , StreamConnectionFactory รอการเชื่อมต่อเข้า จาก
server socket และสร้าง StreamConnection ควบคุมช่วงที่เกี่ยวข้องกับ
Streaming ทั้งหมด เช่น StreamReader ,StreamWriter และ Streamer
ข้อมูลที่โปรแกรมพยายามจะส่ งเข้าตามลาดับก่อนหลังใน StreamWriter
รวมไปถึงเส้นทาง HHFRHandler และ StreamConnection ข้อมูลที่
ได้รับดังต่อไปนี้ ถ้าเส้นทางตรงข้ามกันจะถูกส่ งไปที่ วิธีการ onMessage
4. กำรดำเนินกำร (ต่ อ)
4.3 Data Streaming
รูปที่ 5. Fast communication channel layer.
4. กำรดำเนินกำร (ต่ อ)
4.4 Context-store
• ส่ วนของข้อความที่ซ้ าซ้อนอาจจะถือว่าเป็ นMetadata และ เก็บไว้ในที่
เก็บข้อมูล เราปรับข้อมูลบริ การ (ระบบMetadata catalpg) สาหรับการ
จัดเก็บ Metadata ที่จาเป็ นชัว่ คราว
• ระบบสารสนเทศ, จากความเห็นที่บอกว่ามีขอ้ ผิดพลาด ในข้อมูลบริ การ
(FTHPIS) ซึ่งใช้และเสนอให้ the WS-Context Specification พัฒนา
โดยชุมชนห้องปฏิบตั ิการ Grids ของมหาวิทยาลัยอินเดียนาและจะถูก
นามาใช้เป็ นที่พกั เพื่อเก็บเก็บ metadata ชัว่ คราว นัน่ คือจะเก็บส่ วนที่
ซ้ าซ้อน จากข้อความ SOAP ซึ่งมีการแลกเปลี่ยนระหว่างสอง endpoints
4. กำรดำเนินกำร (ต่ อ)
4.4 Context-store
• วิธีน้ ีจะลดขนาดของข้อความ SOAP ซึ่งถือว่าเป็ นส่ วนของ XML ซึ่งมี
การเข้ารหัสทุกๆข้อความ ในSOAP ในระหว่างการแลกเปลี่ยนระหว่าง
สองบริ การ องค์ประกอบ XML เหล่านี้ เก็บไว้เป็ นบริ บทในการบริ การ
ข้อมูล แต่ละบริ บทอ้างอิงโดยระบบที่กาหนด URI เอกลักษณ์ของURI
คือมัน่ ใจบริ การข้อมูลที่สอดคล้องกัน URI แทนที่องค์ประกอบที่
ซ้ าซ้อนของ XML ในข้อความ SOAP ดังนั้นขนาดของข้อความจะลดลง
ได้เร็ วขึ้น การถ่ายโอนข้อความ เมื่อได้รับข้อความ SOAP, ฝ่ ายที่
เกี่ยวข้องมีปฏิสมั พันธ์กบั มาตรฐาน WS Context บริ การข้อมูลเพื่อดึง
บริ บทที่เกี่ยวข้องกับ URIs ระบุไว้ในข้อความ SOAP
4. กำรดำเนินกำร (ต่ อ)
4.4 Context-store
รูป6 .Context-store operation overview
4. กำรดำเนินกำร (ต่ อ)
4.4 Context-store
• ในภาพที่ 6 Ws-Context มี 2 method ที่เป็ นพื้นฐาน เกี่ยวข้องกับ
Information Services คือ getContent() และ setContent() methods, ซึ่ง
เป็ นการเข้าถึงและจัดเก็บ Operation methods สามารถเรี ยกได้เมื่อไหร่ ก็
ตามที่ปลายทางต้องการสร้าง, อัพเดต,หรื อเรี ยกข้อมูลใน Context-store
(บริ การสารสนเทศ)
4. กำรดำเนินกำร (ต่ อ)
4.4 Context-store
• Context-store client สามารถทาสิ่ งต่อไปนี้ได้คือ
1) สร้าง ContextServiceHandler object กับ ContextService URI
2)เก็บข้อมูลประเภทใดๆที่ไม่ซ้ ากัน
3)เรี ยกข้อมูลจาก Contex Context ServiceHandler object เป็ น wrapper
class และประกอบด้วย 2 methods คือ getContent() และ SetContent()
methods.
จบการนาเสนอ
รำยชื่อสมำชิกกลุ่ม Mobile Computing
• นาย ถิรายุ วรรณี เวชศิลป์
• นางสาว มาลินี มีโพธิ์
• นางสาว ณัฏฐนันท์ แสงสุ ริย ์
• นางสาว ผกามาศ โวลา
• นางสาว เกษริ นทร์ ต๊ะนา
• นางสาว จริ ยา มงคลธนวัฒน์
• นางสาว ประภา สัทธยาสัย
รหัสนิสิต 53160005
รหัสนิสิต 53160014
รหัสนิสิต 53160026
รหัสนิสิต 53160028
รหัสนิสิต 53160062
รหัสนิสิต 53160063
รหัสนิสิต 53160070