r52 - 23 May 2008 - 19:21:28 - PheungSeenuan^?You are here: SETEC Wiki >

Knowledge Web > WebTechnologyCategory > WebServicesTesting

-- AchawonWatcharakorn - 10 Apr 2006 - 15:14

Web Services Testing

Web Services Testing

เว็บเซอร์วิส (Web Service) ได้ถูกออกแบบขึ้นเพื่อปรับปรุงความสามารถในการทำงานร่วมกัน (interoperability) ระหว่างแอปพลิเคชัน ให้มีประสิทธิภาพยิ่งขึ้น นักพัฒนาแอปพลิเคชันในปัจจุบันสามารถใช้ internet messaging standard ในการสร้างแอปพลิเคชันที่มีความสามารถในการติดต่อกับแิอปพลิเคชันอื่น และสามารถส่งข้อมูลไปให้อีกแอปพลิเคชันหนึ่งทำงานบางอย่างให้ หรือเพื่อเรียกใช้บริการนั่นเอง โดยเราสามารถสร้าง Web service ด้วยเทคโนโลยีที่หลากหลาย บนแพลตฟอร์มที่มีความเหมาะสมกับโครงสร้างของเว็บเซอร์วิสนั้น ๆ ซึ่งช่วยลดภาระของนักพัฒนาในการสร้าง custom code ลงได้

ความสามารถในการทำงานร่วมกันของเว็บเซอร์วิส หมายความว่าแอปพลิเคชันจะต้องมีประสิทธิภาพที่คงเดิม ท่ามกลางตัวแปรที่แตกต่าง อาทิเช่น แอปพลิเคชันแพลตฟอร์ม ภาษาโปรแกรมมิ่ง ฮาร์ดแวร์ ระบบปฏิบัติการ และแอปพลิเคชันดาต้าโมเดล เป็นต้น ตัวอย่างเช่น แอปพลิเคชันที่เขียนด้วย Perl และทำงานอยู่บนเครื่อง Linux อาจจะเรียกใช้บริการแอปพลิเคชันที่เขียนด้วย Java ที่ทำงานอยู่บนเครื่อง Sun Solaris ก็ได้ อย่างไรก็ดี การทดสอบความสามารถในการทำงานร่วมกันของ Web service ไม่สามารถทำได้เหมือนการทดสอบการทำงานบนหน้าเว็บเพจหรือเบราเซอร์โดยทั่วไป เพราะการทดสอบเช่นนั้น เกี่ยวข้องกับ client จำนวนไม่มากนัก (เช่น Internet Explorer และ Netscape เป็นต้น) แต่การทดสอบความสามารถในการทำงานร่วมกันของเว็บเซอร์วิส นั้น เกี่ยวข้องกับ client จำนวนมาก ซึ่งส่วนหนึ่งสืบเนื่องมาจากความหลากหลายของภาษาโปรแกรมมิ่งที่ถูกใช้ในการพัฒนาเว็บเซอร์วิส การทดสอบกับ client ทั้งหมดเป็นความท้าทายอย่างหนึ่ง และเมื่อทดสอบได้แล้ว ยังต้องคำนึงอีกด้วยว่า ปัญหาที่ค้นพบที่เกี่ยวข้องกับความสามารถในการทำงานร่วมกันของเว็บเซอร์วิส นั้น เกิดจากความบกพร่องของเว็บเซอร์วิส เอง หรือเกิดจากซอฟต์แวร์ client อย่างไรก็ดี เป็นที่แน่ชัดแล้วว่า การทดสอบความสามารถในการทำงานร่วมกัน จัดได้ว่าเป็นส่วนสำคัญส่วนหนึ่งในการรับรองคุณภาพของ Web service และนักพัฒนาควรที่จะคำนึงถึงความสำคัญตรงจุดนี้ ตั้งแต่ระยะแรกของการพัฒนาเว็บเซอร์วิส ทุกวันนี้ยังไม่มีการสรุปเป็นที่แน่ชัดว่า ปัจจัยใดที่เป็นกลไกสำคัญที่สุดในการสร้างให้เว็บเซอร์วิส มีคุณสมบัติดังกล่าวได้อย่างสมบูรณ์ ดังนั้นจึงควรมีการทดสอบเพื่อให้ได้ข้อมูลที่จะช่วยในการตัดสินใจของนักพัฒนา ในการเลือกวิธีการออกแบบเว็บเซอร์วิสให้มีประสิทธิภาพสูงสุด

