Introduction to Grid Services (of Globus Toolkit 3), but it is deprecated since Globus Toolkit 4
This document is presented in Thai language
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
ในบทน้ีจะกลาวถึง 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 ที่ตองการ
รูปที่ 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 ได
สําหรับเปาหมายของ 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
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
บทน้ีกลาวถึงพ้ืนฐานของ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 วาตองมีและควรมีอะไรบาง รวมถึงเทคโนโลยีที่ประกอบขึ้นมาเปนกริดเวอรซิส
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 มีขอดีเหนือกวาเทคโนโลยีอื่นๆอยางไร
• ความเปนอิสระ (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 หรือใชภายในองคกร
เดียวกันมากกวา แต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 ที่ตองการบริการพยากรณอากาศของประเทศไทย
ที่ช่ือวา 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 เปนตน
ในระบบเครือขายน้ันประกอบไปดวยทรัพยากรตางๆมากมาย การที่เราจะอางอิงถึงทรัพยากรที่เราตองการน้ัน ระบบจําเปนตองมอบหมายที่อยูที่เปนเอกลักษณใหแกทรัพยากรแตละตัว ซึ่งวิธีการอางอิงถึงที่อยูของทรัพยากรท่ีเราใชกันอยางกวางขวางน้ัน เราจะใชวิธีการอางอิงที่เรียกวา 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) ไดจากภาพตอไปน้ี
• เลเยอรการคนหาบริการ (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 ซึ่งแตละคุณสมบัติอธิบายไดดังน้ี
• 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 ได
• 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
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 สามารถทํางานไดอยางตอเน่ืองจากงานเดิมได
สําหรับหัวขอยอยในบทน้ี เราจะเริ่มตนดวยการอธิบายถึงขั้นตอนเบื้องตนในการเขียนโปรแกรมใหเปน 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 มีดังตอไปน้ี
จากตัวอยางการใช 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
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();
Parameter “instance-baseClassName” ระบุถึง instance ของคลาสของ Grid service ที่เปนมอบการทํางานของ operation ของ Grid service จากตัวอยาง Math service เราระบุดวยคา com.hpcnc.gridservice.math.stubs.MathImpl
ไฟล 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
โดยผลลัพธจากการรัน 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 น่ันเอง
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