Grid Services (in Thai)

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

สารบัญ บทที่ 1 สถาปตยกรรมบนฐานของบริการ (Service Oriented Architecture)……………………………………2 1.1 อะไรคือ SOA…………………………………………………………………………………………2 1.2 องคประกอบพื้นฐานของ SOA………………………………………………………………….....…2 1.3 Web services คือเทคโนโลยีที่เกิดจากแนวคิด SOA…………………………………………...…..…3 บทที่ 2 สถาปตยกรรมแบบเปดของ Grid service….……………………………………………………………..6 2.1 Grid service บนแนวคิดของ OGSA….…………………………………………………………..…6 2.2 Web service ตนตระกูลของ Grid service….………………………………………………………..7 2.3 Enter Grid Services: กาวเขาสูยุคของ Grid Service………………………………………………12 บทที่ 3 กลไกสําคัญของ Grid service……………………………………………………………………………16 3.1 กลไกสรางและทําลาย Grid service (Grid service Factory) ……………………………………….16 3.2 กลไกกําหนดขอมูลใหกับ Grid service (Service Data Elements)………………………………….17 3.3 กลไกจัดการวงจรชีวิต (Life Cycle Management)………………………………………………….17 3.4 กลไกการแจงขาว (Notification)…………………………………………………………………….18 บทที่ 4 การพัฒนา Grid service…………………………………………………………………………………20 4.1 ขั้นตอนพื้นฐานสําหรับเขียนโปรแกรมใหเปน Grid service………………………………………...20 4.2 การ deploy เอา Grid service ไปยัง container………………………………………………………29 4.3 รัน Grid service……………………….…………………………………………………………….32 Appendix………………………………………………………………………………………………………..35

1

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

บทที่ 1 สถาปตยกรรมบนฐานของบริการ (Service Oriented Architecture) ในบทนี้จะกลาวถึง Service Oriented Architecture (SOA) ซึ่งเปนเทคโนโลยีที่ Grid Service และ Web Service ใชเปนพื้นฐานในการพัฒนา โดยจะขอกลาวถึง Web Service กอน องคประกอบที่สําคัญของ Web Service ประกอบไปดวย Web Services Description Language (WSDL) ใชสําหรับอธิบายรายละเอียดและการใชงานของ Web Service, Simple Object Access Protocol (SOAP) เปนโพล โตคอลมาตรฐานสําหรับการแลกเปลี่ยนขอความระหวางการใชงาน Web Service และ Universal Description Discovery and Integration (UDDI) เปนแหลงบริการจัดเก็บที่อยูและคนหา Web Service 1.1 อะไรคือ SOA ? Service Oriented Architecture (SOA) คือ สถาปตยกรรมของแอปพิเคชั่นที่ประกอบดวย independent, distributed และ co-operating ซึ่งเรียกวา service โดย services สามารถกระจายเขาไปภายในหรือภายนอกของ องคกรและอาณาเขตที่ปลอดภัย นอกจากนี้สวนประกอบของ service สามารถอยูบนแพลตฟอรมทึ่ตางกันและ สามารถพัฒนาดวยภาษาโปรแกรมที่แตกตางกันได 1.2 องคประกอบพื้นฐานของ SOA สวนประกอบพื้นฐานของ SOA คือ elements และ operation โดยมีรายละเอียดดังนี้ 1.2.1 Element ที่สําคัญประกอบดวย Service Provider, Service Requestor และ Service Registry ซึ่งแสดงในรูป 1.1 - Service Provider เปนผูใหบริการ มีหนาที่ในการเปดบริการเพื่อรองรับการขอใชบริการจาก Requestor ที่เรียกเขามาขอใช โดยจะสราง service description และนําไปลงทะเบียนเก็บไวที่ Service Registry - Service Requestor เปนใครก็ตามที่ตองการเรียกใชบริการจาก Service Provider ซึ่งสามารถคนหา บริการที่ตองการไดจาก UDDI registry หรือ Service Registry หรือติดตอจาก Provider โดยตรง - Service Registry ทําหนาที่เปนตัวกลางในการจัดเก็บ service description ที่ลงทะเบียนไวโดย Service Provider และจัดสง service description ใหกับ Service Requestor เมื่อมีการมาคนหา service description ที่ ตองการ

2

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

รูปที่ 1.1 Elements of the Service Oriented Architecture (SOA) 1.2.2 Operation จะกําหนดการติดตอระหวาง elements ซึ่งประกอบดวย Publish, Find และ Bind ที่แสดงในรูป 1.1 - Publish operation คือการาติดตอกันระหวาง Service Provider และ Service Registry โดย Service Provider จะลงทะเบียนที่ service interfaces ซึ่ง Publish operation จะจัดเตรียมใหที่ Service Registry - Find operation คือการติดตอกันระหวาง Service Requestor และ Service Registry โดย Service Requestor ใช Find operation ไปดึงเอารายการที่ตองการของ Service Provider ซึ่งประกาศไวใน Service Registry - Bind operation คือการติดตอกันระหวาง Service Requestor และ Service Provider มันจะให Service Requestor เชื่อมตอกับ Service Provider กอนที่จะรองขอ operation โดยเฉพาะ Service Requestor สามารถ generate client-side proxy สําหรับ service ไดโดยมี Service Provider เปนตัวจัดเตรียมให (bind สามารถเปนได ทั้ง dynamic หรือ static ) ในกรณีที่ bind เปนdynamic ทําให Service Requestor สามารถ generate client-side proxy บน sevice description ซึ่งไดจาก Service Registry ที่เวลามีการรองขอ service และในกรณีที่ bind เปน static ทำให Service Requestor สามารถ generate client-side proxy ไดระหวางที่ทําการพัฒนาแอปพิเคชั่น 1.3 Web services คือเทคโนโลยีที่เกิดจากแนวคิด SOA Web service เปนการนํา SOA มาใชเปนแนวคิดพื้นฐานเพื่อทําการพัฒนาเทคโนโลยีสําหรับ ในการ เชื่อมตอโมเดลของโปรแกรมที่สรางบนมาตรฐานอินเทอรเน็ตดวยไวยากรณภาษาของ eXtensible Markup Language (XML) สําหรับใชอธิบายรายละเอียดของขอมูลในแพลตฟอรม, ภาษา, ฮารดแวต และ ซอฟตแวร ซึ่ง ใน Web service ไมเจาะจงโพรโตคอลในการติดตอสื่อสาร ดวยเหตุนี้จึงสามารถใชโพลโตคอลตัวใดก็ไดในการ ติดตอสื่อสาร ดังนั้น HTTP หรือ JMS สามารถใชในการแลกเปลี่ยน message ได

3

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

สําหรับเปาหมายของ Grid service เปนการใชแนวคิดพื้นฐานของ Web service ใหเปนประโยชน ซึ่ง Web service Description Language (WSDL) จะอธิบายรายละเอียดและการใชงาน service ตาง ๆ การพัฒนา มาตรฐานของ SOAP โพลโตคอลสําหรับการแลกเปลี่ยน message ระหวาง service และ Universal Description Discovery and Integration (UDDI) เปนแหลงจัดเก็บที่อยูและการคนหา service ตาง ๆ ที่ลงทะเบียนไว 1.3.1 Web Service Description Language (WSDL) Web Service Description Language (WSDL) เปนภาษาที่ใชอธิบายคุณลักษณะของ Web service และ วิธีการติดตอกับ Web service โดยใชไวยากรณของภาษา XML-base ซึ่งเปนอิสระกับภาษาโปรแกรมอื่น ๆ และ พัฒนาดวยสภาพแวดลอมอะไรก็ได WSDL เปนภาษาที่อยูในความดูแลขององคการ World Wide Web Consortium (W3C) เอกสาร WSDL ประกอบดวย 3 สวน คือ Service Interface, Service Bindings, Service Implementation ซึ่งเกี่ยวของกับขอมูลของ Web service ซึ่ง service จะกําหนดโครงสรางในการติดตอสื่อสารขอมูลและการลง นามของ operation ที่จัดเตรียมโดย service ในภาษา, แพลตฟอรม และโพลโตคอลในการติดตอสื่อสาร 1.3.1.1 Service Interface มีสวนประกอบทีสําคัญคือ Types, Message, Operation และ Port Type - Types เปนการกําหนดการใช data type โดยการแลกเปลี่ยน message ระหวาง Service Requestor และ Service Provider - Messages เปนการแสดงสัญญาณระหวาง Service Requestor และ Service Provider ถา operation คือ Remote Procedure Call (RPC) มันจะสงคากลับมา ถาเปน bi-directional และกําหนดดวยสอง message (ในตัวอยางคือ) getMOTDRequest และ getMOTDResponse โดย getMOTDRequest message เปนการ สงจาก Service Requestor ไปที่ Service Provider และ Service Provider ตอบกลับโดยการสง getMOTDResponse message ไปที่ Service Requestor อีกครั้ง message สามารถมี types parts ไดหนึ่ง ตัวหรือมากกวา - Operation เปนการอธิบายการทํางานของ Web service โดย operation ของ Message Exchange Patterns (MEP) จะมีอยู 4 ประเภท คือ One-way, Request-response, Solicit-response และ Notification 1.3.1.2 Binding เปนการระบุรายละเอียดเกี่ยวกับการใชโพลโตคอลในการสงผานขอมูลระหวาง Service Requestor และ Service Provider ใน service สามารถรองรับ Binding ไดหลายตัวสําหรับให Port Type แตละ Binding เปนเสนทางในการเขาถึงที่อยู Uniform Resource Identifier (URI) ซึ่งจะประกอบดวย element ดังนี้ - Name and type เปนการระบุรายละเอียดใหกับ Port Type ในตัวอยาง binding name คือ MOTDSoapBinding และ MOTD1 port type - Style เปนการกําหนดการติดตอสื่อสารโดยใชโพลโตคอลเมื่อมีการรองขอ operation ของ port type ซึ่ง WSDL จะกําหนดรายละเอียดของ binding style ใหกับ SOAP เปนสองประเภทคือ Document style และ RPC style

4

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

รูปที่ 1.2 Relationship of WSDL elements - Transport เปนการระบุ protocol ที่ใชสําหรับการติดตอสื่อสาร - Encoding style เปนการเพิ่ม binding style ในเอกสาร WSDL จะประกอบดวยสอง encoding style คือ Encode และ Literal 1.3.1.3 Service Implementation เปนรายละเอียดในการรองขอเพื่อใชงาน Web service ซึ่งประกอบดวย Service name และ Port - Service name เปนการบอกชื่อ Web service - Port เปนเสนทางในการเขาถึง Web service 1.3.2 Simple Object Access Protocol (SOAP) SOAP จัดเปนโพรโตคอลสื่อสารที่อาศัยไวยากรณของภาษา XML และทํางานกับโพรโตคอลอื่น ๆ ได หลายชนิด เชน HTTP, SMTP, FTP, IIOP เปนตน สาเหตุที่ใชไวยากรณของ XML จึงทํางานไดในทุก แพลตฟอรม ไมขึ้นกับแพลตฟอรม ดังนั้นเราก็สามารถเรียกใชงานคอมโพเนนตขามแพลตฟอรมได ในขณะที่ RMI เปนโพรโตคอลที่ขึ้นกับแพลตฟอรม จึงไมสามารถเรียกคอมโพเนนตขามแพลตฟอรมได 1.3.3 Universal Description, Discovery and Integration (UDDI) UDDI เปนมาตรฐานที่สรางขึ้นมาเพื่อคนหาบริการ Web service สําหรับผูตองการใชงาน Web service โดย UDDI เปรียบเสมือนฐานขอมูลขนาดใหญซึ่งมีขอมูลของ Web service ที่ใหบริการอยูบน Internet

5

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

