Optimizing Web Service messaging performance in mobile computing

1. Optimizing Web Service messaging performance in mobile computing Sangyoon Oh*, Geoffrey C. Fox

2. What is Mobile computing ??? • Mobile computing ปัญญาประดิษฐ์แบบพกพา คือ การนำเครือข่ายคอมพิวเตอร์ และโทรศัพท์ไร้สายมาเชื่อมโยงกัน ทำให้สามารถใช้โทรศัพท์ไร้สายติดต่อทำงานร่วมกับระบบคอมพิวเตอร์ได้ มีช่วงการพัฒนา 3 ระดับ กล่าวคือ

3. What is Mobile computing ??? • ในเฟสแรก เป็นการทำคอมพิวเตอร์ให้เล็กลงเพื่อง่ายต่อการพกพา เป็นยุคของ Mobile devices เริ่มจากคอมพิวเตอร์ Laptop แล้วก็พัฒนาให้มีขนาดเล็กลงเรื่อย ๆ จนกลายมาเป็น PDA (Personal Digital Assistants) ในปัจจุบัน สามารถดาวน์โหลด(หรืออัพโหลด)สารสนเทศจากเครื่อง Desktop Computer ได้ ผ่านกระบวนการที่รู้จักกันทั่วไปว่า “Synchronization” (เรียกสั้นๆว่า Sync)

4. What is Mobile computing ??? • ในเฟสที่สอง เปลี่ยนจากการ ใช้สายนำสัญญาณ มาเป็นแบบไร้สาย หรือ wireless communication media. • ในเฟสที่สาม เป็นการรวมกันของสองเฟสแรก กล่าวได้ว่า เป็นการใช้ Mobile devices ในสภาพแวดล้อมแบบไร้สาย (ซึ่งหมายถึง wireless mobile computing นั่นเอง)

5. What is Mobile computing ??? คุณสมบัติหลักๆ ที่ส่งผลให้ Mobile computing มีคุณสมบัติที่แตกต่างจาก computing แบบอื่น ๆ คือ mobility และ broad reach • Mobility (ความหมายโดยอ้อมคือ portability) หมายถึงผู้ใช้สามารถถือ mobile device ติดตัวไปได้ • Broad reach หมายถึง สามารถติดต่อได้ตลอดเวลา

6. บทคัดย่อ เนื่องจาก ปัจจุบันมีเว็บบริการเกี่ยวกับการส่งข้อความ สนทนา หรือข้อความแลกเปลี่ยนกันมากมาย และเป็นที่มาของการเพิ่มขึ้นของการ ส่งข้อความแบบ streaming message คือการส่งข้อความ ที่แสดงผลเป็น multimedia ในที่นี้ จะอธิบาย เกี่ยวกับการ ออกแบบ และคิดค้นแนวทางใหม่ เพื่อเพิ่มประสิทธิภาพ ในการแลกเปลี่ยนข้อความ ดังกล่าว ซึ่งมีทรัพยากรอย่างจำกัด บน โทรศัพท์เคลื่อนที่ และ ใน XML-based SOAP จะมีส่วนที่ไม่จำเป็น เช่น Overhead ของ Mobile Application

7. บทคัดย่อ ดังนั้น เพื่อให้สามารถแยกข้อมูล ออกจาก Syntax ออกเราจึงต้องใช้ streaming message โดยข้อมูลที่เหมือนกัน จะใช้พื้นที่ ในการจัดเก็บเดียวกัน โดยใช้งานร่วมกัน คือ metadata ทำให้รวดเร็ว และดีกว่าเดิม จากผลการทดลอง จะแสดงให้เห็นว่า มันมีประสิทธิภาพที่ดีกว่าเว็บบริการแบบเดิม ทั้งเรื่องของข้อความสนทนา และการแลกเปลี่ยน ข้อความแบบ streaming message