Web Service Architecture

โครงสร้างสถาปัตยกรรมเว็บเซอร์วิส (Web Service Architecture) มีองค์ประกอบหลัก 3 อย่าง ได้แก่

Service
Service Requestor
Service Container

จากโครงสร้างของเว็บเซอร์วิส จะพบว่าเว็บเซอร์วิสประกอบด้วย event ต่าง ๆ ดังนี้

Create Service - โดยบริการ (service) จะถูกสร้างขึ้นจากเครื่องมือและภาษาที่เหมาะสมสำหรับเว็บเซอร์วิส เช่น C++ VB Java Perl PHP Python เป็นต้น
Publish - หลังจากบริการถูกสร้างขึ้น จะถูก publish ไว้ใน UDDI registry โดย Service Container ซึ่งภายใน registry จะประกอบไปด้วยข้อมูลเกี่ยวกับ บริการ และผู้สร้างบริการนั้น ๆ โดยจะจำแนกตามประเภทของธุรกิจ ซึ่งช่วยให้ผู้ขอบริการ (Service Requestor) สามารถค้นหาบริการได้อย่างง่ายดาย ตัวอย่างเช่น โบรกเกอร์หุ้นสามารถ publish บริการการค้าหุ้น ไว้ในประเภทธุรกิจการเงิน โดยใช้ IBM UDDI registry และจะต้อง publish บริการในรูปของไฟล์ WSDL (Web Service Description Language) ซึ่งเก็บข้อมูลทั้งหมดเกี่ยวกับบริการและโบรกเกอร์ไว้
Search - ผู้ขอบริการ (Service Requestor) สามารถค้นหาบริการใน registry ผ่านทางอินเทอร์เฟสของผู้ให้บริการ (Service Provider)
Reference - หลังจากผู้ขอบริการค้นหาบริการที่ต้องการ จะได้ผลการค้นหาเป็นรายการของบริการ ซึ่งประกอบด้วย reference และ specification ของบริการต่าง ๆ ซึ่งผู้ขอบริการสามารถเลือกได้ว่าบริการใดที่ตรงกับความต้องการของตนเองมากที่สุด
Bind - ผู้ขอบริการสามารถใช้ reference ที่เลือกไว้ เพื่อโยงไปยังบริการที่ต้องการ
Invoke - บริการจะถูกเรียกใช้ผ่านทาง reference โดยใช้เทคโนโลยีมาตรฐานต่าง ๆ เช่น การเรียกบริการโดย SOAP ในรูปของเอกสาร XML ผ่านทาง HTTP protocol

Messaging Protocols

Internet messaging protocols เช่น SOAP และ XML-RPC เป็นองค์ประกอบสำคัญอย่างหนึ่งในการออกแบบเว็บเซอร์วิส ดังนั้นการทดสอบคุณสมบัติและประสิทธิภาพของ protocol แต่ละชนิด โดยการกำหนดปัจจัยที่จะก่อให้เกิดการเปรียบเทียบ อาทิเช่น การใช้ dataset ที่มีคุณลักษณะแตกต่างกัน เป็นต้น จะมีส่วนอย่างมากในการบ่งชี้รูปแบบการสร้างเว็บเซอร์วิสที่เหมาะสมต่อความต้องการของนักพัฒนา

SOAP

SOAP เป็น XML-based messaging protocol ที่ได้รับการรับรองมาตรฐานจาก W3C บริษัทผู้ผลิตแอปพลิเคชันชั้นนำของโลกต่างยอมรับ SOAP ว่าเป็น standard protocol สำหรับเรียก remote object การใช้สามารถทำได้สองวิธี คือแบบ remote procedure call (RPC) และแบบ document โดย W3C สนับสนุน SOAP ทั้งรูปแบบ RPC และรูปแบบ document

RPC-Style SOAP คือการมอง เว็บเซอร์วิสให้เป็นประหนึ่ง object โดยภายใน request จะมี method name ที่ใช้เรียก parameter และ method จะกระทำการบน server และส่ง XML response กลับไปให้ client ตัวอย่างต่อไปนี้ แสดง RPC-request สำหรับการบวกเลข