บทที่ 2 สถาปตยกรรมแบบเปดของGrid service บทนี้กลาวถึงพื้นฐานของGrid service และขอกําหนดสําหรับการสรางGrid service นอกจากนี้แลวเรา จะกลาถึงเฟรมเวิรคที่กอใหเกิดสถาปตยกรรมแบบเปดของGrid service หรือ Open Grid Service Architecture (OGSA) ซึ่งตั้งอยูบนรากฐานของเทคโนโลยี Web service อันเปนเทคโนโลยีที่เปนรากเหงาของ Grid service นั่นเอง 2.1 Grid service บนแนวคิดของ OGSA อยางที่ไดเกริ่นนํามาตอนตนแลววา OGSA เปนสถาปตยกรรมของ Grid service ในหัวขอตอไปนี้ เราจะ มากลาวถึงรายละเอียดของ OGSA ใหมากขึ้นวา OGSA คืออะไร และ OGSA เกี่ยวของอะไรกับ Grid service “OGSA ใหคําจํากัดความของ Grid service” OGSA ไดกําหนดสถาปตยกรรมพื้นฐานของแอพพลิเคชันแบบกริด (grid-based applications) วา โปรแกรมหรือแอพพลิเคชันที่จะนํามาทํางานบนระบบกริดนั้นควรจะเปนเชนไร และระบบกริดควรจะจัดเตรียม องคประกอบใดใหแกแอพพลิเคชันเหลานั้น โดยแกนแทของสถาปตยกรรมของ OGSA นั้นไดใหความสําคัญกับ การพัฒนาแอพพลิเคชันในรูปแบบของบริการที่เรียกวา Grid service อยางไรก็ตาม OGSA ไมไดลงรายละเอียด ทางเทคนิควาจะพัฒนา Grid service ดวยวิธีใด แตทวา OGSA ไดใหคําจํากัดความหรือความหมายของ Grid service วาคืออะไร รวมถึงความสามารถของGrid service วาตองมีและควรมีอะไรบาง รวมถึงเทคโนโลยีที่ ประกอบขึ้นมาเปนกริดเวอรซิส “OGSI กําหนดรายละเอียดสําหรับสราง Grid service” อยางที่ไดกลาวแลววา OGSA ไดใหคํานิยามหรือความหมายขอ Grid service วาคืออะไร แตรายละเอียด ทางเทคนิค หรือที่เรียกวา technical specification สําหรับการพัฒนา Grid service ไดถูกบัญญัติโดย OGSI (Open Grid Service Infrastructure) “Globus Toolkit 3 ถูกสรางขึ้นมาโดย OGSI” Globus Toolkit 3 หรือเรียกสั้นๆวา GT3 เปนเครื่องมือที่ใชงานไดจริงๆซึ่งถูกสรางโดยขอกําหนดของ OGSI (และเชนเดียวกัน GT3 ก็ถูกสรางตามหลักการพื้นฐานของ OGSA) ความแตกตางของ OGSA, OGSI และ GT3 ถึงตรงนี้คําสามคําไดผลุดขึ้นมาบนฐานของแนวความคิดในการสราง Grid service นั่นคือ OGSA, OGSI และ GT3 และทั้ง 3 สิ่งนี้ มันตางกันอยางไร? เพื่องายตอความเขาใจถึงความแตกตางของ OGSA, OGSI และ GT3 การยกตัวอยางตอไปนี้คงจะพอทําใหผูอานเขาใจความหมายและบทบาทของมันไดมากยิ่งขึ้น “เราสามารถบอกไดวา OGSA ก็เปรียบเสมือนกับพิมพเขียวที่วางสถาปตยกรรมของระบบกริดคลายกับ งานของสถาปนิกที่ออกแบบบาน สวน OGSI ก็เปรียบเสมือนแผนงานของวิศวกรที่ลงมือประกอบบาน แตในที่นี้ OGSI คือแผนงานสําหรับสราง Grid service กลาวคือ OGSA คืองานออกแบบ สวน OGSI คืองานกอสราง สวน

6

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

GT3 เปรียบเสมือนอิฐ ปูนซีเมนตและไมคาน สําหรับกอสรางบาน แตในที่นี้ GT3 ก็เสมือนเครื่องมือสําหรับสราง Grid service เพื่อใชงานจริงนั่นเอง” 2.2 Web service ตนตระกูลของ Grid service Grid service เปนแอพพลิชันแบบกริดที่ถูกนิยามไวใน OGSA นอกจากนี้แลว OGSA ยังไดกําหนดเทคโนโลยี พื้นฐานของGrid serviceไววา พื้นฐานของGrid service ก็ไดมาจากเทคโนโลยี Web service การเขาใจสถาปตยกรรมของ Web service จะนําไปสูการเขาใจพื้นฐานในการพัฒนา Grid service ได ดวย อยางไรก็ตามในรายงานเลมนี้ เราจะไมเนนรายละเอียดวาจะพัฒนา Web service นั้นตองทําอยางไร แตใน หัวขอนี้ก็จะกลาวถึงพื้นฐานของWeb service ในระดับหนึ่ง เพื่อเปนการเขาใจภาพรวมของ Web service เราจึงขอยกตัวอยางเหตุการณจําลองของระบบที่พัฒนาโดย เทคโนโลยี Web service ตัวอยางคือ ระบบสั่งซื้อสินคาออนไลน โดยสมมติวามีบริษัทแหงหนึ่งนําเขาสินคามา จากตางประเทศแตไมไดขายตรง แตทวา จะมีรานคาที่สั่งสินคาจากบริษัทและรับไปขายตรงแกลูกคาอีกทอดหนึ่ง ทุกครั้งที่รานคาจะสั่งสินคาจากบริษัท รานคาจะขอแคตตาล็อกของสินคาจากบริษัทกอนโดยใชบริการที่ชื่อ ShopService ผานทางโปรแกรมที่ทําการตอตรงไปที่ Web service ที่ชื่อ ShopService ของบริษัทนั้น โดยสามารถ แสดงภาพใหเห็นถึงการขอใชบริการ ShopService ไดจากภาพนี้

รูปที่ 2.1 ตัวอยางของการใชงาน Web service จากรูปที่ 2.1 แสดงใหเห็นวา พนักงานรานคาเปดโปรแกรมของรานคาซึ่งเปนโปรแกรมที่ทํางานบน คอมพิวเตอรฝง client ไดรองขอใชบริการเพื่อดึงแคตตาล็อกของสินคาผานทางบริการ ShopService ซึ่งทํางานอยู บนคอมพิวเตอร server ของบริษัท จากนั้นคอมพิวเตอร server ของบริษัทจะทําการสงแคตตาล็อกกลับคืนไปที่ คอมพิวเตอรฝง client การทํางานของWeb service ที่บรรยายไวในภาพนั้น ทานผูอานคงไดรูวาเปนรูปแบบการทํางานที่งาย และก็คลายคลึงกับเทคโนโลยีอื่นๆที่เคยไดเกิดขึ้นแลวในอดีต (อาทิเชน RMI, CORBA, หรือ EJB) คําถามที่ ตามมาคือ แลว Web service มีขอดีเหนือกวาเทคโนโลยีอื่นๆอยางไร

7

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

• ความเปนอิสระ (Independency) Web service มีคุณสมบัติไมยึดติดกับแพลตฟอรม (platformindependent) และไมยึดติดกับภาษา (language-independent) สาเหตุที่ทําให Web service มีคุณสมบัติ เชนนี้ก็เพราะวา Web service ไดใชมารตฐานของภาษาที่ชื่อ eXtended Markup Language (XML) นั่นเอง ซึ่งทําใหนักพัฒนาระบบมีอิสระในการเลือกใชเทคโนโลยีวาจะพัฒนาโปรแกรมบนฝง client หรือ server ดวยเทคโนโลยีใด และเทคโนโลยีในการพัฒนาบนฝง client กับ server ไมจําเปนตอง เหมือนกันก็ได เชน โปรแกรมทางฝง client อาจจะถูกพัฒนาดวย Microsoft Visual C++.NET ซึ่งทํางาน บน Microsoft Windows XP แตทวาโปรแกรมบนฝง server อาจจะถูกพัฒนาโดยภาษา Java ที่ทํางานบน Sun Solaris 9 ก็ได • ขอบเขตที่ขยายอยางกวางขวาง (Scalability) โดยสวนใหญแลว Web serviceใชโปรโตคอล HTTP สําหรับรับสงขอมูลไปมาระหวาง client กับ server และดวยความสามารถนี้ของWeb service มันทําให การเชื่อมโยงโปรแกรมตางๆจากหลากหลายองคกรบนเครือขายอินเตอรเน็ตเปนไปอยางกวางขวางมาก ยิ่งขึ้น เพราะโปรโตคอล HTTP เปนโปรโตคอลที่ไฟรวอล (Firewall) ขององคกรตางๆยอมรับ (ตางจาก โปรโตคอล RMI, CORBA และเทคโนโลยีอื่นๆที่มักจะถูกไฟรวอลสกัดกั้นไว) อยางไรก็ตาม Web service ก็ยังมีจุดออนอยู ดังนี้ • ขนาดที่ใหญเกินพอดี (High overhead) เนื่องดวย Web service เลือกใชเอกสาร XML เปนมาตรฐาน กลางของเอกสารที่รับสงไปมาระหวาง client และ server ซึ่งเอกสาร XML นับวามีขนาดที่ใหญและอาจ กระทบตอประสิทธิภาพของระบบเครือขายใหลดลงได ทั้งนี้ทั้งนั้น ก็นับวาเปนสิ่งที่ตองแลกเปลี่ยนกัน ระหวางของดีกับของเสีย ซึ่งเว็บเซอรจะนํามาซึ่งความเขากันไดของทุกที่ของระบบ (portability) แตก็ นําพาซึ่งประสิทธิภาพ (efficiency) ของระบบเครือขายที่เสื่อมถอยลงดวย • ขาดความสมบูรณแบบ (Lack of versatility) หากจะถามวาเทคโนโลยีที่สมบูรณแบบคือเทคโนโลยีใด ก็ คงตอบไดวายังไมมีในโลก (ถามีก็อาจจะยังไมเกิด หรืออาจจะตายไปแลวจนลืมไปวามันเคยมี) แตทวา ถาพูดถึงเทคโนโลยีที่มีรูปแบบการทํางานที่คลายกับ Web service คือมีการรองขอใชบริการระยะไกล (remote service invocation) ก็มีหลายเทคโนโลยีซึ่งไดจัดเตรียมความสามารถที่มากกวาที่ Web service มีอยู เพราะ Web service ไดเสนอเพียงแคกลไกการรองขอระยะไกลและการแลกเปลี่ยนเอกสารระหวาง client กับ server เทานั้น สวนความสามารถอื่นๆที่ควรจะมีกลับขาดหายไป ขอยกตัวอยางความสามารถ ที่ Web service ควรจะมี โดยเปรียบเทียบกับ เทคโนโลยี CORBA ซึ่ง CORBA ไดเสนอบริการเพิ่มเติม ไวมากมาย อาทิเชน persistency, notification, lifecycle management, transaction และอีกมากมาย แต อยางไรก็ตาม ถาทานอานตอไป ทานก็จะพบวาความสามารถเหลานี้ กลับถูกจัดเตรียมไวใหกับ Grid service ความแตกตางที่เดนชัดของ Web service กับเทคโนโลยีอื่นๆที่ใกลเคียงกับ Web service สามารถพิจารณาไดจากคุณสมบัติ Highly coupled (หรืออาจจะเรียกวา Tightly coupled ก็ได) กับ Loosely coupled โดยเทคโนโลยีอื่นๆอยาง CORBA และ EJB นั้นเปนเทคโนโลยีที่เนนการสรางระบบ การกระจายแบบ Highly coupled ก็คือ โปรแกรมทางฝง client กับ server จะมีความขึ้นตรงตอกันสูง เชน โปรแกรมทางฝง client ชื่อ X จะทํางานกับโปรแกรมทางฝง server ชื่อ Y เทานั้น เปนตน ซึ่งระบบ ที่เปนแบบ Highly coupled มักจะเหมาะกับระบบขององคกรแบบ intranet หรือใชภายในองคกร