8. 1.บทนำ • Web Service ตามสถาปัตยกรรมแบบ SOA ได้เป็นส่วนสำคัญของ Grid computing ซึ่งหมายถึง เครือข่ายที่เชื่อมโยงกันและมีการกระจายทรัพยากรซึ่งกันและกัน ใช้งานร่วมกัน จึงเปรียบเสมือนเป็นการสื่อสารกัน แต่ในปัจจุบัน XML-based SOAP มีปัญหาเรื่องการใช้ทรัพยากร หรือ คำที่ฟุ่มเฟือย เราจึงต้องแก้ปัญหาเหล่านี้ เพื่อให้ เข้ากับโทรศัพท์มือถือ ที่มีความจำกัดในด้านต่างๆ เช่น การประมวลผล แบตเตอรี่ที่จำกัด และการเชื่อมต่อ อินเตอร์เน็ต ที่ล่าช้า สิ่งเหล่านี้ เป็นเหตุสำคัญต่อประสิทธิภาพของการส่งข้อความ

9. 1.บทนำ(ต่อ) และเนื่องด้วย SOAP ใช้ทรัพยากรจำนวนมาก เช่น จำนวนจุดทศนิยม หรือข้อมูลต่างๆ จะต้องถูกแปลงจากเดิมไปเป็น ในรูปแบบของ SOAP ซึ่งเป็นการประมวลผลขั้นสูง ที่ไม่เหมาะกับทรัพยากรที่มีจำกัดของโทรศัพท์มือถือ อีกทั้ง จำนวน tags ของ syntax XML ที่เพิ่มมากขึ้น ทำให้เกิดปัญหาของการจำกัดการใช้งานบนโทรศัพท์มือถือ มากขึ้นไปด้วย

10. 1.บทนำ(ต่อ) มีการวิจัยเพื่อค้นหาวิธีแก้ไข ของประสิทธิภาพการทำงานของระบบมือถือ แต่เพียงแก้ได้แค่ผลลัพธ์ แต่ไม่ได้แก้ปัญหาที่ตัวระบบ ในบทความนี้ เราจะกล่าวถึงการ สถาปัตยกรรมแบบใหม่ ที่เพิ่มประสิทธิภาพของการบริการส่งข้อความบนมือถือให้ดีขึ้น โดยสร้างสถาปัตยกรรมแบบยืดหยุ่น (HHFR) โดยใช้พื้นที่เก็บข้อมูล metadata แบบ Dynamic ซึ่งจะช่วยให้การส่งข้อความและการแสดงผล สมบูรณ์มากยิ่งขึ้น ในที่นี้ มีเนื้อหาหลัก 4 ส่วน คือ ส่วนที่2 จะเป็นเบื้องหลังการทำงาน ส่วนที่ 3 คือการออกแบบสถาปัตยกรรม HHFR ส่วนที่ 4 จะแสดงถึงรายละเอียด ของการดำเนินงานในระบบ

11. 2.ที่มา จากการรายงานขอบเขตขององค์กร W3C ต้องการที่จะลดขนาดของการสื่อสารแบบ XML จึงมีการประชุมเพื่อ ต้องการศึกษา กระบวนการบีบอัดเอกสาร XML และวิเคราะห์ส่วนสำคัญๆก่อนการส่งข้อมูล และต้องระบุความต้องการหรือจุดประสงค์ของ XML ยกตัวอย่างเช่น • ดำเนินการแบบสากล ที่สามารถใช้ได้ทั่วไป • สร้างผลลัพธ์ที่หลากหลาย และไม่เกินขอบเขตของ Application • ลดระยะเวลาของการประมวลผลข้อมูล และเวลาในการทำการซ่อนข้อมูล • มีการแจ้งเตือนกลับมา หากระบบไม่สามารถเข้าใจในรูปแบบของ XML/SOAP