<?xml version=&#8221;1.0&#8221; encoding=&#8221; utf-8 ?>
<soap:Envelope xmlns:soap=&#8221; http://schemas.xmlsoap.org/soap/envelope/&#8221;
          soap:encodingStyle=&#8221; http://schemas.xmlsoap.org/soap/encoding/&#8221;>
   <soap:Body>
      <w:add xmlns:w=&#8221; http://www.wrox.com/services/math&#8221;>
         <w:op1>4.5</w:op1>
         <w:op2>5.4</w:op2>
      </w:add>
   </soap:Body>
</soap:Envelope>

และหาก request นี้กระทำการสำเร็จ จะได้ response ที่มีลักษณะดังต่อไปนี้

<?xml version=&#8221;1.0&#8221; encoding=&#8221; utf-8 ?>
<soap:Envelope xmlns:soap=&#8221; http://schemas.xmlsoap.org/soap/envelope/&#8221;
          soap:encodingStyle=&#8221; http://schemas.xmlsoap.org/soap/encoding/&#8221;>
   <soap:Body>
      <w:addResponse xmlns:w=&#8221; http://www.wrox.com/services/math&#8221;>
         <w:addResult>9.9</w:addResult>
      </w:addResponse>
   </soap:Body>
</soap:Envelope>

Document-Style SOAP ใช้ XML schemas เป็นตัวกำหนดรูปแบบของ request และ response โดย SOAP แบบนี้กำลังได้รับความนิยมอย่างมาก และมีการคาดการณ์ว่าในอนาคตอาจจะเป็นที่นิยมมากกว่า SOAP แบบ RPC ตัวอย่าง document-style request

<?xml version=&#8221;1.0&#8221; encoding=&#8221; utf-8 ?>
<soap:Envelope xmlns:soap=&#8221; http://schemas.xmlsoap.org/soap/envelope/&#8221;>
   <soap:Body>
      <w:add xmlns:w=&#8221; http://www.wrox.com/services/math&#8221; op1="4.5" op2="5.4" />
   </soap:Body>
</soap:Envelope>

จากตัวอย่างโค้ดข้างต้น จะเห็นได้ว่า soap:encodingStyle attribute ได้ถูกตัดออก เพราะ RPC request จำเป็นต้องมีรูปแบบตามชื่อ method ในขณะที่ SOAP แบบ document มีความยืดหยุ่นมากกว่า เพราะรูปแบบจะถูกปรับเปลี่ยนตาม XML schema (เว็บเซอร์วิสที่สร้างด้วย Visual NET จะเป็นแบบ document แต่สามารถเปลี่ยนรูปแบบได้โดยการดัดแปลงโค้ด) อ่านเพิ่มเติมเกี่ยวกับ document-style SOAP ได้ที่ Reap the Benefits of Document Style Web Services

โดยข้อดีของ SOAP คือ message จะส่งผ่านทาง HTTP request ซึ่งทำให้ message สามารถเจาะทะลุ firewall ได้ง่าย ซึ่งได้เปรียบ protocol อื่น ๆ ที่อาจจะถูกกรองโดย firewall SOAP message จะอยู่ภายใน envelope ซึ่งประกอบไปด้วย header และ body ดูตัวอย่างได้ใน SOAP Architecture

XML-RPC

นายเดฟ ไวเนอร์ จาก Userland Software ได้ขยายแนวทางแบบ RPC โดยการสร้าง XML-RPC ขึ้นมา ซึ่ง XML-RPC จะส่ง message ผ่านทาง HTTP โดย RPC request จะถูก encode ไว้ในเอกสาร XML และส่งไปยัง server ดูตัวอย่างได้ใน XML-RPC Architecture ซึ่งข้อแตกต่างที่เด่นชัดระหว่าง XML-RPC และ SOAP คือ XML-RPC ไม่ได้อนุญาตให้ user กำหนด data type เองได้ รวมทั้งไม่สามารถกำหนด named struct และ array ได้เช่นกัน ในขณะที่ SOAP อนุญาตให้มี user-defined data type ได้ อย่างไรก็ตาม XML-RPC ยังไม่ได้ถูกรับรองเป็นมาตรฐานโดยองค์กรใดเลย

XML-RPC Data Types ประกอบไปด้วย