8

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

เดียวกันมากกวา แตWeb service เปนเทคโนโลยีที่เนนการสรางระบบแบบ Loosely coupled กลาวคือ โปรแกรมทางฝง client ไมจําเปนตองรูจักบริการที่มีอยูบนฝง server มากอน รวมถึงไมจําเปนตองทราบ วิธีการรองขอWeb service กอนวาตองทําเชนไร ซึ่งWeb service จะมีวิธีการระบุถึงวิธีการรองขอ Web service โดยการอางผานไฟล XML ที่เรียกวา WSDL และรูปแบบของระบบแบบ Loosely couple นี้มัก เหมาะสมกับการใชงานระหวางองคกร หรือองคกรเดียวกันแตอแยกการบริหารเปนสาขาหลายสาขา ผานเครือขาย extranet หรือ Internet ซึ่งระบบกริดก็ตองการคุณสมบัติในการพัฒนาระบบแบบ Loosely coupled อยางที่ Web service มีเชนกัน 2.2.1 พื้นฐานการรองขอบริการจาก Web service อยางไรก็ตาม ขั้นตอนการทํางานของเทคโนโลยี Web service จริงๆนั้นกลับไมใชมีเพียงแคฝง client ทํา การรองขอใชบริการจาก Web service แลว Web service คืนคาผลลัพธกลับมาที่ client แตทวาเทคโนโลยีWeb service กลับมีขั้นตอนการทํางานเพิ่มเขามาเพื่อใหการรองขอใชบริการWeb service เปนไปอยางมีประสิทธิภาพ ยิ่งขึ้น

รูปที่ 2.2 ขั้นตอนการทํางานของ Web service จากภาพขางบนนี้ กลาวถึงขั้นตอนทั้ง 6 ในการรองขอใชบริการWeb service ซึ่งมีดังตอไปนี้ 1. ขั้นตอนคนหาWeb service อยางที่เราเคยไดกลาวในหัวขอที่ผานมาแลววา client อาจจะยังไมรูจักที่อยูของWeb service ที่ตองการวาจะไป รองขอไดจากที่ใด ดังนั้นขั้นตอนแรกของการรองขอ Web service ก็คือ การคนหาWeb service ซึ่งผูรองขอใช บริการหรือที่เรียกวา Service requestor จะทําการรองขอใชระบบการคนหาบริการที่ตองการจากระบบจัดเก็บ ทะเบียนของWeb service หรือที่เรียกวา Universal Directory, Discovery, and Integration (UDDI) ผมขอ ยกตัวอยางขั้นตอนนี้จากภาพเชน หากคุณคือ Service requestor ที่ตองการบริการพยากรณอากาศของประเทศไทย

9

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

ที่ชื่อวา WeatherService (จากรูปภาพ สมมติเปนบริการสําหรับทํางานที่ชื่อ X) โปรแกรมฝง client จะรองขอใช ระบบการคนหา Web service จาก UDDI 2. ขั้นตอนคืนคาการคนหา Web service จากขั้นตอนแรก หลังจากที่ Service requestor ขอใชระบบการคนหาWeb service จาก UDDI แลว UDDI จะทํา การคนหา Web service ในทะเบียนของ Web service ที่เคยไดลงทะเบียนไวกับ UDDI ซึ่งถาจะเปรียบเปรยนั้น UDDI ก็เปนเสมือนสมุดหนาเหลืองที่เก็บทะเบียนของWeb service เพื่อทําให Service requestor ทราบถึงที่อยูเพื่อ ติดตอกับ Web service นั้นได 3. ขั้นตอนสอบถามวิธีการใชงานWeb service หลังจากที่ Service requestor ทราบถึงที่อยูของWeb service แลว (ซึ่งก็คือ server ที่ Web serviceนั้นทํางานอยู) Service requestor จะยังไมสามารถเขาใชบริการจากWeb service นั้นได จนกวา Service requestor จะทราบถึง รายละเอียดของวิธีการใชงาน Web service นั้น โดย Service requestor จะทําการสอบถามวิธีการใชงานWeb service จาก server ที่เปดบริการWeb service นั้น ยกตัวอยางเชน หากเราทราบที่อยูของบริการพยากรณอากาศของ ประเทศไทย แตอยางไรก็ตาม เราคงจะยังไมทราบถึงฟงกชันการทํางานที่ Web service นั้นจัดเตรียมไวให (ศัพท ที่เราใชเรียกฟงกชันของเว็บเซอรนั้น อาจจะเรียกวา remote method) รวมถึงพารามิเตอรที่เราตองใสเขาไปและ คาที่จะคืนจากWeb service นั้นดวย ซึ่งฟงกชันของการพยากรณอากาศนั้นอาจจะอยูในรูปแบบ String forcast(String provinceName) โดยฟงกชันนี้เราตองใสชื่อจังหวัดขที่ตองการคําพยากรณ และผลลัพธจากฟงกชัน ก็คือคําพยากรณ 4. ขั้นตอนตอบกลับวิธีการใชงาน Web service วิธีการใชงานWeb service จะถูกตอบกลับไปที่ Service Requestor ในรูปแบบเอกสาร XML ที่เราเรียกวา Web Service Description Language (WSDL) เมื่อ Service requestor ไดรับเอกสารนี้แลว มันจะทราบถึงวิธีการใชงาน Web service นั้นไดแลว 5. ขั้นตอนการเขาถึง Web service เพื่อรับบริการ Service requestor ทําการรองขอบริการWeb service โดยยึดวิธีการใชงานฟงกชันของWeb service ที่อธิบายไวใน WSDL และการเขาใชบริการWeb service นั้น จําเปนตองมีขอความ (ซึ่งระบุคาที่ไดสงผานพารามิเตอรของ ฟงกชัน) สงไปถึงWeb service ผานทางโปรโตคอลที่ชื่อ Simple Object Access Protocol (SOAP) 6. ขั้นตอนคืนผลลัพธอนั เกิดจากการทํางานของWeb service ผลลัพธอันเกิดจากการการประมวลผลฟงกชันของWeb service นั้น จะถูกคืนคากลับไปให Service requestor ผาน ทางโปรโตคอล SOAP ยกตัวอยางเชน หากเปนการเรียกฟงกชันการพยากรณอากาศที่ไดกลาวมานั้น ผลลัพธของ การพยากรณจะถูกสรางเปนขอความสงไปให Service requestor ผาน SOAP เปนตน

10

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

2.2.2 การอางอิงที่อยูของ Web service ในระบบเครือขายนั้นประกอบไปดวยทรัพยากรตางๆมากมาย การที่เราจะอางอิงถึงทรัพยากรที่เรา ตองการนั้น ระบบจําเปนตองมอบหมายที่อยูที่เปนเอกลักษณใหแกทรัพยากรแตละตัว ซึ่งวิธีการอางอิงถึงที่อยู ของทรัพยากรที่เราใชกันอยางกวางขวางนั้น เราจะใชวิธีการอางอิงที่เรียกวา Uniform Resource Identifier (URI) สําหรับการอางอิงไปหา Web service นั้น เราก็ใช URI เชนกัน อยางที่เราไดกลาวมาแลววา เทคโนโลยี Web service จะมี UDDI ที่ทําหนาที่เก็บทะเบียนหรือที่อยูของ Web service ซึ่งผลลัพธจากการสอบถามที่อยูของWeb service ผาน UDDI นั้น จะถูกตอบกลับมาในรูปแบบ URI นั่นเอง เพื่อเปนการเห็นภาพใหมากยิ่งขึ้น ดูตัวอยาง URI ของ Web service หนึ่งตอไปนี้ http://webservice.hpcnc.ku.ac.th/weather/th/WeatherService จากตัวอยาง URI ขางบนนี้ เปนตัวอยางของWeb serviceที่ชื่อ WeatherService ซึ่งทานผูอานสามารถ สังเกตไดวา การอางอิงที่อยูของWeb serviceนั้นก็ไมไดตางอะไรจากการอางอิงเว็บเพจ แตทวาหากคุณพิมพ URI นี้ลงไปในชองกรอกที่อยูหนาเว็บเพจของโปรแกรมบราวเซอร ผลลัพธที่ไดอาจจะแสดงเปนความผิดพลาด หรือ อาจจะเปนขอความที่พอดูไดแตไมสามารถใชงานWeb service นั้นไดแตอยางใด แตเราสามารถนํา URI ของWeb service นั้นไปใชกับโปรแกรมทางฝง client (หรือโปรแกรมของ Service requestor นั่นเอง) แลวโปรแกรมนั้นจะ เชื่อมการติดตอไปหาWeb serviceโดยอางอิงที่อยูผาน URI 2.2.3 สถาปตยกรรมของ Web service สถาปตยกรรมของWeb service ถูกบรรยายเปนลําดับชั้นหรือเลเยอร (layer) ไดจากภาพตอไปนี้

รูปที่ 2.3 เลเยอรทั้ง 4 ของเทคโนโลยี Web service

11

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

• เลเยอรการคนหาบริการ (Service Discovery Layer) เลเยอรนี้เปนเลเยอรที่เสนอวิธีการสําหรับการคนหา Web service ที่ Service requester ตองการ โดย เทคโนโลยี Web service ไดจัดเตรียมกลไกที่ชื่อ UDDI สําหรับการคนหา Web service อยางที่ไดกลาว ไวแลวในขางตน • เลเยอรการใหรายละเอียดบริการ (Service Description Layer) เลเยอรนี้เสนอขั้นตอนการใหรายละเอียดการเรียกใชบริการของ Web service โดยเทคโนโลยี Web service ไดเสนอการอธิบายรายละเอียดนี้ผานทางเอกสาร XML ที่เรียกวา Web Service Description Language (WSDL) • เลเยอรการรองขอใชบริการ (Service Invocation Layer) เลเยอรนี้เสนอวิธีการในการรองขอใชบริการจาก Web service โดยเรียกบริการที่ Web service เปด บริการวา operation (ซึ่งในเชิงเทคนิคในขั้นตอนการเขียนโปรแกรม อาจจะเรียก operation วา method หรือ function) • เลเยอรการรับสงขอมูล (Transport Layer) เลเยอรนี้เสนอวิธีการในการรับสงขอมูลระหวางโปรแกรมทางฝง Service requester (หรือโปรแกรมทาง ฝง client) กับโปรแกรมของ Web service (หรือโปรแกรมทางฝง server) ซึ่งเทคโนโลยี Web service แนะนําโปรโตคอลที่ชื่อ Simple Object Access Protocol (SOAP) สําหรับการรับสงขอมูลหรือ ติดตอสื่อสารระหวางโปรแกรมทั้ง 2 ฝง 2.3 Enter Grid Services: กาวเขาสูยุคของ Grid Service อยางที่ไดกลาวมาขางตนแลววา Web service เปนเทคโนโลยีหนึ่งสําหรับพัฒนาโปรแกรมเพื่อใชงาน บนเครือขายอินเตอรเน็ตที่สามารถทําลายกําแพงของความแตกตางของเทคโนโลยีระหวางระบบหลายๆระบบได อยางลงตัว และนี่เองจึงเปนที่มาที่วา ทําไมบรรดานักเทคโนโลยีทางดานเทคโนโลยี Grid จึงไดใหความสนใจใน เทคโนโลยี Web service วานาจะเปนเทคโนโลยีที่สามารถกําหนดแนวทางใหมสําหรับการพัฒนาโปรแกรม สําหรับ Grid อยางไรก็ตาม Web service ก็ยังมีขอจํากัดอยู อยางที่ไดกลาวไวแลวในขางตน ซึ่งถาจะวากันจริงๆแลว Web service (ตามที่กําหนดโดยองคกร W3C) ก็ยังไมใชเทคโนโลยีที่สามารถชวยในการพัฒนาโปรแกรมสําหรับ ใชกับ Grid ได ดังนั้น เพื่อเปนการปรับปรุงจุดออนของ Web service และเพิ่มเติมจุดแข็งเขาไปนั้น จึงไดเกิด เทคโนโลยีที่อิงตามแนวคิด Service Oriented Architecture (SOA) ตัวใหมที่ชื่อวา Grid service ความแตกตางอันเดนชัดระหวาง Web service กับ Grid service และนับวาเปนขอดอยของ Web service เลยก็วาไดนั้นพิจารณาไดจากคุณสมบัติ 2 ประการที่ Web service ไดประสบ คือ Web service จัดเตรียมบริการ แบบ stateless และยังเปน non-transient ซึ่งแตละคุณสมบัติอธิบายไดดังนี้