12. 2.ที่มา (ต่อ) เราจะแบ่งส่วนที่คล้ายกันของ Grid/Web Service ที่สื่อสารตามรูปแบบเดียวกัน • อย่างแรก ส่วนใหญ่ข้อเสนอของ XML จะมีลักษณะพิเศษของ W3C ที่มีจุดมุ่งหมายที่จะสร้างข้อจำกัดของตนเอง ไปยัง XML Massage มันควรจะมีวิธีที่ดีกว่านี้ ที่ทำให้ การประมวลผลเร็วขึ้น และขนาดของ Packet ของข้อมูลเล็กลง และส่วนที่คล้ายคลึงกัน ของข้อมูลในหมวดนั้นๆ จะแทนที่คำศัพท์ที่ใช้บ่อย ด้วย index ตัวอย่างข้อมูลที่เป็นหมวดเดียวกันคือ การบีบอัด XML Schema-based(XSBC) และ XML Infoset Encoding (XBIS)

13. 2.ที่มา (ต่อ) • อย่างที่สองมีข้อจำกัดที่ไม่ใช่ของมันเอง ดังเช่นสถาปัตยกรรม HHFR ที่จะกล่าวดังต่อไปนี้ หมวดหมู่สุดท้าย ที่นำข้อความมาบีบอัด ซึ่งการบีบอัดจะช่วยลดขนาดของเอกสารแต่เพิ่มเวลาของการทำงาน พอๆ กับ XML – Specific Compression เช่น XMill ซึ่งจะดีกว่าการบีบอัดแบบธรรมดา แบบพวก Gzip แต่มันก็ไม่ได้ทำให้ประสิทธิภาพดีมาก เพราะมันจะเพิ่มขั้นตอนของการประมวลผล ซึ่งหากมี Compression ก็ต้องมี Decompression ด้วยเช่นกัน

14. 2.ที่มา (ต่อ) • The Global Grid Forum’s Data Description Language (DFDL) มันจะกล่าวถึงข้อตกลงของภาษา หรือคำบรรยายเอกสารหรือรูปแบบข้อมูลแบบ Grid Computing สถาปัตยกรรม DFDL จะประกอบไปด้วยขั้นตอนพื้นฐาน 3 ส่วน คือ • ชั้นล่างสุด (Mapping) • ชั้นกลาง (Abstract data Model) • ชั้นล่าง (API)

15. 2.ที่มา (ต่อ) ซึ่งชั้น mapping มันจะทำการจับคู่ระหว่าง ตัวแทนข้อมูลกับหัวข้อมูล เช่น มันจะนิยามรูปแบบตัวเลขสำหรับข้อมูล ไม่ว่าจะขนาดใด หรือรูปแบบซับซ้อน เช่น Array แต่ model ชั้นนี้ ก็จะนิยามโครงสร้างข้อมูลขึ้นเอง สิ่งที่นิยามคล้ายกัน คือ จะมุ่งเน้นไปที่การนำเสนอ Massage ที่ดีกว่า และมีประสิทธิภาพที่ดีกว่าขึ้น และสถาปัตยกรรม HHFR มีขอบเขตของงานทั้งหมดนั้น จะใช้เว็บบริการด้านฐานข้อมูล เพื่อลดขนาดของ Massage และเพื่อสนับสนุนการแลกเปลี่ยนข้อความ แบบ Streaming อีกด้วย

16. 3. การออกแบบสถาปัตยกรรม • สถาปัตยกรรมซอฟท์แวร์แบบใหม่ ที่มีชื่อว่าThe Handheld Flexible Representation หรือ HHFR นั้น ถูกออกแบบมาสำหรับช่วยให้การสื่อสารข้อมูล หรือการแลกเปลี่ยน message ได้มากขึ้น เร็วขึ้น และดีขึ้นกว่าเดิม บน mobile web services • HHFR จะทำการแยกmessage content ออกจาก SOAP message ที่อยู่ในเครื่องหมาย Angle-Bracket ( [ - ] ) และจะทำงานอยู่ในend point หรือ ฝั่งผู้ส่งและฝั่งผู้รับของการสื่อสาร (ทั้งสองฝ่าย)