Tag	Type	Example
string	ASCII string หรือ Unicode sequence of characters	hello world
int	32-bit signed integer	-12
boolean	true (1) หรือ false	(0)
double	double precision floating point number	-12.214
dateTime.iso8601	date/time (แต่ไม่มี time zone)	19990321T17:23:40
base64	base64 encoded string (raw binary data และไม่จำกัดความยาว)	eW911GNhbid0IHJ1YWgdBhpcyE=
array	one-dimensional array of values (value ใน array จะเป็น data type ใดก็ได้)
struct	key-value pairs (key เป็น string ขณะที่ value จะเป็น type ใดก็ได้)

ตัวอย่างเอกสาร XML ที่บรรจุ RPC request ไว้ มีลักษณะดังต่อไปนี้

<?xml version="1.0"?>
<methodCall>
   <methodName>Calculator.Add</methodName>
   <params>
      <param>
         <value><i4>30</i4></value>
      </param>
      <param>
         <value><i4>40</i4></value>
      </param>
   </params>
</methodCall>

โดยเอกสาร XML ข้างต้น ถูกสร้างขึ้นจากฝั่ง client เพื่อแสดง request และจะได้รับ response ที่มีลักษณะดังนี้

<?xml version="1.0"?>
<methodResponse>
   <params>
      <param>
         <value><i4>70i4></value>
      </param>
   </params>
</methodResponse>

REST

REST หรือ Representational State Transfer เป็นอีกทางเลือกหนึ่งที่นำเว็บเทคโนโลยีพื้นฐาน ได้แก่ URL HTTP (รวมทั้ง PUT, GET, POST และ DELETE operator) และ XML มาใช้ประโยชน์อย่างเต็มที่ โดยเฉพาะอย่างยิ่งการใช้ประโยชน์จาก URL หรือ URI ที่ถูกนำมาใช้แสดง method และ parameter โดย REST เป็นการใช้ HTTP protocol ในการรับส่งดาต้า และช่วยให้เราสามารถเรียก URL ในรูปแบบที่เฉพาะเจาะจงได้ REST ไม่สามารถจัดได้ว่าเป็นมาตรฐาน หากแต่เป็นรูปแบบ (Style) ที่นักพัฒนาสามารถยึดเป็นแนวทางในการพัฒนาได้

ตัวอย่างเช่น URI http://www.wrox.com/services/authors/ อาจจะรีเทอร์น XML ที่แสดงรายชื่อนักเขียน รวมทั้งวิธีการเข้าถึงรายละเอียดข้อมูลของนักเขียนแต่ละคน ดังนี้

<?xml version="1.0" encoding=" utf-8" ?>
<authors xmlns:xlink="http://www.w3.org/1999/xlink"
             xmlns="http://www/wrox.com/services/authors-books"
             xlink:href="http://www.wrox.com/services/authors/">
   <author forenames="Michael" surname="Kay"
      xlink:href="http://www.wrox.com/services/authors/kaym" id=" kaym"/>
   <author forenames="Joe" surname="Fawcett"
      xlink:href="http://www.wrox.com/services/authors/fawcettj" id=" fawcettj"/>
   <author forenames="Jeremy" surname="McPeak"
      xlink:href="http://www.wrox.com/services/authors/mcpeakj" id=" mcpeakj"/>
   <author forenames="Nicholas" surname="Zakas"
      xlink:href="http://www.wrox.com/services/authors/zakasn" id=" zakasn"/>
   <!--
      More authors
   -->
</authors>

จากตัวอย่างข้างต้น namespace "http://www/wrox.com/services/authors-books" ถูกนำมาใช้เป็น unique string นั่นหมายความว่า namespace นี้เป็น URI ไม่ใช่ URL โดย URI มีความแตกต่างจาก URL คือ URI หรือ Uniform Resource Identifier เป็นเพียง identifier จึงไม่สามารถรับรองได้ว่ามี resource อยู่จริงที่โลเกชั่นนั้น ในขณะที่ถ้าเป็น URL หรือ Uniform Resource Locator จะรับรองได้ว่า resource นั้นมีอยู่จริงที่โลเกชั่นอย่างแน่นอน