12

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

• Web service ใหบริการแบบ stateless คุณสมบัติ stateless หมายถึงวา Web service ไมสามารถจดจําคาหรือสถานะที่แลวมาวาไดทําอะไร ไปและเคยไดผลลัพธอะไรแลวบาง กลาวคือ ถาเรามีการรองขอ operation (หรือเรียก method) หนึ่ง ของ Web service แลวหากคุณเรียก operation ตัวอื่นหรือแมกระทั่งเรียก operation เดิม Web service จะจําไมไดวาผลลัพธที่ไดจากการทํา operation ตัวกอนหนานี้มีคาเทาไหร ซึ่งวิธีการแกปญหานี้ของ Web service สามารถแกไดที่ฝง client โดยใหโปรแกรมฝง client จดจําคาของแตละ operation กอนที่ จะเรียก operation ครั้งตอไป และก็ตองปอนคาเดิมกลับไปที่ operation ครั้งใหมนี้อีกครั้ง หรืออีกวิธี หนึ่งก็คือ ให Web service เขียนคาลง storage หาก Web service ตองการรื้อฟนความจําก็จะกลับไป อานที่ storage กอน • Web service ใหบริการแบบ non-transient คําวา non-transient หมายถึงอายุของ Web service นั้นยืนยงตลอดไป และ client ทุกๆตัวสามารถแชร Web service ผานเพียง instance เดียวเทานั้น โดย instance ก็เปรียบเสมือน process ของ Web service ที่คอยใหบริการ operation ตางๆแก client ซึ่งถาแมวาเราปรับกลไกให Web service จดจําขอมูลอะไร บางอยางจาก client รายหนึ่งไดแลว ขอมูลที่ Web service นั้นจดจําก็สามารถถูกมองเห็นโดย client รายอื่นไดดวยเชนกัน ซึ่งนับวาไมใชเรื่องที่ดีเลยทีเดียว ดวยขอจํากัดของ Web service ทั้งคุณสมบัติ stateless และ non-transient จึงเปนจุดที่ Grid service นํามา ปรับปรุงใหดียิ่งขึ้นโดย Grid service มีคุณสมบัติแบบ stateful และ transient • Grid service ใหบริการแบบ stateful stateful คือ Grid service สามารถจดจําการทํางานของแตละ operation ไดโดยที่ผูพัฒนาโปรแกรมไม จําเปนตองคิดคนวิธีการเพิ่มเติมเหมือนกับที่ไดกลาวไวใน Web service แตทวา Grid service ยัง สามารถทําใหเปน stateless ไดดวยเชนกัน • Grid service ใหบริการแบบ transient transient คือ Grid service สามารถมี instance ใหกับ client เพียงรายเดียว หรือกลุมของ client เพียง กลุมใดกลุมหนึ่งได และ Grid service ชนิดเดียวกันยังสามารถมี instance ไดหลาย instance เพื่อ ใหบริการ client รายใดรายหนึ่งหรือกลุมของ client กลุมใดกลุมหนึ่งไดดวย แตอยางไรก็ตาม เรา สามารถทําให Grid service เปนแบบ non-transient ได

13

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

ในหัวขอถัดไปเราจะกลาวถึงกลไกที่ทําให Grid service สามารถมีคุณสมบัติอยาง stateful และ transient ได ซึ่งกลไกนั้นมีชื่อวา Factory 2.3.1 Factory: โรงงานสําหรับผลิตและทําลาย Grid service Grid service ไดแกปญหาที่ไดพบเจออยาง stateless กับ non-transient ดวยการเสนอกลไกที่ชื่อวา Factory ขึ้นมา โดย Factory จะทําหนาที่ในการสราง instance ของ Grid service ขึ้นมาใหกับ client รายใดรายหนึ่ง หรือกลุมใดกลุมใดหนึ่งได อีกทั้ง Grid service ที่ไดมานั้นยังมีคุณสมบัติ stateful อีกดวย ถาจะวาไปแลว Factory จะมีเพียง instance เดียวเพื่อใชสําหรับสรางหรือทําลาย Grid service ชนิดใด ชนิดหนึ่ง (ซึ่งในทางปฏิบัติ เราอาจสราง Factory สําหรับ Grid service หนึ่งหลายๆ Factory ก็ได) โดยทุกครั้งที่ client ตองการใชงาน Grid service ชนิดหนึ่ง client ก็จะทําการรองขอ Factory ที่เกี่ยวกับ Grid service ชนิดนั้นให สราง instance ของ Grid service ขึ้นมา แตถา client จะเรียก operation ของ Grid service นั้น client จะไมติดตอไป ที่ Factory อีกแลว แตจะติดตอตรงไปที่ instance ของ Grid service ที่ถูกสรางขึ้นมา และ client สามารถรองขอให Factory ทําลาย instance ของ Grid service ที่ไดเกิดขึ้นมาแลวได

รูปที่ 2.4 ตัวอยางการใช Factory จากรูปที่ 2.4 ที่แสดงดานบนนี้ เปนรูปที่แสดงใหเห็นถึงการติดตอระหวาง client กับ Factory โดยมี Factory ที่ชื่อ วา MathService Factory ซึ่งเปน Factory สําหรับสรางและทําลายบริการที่ชื่อวา MathService โดยภาพไดแสดงให เห็นวามีกลุมของ client อยู 4 client ที่ตางใช MathService ที่สรางโดย Factory รวมกัน ซึ่งอาจจะเปนไปไดวา client D เปน client ที่รองขอให MathService Factory สรางกลุมของ instance ของ MathService เพื่อบริการแก client A, client B และ client C ซึ่งจะเห็นไดวา client C อาจจะเปน client เดียวที่ครอบครอง instance ของ Math service เพียง instance เดียวไวใชเพียงลําพัง แต client B ใช instance ของ MathService รวมกับ client A ก็ได 2.3.2 กลไกอื่นๆที่ Grid service จัดเตรียมมาให Grid service ยังไดจัดเตรียมกลไกพื้นฐานอื่นๆที่นาสนใจ กลไกเหลานั้นคือ Life cycle management, Service data และ Notification 14

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

• Life cycle management เปนกลไกสําหรับการจัดการวงจรชีวิตของ Grid service โดย Grid service จะมี วงจรเปนระยะตางๆนับตั้งแต Grid service เกิด จนถึง Grid service กําลังใหบริการ จนกระทั่ง Grid service หมดชวงชีวิต (หรือตาย) • Service data เปนกลไกที่เราสามารถกําหนดขอมูลบางอยางใหกับ Grid service เหมือนกับการกําหนด ลักษณะหรือ attribute ของ Grid service ซึ่งเปนเปนไปไดวา Grid service ที่ใหบริการชนิดเดียวกัน (คือ เกิดจาก Factory ตัวเดียวกัน) อาจจะมีลักษณะที่แตกตางกันไปได • Notification เปนกลไกสําหรับการแจงขาว โดยเราสามารถกําหนดให Grid service สามารถเปนตนตอ ของแหลงขาวที่เราสนใจซึ่งเราจะเรียกวา Notification source และสามารถกําหนดใหโปรแกรมทางฝง client เปนหนวยที่สนใจขาวคราวที่เกิดที่ Grid service ไดหรือเรียกวาเปน Notification sink ซึ่งเรา สามารถกําหนดให client รับฟงเฉพาะขาวคราวอยางใดอยางหนึ่งได และเมื่อไหรก็ตามที่ Grid service มีขาวคราวที่ client สนใจเกิดขึ้นแลว Grid service จะทําการแจงขาวคราว (notified) ไปที่ client ให รับทราบขาวนั้นได 2.3.3 การระบุที่อยูของ Grid service ดวย GSH และ GSR อยางที่เราไดกลาวถึงวิธีการระบุที่อยูของ Web service ไปแลววา เราระบุที่อยูของ Web service ดวย URI (หรือ URL) ของ Web service แตทวา การระบุที่อยูของ Grid service ก็ใช URI เชนกัน แตจะไมเรียกวา URI ก็เทานั้น ซึ่งเราจะเรียก URI ของ Grid service วา Grid Service Handle หรือ GSH OGSA ไดใหขอกําหนดวา ที่อยูของ Grid service ตองไมซ้ํากัน โดยเปนไมไดที่ instance ของ Grid service 2 instance จะมี GSH เหมือนกัน แมวา Grid service นั้นจะถูกสรางมาจาก Factory เดียวกันก็ตาม โดย OGSI ไดกําหนดให Factory เปนตัวกําหนด GSH ใหแตละ Grid service ใหแตกตางกัน แตทวาเพียง GSH อยาง เดียวนั้นไมไดบงบอกถึงวิธีในการติดตอกับ Grid service แตอยางใด เชน ไมไดบอกถึง operation หรือ method ของ Grid service วาไดใหบริการอะไรบางและจะสง parameter อะไรบางเขาไปใน operation เหลานั้น เปนตน โดยสวนที่บงบอกวิธีการในการติดตอกับ Grid service จะกําหนดไวใน Grid Service Reference หรือ GSR โดย ขอกําหนดของ OGSI ไมไดนิยามวา GSR จะตองมีรูปแบบอยางไรในการอธิบายถึงวิธีในการติดตอกับ Grid service แตเนื่องจากวา Grid service ไดใช SOAP เปนโปรโตคอลในการรับสงขอมูลระหวาง Grid service กับ client อยูแลว ดังนั้น OGSI จึงเลือกให GSR ถูกจัดอยูในรูปแบบของเอกสาร WSDL

15

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