17. 3. การออกแบบสถาปัตยกรรม(ต่อ) • 3.1 พูดถึงการออกแบบ ส่วนสำคัญที่ถูกออกแบบมาในสถาปัตยกรรมนี้ เช่น การทำให้ขนาดของตัวแทนของข้อมูล (end point) มีขนาดเล็กลง เพราะข้อเสียของ XML Syntax คือ มีความยาวมากเกินไป HHFR จะจัดหาวิธีการติดต่อสื่อสาร เพื่อแลกเปลี่ยน SOAP message กันของทั้งสองฝ่าย โดยจะแยก XML Syntax ของ SOAP message และ SOAP message contents ออกมา

18. 3. การออกแบบสถาปัตยกรรม(ต่อ) • 3.1 พูดถึงการออกแบบ ส่วนประกอบของSOAP โดยทั่วไป ทำให้เกิดปัญหาคอขวด(bottlenect) หรือทำให้เกิดการติดขัดของข้อมูลมากขึ้น เพราะข้อมูลมีปริมาณมากบนระบบเครือข่ายไร้สาย โครงสร้างข้อมูลและประเภทของSOAP body ที่ถูกแยกออกมา จะเริ่มทำการสื่อสารกันในช่วงเริ่มต้นของการ stream

19. 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

20. 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 ลง

21. 3. การออกแบบสถาปัตยกรรม(ต่อ) • 3.1 พูดถึงการออกแบบ • - ทำงานร่วมกับสถาปัตยกรรม Web service ต่างจากวิธีการแก้ปัญหาอื่นๆ เพราะสถาปัตยกรรมนี้ โดยรวมแล้ว ไม่ได้ เปลี่ยนแปลงในเรื่องของการทำงานร่วมกัน ตาม มาตรฐาน ของ web service

22. 3. การออกแบบสถาปัตยกรรม(ต่อ) • 3.2 การแยกตัวแทนข้อมูล แนวคิดสำคัญของสถาปัตยกรรม HHFR อย่างหนึ่ง คือการมีตัวแทนข้อมูลที่เหมาะสม และขณะที่กำลังทำการติดต่อสื่อสารกันของทั้ง 2 ฝ่าย จะไม่ทำให้ความสามารถในการทำงานร่วมกันได้เสียไป เพราะเราออกแบบ HHFR ให้มันทำการจัดหาตัวแทนข้อมูลที่มีความเหมาะสมกับสภาพแวดล้อมของการสื่อสารXML และ SOAP Infoset

23. 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

24. 3. การออกแบบสถาปัตยกรรม(ต่อ) • 3.2 การแยกตัวแทนข้อมูล ในสถาปัตยกรรมของเรา เราได้กำหนดให้รูปแบบข้อมูลเป็น SOAP Infoset ดังนั้น สถาปัตยกรรม HHFR สามารถแยกตัวแทน -XML/SOAP syntax และ SOAPmessage content โดนไม่ต้องเสีย message contents ใดๆ

25. 3. การออกแบบสถาปัตยกรรม(ต่อ) • Binary Representation of SOAP Binary representation เป็นตัวเลือกที่สำคัญตัวหนึ่ง ในการปรับปรุง ประสิทธิภาพโดยรวมของสถาปัตยกรรม HHFR ซึ่งมีหลายอย่าง อย่างแรก คือมันจะช่วยลดขนาดของการแลกเปลี่ยน message โดยการดึงส่วนของ SOAP syntax (พวกวงเล็บ [ ] )ที่มีมากเกินไปออกไป ทำให้สามารถลดขนาดลงไปได้สูงสุดถึง10เท่า เมื่อโครงสร้างเอกสารนั้นมีความซ้ำซ้อนมาก โดยอย่างง่ายที่สุดก็คือ พวก single textสามารถลดขนาดตัวมันเองได้ครึ่งหนึ่ง ดังนั้น จึงเป็นการดีที่เราสามารถลดขนาดของเอกสาร เพื่อการแลกเปลี่ยนกันได้