นอกจากนั้น จะสังเกตได้ว่ามีการใช้ href attribute จาก http://www.w3.org/1999/xlink namespace ซึ่ง XLink หรือ XML Linking Language เป็น XML markup language ที่ใช้ในการสร้าง hyperlink ภายในเอกสาร XML และช่วยสร้างลิงค์ระหว่างหลายทรัพยากรได้ โดยเป็นมาตรฐาน W3C อย่างไรก็ตาม XLink ยังไม่ถูกใช้กันอย่างแพร่หลายมากนัก โดยเมื่อวันที่ 28 มีนาคม พ.ศ.2549 W3C ได้นำเสนอ XLink เวอร์ชั่น 1.1 ซึ่งจะยังเป็น candidate recommendation อยู่จนถึงวันที่ 1 กรกฎาคม พ.ศ.2549

โดย user จะได้รับดาต้าของผู้เขียนแต่ละรายโดยเลือกการลิงค์ของผู้เขียนที่ต้องการ เอกสาร XML ที่จะได้รับอาจมีลักษณะดังนี้

<?xml version="1.0" encoding=" utf-8" ?>
<author xmlns:xlink="http://www.w3.org/1999/xlink"
             xmlns="http://www/wrox.com/services/authors-books"
             xlink:href="http://www.wrox.com/services/authors/fawcettj"
             id=" fawcettj" forenames=" Joe" surname=" Fawcett">
   <books>
      <book
        xlink:href="http://www.wrox.com/services/books/0764570773"
        isbn="0764570773" title=" Beginning XML"/>
      <book
        xlink:href="http://www.wrox.com/services/books/0471777781"
        isbn="0471777781" title=" Professional Ajax"/>
   </book>
</author>

โดย xlink:href จะช่วยขยายข้อมูลออกไปได้เรื่อย ๆ และหาก user เลือกลิงค์สำหรับ Professional Ajax อาจจะได้รับ response เป็นเอกสาร XML ในลักษณะดังตัวอย่างข้างล่าง

<?xml version="1.0" encoding=" utf-8" ?>
<book xmlns:xlink="http://www.w3.org/1999/xlink"
             xmlns="http://www/wrox.com/services/authors-books"
             xlink:href="http://www.wrox.com/services/books/0471777781"
             isbn="0764570773">
   <genre>Web Programming</genre>
   <title>Professional AJAX</title>
   <description>How to take advantage of asynchronous JavaScript and
   XML to give your web pages a rich UI.</description>
   <authors>
      <author forenames=" Nicholas" surname=" Zakas"
        xlink:href="http://www.wrox.com/services/authors/zakasn" id=" zakasn" />
      <author forenames=" Jeremy" surname=" McPeak"
        xlink:href="http://www.wrox.com/services/authors/mcpeakj" id=" mcpeakj" />
        author forenames=" Joe" surname=" Fawcett"
        xlink:href="http://www.wrox.com/services/authors/fawcettj" id=" fawcettj" />
   </authors>
</book>

Amazon Web Service เป็นตัวอย่างที่ชัดเจนในการนำ REST มาพัฒนา ซึ่งถึงแม้ว่า Amazon Web Service จะได้นำทั้ง SOAP และ REST มาใช้ แต่ได้มีการสังเกตว่านักพัฒนาส่วนใหญ่นิยมที่จะใช้ REST interface มากกว่า SOAP ตัวอย่างการใช้ REST ใน Amazon Web Service ดูได้จาก URI: http://xml.amazon.com/onca/xml3?t=aaa&dev-t=bbb&AsinSearch=0782143423&type=heavy&f=xml ซึ่งจะโหลดข้อมูลเกี่ยวกับหนังสือที่มี ASIN (Amazon Standard Identification Number) ตรงกับใน URI โดยการตั้ง URI มักจะเริ่มต้นด้วย URI scheme ตามด้วย domain name และ path และอาจตามด้วยคิวรี ซึ่งจะอยู่ข้างหลัง (?) จากตัวอย่าง URI ของ Amazon Web Service จะพบคิวรีที่ขึ้นต้นด้วย referral token และ developer token ใน parameter สองอันแรก ถัดมาจะเป็น ASIN และตามด้วยปริมาณ data และ format โดย user จะได้รับ response เป็นเอกสาร XML ที่บรรยายข้อมูลเกี่ยวกับหนังสือเล่มนั้นจากเว็บไซด์ Amazon เช่น ราคา และเรตติ้ง เป็นต้น อ่านรายละเอียดเพิ่มเติมเกี่ยวกับ URI ได้ที่ http://www.w3.org/Addressing/