บทที่ 3 กลไกสําคัญของ Grid service Grid application มีลักษณะที่พิเศษ โดยไดจัดเตรียมกลไกสําหรับการพัฒนา Grid service ดังนี้คือ Factory, Service Data Elements, Life cycle และ Notification 3.1 กลไกสรางและทําลาย Grid service (Grid service Factory) Factory ใน grid service ทําหนาที่ในการสราง instances ของ Grid service ใหกับ client ซึ่งมี ความสามารถเหมือนกับแนวความคิดของ factory ใน object-oriented deign และ object-oriented programming ใน Java ที่ทําหนาที่ในการสราง instances ของ class ในการเรียกใชบริการของ client อันดับแรก client จะทําการหาที่อยูของ factory กอนจากนั้นทําการรอง ขอให factory สราง instance ของ service เมื่อ factory ไดรับการรองขอ จะทําการสราง instance ของ grid service และสงคาของ Grid Service Handle (GSH) และ Grid Service Reference (GSR) กลับไปให client Grid Service Handle (GSH) เปนตัวชี้ที่อยูของ service ที่เปนลักษณะเฉพาะซึ่งมีไดหนึ่งเดียว โดย client จะใชในการติดตอกับ instance ของ service นั้น ๆ Instance ของ grid service ทําการเก็บสถานะของขอมูลซึ่งมีความสัมพันธกับขอมูลที่มีการองขอ โดยใน การรองขอสามารถรองขอไดหลาย ๆ client ซึ่งระยะเวลาในการใชงาน instance ของ client จะสิ้นสุดลงเมื่อ client เลิกใชงาน หรือสามารถกําหนดชวงระยะเวลาในการใชงานวาจะใหสิ้นสุดเมื่อไร โดยไปกําหนดที่ตัวแปร termination time ได เมื่อถึงเวลาที่กําหนด มันจะไปทําลาย instance นั้นทิ้ง ขั้นตอนในการทํางาน 1. Client ทําการสอบถามไปยังที่จัดเก็บบริการตาง ๆ เพื่อทําการคนหา factory 2. Client ทําการรองขอไปยัง factory เพื่อสราง instance ของ grid service 3. Factory ทําการสราง instance ใหมของ grid service 4. Factory ทําการสงคาของ GSH ของ instance ใหม ไปให client 5. Client สามารถเรียกใชบริการได ตัวอยางในรูปที่ 3.1 แสดงใหเห็นแนวคิดของ client ในการรองขอ instance จาก factory โดย factory จะ สราง instance และ สงคา GSH หรือ URL ไปให client และ client จะใช GSH นี้ติดตอโดยตรงกับ instance ของ service

รูปที่ 3.1 การติดตอสื่อสาร Factory

16

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

3.2 กลไกกําหนดขอมูลใหกับ Grid service (Service Data Elements) Service data คือการรวบรวมโครงสรางขอมูลโดยมีความสัมพันธกับสถานะของขอมูลใน instance สําหรับ grid service โดยจะตองสามรถเขาใชไดงาย ซึ่งแบงออกเปนประเภทตาง ๆ โดยขึ้นอยูกับลักษณะของ บริการนั้น ๆ Service Data Elements (SDE) จะประกอบดวยกลุมของขอมูลของ instance ใน grid service ซึ่ง ประกอบดวยสองประเภทคือประเภท A และประเภท B โดยประเภท A จะเปนการบอกรายละเอียดขอมูลของ ทรัพยากร เชน สถาปตยกรรม, ความเร็ว, ระบบปฏิบัตกิ าร และพื้นที่วางในการจัดเก็บขอมูล สวนประเภท B เปน การบอกรายละเอียดของคุณภาพและระดับความถูกตองของบริการ SDE สามารถเปนไดทั้ง static และ dynamic โดย static service data เปนการกําหนดเงื่อนไขในสวนของ การติดตอกับบริการ แต dynamic service data เปนการเพิ่ม instance ของ service ในการใชแบบ dynamic service data นั้น client จะตองไปเอาคามาจากรายการของ Service Data Elements ในขณะที่กําลังทํางาน ในตัวอยางเปนการสงคาทั้งหมดของ Service Data Elements กลับไปที่ instance ของบริการนั้น ๆ ใน grid service จะมี findServiceData เปนฟงกชันในการกําหนดการติดตอซึ่งกันและกัน ในการพัฒนาดวยภาษาจาวา เพื่อตองการให service data มีประสิทธิภาพ ดังนั้นจึงเพิ่ม SDE เขาไปใน การติดตอของ grid service ขอแนะนําควรแยกคลาสของจาวาออกเปนคลาสของแตละประเภทของ service data ซึ่งในกรณีนี้แตละ instance ของ SDE ก็คือหนึ่งคลาสของจาวา และแตละคุณสมบัติมีความสัมพันธกับ service data ที่มีการเขาถึงฟงกชัน ซึ่งเรียกวา getters และ setters ในสวนของโปรแกรมสามารถสรางจาก service data description ซึ่งระบุเปนเอกสาร XML โดยนําเขาไปในรายละเอียด GWSDL ของ grid service 3.3 กลไกจัดการวงจรชีวิต (Life Cycle Management) เปนความจริงทางธรรมชาติที่กลาวไววาสรรพสิ่งนั้นมีทุกขัง อนิจจัง และอนัตตา หรือเราจะเรียกไดวา สรรพสิ่งมีวัฏจักรหรือวงจรชีวิต (Life cycle) ของมัน ดังนั้น Grid service จึงควรจะมี Life cycle ไดเชนกัน ซึ่ง Life cycle ในที่นี้ก็คือ สถานะตั้งแต Grid service เกิดจนกระทั่ง Grid service ตาย โดย Grid service มีชวงชีวิต ทํางานชวงหนึ่งอยูที่ container ซึ่งในทางปฏิบัติจริงนั้น container ก็เปนเสมือน application server สําหรับรันการ ทํางานของ Grid service และจัดเตรียมสภาพแวดลอมพื้นฐานใหกับ Grid service (อยางเชน จัดเตรียมโปรโตคอล สําหรับการติดตอสื่อสาร หรือจัดเตรียมกลไกรักษาความปลอดภัย เปนตน) กลไก Life cycle management เปนกลไกที่สําคัญมากในระบบที่มีสภาพแวดลอมที่ตองการความคงทน สูง (Robust environment) อาทิเชน Grid service สามารถดําเนินงานไดตอเนื่องหลังจากที่ container ทํางาน ลมเหลว เปนตน กลไก Life cycle management จะตองมีวิธีการที่สามารถบงบอกไดวาในแตละชวงเวลานั้น Grid service กําลังอยูในสถานะใด และถาหาก Grid service ตองการความคงทนตอสภาพแวดลอมที่ไมแนนอน (unreliable) ไดนั้น Grid service ตองมีวิธีการในการบันทึกสถานะในแตละชวงเวลาไดหรือกลาวไดวาเปนการทํา checkpoint ซึ่งเมื่อไหรก็ตามที่สภาวะแวดลอมของ Grid service ลมเหลว (อยางเชน container ทํางานลมเหลว เปนตน) Grid service ก็จะดึงสถานะที่ไดเคยบันทึกไวขึ้นมาใชงานตอไป ซึ่งดวยวิธีเหลานี้ก็จะทําให Grid service สามารถทํางานไดอยางตอเนื่องจากงานเดิมได

17

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

วงจรชีวตหรือ Life cycle ของ Grid service แบงออกเปน 5 สถานะดวยกัน ดังนี้ • preCreate – เปนสถานะที่เกิดขึ้นในขณะที่มีกระบวนการสราง instance ของ Grid service ขึ้นมาที่ container • postCreate – เปนสถานะหลังจากที่ instance ของ Grid service เพิ่งถูกสรางเสร็จสิ้น • activate – เปนสถานะที่ Grid service กําลังทํางานหรือกําลังใหบริการ หรือกลาวไดวาเปนสถานะที่ Grid service ถูกโหลดขึ้นไปที่หนวยความจําเพื่อทํางาน • deactivate – เปนสถานะที่ Grid service หยุดการทํางาน หรือออกจากหนวยความจํา • preDestroy – เปนสถานะกอนที่ Grid service จะถูกทําลายหรือหมดชวงชีวิต (ตาย) 3.4 กลไกการแจงขาว (Notification) Notification หรือกลไกการแจงขาว เปนกลไกที่ทําหนาที่ในการสดับรับฟงเหตุการณที่สนใจ และเมื่อไหรก็ตามที่ เหตุการณนั้นเกิดขึ้นหรือมีการเปลี่ยนแปลงในเหตุการณนั้นแลว กลไกจะทําการแจงขาวนี้ไปใหกับผูที่สนใจ โดย เราจะเรียกกลุมของผูที่สนใจขาวหรือเหตุการณการวา Notification sink (ผูสนใจขาว) และเราจะเรียกผูที่สรางขาว หรือเหตุการณวา Notification source (แหลงขาว) อยางที่ไดกลาวมาในหัวขอกอนหนานี้แลววา Grid service จัดเตรียมกลไกอยาง Service Data Element (SDE) สําหรับจัดเก็บขอมูลของ Grid service ซึ่งเราสามารถนํากลไก Notification ไปดักจับเหตุการณหรือความ เปลี่ยนแปลงของขอมูลใน SDE ได

รูปที่ 3.2 กระบวนการทั้ง 5 ของ Notification

18

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

จากรูปที่ 3.2 ดานบนนี้ แสดงใหเห็นถึงกระบวนการของกลไก Notification ซึ่งการทํา Notification จะประกอบ ไปดวยกลุมของผูที่สนใจเหตุการณหรือขาว และเราจะเรียกกลุมนี้วา Notification sink ซึ่งอาจจะเปนโปรแกรม ทางฝง client หรืออาจจะเปน Grid service ก็ได โดยกลุมผูสนใจเหตุการณตองสมัครเขาใชบริการ Notification จาก Grid service ที่มีเหตุการณหรือขอมูลที่สนใจ และเราเรียก Grid service นี้วา Notification source โดย Notification source จะติดตอไปที่บริการหนึ่งที่เรียกวา Subscription Management เพื่อสราง Subscription Manager คืนไปที่ Notification sink โดย Subscription Manager จะมีหนาที่ในการจัดการรับขาวหรือเหตุการณที่ เกิดขึ้นจาก Notification source และเมื่อไหรก็ตามที่มีเหตุการณที่มีผูสนใจเกิดขึ้น ฝง Notification source จะทํา การแจงขาวกลับไปที่ Notification sink สรุปขั้นตอนของ Notification ทั้ง 5 ขั้นตอนตามที่แสดงไวในรูปที่ 3.2 ไดดังนี้ 1. โปรแกรม (หรืออาจจะเปน Grid service) ใดก็ตามที่ตองการรับรูเหตุการณใดๆที่เกิดกับ Grid service อื่นๆ โปรแกรมนั้นจะตองสมัครขอใชกลไก Notification (Notification subscription) ไปยัง Grid service ที่มีเหตุการณหรือขอมูลที่สนใจ 2. Grid service ที่มีผูขอรับฟงเหตุการณ จะติดตอไปที่บริการที่ชื่อ Subscription Management เพื่อขอ instance ของการจัดการ Notification ที่ชื่อ Subscription Manager 3. Grid service สง Subscription Manager กลับไปที่โปรแกรมที่สนใจเหตุการณ 4. ฝง Notification sink สามารถใช Subscription Manager ในการตรวจดูชวงเวลา (Lifetime) ของการ รับฟงเหตุการณไดวาเปนเวลาเทาไหรแลว ซึ่งถาหากเวลานี้เกินชวงเวลาที่ Notification sink สามารถรอได มันก็สามารถยกเลิกการรับฟงเหตุการณนี้ได 5. เมื่อไหรก็ตามที่มีเหตุการณที่โปรแกรมสนใจเกิดขึ้นที่ Grid service กลไก Notification จะสั่งให Notification source สงขอความแจงไปที่ Notification sink จากนั้นโปรแกรมที่สนใจเหตุการณ อาจจะมีการเรียก method หรือฟงกชันการทํางานบางอยางขึ้นเพื่อรองรับสถานการณที่เกิดจาก เหตุการณเหลานั้นได

19

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