26. 3. การออกแบบสถาปัตยกรรม(ต่อ) • Binary Representation of SOAP อย่างไรก็ตาม มันก็มีความจำเป็นอย่างมากอยู่ดี เพราะในระแบบ mobile computing ยังมีการจำกัดของ bandwidth อยู่ สุดท้ายนี้ ประโยชน์ข้ออื่นๆของ Binary representation ของ SOAP message ในสถาปัตยกรรม HHFR คือ สามารถแยกแต่ละ message ออกมาได้

27. 3. การออกแบบสถาปัตยกรรม(ต่อ) • Message handling soap message มีองค์ประกอบภายนอกมากที่สุด soap envelope ในเอกสาร XML ประกอบด้วย header และ body ซึ่งบรรจุโปรแกรม หรือข้อมูลอยู่ เช่น คำแนะนำในการแยก , ข้อมูลความปลอดภัย , และการกำหนดเส้นทาง/ข้อมูลความน่าเชื่อถือ การจัดการสถาปัตยกรรม

28. 3. การออกแบบสถาปัตยกรรม(ต่อ) • Context store หนึ่งในองค์ประกอบที่สำคัญของสถาปัตยกรรม HHFR คือ context store โดยcontext store ทำให้สามารถค้นหา context information จากการสื่อสารของ SOAP message ได้

29. 4. การดำเนินการ • การทดลองเพื่อแสดงให้เห็นถึงประสิทธิภาพของสถาปัตยกรรม HHFR และเราได้ดำเนินการตามแบบแผนของ Mobile Web Service โดยมีโครงสร้างพื้นฐานตั้งอยู่บนสถาปัตยกรรม ซึ่งสถาปัตยกรรม HHFR ประกอบไปด้วย HHFR Schema และ Processor ที่มีช่องทางการติดต่อสื่อสารที่รวดเร็วประกอบกับมีการทำงานที่ยืดหยุ่นมาเป็นตัวดำเนินการแทน แล้วยังมีการจัดเก็บข้อมูลไว้ที่ Context-store

30. 4. การดำเนินการ (ต่อ) • ขั้นตอนโดยพื้นฐานสามารถทำได้ดังนี้ 1.) ปลายทางของ HHFR-capable จะส่งการเจรจาต่อรองที่เป็นคำร้องขอ ไปยังปลายทางที่ได้เตรียมไว้ ซึ่งการร้องขอนี้เป็นแบบ SOAP message ประกอบกับลักษณะเฉพาะ แล้วส่งไปยังช่วงต่อไป 2.)ในการเจรจาต่อรอง message ของ ปลายทาง service client ที่เป็นผู้เริ่มส่งข้อมูลเพื่อไปอ้างถึงการเขียน HHFR Schema ซึ่งจะมีการอธิบายเพิ่มเติมในหัวข้อที่ 4.2 และระบบบริการลูกค้าปลายทาง จะเป็นผู้โต้ตอบโดยการส่งข้อมูลที่เป็นผลลัพธ์ออกไป

31. 4. การดำเนินการ (ต่อ) • ขั้นตอนโดยพื้นฐานสามารถทำได้ดังนี้ 3.) ทั้งสองปลายทางจะมีช่องทางอื่นในการขนย้าย สำหรับการแลกเปลี่ยน message โดยจะมีการส่งต่อข้อความอย่างต่อเนื่อง ซึ่ง message จะส่งต่อข้อมูลอยู่ในระบบโดยมีการเจรจาเป็นตัวดำเนินงาน 4.) ส่วนของ message ที่ซ้ำหรือไม่มีการเปลี่ยนแปลงจะทำให้การเก็บข้อมูลกลายเป็นแบบ dynamic นั่นหมายถึง เมื่อไม่มีข้อมูลใหม่เข้ามา ก็จะส่งผลให้ เกิดช่องว่างระหว่าง Context-store ทำให้ข้อมูลมีการหมุนเวียนได้คล่องตัวมากขึ้น