-- TisanaiKrisanathamakul - 10 Apr 2006 - 15:14

Web Services Interoperability

เนื่องเพราะเว็บเซอร์วิส คือเทคโนโลยีที่เป็นอิสระจาก platform หรือภาษาที่ใช้ในการพัฒนา ดังนั้นสาระสำคัญประการหนึ่งของการทำงานในส่วนของ web services ก็คือพยายามให้เกิดการทำงานร่วมกัน (Interoperability) ระหว่าง services ที่ถูกพัฒนาจากหน่วยงานต่างๆ ให้ได้มากที่สุด ซึ่งหน่วยงานที่เกิดจากการประสานงานของหลายฝ่ายอันที่จะพยายามสร้างมาตรฐานของ Interoperability ระหว่างเว็บเซอร์วิสก็คือ Web Services Interoperability Organization (WS-I)

สิ่งที่ WS-I นำเสนอก็คือมาตรฐานแห่งการเชื่อมต่อระหว่างผู้ให้บริการ ซึ่งกลุ่มทำงานภายใน WS-I ได้ออกมาตรฐานที่เกี่ยวข้องในรูปแบบของ Profile ซึ่งเป็นการให้ข้อแนะแนวเกี่ยวกับการใช้ข้อกำหนดทางเทคนิคอันที่จะทำให้เกิด Interoperability ได้เหมาะสมที่สุด ในสถานะปัจจุบันสิ่งที่ profile ที่ WS-I ได้กำหนดออกมาประกอบด้วย Basic Profile Attachments Profile Simple SOAP binding profile และกำลังอยู่ในระหว่างการจัดทำ Basic Security Profile

โดยเบื้องต้นแนวทางในการทำการทดสอบเว็บเซอร์วิส ของกลุ่มงาน Web Technology GITI จะยึดรูปแบบตาม Profile ที่ WS-I กำหนดเอาไว้ ซึ่งคงจะเป็นเรื่องที่น่าสนใจที่จะศึกษาในรายละเอียดของแต่ละ Profile ดังกล่าว

นอกจากนั้น WS-I ยังเสนอตัวอย่างโปรแกรมประยุกต์ที่ใช้แนวทางการเชื่อมต่อตาม Profile ที่วางเอาไว้ โดยมีเครื่องมือในการทดสอบให้เห็นว่าการเชื่อมต่อดังกล่าวนั้นเป็นไปตามข้อกำหนดหรือไม่ ดูรายละเอียดได้จาก Sample Application และ Testing Tools

-- AchawonWatcharakorn - 26 Apr 2006 - 15:14

WS-I

Microsoft/IBM/Accenture/BEA Systems/Fujitsu/Hewlett-Packard/Intel/Oracle/SAP ได้ประกาศการก่อตั้ง Web Services Interoperabilty Organization (WS-I) เมื่อวันที่ 5 กุมพาพันธ์ พ.ศ. 2545 โดยอธิบายไว้ว่า WS-I เป็นองค์กรที่มุ่งที่จะสนับสนุน Web services interoperability ระหว่างแพลตฟอร์ม OS และภาษาโปรแกรมมิ่งต่าง ๆ ภารกิจของ WS-I คือ

การจัดหาแนวทาง implementation เพื่อรองรับลูกค้าที่สร้างเว็บเซอร์วิส
สนับสนุน interoperability ให้มีความแน่นอนและไว้วางใจได้
ประกาศวิสัยทัศน์ที่ชัดเจนของเว็บเซอร์วิส

ขั้นตอนแรกของการปฏิบัติงานของ WS-I คือการจัดตั้งกลุ่มของ profiles ที่จะกำหนดเกณฑ์มาตรฐานที่สามารถนำมาประยุกต์ใช้กับเว็บเซอร์วิส เพื่อทำให้เว็บเซอร์วิสมี interoperability โดยมีกลุ่มปฏิบัติงานที่ได้รับมอบหมายให้สร้างธรรมเนียมปฏิบัติ รวมไปถึงแนวทางการปฏิบัติที่มีประสิทธิภาพมากที่สุด เพื่อใส่ไว้ใน Basic Profile นอกจากนี้ยังได้มีการจัดทำเครื่องมือการวิเคราะห์ไฟล์ WSDL และ SOAP message อีกด้วย