บทที่ 4 การพัฒนา Grid service ในบทนี้ เราจะกลาวถึงการพัฒนาGrid service โดยการพัฒนาGrid serviceของเรานั้นจะตั้งอยูของ OGSI สําหรับการพัฒนาโดยJava แตอยางไรก็ตาม Globus Toolkit 3 ไดจัดเตรียม OGSI.NET ซึ่งเปน OGSI สําหรับการ พัฒนาโดย .NET Framework แตสําหรับในหนังสือเลมนี้ เราจะไมกลาวถึงการพัฒนาดวยวิธีดังกลาว สําหรับหัวขอยอยในบทนี้ เราจะเริ่มตนดวยการอธิบายถึงขั้นตอนเบื้องตนในการเขียนโปรแกรมใหเปน Grid service ตอจากนั้นเราจะกลาวถึงการ deploy เอา Grid service ไปติดตั้งที่ container โดยเราเนนวิธีการลงมือ ปฏิบัติจริงเปนหลัก โดยเราจะยกตัวอยาง Grid service ที่มีชื่อวา Math Service ที่ใหบริการ operation ที่ชื่อ add ซึง่ เปนฟงกชันเหมือนกับ counter ที่ทําหนาที่ในการสะสมคา อยางไรก็ตาม ในบทนี้เราจะไมกลาวถึงวิธีการติดตั้งชุด โปรแกรมพื้นฐานสําหรับการพัฒนาโปรแกรมไวในบทนี้ ซึ่งทานผูอานสามารถเขาไปดูเนื้อหาเหลานี้ไดใน Appendix สําหรับหัวขอยอยสุดทายที่เราจะกลาวถึงคือการรัน Math service ที่ได deploy แลว และการเรียก โปรแกรมฝง client ใหไปใชบริการ Math service 4.1 ขั้นตอนพื้นฐานสําหรับเขียนโปรแกรมใหเปน Grid service ขั้นตอนพื้นฐานสําหรับเขียนโปรแกรมใหเปน Grid service มีดังตอไปนี้ 1. ออกแบบ interface ของ Grid service 2. สรางไฟล WSDL 3. ตกแตง WSDL ใหเปน GSDL 4. สรางโคด stubs จาก GSDL 5. สรางโคดการทํางานใหกับ Grid service 6. สรางโปรแกรมฝง client 4.1.1 ออกแบบ interface ของ Grid service ในขั้นตอนนี้ เปนการออกแบบ interface ของ Grid service ซึ่ง interface นั้นเปรียบเสมือนโครงสรางหรือ พิมพเขียวของ Grid service โดยอธิบายถึง method หรือ operation ที่ Grid service ใหบริการ แตทวาไมไดลง รายละเอียดลงไปวาการทํางานของ operation เปนเชนไร สําหรับ interface ของ Math Service นั้นมีโครงสรางดังนี้ package com.hpcnc.gridservice.math; public interface Math { public double add(double in0); }

20

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

เราใหชื่อ interface ของ Grid service คือ Math โดย Math มี operation ชื่อ add ซึ่งเราตั้งใจวาจะใหผูใชบริการนี้ใส parameter มาหนึ่งตัว (ผาน in0) แลวคาที่ใสเขาไปจะไปรวมกับคาเดิมของ Math อีกทีหนึ่ง ซึ่งทานผูอานจะเห็น ภาพชัดเจนยิ่งขึ้นใน 4.1.5 4.1.2 สรางไฟล WSDL อยางที่เราทราบแลววา WSDL เปนขอความที่ใชอธิบายการใชบริการ ซึ่งนับวาเปนสวนที่จําเปนสําหรับ การทําให Grid service (หรือ Web service) นั้นถูกใชงานไดอยางถูกตอง โดยวิธีในการสรางไฟล WSDL นั้น เรา อาจจะทําไดดวยตนเองผาน editor ใดๆก็ได แตถาหากวาเรามี interface อยูแลว (ที่ไดทําใน 4.1.1) การสราง WSDL ก็จะทําไดสะดวกและรวดเร็วยิ่งขึ้น เพราะวา Globus Toolkit 3 ไดจัดเตรียมเครื่องมือสําหรับการสราง WSDL โดยอิงตาม interface ที่ไดสรางไวแลว Globus Toolkit 3 ไดจัดเตรียมชุดของคลาสที่ชื่อวา Apache AXIS (ขอเรียกสั้นๆวา AXIS) โดย AXIS เปน SOAP Implementation และไดจัดเตรียมคลาสสําหรับการเขียนโปรแกรมแบบ Web service ไวอยางมาก ทีเดียว และยังไดจัดเตรียมคลาสที่ชื่อ Java2WSDL ซึ่งเปนคลาสที่ใชในการแปลง interface (ที่เขียนโดยภาษา Java) ไปเปนไฟลเอกสาร WSDL วิธีการใช Java2WSDL มีรูปแบบดังนี้ java org.apache.axis.wsdl.Java2WSDL [options] [Java interface]

ขอยกตัวอยาง จากการสราง WSDL โดยใช Java2WSDL โดยอางอิงตาม interface ที่ชื่อ Math ของเรา java org.apache.axis.wsdl.Java2WSDL -S Math -P MathPortType -o schema/math/math.wsdl -l "http://localhost:8080/ogsa/services/Math" -n "http://math.gridservice.hpcnc.com/stubs" com.hpcnc.gridservice.math.Math

จากตัวอยางการใช Java2WSDL ทานจะเห็นวามี option เพิ่มเติมเขามา 4 options ดวยกัน โดยแตละ option มี รายละเอียด ดังนี้ - S ระบุชื่อของ Grid service - P ระบุชื่อ Port type (Port type เปนหลักการของ Web service โดย Port type ก็คือ interface ที่ไดออกแบบไว แตถูกดัดแปลงใหใชไดกับการติดตอสื่อสารผานเครือขาย) - o ระบุไฟล WSDL ที่ตองการสราง - n ระบุ namespace ของ stubs ที่จะเกิดขึ้นในขั้นตอน 4.1.4

21

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

4.1.3 ตกแตง WSDL ใหเปน GSDL ขั้นตอนนี้เปนการสรางไฟล GSDL (Grid WSDL) โดยไฟลนี้เกิดจากการนํา WSDL ที่ไดจาก 4.1.2 มา แกไข ซึ่งเราอาจจะแกไขดวยตัวเอง แตวา Globus Toolkit 3 ไดจัดเตรียมคลาสชวยเหลือที่ชื่อ DecorateWSDL ซึ่ง คลาสนี้มีกลไกงายๆคือ คลาสนี้จะดึงเอา schema จากไฟลที่ชื่อ ogsi_bindings.wsdl มาแทรกไวในไฟล WSDL นั่นเอง วิธีการใช DecorateWSDL สามารถทําได ดังนี้ java org.globus.ogsa.tools.wsdl.DecorateWSDL [ogsi_bindings location] [WSDL file]

ขอยกตัวอยาง จากการสราง GSDL โดยใช DecorateWSDL โดยอางอิงตาม math.wsdl ของเรา java org.globus.ogsa.tools.wsdl.DecorateWSDL schema/ogsi_bindings.wsdl schema/math/math.wsdl

หลังจากเรียก DecorateWSDL แลว ไฟล math.wsdl จะถูกปรับแตงใหมใหเปนไฟล GSDL 4.1.4 สรางโคด stubs จาก GSDL หลังจากเราได GSDL ขั้นตอนนี้ก็จะเปนการสราง stubs โดยอิงจากไฟล GSDL โดย stubs ก็คือ กลุม ของคลาสที่มีหนาที่เสมือนคลาสตัวกลางที่ชวยในการสราง SOAP message (ซึ่งมีทั้ง SOAP request และ SOAP response) และทําหนาที่ในการติดตอสื่อสรางผานโปรแกรม SOAP โดย Globus Toolkit 3 ไดจัดเตรียมคลาสที่ชื่อ GSDL2Java สําหรับสราง stubs จาก GSDL ซึ่งวิธีการใช GSDL2Java มีรูปแบบดังนี้ java org.globus.ogsa.tools.wsdl.GSDL2Java [GSDL file]

สําหรับตัวอยางการเรียกใช GSDL2Java โดยสรางจากไฟล math.wsdl ทําไดดังนี้ java org.globus.ogsa.tools.wsdl.GSDL2Java schema/math/math.wsdl

22

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

หลังจากเรียกคําสั่งนี้แลว จะไดกลุมของคลาส stubs ซึ่งเก็บใน com.hpcnc.gridservice.math.stubs ซึ่งที่อยูนี้เปนที่ อยูที่เราไดระบุไวตอนสราง WSDL ในหัวขอ 4.1.2 ในสวนของ option -n โดย source code ของคลาส stubs ที่ เกิดขึ้นนั้น มีดังนี้ MathGridLocator.java Math.java MathLocator.java MathPortType.java MathSoapBindingStub.java ซึ่ง คลาสทั้ ง 5 ที่เ กิ ด ขึ้ นนี้ คลาสที่ เ ราได ใ ชจ ริ ง ๆในตอนเขี ย นโปรแกรมมี เ พีย ง 2 คลาสเท านั้ น คื อ MathGridLocator และ MathPortType โดยโปรแกรมฝง client เรียกใช MathGridLocator มีหนาที่ในการดึงเอา reference ของ instance ของ Grid service มาใชงาน สวน MathPortType เปนคลาสที่เกิดในขั้นตอนที่เราสราง WSDL (ดูจาก 4.1.2 ตรง option -P) ซึ่งโปรแกรมฝง client จะใชคลาสMathPortType เพื่อรับ reference ที่ไดจาก MathGridLocator 4.1.5 สรางโคดการทํางานใหกับ Grid service หลังจากเราได stubs แลว ขั้นตอนตอมาก็คือ การสรางโคดของการทํางานใหกับ Grid service โดย Grid service จะตองไดรับมรดกจาก MathPortType ที่เกิดในขั้นตอน 4.1.4 ซึ่งมรดกที่ไดก็คือ operation ที่เรากําหนดไว ใน interface ในขั้นตอน 4.1.1 นั่นเอง จากนั้น ใหเราเขียนโคดการทํางานใหกับ operation ที่ไดกําหนดไว (ซึ่งก็คือ operation ที่ชื่อ add นั่นเอง) นอกจากนี้ โคดการทํางานของ Grid service ยังตองรับมรดกจาก GridServiceImpl อีกดวย ซึ่งเปนขอกําหนดพื้นฐานของ OGSI วา Grid service ตองรับมรดกจากคลาสนี้นั่นเอง เราสรางคลาสใหมที่ชื่อ MathImpl ซึ่งเปนคลาสของการทํางานของ Grid service package com.hpcnc.gridservice.math.stubs; import java.rmi.RemoteException; import org.globus.ogsa.impl.ogsi.GridServiceImpl; public class MathImpl extends GridServiceImpl implements MathPortType { private double results = 0; public MathImpl() { super(); }

23

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

public double add(double in0) throws RemoteException { results += in0; return results; } }

คลาส MathImpl ไดสรางตัวแปรที่ชื่อ results โดยใหคาเริ่มตนเปนศูนย โดยเรามีวัตถุประสงควา ทุกครั้งที่มี โปรแกรมฝง client มาขอใชบริการผานทาง operation ที่ชื่อ add คาของ results จะถูกบวกหรือลบจากคาที่ client ใสเขามาทาง parameter ที่ชื่อ in0 ของ add 4.1.6 สรางโปรแกรมฝง client เราเขียนโปรแกรมทางฝง client เพื่อใหเรียกใชบริการจาก Math service แบบงายๆ ดังตัวอยาง ดังตอไปนี้

package com.hpcnc.gridservice.math.client; import java.net.URL; import org.globus.ogsa.utils.GridServiceFactory; import org.globus.ogsa.wsdl.GSR; import org.gridforum.ogsi.Factory; import org.gridforum.ogsi.GridService; import org.gridforum.ogsi.LocatorType; import org.gridforum.ogsi.OGSIServiceGridLocator; import com.hpcnc.gridservice.math.stubs.MathPortType; import com.hpcnc.gridservice.math.stubs.MathGridLocator; public class MathClient { public static void main(String[] args) throws Exception { URL GSH = new URL("http://127.0.0.1:8080/ogsa/services/Math/MathFactory");

24

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

OGSIServiceGridLocator gl = new OGSIServiceGridLocator(); Factory factory = gl.getFactoryPort(GSH); GridServiceFactory gfact = new GridServiceFactory(factory); LocatorType lt = gfact.createService(); MathGridLocator mathLocator = new MathGridLocator(); MathPortType mathPort = mathLocator.getMath(lt); System.out.println(mathPort.add(10)); System.out.println(mathPort.add(-3)); GridService service = (GridService)gl.getGridServicePort(lt); service.destroy(); } }