32. 4. การดำเนินการ (ต่อ) • โดยจะมุ่งเน้นไปที่การตรวจสอบหาค่าที่เหมาะสมของการแลกเปลี่ยน message โดยพยายามจัดการกับปัญหาที่มีอยู่ และไปดำเนินการพร้อมทั้งแทรกหัวข้อที่เราสนใจนอกเหนือจากเรื่องที่เราศึกษา และ SOAP ที่เป็นตัวชี้แจง สำหรับการเคลื่อนที่ในสภาวะแวดล้อมต่างๆ และแหล่งเก็บข้อมูลของ metadata ซึ่งภาพรวมสามารถดูได้จากภาพที่ 3

33. 4. การดำเนินการ (ต่อ) รูปภาพที่ 3 ภาพรวมของการดำเนินการขั้นพื้นฐาน

34. 4. การดำเนินการ (ต่อ) 4.1 รูปแบบการเจรจาต่อรอง (Negotiation scheme) โดยปกติของ HHFR session จะมีระยะเวลาเริ่มต้นในการเจรจาต่อรอง เพื่อแลกเปลี่ยนการต่อรองระหว่างสองปลายทางด้วย SOAP message โดยการออกแบบระยะเวลาในการเจรจาต่อรองเป็นสิ่งที่สำคัญมาก เพื่อนำไปสู่การสร้างลักษณะเฉพาะดังต่อไปนี้

35. 4. การดำเนินการ (ต่อ) 4.1 รูปแบบการเจรจาต่อรอง (Negotiation scheme) • ในระยะเวลาระหว่างการโต้ตอบกับระบบ Service ปลายทาง จะมีลักษณะเฉพาะ นั่นก็คือแนะนำวิธีในการริเริ่มการเจรจาต่อรองและการได้รับการยืนยันจากระบบ Service ปลายทาง ซึ่งในส่วนของ Prototype จะมีการดำเนินการโดยขั้นตอนการเริ่มต้นอย่างง่ายๆ • เมื่อเริ่มมีการส่งคำร้อง SOAP ไปยังระบบ intended ปลายทางแล้วการเจรจาต่อรองจะสิ้นสุดลงเมื่อมีการได้รับการโต้ตอบจาก Service

36. 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 ของการเจรจาต่อรองนี้ได้

37. 4. การดำเนินการ (ต่อ) 4.2HHFR: อธิบายภาษาของข้อมูล • ข้อมูลที่ไม่ใช่ XML- แยก ข้อความและข้อมูล XML - ข้อความ SOAP หรือการดำเนินการที่ต้องการใดๆ เรากำหนด DFDL-style เป็นภาษาในการบรรยายข้อมูล HHFR Schema ซึ่งมันเป็นเซตย่อยของ XSDกับสิ่งเพิ่มเติมเข้าไปบางอย่าง ,สถาปัตยกรรมของ HHFR schema คล้ายกับ DFDL: HHFR Schema อธิบายรูปแบบข้อมูล,Schema Processor (DSParser) สร้างแบบจำลองข้อมูล HHFR และStreamer แปลงเนื้อหาข้อมูลและนำเสนอรูปแบบข้อมูลที่ต้องการ

38. 4. การดำเนินการ (ต่อ) 4.2HHFR: อธิบายภาษาของข้อมูล • HHFR Schema กำหนดเซตย่อยขององค์ประกอบ XSD: การกำหนดประเภทแบบง่าย , ประเภทองค์ประกอบความหมายที่ซับซ้อน, ประกาศ element , และประกาศ แอตทริบิวต์HHFR schema กำหนดจำนวน จำกัด รูปแบบง่ายๆในตัว.XML schema พวก string, int, byte, float, Boolean. ปัจจุบันของ HHFR Schema ไม่สนับสนุน User-Defined symple Type องค์ประกอบของ HHFR Schema สามารถมีเนื้อหาที่หลากหลาย แต่ไม่สามารถมีเนื้อหาที่มีองค์ประกอบเดียวหรือเนื้อหาที่ว่างเปล่า ดังนั้นเราจึงประกาศcomplexType element โดยไม่ต้องรวมแอตทริบิวต์ ดังตัวอย่างต่อไปนี้:

39. 4. การดำเนินการ (ต่อ) 4.2HHFR: อธิบายภาษาของข้อมูล

40. 4. การดำเนินการ (ต่อ) 4.2HHFR: อธิบายภาษาของข้อมูล • การประมวลผล HHFR Schema เกี่ยวข้องกับหลายโมดูล แสดงในรูปที่ 4HHFR Schema processor, DSParser, ได้รับ HHFR Schema, ซึ่งมีอยู่ในการเจรจาต่อรองร้องขอและข้อความตอบกลับของSOAP ดูในรูปที่ 4 ขั้นตอน ที่1 เป็น input และสร้างข้อมูลภายในแบบจำลอง HHFR ขณะที่ output ดูในขั้นตอน 2 ที่ภาพ ความสัมพันธ์ระหว่างHHFR Schema และ HHFR data model มีความคล้ายคลึงกับความสัมพันธ์ระหว่างเอกสาร XML และ Java DOM Object

41. 4. การดำเนินการ (ต่อ) 4.2HHFR: อธิบายภาษาของข้อมูล • หลังจาก2ขั้นตอน , HHFR ตอนเริ่มรันเป็นตัวเลือกของการส่งต่อที่รวดเร็วซึ่งจะกล่าวถึงในต่อไปนี้ องค์ประกอบและการประมวลผลข้อมูลผ่าน StreamerStreamer เป็น interpret-style stub object ซึ่งเป็นสไตล์การออกแบบที่นิยมมาก เมื่อเทียบกับ compiled-style stub มีประสิทธิภาพมากกว่า ซึ่งเป็นที่นิยมจำนวนมากในclient และการใช้งาน RPC server interpret-style stub มีความยืดหยุ่น และเป็นการดำเนินงาน เพื่อนำเข้าข้อมูล แบบDynamic

42. 4. การดำเนินการ (ต่อ) 4.2HHFR: อธิบายภาษาของข้อมูล จากการป้อนข้อมูล stub(ส่วนที่ยังเหลืออยู่)ไม่จำเป็นต้องถูก re-compliedเพื่อเป็นการดำเนินการแทนข้อมูลที่ต่างกัน , อ่านและเขียน แพ็กเก็ตข้อความ stub(ส่วนที่ยังเหลืออยู่)ผ่าน switch statement; packetข้อความเป็นตัวแทนหน่วยหนึ่งของข้อความที่ต้องการ , ในPrototype แทน binary เป็นลำดับของไบต์ เป็นรูปแบบการแสดงเริ่มต้นสำหรับแพ็คเก็ตข้อความ

43. 4. การดำเนินการ (ต่อ) รูปที่ 4. HHFR schema processing and interactions between related modules.

44. 4. การดำเนินการ (ต่อ) 4.3 Data Streaming • Data Streaming เป็นคุณลักษณะต้นแบบที่สำคัญของ HHFR Prototype และมันช่วยให้ระบบมือถือแลกเปลี่ยนข้อความบนเครือข่ายไร้สายได้อย่างมีประสิทธิภาพ ด้วยวิธี Streaming การแลกเปลี่ยนข้อความแบบเครือข่ายไร้สายอาจมีปัญหา อย่างเช่น ใช้เวลาค่อนข้างสูงและการเชื่อมต่อช้า ปัญหาดังกล่าวจึงควรหาแนวทางเพื่อให้มันยืดหยุ่น ลดระยะเวลาส่งข้อความและลดการใช้ bandwidth