WS-I Basic Profile

WS-I ได้ออกแบบ WS-I Basic Profile เพื่อปรับปรุง interoperability ระหว่างเว็บเซอร์วิส โดย Basic Profile เวอร์ชัน 1.0 ได้จัดการกับปัญหาบางประการที่เกี่ยวข้องกับ interoperability ของเว็บเซอร์วิส ได้แก่

XML message encoding
SOAP fault syntax
SOAP message structure and processing requirements
Supported versions of HTTP and SOAP
HTTP header requirements and status codes
Updated WSDL schema and type constraints
WSDL import statements
Restrictions on WSDL port types and bindings
Use of XML schema
Description and discovery restrictions

ในการสร้างเว็บเซอร์วิสให้สอดคล้องกับ Basic Profile เว็บเซอร์วิสดังกล่าวสามารถใส่คำประกาศไว้ส่วนประกอบของเว็บเซอร์วิส 3 แห่งดังนี้

Message เช่น SOAP
Description เช่น WSDL
Registry เช่น UDDI

ตัวอย่างเช่น หากต้องการให้ message มีความสอดคล้องกับ Basic Profile จะต้องใส่คำประกาศ หรือ claim element ไว้ใน message header ดังตัวอย่างข้างล่าง

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" >
   <soap:Header>
    :
      <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0"
        xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
   </soap:Header>
   <soap:Body>
   :
   </soap:Body>
</soap:Envelope>

สังเกตได้ว่าแอททิบิว conformsTo ได้ประกาศเวอร์ชันของ Basic Profile ที่เว็บเซอร์วิสนี้ยึดปฏิบัติตาม ซึ่งในที่นี้คือ Basic Profile 1.0 โดยใน Basic Profile เวอร์ชันนี้ ได้อ้างอิงถึงมาตรฐานต่าง ๆ ดังนี้

WS-I Basic Profile 1.0 base specification

Specification	URL
Simple Object Access Protocol (SOAP) 1.1	http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
Extensible Markup Language (XML) 1.0 Second Edition	http://www.w3.org/TR/REC-xml
RFC2616 : Hypertext Transfer Protocol-HTTP/1.1	http://www.ietf.org/rfc/rfc2616
RFC2965 :HTTP State Management Mechanism	http://www.ietf.org/rfc/rfc2965
WSDL 1.1	http://www.w3.org/TR/wsdl.html
XML Schema Part 1: Structures	http://www.w3.org/TR/xmlschema-1
XML Schema Part 2: Structures	http://www.w3.org/TR/xmlschema-2
UDDI Version 2.04 API Specification	http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm
UDDI Version 2.03 Data Structure Reference	http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm
UDDI Version 2 XML Schema	http://uddi.org/schema/uddi_v2.xsd
RFC2818: HTTP Over TLS	http://www.ietf.org/rfc/rfc2818
RFC2246: The TLS Protocol version 1.0	http://www.ietf.org/rfc/rfc2246
SSL Protocol Version 3.0	http://wp.netscape.com/eng/ssl3/draft302.txt
RFC2459: Internet X 509 Public Key infrastructure Certificate and CRL Profile	http://www.ietf.org/rfc/rfc2459

โปรดสังเกตว่า WS-I ใช้

MUST แสดงถึงสิ่งที่ต้องมีหรือต้องทำ
SHOULD แสดงถึงสิ่งที่แนะนำว่าควรมีหรือควรทำ หากเลือกที่จะไม่ทำตาม ควรจะแน่ใจในผลที่จะตามมา
MAY แสดงถึงสิ่งที่ให้เลือกว่าจะทำหรือไม่ทำก็ได้ นั่นหมายถึงว่าสิ่งนั้นจะไม่ส่งผลต่อ interoperability

WS-I Deliverables