จากโคดของ MathClient อธิบายหลักการทํางานไดดังนี้ โคดนี้เปนการะบุที่อยูของ Factory ของ Math service โดยการสรางเปน instance ของ URL URL GSH = new URL("http://127.0.0.1:8080/ogsa/services/Math/MathFactory"); โคดนี้ใชในการรับคา reference ของ Factory ของ Math service ที่อยูใน container OGSIServiceGridLocator gl = new OGSIServiceGridLocator(); Factory factory = gl.getFactoryPort(GSH); GridServiceFactory gfact = new GridServiceFactory(factory); หลังจากได reference ของ Factory แลว เราก็ให Factory สราง instance ของ Math service โดยสิ่งที่คืนมาจากการ สราง Math service ก็คือที่อยูของ Math service ซึ่งอยูในรูปแบบของ LocatorType LocatorType lt = gfact.createService(); คลาส MathGridLocator ใชสําหรับดึงคา reference ของ instance ของ Math service โดย MathGridLocator จะมี method ที่ชื่อ getMath ที่ใชสําหรับดึงคา reference ของ MathPortType (ซึ่งก็คือ reference ของ instance ของ Math service นั่นเอง) โดยการสงคา LocatorType ที่ไดรับมาจากโคดกอนหนานี้ MathGridLocator mathLocator = new MathGridLocator();

25

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

MathPortType mathPort = mathLocator.getMath(lt); สําหรับสองบรรทัดตอไป คือการลองเรียก operation ของ Math service System.out.println(mathPort.add(10)); System.out.println(mathPort.add(-3)); 4.1.7 โครงสรางของไฟลที่ไดจากการเขียนโปรแกรม +---com | \---hpcnc | +---gridservice | | \---math | | | Math.class | | | Math.java | | | | | +---client | | | MathClient.class | | | MathClient.java | | | | | \---stubs | | Math.class | | Math.java | | MathGridLocator.class | | MathGridLocator.java | | MathImpl.class | | MathImpl.java | | MathLocator.class | | MathLocator.java | | MathPortType.class | | MathPortType.java | | MathSoapBindingStub.class | | MathSoapBindingStub.java | | _add.class | | _add.java | | _addResponse.class | | _addResponse.java 26

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

| | +---org | \---gridforum | \---ogsi | _add.class | _add.java | _addResponse.class | _addResponse.java | _createService.class | _createService.java | _createServiceResponse.class | _createServiceResponse.java | _deliverNotification.class | _deliverNotification.java | _destroy.class | _destroy.java | _destroyResponse.class | _destroyResponse.java | _findByHandle.class | _findByHandle.java | _findByHandleResponse.class | _findByHandleResponse.java | _findServiceData.class | _findServiceData.java | _findServiceDataResponse.class | _findServiceDataResponse.java | _remove.class | _remove.java | _removeResponse.class | _removeResponse.java | _requestTerminationAfter.class | _requestTerminationAfter.java | _requestTerminationAfterResponse.class | _requestTerminationAfterResponse.java | _requestTerminationBefore.class | _requestTerminationBefore.java

27

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

| _requestTerminationBeforeResponse.class | _requestTerminationBeforeResponse.java | _setServiceData.class | _setServiceData.java | _setServiceDataResponse.class | _setServiceDataResponse.java | _subscribe.class | _subscribe.java | _subscribeResponse.class | _subscribeResponse.java | +---schema | | ogsi.wsdl | | ogsi_bindings.wsdl | | | \---math | | math.wsdl | | | \---schema | ogsi.wsdl | ogsi_bindings.wsdl จากโครงสรางที่ไดแสดงใหดู ทานอาจสังเกตไดวามีคลาสอยูหลายตัวทีเดียวที่เกิดในระหวางการเขียนโปรแกรม อาธิเชน คลาสที่อยูใน package ชื่อ org.gridforum.ogsi เปนตน โดยคลาสเหลานี้เกิดขึ้นมาในระหวางขั้นตอนการ ทํา GSDL2Java โดยเปนคลาสที่ทาง OGSI ไดกําหนดขึ้นมาสําหรับการพัฒนาโปรแกรมโดยภาษาจาวา นอกจากนี้แลว เรายังตองจัดเตรียมไดเร็กทอรีในสวน schema/ กอนที่จะเขาสูขั้นตอนการ deploy ที่จะ กลาวในหัวขอถัดไป โดยภายใน schema/ นั้นจะเปนที่สําหรับจัดเก็บไฟล WSDL ที่สําคัญๆ และเราตองเตรียม โครงสรางดังที่ไดแสดงไวดานบน สําหรับไฟล ogsi.wsdl และ ogsi_bindings.wsdl นั้นสามารถคัดลอกไดจาก {GLOBUS_LOCATION}/schema/ogsi

28

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

4.2 การ deploy เอา Grid service ไปยัง container Container เปนไดจัดเตรียม runtime environment เพื่อให Grid service สามารถทํางานได โดย Globus Toolkit 3 ไดจัดเตรียม container ที่ชื่อวา Catalina (ซึ่งพัฒนาโดย Apache Software Foundation) แตอยางไรก็ตาม เราสามารถเลือก container ยี่หออื่นๆไดดวย ซึ่งเราจะไมลงรายละเอียดของการใช container รายอื่น ขั้นตอนในการ deploy มีดังตอไปนี้ 1. สรางไฟล WSDD 2. จัดทําแพ็คเก็จ (Packaging) 3. ลงมือ deploy 4.2.1 สรางไฟล WSDD WSDD ยอมาจาก Web Service Deployment Description โดย WSDD เปนไฟล XML ที่อธิบายถึงรายละเอียดใน การ deploy ตัว Grid service ขึ้นไปยัง container ซึ่ง WSDD สามารถถูกสรางไดโดยการใช editor ใดๆสรางขึ้นมา โดยการอธิบายรายละเอียดของ WSDD จะมี parameter อยูหลายตัวดวยกัน ซึ่งเราไมจําเปนตองระบุ parameter บางตัวลงไปในไฟล WSDD ก็ได ทั้งนี้ก็ขึ้นอยูกับวาเราตองการให Grid service ของเราใชความสามารถใดของ Grid service บาง (เชน ตองการมี Notification หรือไม หรือตองการระบุ Service data element หรือเปลา เปนตน) แตในที่นี้ เราจะกลาวถึงการระบุ parameter พื้นฐานของ Grid service เทานั้น WSDD สําหรับการ deploy Grid service มีอยู 2 ชนิด คือ WSDD สําหรับการ deploy Grid service ซึ่ง เปนWSDD และ WSDD สําหรับการ undeploy Grid service สําหรับ WSDD สําหรับการ undeploy จะอธิบายถึง การถอดถอนเอา Grid service ออกมาจาก container WSDD สําหรับการ deploy จะตองบันทึกลงไฟลชื่อ server-deploy.wsdd และสําหรับตัวอยาง Math service เราสามารถเขียน server-deploy.wsdd ออกมาไดดังนี้ <deployment name="defaultServerConfig" xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="Math/MathFactory" provider="Handler" style="wrapped"> <parameter name="name" value="Math Factory"/> <parameter name="instance-name" value="Math Instance"/> <parameter name="instance-schemaPath" value="schema/math/math.wsdl"/> <parameter name="instance-baseClassName" value="com.hpcnc.gridservice.math.stubs.MathImpl"/>

29

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

<parameter name="allowedMethods" value="*"/> <parameter name="persistent" value="true"/> <parameter name="className" value="org.gridforum.ogsi.Factory"/> <parameter name="baseClassName" value="org.globus.ogsa.impl.ogsi.PersistentGridServiceImpl"/> <parameter name="schemaPath" value="schema/ogsi/ogsi_factory_service.wsdl"/> <parameter name="handlerClass" value="org.globus.ogsa.handlers.RPCURIProvider"/> <parameter name="factoryCallback" value="org.globus.ogsa.impl.ogsi.DynamicFactoryCallbackImpl"/> <parameter name="operationProviders" value="org.globus.ogsa.impl.ogsi.FactoryProvider"/>

จาก parameter ที่ระบุลงไปในไฟล server-deploy.wsdd นั้น เฉพาะสวนที่เปนตัวหนังสือแบบหนา คือสวนที่ Grid service อื่นๆสามารถนําไปแกไขได สําหรับสวนอื่นๆใหคงไวเชนเดิม เพราะวา Grid service ทุกๆก็ใชสวนอธิบาย เหลานี้เหมือนกัน สําหรับรายละเอียดในการแกไข parameter แตละตัวถูกอธิบายในยอหนาตอไป Parameter แรกหรือ service name เปน parameter หลักซึ่งบงบอกถึงชื่อของ Factory ซึ่งจะถูกใชตอน deploy Grid service ขึ้นไปยัง container โดยชื่อนี้จะถูกนําไปตอเติมใน GSH ของ Factory โดยในที่นี้เราระบุเปน Math/MathFactory สมมติวา URL ของ OGSA ที่ติดตั้งเขาไปใน container คือ http://localhost:8080/ogsa เราจะสามารถอางอิงถึง URL (หรือ GSH) ของ Factory ไดดังนี้คือ http://localhost:8080/ogsa/services/Math/MathFactory <service name="Math/MathFactory" provider="Handler" style="wrapped">

30

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

Parameter ตอมาคือ “name” เปนตัวที่ใชในการระบุถึงชื่อของ Factory ของ Grid service ซึ่งในที่นี้เราระบุคาเปน Math Factory <parameter name="name" value="Math Factory"/> Parameter “instance-name” เปนตัวใชบอก instance ของ Grid service ซึ่งเราระบุเปน “Math Instance” <parameter name="instance-name" value="Math Instance"/> Parameter “instance-baseClassName” ระบุถึง instance ของคลาสของ Grid service ที่เปนมอบการทํางานของ operation ของ Grid service จากตั ว อย า ง Math service เราระบุ ด ว ยค า com.hpcnc.gridservice.math.stubs.MathImpl <parameter name="instance-baseClassName" value="com.hpcnc.gridservice.math.stubs.MathImpl"/> สําหรับ WSDD ในการ undeploy หรือ server-undeploy.wsdd ของ Math service สามารถเขียนไดดังนี้ <service name="Math/MathFactory" provider="Handler" style="wrapped" />

ไฟล server-undeploy.wsdd ระบุแคเพียง paramenter เดียวคือ service name โดยในที่นี้ เราจะระบุคาเปน Math/MathFactory ซึ่งคานี้จะตองสัมพันธกับ service name ที่เราไดระบุไวใน server-deploy.wsdd 4.2.2 จัดทําแพ็คเก็จ (Packaging) การทําแพ็คเก็จคือการสราง JAR (Java Archive) file กับ GAR (Grid Archive) file ขึ้นมา โดย JAR file จะจัดเก็บ class ของ stubs รวมถึงคลาสการทํางานของ Grid service เอาไว สวน GAR file จะจัดเก็บ JAR file ที่ ไดของคลาส รวมถึง WSDD และ WSDL ไฟลที่เกี่ยวของทั้งหมด เราสามารถทําแพ็คเก็จใหกับ Math service โดยใชเครื่องมือที่ชื่อ jar ซึ่งเปนเครื่องมือที่มากับ Java Development Kit โดยวิธีการใช jar จะเหมือนกับการใช tar ที่ใชกันบน Unix jar cvf math.jar com\hpcnc\gridservice\math\stubs\*.class

31

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

