grid services (in thai)

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

1

สารบัญ บทท่ี 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


2

บทท่ี 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 ที่ตองการ


3

รูปที่ 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 ได


4

สําหรับเปาหมายของ 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


5

รูปที่ 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


6

บทท่ี 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 คืองานกอสราง สวน


7

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 มีขอดีเหนือกวาเทคโนโลยีอื่นๆอยางไร


8

• ความเปนอิสระ (Independency) Web service มีคุณสมบัติไมยึดติดกับแพลตฟอรม (platform-independent) และไมยึดติดกับภาษา (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 หรือใชภายในองคกร


9

เดียวกันมากกวา แต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 ที่ตองการบริการพยากรณอากาศของประเทศไทย


10

ที่ช่ือวา 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 เปนตน


11

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


12

• เลเยอรการคนหาบริการ (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 ซึ่งแตละคุณสมบัติอธิบายไดดังน้ี


13

• 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 ได


14

ในหัวขอถัดไปเราจะกลาวถึงกลไกที่ทําให 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


15

• 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


16

บทท่ี 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


17

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 สามารถทํางานไดอยางตอเน่ืองจากงานเดิมได


18

วงจรชีวตหรือ 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


19

จากรูปที่ 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 หรือฟงกชันการทํางานบางอยางขึ้นเพ่ือรองรับสถานการณที่เกิดจากเหตุการณเหลาน้ันได


20

บทท่ี 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); }


21

เราใหช่ือ 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


22

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


23

หลังจากเรียกคําสั่งน้ีแลว จะไดกลุมของคลาส 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(); }


24

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");


25

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();


28

| _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


29

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 ออกมาไดดังน้ี

<?xml version="1.0"?> <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"/>

30

 <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"/> </service> </deployment>

จาก 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">


31

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 สามารถเขียนไดดังน้ี

<?xml version="1.0" encoding="UTF-8" ?> <undeployment 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" /> </undeployment>

ไฟล 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


32

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


33

และหยุด 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 ….


34

โดยผลลัพธจากการรัน 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 น่ันเอง


35

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/


36

# 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


37

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


38

[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


39

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

grid services (in thai)

Documents