45. 4. การดำเนินการ (ต่อ) 4.3 Data Streaming • ช่องทางการสื่อสารที่รวดเร็วของ HHFR Prototype จัดหาให้แบบไม่ประสานเวลาและเป็นทางเลือกที่เหมาะสม ใช้ HTTPอัตโนมัติ ในการสื่อสาร ตามที่ได้อธิบาย, การเจรจาต่อรอง การตอบสนองจากการให้บริการจะต้องมีจุดสิ้นสุด (IP และหมายเลขพอร์ต) การสื่อสารจะเริ่มโดย service client

46. 4. การดำเนินการ (ต่อ) 4.3 Data Streaming • ช่องการสื่อสารที่รวดเร็วสำหรับชั้น TCP จะแสดงในรูปที่ 5 ด้านผู้ให้บริการ , StreamConnectionFactory รอการเชื่อมต่อเข้า จาก serversocket และสร้าง StreamConnection ควบคุมช่วงที่เกี่ยวข้องกับ Streaming ทั้งหมด เช่น StreamReader ,StreamWriter และ Streamer ข้อมูลที่โปรแกรมพยายามจะส่งเข้าตามลำดับก่อนหลังใน StreamWriter รวมไปถึงเส้นทาง HHFRHandler และ StreamConnection ข้อมูลที่ได้รับดังต่อไปนี้ ถ้าเส้นทางตรงข้ามกันจะถูกส่งไปที่ วิธีการ onMessage

47. 4. การดำเนินการ (ต่อ) 4.3 Data Streaming รูปที่ 5. Fast communication channel layer.

48. 4. การดำเนินการ (ต่อ) 4.4 Context-store • ส่วนของข้อความที่ซ้ำซ้อนอาจจะถือว่าเป็นMetadata และ เก็บไว้ในที่เก็บข้อมูล เราปรับข้อมูลบริการ (ระบบMetadata catalpg) สำหรับการจัดเก็บ Metadata ที่จำเป็นชั่วคราว • ระบบสารสนเทศ, จากความเห็นที่บอกว่ามีข้อผิดพลาด ในข้อมูลบริการ (FTHPIS) ซึ่งใช้และเสนอให้ the WS-Context Specification พัฒนาโดยชุมชนห้องปฏิบัติการ Grids ของมหาวิทยาลัยอินเดียนาและจะถูกนำมาใช้เป็นที่พักเพื่อเก็บเก็บ metadata ชั่วคราว นั่นคือจะเก็บส่วนที่ซ้ำซ้อน จากข้อความ SOAP ซึ่งมีการแลกเปลี่ยนระหว่างสอง endpoints

49. 4. การดำเนินการ (ต่อ) 4.4 Context-store • วิธีนี้จะลดขนาดของข้อความ SOAP ซึ่งถือว่าเป็นส่วนของ XML ซึ่งมีการเข้ารหัสทุกๆข้อความ ในSOAP ในระหว่างการแลกเปลี่ยนระหว่างสองบริการ องค์ประกอบ XML เหล่านี้ เก็บไว้เป็นบริบทในการบริการข้อมูล แต่ละบริบทอ้างอิงโดยระบบที่กำหนด URI เอกลักษณ์ของURI คือมั่นใจบริการข้อมูลที่สอดคล้องกัน URI แทนที่องค์ประกอบที่ซ้ำซ้อนของ XML ในข้อความ SOAP ดังนั้นขนาดของข้อความจะลดลงได้เร็วขึ้น การถ่ายโอนข้อความ เมื่อได้รับข้อความ SOAP, ฝ่ายที่เกี่ยวข้องมีปฏิสัมพันธ์กับมาตรฐาน WS Context บริการข้อมูลเพื่อดึงบริบทที่เกี่ยวข้องกับ URIs ระบุไว้ในข้อความ SOAP

50. 4. การดำเนินการ (ต่อ) 4.4 Context-store รูป6 .Context-store operation overview