jar cvf math.gar math.jar server-deploy.wsdd server-undeploy.wsdd schema\

คําสั่งแรกคือ การสราง JAR file ของ stubs และคลาสการทํางานของ Math service เราตั้งชื่อ JAR file ไววา math.jar คําสั่งที่สองเปนการสราง GAR file โดยนํา WSDD และ WSDL ที่เราไดสรางเอาไวใสเขาไป โดยเราตั้ง ชื่อ GAR file ไววา math.gar 4.2.3 ลงมือ deploy ขั้นตอนนี้เปนการ deploy Grid service ขึ้นไปยัง container โดย Globus Toolkit 3 ไดเตรียมวิธีการ deploy ผานทางเครื่องมือ Apache Ant โดยหลังจากที่รูปแบบของการ deploy เปนดังนี้

ant deploy –Dgar.name={ที่อยูของ GAR}/{GAR file}

เรา deploy Math service ไดตามคําสั่งดังนี้ ant deploy –Dgar.name=/home/g4665304/MyGridService/math.gar

โดยที่อยูของ GAR คือ /home/g4665304/MyGridService และ GAR file คือ math.gar 4.3 รัน Grid service หลังจากทําการ deploy Grid service ขึ้นไปยัง container แลว เราสามารถรัน container ขึ้นมาทํางานได ดวยเครื่องมือ Ant ที่ {GLOBUS_LOCATION} หรือรัน globus-start-container ที่อยูใน {GLOBUS_LOCATION}/bin ก็ได วิธีการรัน container ดวย Ant จะตองรันที่ {GLOBUS_LOCATION} ซึ่งทําไดดังนี้

ant startContainer

32

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

และหยุด container ดวย ANT ก็ทําที่ {GLOBUS_LOCATION} ไดดังนี้ ant stopContainer

วิธีรัน container อีกวิธีคือ รันที่ {GLOBUS_LOCATION}/bin ซึ่งทําไดดังนี้ ./globus_start_container.sh

และหยุด container ที่ {GLOBUS_LOCATION}/bin ซึ่งทําไดดังนี้ ./globus_stop_container.sh

ในที่นี้เราจะลองเรียกโปรแกรมทางฝง client ขึ้นมาเพื่อเรียกใชบริการ Math service กอนเราตองรัน container ซึ่ง เมื่อเรารัน container แลว ควรจะมีขอความตอไปนี้แสดงขึ้นมา http://127.0.0.1:8080/ogsa/services/core/admin/AdminService http://127.0.0.1:8080/ogsa/services/core/management/OgsiManagementService http://127.0.0.1:8080/ogsa/services/core/registry/ContainerRegistryService http://127.0.0.1:8080/ogsa/services/core/jmsadapter/JMSAdapterFactoryService http://127.0.0.1:8080/ogsa/services/core/logging/OgsiLoggingManagementService http://127.0.0.1:8080/ogsa/services/core/notification/httpg/NotificationSubscriptionFactoryService http://127.0.0.1:8080/ogsa/services/core/ping/PingService http://127.0.0.1:8080/ogsa/services/Math/MathFactory http://127.0.0.1:8080/ogsa/services/samples/registry/VORegistryService http://127.0.0.1:8080/ogsa/services/samples/counter/notification/CounterService http://127.0.0.1:8080/ogsa/services/samples/counter/notification/CounterFactoryService http://127.0.0.1:8080/ogsa/services/samples/counter/encoded/CounterFactoryService ….

33

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

โดยผลลัพธจากการรัน container แลว ถาหากวา Math service ได deploy ขึ้นไปบน container สําเร็จ ควรจะมี รายชื่อ Math service ปรากฏขึ้นมาในขอความดวย ดังที่บรรทัดที่เปนตัวหนาไดแสดงไว แลวเรารันคลาสฝง client ไดดังนี้ java com.hpcnc.gridservice.math.client.MathClient

ผลลัพธที่ไดควรเปนดังนี้ 10 7

ซึ่งผลลัพธที่นั้นเกิดจากการเรียกใช Math service ที่บรรทัด System.out.println(mathPort.add(10)) System.out.println(mathPort.add(-3)) โดยผลลัพธที่ไดเปนการสะสมคาของ results

กับ

ผลลัพธที่ไดนั้นเปนการสะสมคาไดนั้น เพราะคุณสมบัติ stateful ของ Grid service นั่นเอง ถาหากวา เปน Web service ผลลัพธที่ไดก็จะเปนดังนี้ 10 -3

ที่ Web service ใหผลลัพธแบบไมสะสมคาก็เพราะวา Web service ขาดคุณสมบัติ stateful หรือกลาวอีก นัยหนึ่งคือ Web service จดจําคาแบบ stateless นั่นเอง

34

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

Appendix: การติดตั้งสภาพแวดลอมสําหรับพัฒนา Grid service ติดตั้งบนระบบปฏิบัติการ Linux A.1. Java Development kit Configuration Download : j2sdk-1_4_2_02-linux-i586-rpm.bin จาก http://www.java.sun.com • ทําการติดตั้ง J2SE 1.4.2 ลงในระบบของเรา ล็อกอินเปน root แลวใช command ตอไปนี้ # cd /usr/local/ # mkdir sun- java # cd sun- java # ./ j2sdk-1_4_2_02-linux-i586-rpm.bin # rpm –ivh j2sdk-1_4_2_02-linux-i586-rpm • ทําการปรับ Configure โดยทํา ใน /etc/profile หรือ .bashrc ดังนี้ ล็อกอินเปน root แลวใช command ตอไปนี้ # vi /etc/profile if [ -z “$INPUTRC” –a ! –f “$HOME/.inputrc”]; then INPUTRC=/etc/inputrc fi JAVA_HOME = /usr/local/sun-java/j2sdk1.4.2_02 PATH=$JAVA_HOME/bin:$PATH export JAVA_HOME export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC …(author omits lines) # . /etc/profile สําหรับปญหาที่เคยเกิดขึ้นในการใชงานกริดเซอรวิสคือการเรียกใชงานจากฝง Client มาที่ Server ซึ่งเกิด error เกี่ยวกับ Security ซึ่งเปน error ที่มาจาก rt.jar เมื่อเราใช J2SE 1.4.2_05 ดังนั้นขอแนะนําใหใช J2SE ที่ต่ํากวา 1.4.2_05 อยางเชน 1.4.2_02 และ 1.4.2_03 A.2. Apache Ant Configuration Download : apache-ant-1.6.2-bin.tar.gz จาก http://ant.apache.org • ทําการ Unzip ant ไปยังที่ๆเราตองการ ล็อกอินเปน root แลวใช command ตอไปนี้ # cd /usr/local/ 35

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

# mkdir apache-ant # cd apache-ant # tar –xzvf /apache/apache-ant-1.6.2-bin.tar.gz ตัวอยางผลของการติดตั้ง Apache Ant apache-ant-1.6.2/bin/ant apache-ant-1.6.2/bin/runant.pl apache-ant-1.6.2/bin/antRun apache-ant-1.6.2/bin/runant.py apache-ant-1.6.2/bin/antRun.pl apache-ant-1.6.2/bin/complete-ant-cmd.pl apache-ant-1.6.2/ apache-ant-1.6.2/bin/ apache-ant-1.6.2/lib/ ...(author omits lines) apache-ant-1.6.2/etc/log.xsl apache-ant-1.6.2/LICENSE.xerces apache-ant-1.6.2/KEYS apache-ant-1.6.2/LICENSE.sax apache-ant-1.6.2/LICENSE.dom apache-ant-1.6.2/WHATSNEW apache-ant-1.6.2/welcome.html apache-ant-1.6.2/LICENSE apache-ant-1.6.2/README • ทําการ Configure โดยทําใน /etc/profile หรือ .bashrc ดังนี้ ล็อกอินเปน root แลวใช command ตอไปนี้ # vi /etc/profile if [ -z “$INPUTRC” –a ! –f “$HOME/.inputrc”]; then INPUTRC=/etc/inputrc fi ANT_HOME= /usr/local/apache-ant/ant1.6.1 JAVA_HOME = /usr/local/sun-/java/j2sdk1.4.2_02

36

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

PATH=$JAVA_HOME/bin:$ANT_HOME/bin:$PATH export ANT_HOME export JAVA_HOME export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC …(author omits lines) # . /etc/profile A.3 Core OGSA Configuration Download : core-0.9.tar.gz จาก http://globus.org • ติดตั้ง Globus โดยการแก Unzip file core-0.9.tar.gz ล็อกอินเปน root แลวใช command ตอไปนี้ # mkdir globus # cd globus # tar zxvf core-0.9.tar.gz คําสั่ง ant dist ใขในการติดตั้ง OGSA โดยการ compile จาก source code # cd /home/globus/core-scr/impl/java # ant dist ตัวอยางผลที่ไดจารคําสั่ง ant dist Buildfile: build.xml setenv: [echo] Build environment for OGSA [echo] Flags (Note: If the {property name} is displayed, [echo] then the component is not present) [echo] Property values [echo] debug=true [echo] deprecation=true ...(author omits lines) [copy] Copying 31 files to /home/globus/core-src/impl/java/build/ogsa-3.2/docs [copy] Copying 17 files to /home/globus/core-src/impl/java/build/ogsa-3.2/licenses [copy] Copying 1 file to /home/globus/core-src/impl/java/build/ogsa-3.2 [copy] Copying 1 file to /home/globus/core-src/impl/java/build/ogsa-3.2

37

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

[copy] Copying 1 file to /home/globus/core-src/impl/java/build/ogsa-3.2 [copy] Copying 1 file to /home/globus/core-src/impl/java/build/ogsa-3.2 distJavaDoc: [mkdir] Created dir: /home/globus/core-src/impl/java/build/ogsa-3.2/docs/api [copy] Copying 1525 files to /home/globus/core-src/impl/java/build/ogsa3.2/docs/api dist: BUILD SUCCESSFUL Total time: 7 minutes 18 seconds • จากนั้นใหเรา Set Globus location โดยที่แกที่ /etc/profile หรือ .bashrc ดั งนี้ ล็อกอินเปน root แลวใช command ตอไปนี้ # vi /etc/profile if [ -z “$INPUTRC” –a ! –f “$HOME/.inputrc”]; then INPUTRC=/etc/inputrc fi GLOBUS_LOCATION = /home/globus/core-scr/impl/java/build/ogsa-3.2 ANT_HOME= /usr/local/apache-ant/ant1.6.1 JAVA_HOME = /usr/local/sun-/java/j2sdk1.4.2_02 PATH=$JAVA_HOME/bin:$ANT_HOME/bin:$PATH Export GLOBUS_LOCATION export ANT_HOME export JAVA_HOME export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC …(author omits lines) # . /etc/profile รันคําสั่ง ant setup ใชในการปรับแตง OGSA ใหเขากับระบปปฎิบัติการ # cd $GLOBUS_LOCATION # ant setup ตัวอยางผลที่ไดจากการใชคําสั่ง ant setup Buildfile: build.xml launchers: generateLaunchers: [echo] generating launcher scripts

38

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ Copyright 2003 © High Performance Computing and Networking Center, Thailand

setAbsoluteGlobusLocation: setClasspathScriptPath: generateLauncher: [echo] Creating launcher script globus-service-browser testUnix: generateUnix: [copy] Copying 1 file to /home/g4765412/globus/core-src/impl/java/bin …(author omits lines) setAbsoluteGlobusLocation: setClasspathScriptPath: generateLauncher: [echo] Creating launcher script ogsa-edit-wsdd testUnix: generateUnix: [copy] Copying 1 file to /home/g4765412/globus/core-src/impl/java/bin testWindows: generateWindows: testWindows: generateCoGLaunchersWindows: setup: BUILD SUCCESSFUL Total time: 7 seconds

39