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
บทที่ 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
รูปที่ 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
สําหรับเปาหมายของ 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
รูปที่ 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
บทที่ 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
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
• ความเปนอิสระ (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 หรือใชภายในองคกร
8
เดียวกันมากกวา แต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
ที่ชื่อวา 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
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
• เลเยอรการคนหาบริการ (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
• 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
ในหัวขอถัดไปเราจะกลาวถึงกลไกที่ทําให 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
• 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
บทที่ 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
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
วงจรชีวตหรือ 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
จากรูปที่ 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
บทที่ 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
เราใหชื่อ 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
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
หลังจากเรียกคําสั่งนี้แลว จะไดกลุมของคลาส 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
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
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
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
| |
+---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
| _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
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"/>
29


<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">
30
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
31
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
และหยุด 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
โดยผลลัพธจากการรัน 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
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 ดังนี้
# 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 ไปยังที่ๆเราตองการ
# cd /usr/local/
35
# 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 ดังนี้

# vi /etc/profile
fi
ANT_HOME= /usr/local/apache-ant/ant1.6.1
JAVA_HOME = /usr/local/sun-/java/j2sdk1.4.2_02
36
PATH=$JAVA_HOME/bin:$ANT_HOME/bin:$PATH
export ANT_HOME
export JAVA_HOME
# . /etc/profile
A.3 Core OGSA Configuration

Download : core-0.9.tar.gz จาก http://globus.org
• ติดตั้ง Globus โดยการแก Unzip file core-0.9.tar.gz
# 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
37
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 ดั งนี้
# vi /etc/profile
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
# . /etc/profile
รันคําสั่ง ant setup ใชในการปรับแตง OGSA ใหเขากับระบปปฎิบัติการ

# cd $GLOBUS_LOCATION
# ant setup
ตัวอยางผลที่ไดจากการใชคําสั่ง ant setup
Buildfile: build.xml
launchers:
generateLaunchers:
[echo] generating launcher scripts
38
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
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

Grid Services (In Thai)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Grid Services (In Thai)

Uploaded by

Copyright:

Available Formats

Technical Report: Grid Services แปลและเรียบเรียงโดย ศิวดล ไชยศิริ

Copyright 2003 © High Performance Computing and Networking Center, Thailand

บทที่ 1 สถาปตยกรรมบนฐานของบริการ (Service Oriented Architecture)……………………………………2

องคประกอบที่สําคัญของ Web Service ประกอบไปดวย Web Services Description Language (WSDL)

1.1 อะไรคือ SOA ?

1.2 องคประกอบพื้นฐานของ SOA

รูปที่ 1.1 Elements of the Service Oriented Architecture (SOA)

1.3 Web services คือเทคโนโลยีที่เกิดจากแนวคิด SOA

1.3.1 Web Service Description Language (WSDL)

1.3.1.2 Binding เปนการระบุรายละเอียดเกี่ยวกับการใชโพลโตคอลในการสงผานขอมูลระหวาง Service

รูปที่ 1.2 Relationship of WSDL elements

- Transport เปนการระบุ protocol ที่ใชสําหรับการติดตอสื่อสาร

1.3.1.3 Service Implementation เปนรายละเอียดในการรองขอเพื่อใชงาน Web service ซึ่งประกอบดวย Service

1.3.2 Simple Object Access Protocol (SOAP)

1.3.3 Universal Description, Discovery and Integration (UDDI)

บทนี้กลาวถึงพื้นฐานของGrid service และขอกําหนดสําหรับการสรางGrid service นอกจากนี้แลวเรา

2.1 Grid service บนแนวคิดของ OGSA

“OGSA ใหคําจํากัดความของ Grid service”

“OGSI กําหนดรายละเอียดสําหรับสราง Grid service”

“Globus Toolkit 3 ถูกสรางขึ้นมาโดย OGSI”

ความแตกตางของ OGSA, OGSI และ GT3

2.2 Web service ตนตระกูลของ Grid service

Grid service เปนแอพพลิชันแบบกริดที่ถูกนิยามไวใน OGSA นอกจากนี้แลว OGSA ยังไดกําหนดเทคโนโลยี

การเขาใจสถาปตยกรรมของ Web service จะนําไปสูการเขาใจพื้นฐานในการพัฒนา Grid service ได

เพื่อเปนการเขาใจภาพรวมของ Web service เราจึงขอยกตัวอยางเหตุการณจําลองของระบบที่พัฒนาโดย

รูปที่ 2.1 ตัวอยางของการใชงาน Web service

จากรูปที่ 2.1 แสดงใหเห็นวา พนักงานรานคาเปดโปรแกรมของรานคาซึ่งเปนโปรแกรมที่ทํางานบน

การทํางานของWeb service ที่บรรยายไวในภาพนั้น ทานผูอานคงไดรูวาเปนรูปแบบการทํางานที่งาย

อยางไรก็ตาม Web service ก็ยังมีจุดออนอยู ดังนี้

2.2.1 พื้นฐานการรองขอบริการจาก Web service

อยางไรก็ตาม ขั้นตอนการทํางานของเทคโนโลยี Web service จริงๆนั้นกลับไมใชมีเพียงแคฝง client ทํา

รูปที่ 2.2 ขั้นตอนการทํางานของ Web service

จากภาพขางบนนี้ กลาวถึงขั้นตอนทั้ง 6 ในการรองขอใชบริการWeb service ซึ่งมีดังตอไปนี้

4. ขั้นตอนตอบกลับวิธีการใชงาน Web service

5. ขั้นตอนการเขาถึง Web service เพื่อรับบริการ

6. ขั้นตอนคืนผลลัพธอนั เกิดจากการทํางานของWeb service

จากตัวอยาง URI ขางบนนี้ เปนตัวอยางของWeb serviceที่ชื่อ WeatherService ซึ่งทานผูอานสามารถ

2.2.3 สถาปตยกรรมของ Web service

สถาปตยกรรมของWeb service ถูกบรรยายเปนลําดับชั้นหรือเลเยอร (layer) ไดจากภาพตอไปนี้

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

• เลเยอรการใหรายละเอียดบริการ (Service Description Layer)

• เลเยอรการรองขอใชบริการ (Service Invocation Layer)

• เลเยอรการรับสงขอมูล (Transport Layer)

2.3 Enter Grid Services: กาวเขาสูยุคของ Grid Service

อยางไรก็ตาม Web service ก็ยังมีขอจํากัดอยู อยางที่ไดกลาวไวแลวในขางตน ซึ่งถาจะวากันจริงๆแลว

ความแตกตางอันเดนชัดระหวาง Web service กับ Grid service และนับวาเปนขอดอยของ Web service

• Web service ใหบริการแบบ non-transient

• Grid service ใหบริการแบบ stateful

• Grid service ใหบริการแบบ transient

2.3.1 Factory: โรงงานสําหรับผลิตและทําลาย Grid service

ถาจะวาไปแลว Factory จะมีเพียง instance เดียวเพื่อใชสําหรับสรางหรือทําลาย Grid service ชนิดใด

รูปที่ 2.4 ตัวอยางการใช Factory

2.3.2 กลไกอื่นๆที่ Grid service จัดเตรียมมาให

• Service data เปนกลไกที่เราสามารถกําหนดขอมูลบางอยางใหกับ Grid service เหมือนกับการกําหนด

• Notification เปนกลไกสําหรับการแจงขาว โดยเราสามารถกําหนดให Grid service สามารถเปนตนตอ

2.3.3 การระบุที่อยูของ Grid service ดวย GSH และ GSR

Grid application มีลักษณะที่พิเศษ โดยไดจัดเตรียมกลไกสําหรับการพัฒนา Grid service ดังนี้คือ

3.1 กลไกสรางและทําลาย Grid service (Grid service Factory)

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

Service data คือการรวบรวมโครงสรางขอมูลโดยมีความสัมพันธกับสถานะของขอมูลใน instance

3.3 กลไกจัดการวงจรชีวิต (Life Cycle Management)

เปนความจริงทางธรรมชาติที่กลาวไววาสรรพสิ่งนั้นมีทุกขัง อนิจจัง และอนัตตา หรือเราจะเรียกไดวา

กลไก Life cycle management เปนกลไกที่สําคัญมากในระบบที่มีสภาพแวดลอมที่ตองการความคงทน

วงจรชีวตหรือ Life cycle ของ Grid service แบงออกเปน 5 สถานะดวยกัน ดังนี้