WS-I ไม่ได้สร้าง specification ขึ้นมาเอง หากแต่ได้รวบรวม specification มาจากองค์กรหลายองค์กร โดย WS-I เองได้ให้คำแนะนำ แนวทางปฏิบัติ ตัวอย่างแอปพลิเคชัน use case แผนการใช้งาน ข้อจำกัด รวมทั้งเครื่องมือการทดสอบต่าง ๆ (Testing Tools) ซึ่งเครื่องมือการทดสอบเหล่านี้ ได้ถูกออกแบบมาเพื่อช่วยให้นักพัฒนาสามารถทดสอบได้ว่าเว็บเซอร์วิสที่สร้างขึ้น มีความสอดคล้องกับแนวทางปฏิบัติใน WS-I profile หรือไม่ โดย WS-I ได้แนะนำไว้ด้วยว่านักพัฒนาควรที่จะทดสอบเว็บเซอร์วิสของตนด้วยเครื่องมือทดสอบ ก่อนที่จะประกาศว่าเว็บเซอร์วิสของตนยึดแนวทางตาม WS-I

WS-I Testing Tools

WS-I Testing Tools มีส่วนประกอบสองส่วน ได้แก่ Monitor และ Analyzer โดย Monitor ทำหน้าที่เป็นตัวดักจับ (interceptor) SOAP message ที่ถูกส่งไปมาระหว่าง requestor และ service โดยใช้วิธี man-in-the-middle และยังทำหน้าที่เป็น logger แปลง message ที่ดักจับมา ให้อยู่ในฟอร์แมตมาตรฐาน และเก็บไว้ใน message log สำหรับใช้ในการวิเคราะห์ โดย monitor configuration file จะทำหน้าที่ควบคุมการทำงานของ Monitor และกำหนด parameter ในการที่ monitor จะทำงานได้นั้น requestor จะต้องติดต่อกับ monitor ประหนึ่งว่า monitor เป็นเว็บเซอร์วิสอันหนึ่ง และ SOAP message จะถูกส่งไปยัง monitor แทนที่จะส่งไปที่เว็บเซอร์วิสทั่วไป

Analyzer เป็นเครื่องมือสำหรับการวิเคราะห์ที่ทำหน้าที่ตรวจสอบว่าส่วนประกอบของเว็บเซอร์วิส ซึ่งได้แก่ message description และ registry เป็นไปตามข้อกำหนดใน Basic Profile หรือไม่ โดย Analyzer จะทำหน้าที่วิเคราะห์ message ระหว่างเว็บเซอร์วิส โดยวิเคราะห์จาก message log ที่ถูกเก็บไว้โดย Monitor และยังมีหน้าที่ในการ validate description และ registration ของเว็บเซอร์วิสด้วย Analyzer จะสร้างรายงานที่ระบุว่าเว็บเซอร์วิสนั้น ๆ เป็นไปตามแนวทางที่กำหนดโดย WS-I Basic Profile 1.0 หรือไม่ รวมทั้งแสดงรายละเอียดเกี่ยวกับข้อบกพร่อง เพื่อให้ทราบว่า requirement อันไหนที่ถูกละเลย

SOAP Builders Group

เป็น Yahoo! group ที่ถูกจัดตั้งขึ้นเพื่อทำการทดสอบ interoperability ในเว็บเซอร์วิสที่เป็น rpc ก่อตั้งโดยนายโทนี่ ฮอง ซึ่งเป็นผู้ก่อตั้งเว็บไซด์ XMethods (http://www.xmethods.net) ได้ริเริ่มกลุ่ม SOAP Builders Group ขึ้นในปี พ.ศ. 2544 ซึ่งผู้ที่สนใจจะเข้าร่วมกลุ่ม SOAP Builders นี้สามารถไปยังเว็บไซด์ http://groups.yahoo.com/group/soapbuilders/

ตัวอย่างงานค้นคว้าที่น่าสนใจเกี่ยวกับ Web Services Testing ได้แก่

Latency Performance of SOAP Implementations

References

Apshankar, K. (2003). Professional Open Source Web Services. Apress.
Fawcett, J., McPeak, J. & Zakas, N.C. (2006). Professional Ajax. Wrox Press.
Jennings, R. (2002). Visual Basic .NET XML Web Services Developer's Guide. Osborne:McGraw-Hill.
Swithinbank, P. (2005). !WebSphere and .Net Interoperability Using Web Services. IBM Redbook.
URL http://www.xmlrpc.com/

MSTI.WebServicesTesting moved from MSTI.WebServiceTesting on 21 Apr 2006 - 19:21 by TWikiAdmin

Knowledge

Reset Password

External Webs
Knowledge
Products
Pub
Internal Webs
Management
Projects
CMMI
Kampong School

Reset Password