อเล็กซานเดอร์ คาชานอฟ
แนวคิดของบริการบนเว็บได้รับการพัฒนาโดยยักษ์ใหญ่ในอุตสาหกรรมคอมพิวเตอร์เช่น Sun, Oracle, HP, Microsoft และ IBM แนวคิดนี้ไม่ใช่เรื่องใหม่ แต่เป็นก้าวสำคัญในการทำให้โปรแกรมต่างๆ เข้าถึงได้ง่ายขึ้นผ่านทางเว็บ ตามรูปแบบการสื่อสารมาตรฐาน โดยทั่วไป บริการบนเว็บสามารถเปลี่ยนความเข้าใจของเราเกี่ยวกับวิธีการสร้างเว็บไซต์
บริการเว็บคืออะไร?
ด้วยบริการบนเว็บ ฟังก์ชันต่างๆ ของโปรแกรมต่างๆ สามารถใช้งานได้ทางอินเทอร์เน็ต ดังนั้น โปรแกรมต่างๆ เช่น PHP, ASP, สคริปต์ JSP, JavaBeans, ออบเจ็กต์ COM และเครื่องมือการเขียนโปรแกรมอื่นๆ ที่เราชื่นชอบทั้งหมดสามารถเข้าถึงบางโปรแกรมที่ทำงานบนเซิร์ฟเวอร์อื่น (เช่น บริการเว็บ) และใช้การตอบสนองที่ได้รับจากเธอบนเว็บไซต์หรือแอปพลิเคชันของเธอ
สมมติว่าถ้าฉันจำเป็นต้องทำงานด้านการเขียนโปรแกรมและฉันยุ่งเกินไป (หรือคิดไม่ออกว่าจะประดิษฐ์วงล้อใหม่ด้วยตัวเอง) ฉันสามารถใช้บริการของบริการเว็บที่ไซต์ของฉันจะเข้าถึงผ่านอินเทอร์เน็ตได้ เมื่อส่งคำขอพร้อมพารามิเตอร์ไปยังบริการบนเว็บ ฉันคาดว่าจะได้รับการตอบกลับซึ่งจะประกอบด้วยผลลัพธ์ของคำขอของฉัน
ใครเคยทำงาน เมื่อเร็วๆ นี้กับ จดหมายร้อนได้พบบริการบนเว็บบางอย่างแล้ว: ระบบยืนยันตัวตนผู้ใช้ Passport เป็นหนึ่งในบริการที่รวมอยู่ในโครงการริเริ่ม Microsoft .NET ในขณะที่มีให้ใช้งานฟรี เพื่อให้ผู้สร้างเว็บไซต์สามารถใช้การรับรองความถูกต้องของผู้ใช้บนไซต์ของตนได้อย่างง่ายดาย
พื้นฐาน
หลักการเบื้องหลังบริการเว็บนั้นเรียบง่ายอย่างน่าทึ่ง และพวกเขาไม่ได้เพิ่มอะไรใหม่ให้กับโลกของการประมวลผลแบบกระจายและอินเทอร์เน็ต:
- ผู้รับผิดชอบบริการเว็บกำหนดรูปแบบคำขอไปยังบริการเว็บของตนและการตอบสนอง
- คอมพิวเตอร์ทุกเครื่องในเครือข่ายส่งคำขอไปยังบริการเว็บ
- บริการเว็บประมวลผลคำขอ ดำเนินการบางอย่าง แล้วส่งการตอบกลับ
การดำเนินการนี้อาจเป็นเช่น การแสดงราคาหุ้น การแสดงราคาของผลิตภัณฑ์เฉพาะ บันทึกรายการปฏิทินนัดหมาย แปลข้อความจากภาษาหนึ่งเป็นอีกภาษาหนึ่ง หรือตรวจสอบหมายเลขบัตรเครดิต
มาตรฐานที่แกนกลาง
เหตุผลที่เราทุกคนสนใจในบริการบนเว็บอย่างกระทันหันก็เพราะพวกเขาใช้มาตรฐาน โปรโตคอลแบบเปิดสำหรับการแลกเปลี่ยนและส่งข้อมูล
ก่อนหน้านี้ หลายๆ บริษัทได้พัฒนามาตรฐานและรูปแบบที่เป็นกรรมสิทธิ์ของตนเอง และตอนนี้ ในการทำงาน เราเพียงต้องรู้ XML (eXtensible Markup Language) อย่างง่าย ซึ่งส่งผ่านโปรโตคอล HTTP เดิมที่คุ้นเคย ซึ่งหมายความว่าทุกคนสามารถเข้าถึงข้อมูลเกี่ยวกับวิธีการทำงานของบริการเว็บได้ และนักพัฒนาเว็บที่คุ้นเคยกับเทคโนโลยีเหล่านี้ตามอาชีพสามารถเริ่มเล่นบริการเว็บได้แล้ววันนี้
ความแตกต่างระหว่างบริการบนเว็บและเทคโนโลยีอื่นๆ ที่นักพัฒนาพบ (เช่น DCOM, NamedPipe - Name Pipe, RMI) คือบริการบนเว็บนั้นอิงตามมาตรฐานเปิด เรียนรู้ได้ง่าย และมาตรฐานเหล่านี้ได้รับการสนับสนุนอย่างกว้างขวางบน แพลตฟอร์ม Unix และ Windows ทั้งหมด
Simple Object Access Protocol (SOAP) เป็นโปรโตคอลมาตรฐานที่พัฒนาโดย W3C กำหนดรูปแบบการร้องขอบริการเว็บ
ข้อความระหว่างบริการเว็บและผู้ใช้จะถูกบรรจุลงในซองจดหมาย SOAP (ซองจดหมาย SOAP) ข้อความมีทั้งคำขอให้ดำเนินการบางอย่าง หรือการตอบสนอง - ผลลัพธ์ของการดำเนินการนี้ ซองจดหมายและเนื้อหาถูกเข้ารหัสด้วย XML และค่อนข้างเข้าใจง่าย นี่คือลักษณะของคำขอ SOAP อย่างง่าย ซึ่งส่งผ่าน HTTP ไปยังบริการบนเว็บ:
xmlns:m="http://www.somesite.com/postcode">
องค์ประกอบหลักของซองจดหมาย SOAP นั้นง่ายต่อการจดจำ: นี่คือพารามิเตอร์สองตัว (
และคำตอบจะมีลักษณะดังนี้:
xmlns:m="http://www.somesite.com/postcode">
ข้อความนี้ยิ่งง่ายต่อการถอดรหัส องค์ประกอบ
ตอนนี้เกี่ยวกับ UDDI
แม้จะมีความเรียบง่ายของโปรโตคอล SOAP แต่ก็ยังมีการใช้เพียงเล็กน้อยในบริการเว็บหากเราไม่สามารถค้นหาได้ โชคดีที่ IBM, Microsoft และ Ariba ได้ริเริ่มและสร้างโครงการ Universal Description, Discovery and Integration (UDDI) ซึ่งพวกเขาหวังว่าจะกลายเป็นแค็ตตาล็อกทั่วไปของบริการเว็บทั้งหมดบนเว็บ
ระบบ UDDI ช่วยให้บริษัทสามารถเปิดเผยบริการเว็บของตนสู่สาธารณะได้ ไดเร็กทอรีนี้ทำงานเหมือนสมุดโทรศัพท์ของบริการบนเว็บทั้งหมด การลงทะเบียนในไดเร็กทอรี UDDI นั้นไม่มีค่าใช้จ่าย และผู้ก่อตั้งโปรเจกต์หวังว่าไดเร็กทอรีนี้จะมีคำอธิบายของบริการแบบ all-all-all ทั่วทั้งเว็บ เพื่อให้ไดเร็กทอรี UDDI เพียงไดเร็กทอรีเดียวก็เพียงพอที่จะค้นหาบริการบนเว็บที่ต้องการ
วิธีการทำงานทั้งหมด
ฉันจะค้นหาบริการเว็บที่เหมาะสมได้อย่างไร
สมมติว่าฉันเป็นนักพัฒนาเว็บไซต์และลูกค้าขอให้ฉันเพิ่มเว็บไซต์ คุณลักษณะใหม่: ต้องเพิ่มการตรวจสอบรหัสไปรษณีย์ในแบบฟอร์มการลงทะเบียน
ในการดำเนินการตรวจสอบนี้ ฉันต้องสร้างฐานข้อมูลรหัสไปรษณีย์ทั้งหมดของทั้ง 30 ประเทศที่บริษัทของเราทำธุรกิจ จากนั้นตรวจสอบว่ารหัสไปรษณีย์ตรงกับเมืองที่ระบุในการลงทะเบียนระหว่างการลงทะเบียน แต่ฉันไม่มีข้อมูลนี้ และฉันคิดว่าการรวบรวมข้อมูลดังกล่าวจะต้องใช้เงินจำนวนมาก
แทนที่จะออกไปซื้อฐานข้อมูล เขียนโค้ดของตัวเอง ตรวจสอบให้แน่ใจว่าข้อมูลทั้งหมดสอดคล้องและถูกต้อง และแก้ไขสคริปต์ ฉันแค่ไปที่ไดเร็กทอรี UDDI และมองหาบริการเว็บที่สามารถทำงานให้ฉันได้ . เมื่อมาถึง http://www.uddi.org/ ฉันทำการค้นหาและพบบริการที่ยอดเยี่ยมจาก XYZ Corp.
ฉันตรวจสอบคำจำกัดความของรูปแบบบริการเว็บอย่างละเอียด (คำจำกัดความเขียนด้วย WSDL (Web Services Description Language)) ตรวจสอบให้แน่ใจว่าบริการทำในสิ่งที่ฉันต้องการ จากนั้นฉันถามเพื่อนร่วมงานเกี่ยวกับชื่อเสียงของ XYZ Corp. ฉันพบว่า มั่นคง จากนั้นฉันติดต่อ XYZ Corp. เพื่อสอบถามราคา หากราคาสำหรับการเข้าถึงบริการอยู่ในงบประมาณของฉัน ฉันจะเขียนหน้า JSP ง่ายๆ สำหรับไซต์ของฉันที่เรียกใช้บริการเว็บของ XYZ Corp และเดี๋ยวก่อน การชำระเงินทันทีจะปรากฏบน เว็บไซต์. รหัสไปรษณีย์.
ใช้เวลาให้คุ้มค่า
แม้ว่าคุณจะไม่มีอะไรเกี่ยวข้องกับเทคโนโลยีการเขียนโปรแกรมหรือการพัฒนาเว็บไซต์ แต่บริการบนเว็บก็คุ้มค่าที่จะเรียนรู้เพิ่มเติม ลองนึกภาพว่าคุณกำลังพูดคุยเรื่องเว็บไซต์ใหม่กับลูกค้า พูดถึงการทำงานทั้งหมดของโครงการใหม่อย่างไร ทุกอย่างเป็นไปได้ด้วยดี: งบประมาณเป็นไปตามความคาดหวังของลูกค้า เขาชอบเค้าโครงของแผนไซต์ เขาชอบตัวอย่างอินเทอร์เฟซ ทุกอย่างดูเหมือนจะทำงาน
และทันใดนั้นพวกเขาก็จำฟังก์ชันที่ซับซ้อนมากได้ เพียงแค่พูดถึงมัน ใบหน้าของนักพัฒนาเว็บของคุณเปลี่ยนเป็นสีเขียว และตัวเขาเองก็เริ่มสำลักไอ นี่คือนักพัฒนาที่ส่งสัญญาณให้คุณทราบว่าการพัฒนาคุณลักษณะนี้จะต้องใช้เงินและเวลาจำนวนมาก หรือเป็นไปไม่ได้ด้วยงบประมาณดังกล่าว
เลิกกลัว! ฉันพนันได้เลยว่ามีบริการเว็บบนเว็บที่พร้อมให้ฟังก์ชันที่จำเป็นแก่คุณ และค่าใช้จ่ายในการใช้บริการเว็บนี้จะต่ำกว่าต้นทุนในการพัฒนาอะนาล็อกด้วยตัวเองมาก ดังนั้น คุณจึงช่วยนักพัฒนาซอฟต์แวร์ของคุณจากเรื่องน่าปวดหัวที่ไม่จำเป็น ไคลเอ็นต์ของคุณไม่ต้องจาก ของเสียเงินเพียงแค่ใช้เวลาสองสามนาทีในการเรียกดูแคตตาล็อก UDDI
การพัฒนาบริการ
แน่นอน นักพัฒนาไม่จำเป็นต้องชำระเพียงบริการเว็บที่สร้างโดยผู้อื่น ด้วยความช่วยเหลือจากหนึ่งในชุดเครื่องมือต่อไปนี้ คุณสามารถสร้างบริการเว็บของคุณเองและให้บริการแก่ผู้อาศัยในเครือข่ายคนอื่นๆ
ทางเลือกของเครื่องมือในการพัฒนาบริการเว็บมีมากมาย ประกอบด้วยชุดเครื่องมือจากบริษัทต่างๆ เช่น Sun (Open Net), Microsoft (.NET), (e-services) และ IBM (Web Services) นอกจากนี้ยังมีกรอบโอเพ่นซอร์ส ตัวอย่างเช่น โครงการโมโนพยายามแทนที่ชุดเครื่องมือ Microsoft .NET โดยจัดหาระบบการคอมไพล์ (คอมไพเลอร์) การดำเนินการโค้ด (รันไทม์) และไลบรารี (ไลบรารี่) เพื่อเรียกใช้บริการเว็บเดียวกันบนทุกแพลตฟอร์ม รวมถึง Unix
แม้จะมีเซิร์ฟเวอร์และเครื่องมือพัฒนาเว็บเซอร์วิสที่หลากหลาย แต่ทั้งหมดก็สนับสนุนโปรโตคอล SOAP, ภาษา XML และระบบ UDDI เดียวกัน
ข้อเสีย
ก่อนที่ฉันจะละทิ้งอาชีพการเป็นโปรแกรมเมอร์และอุทิศตัวให้กับการใช้บริการเว็บ ฉันต้องถามตัวเองว่า "ภาพนี้สีชมพูเกินไป เกิดอะไรขึ้น?" น่าเสียดายที่มีราคาที่ต้องจ่ายสำหรับศักยภาพที่ยอดเยี่ยมของบริการบนเว็บ:
- การใช้ XML เป็นรูปแบบการถ่ายโอนข้อมูลส่งผลให้ข้อความของคุณมีขนาดใหญ่มาก: แท็ก XML เองใช้พื้นที่มาก และสิ่งนี้ทำให้เรามีภาระบางอย่างในการสร้าง ส่ง และตีความข้อความ
- เนื่องจากเราใช้ คอมพิวเตอร์ระยะไกลในการทำหน้าที่บางอย่าง เราพึ่งพาอินเทอร์เน็ตทั้งหมด ซึ่งสร้างลิงก์ที่ไม่น่าเชื่อถือมากเกินไปในสายโซ่ระหว่างเว็บเซิร์ฟเวอร์และบริการบนเว็บของเรา
- ปัจจุบัน มีบริษัทเพียงไม่กี่แห่งที่สร้างบริการบนเว็บ และมีเพียงไม่กี่บริษัทที่ใช้บริการเหล่านี้ ยังต้องใช้เวลาอีกนานในการแก้ไขข้อบกพร่องและปรับปรุงระบบบริการเว็บ
- ระบบการอนุญาตและการเรียกเก็บเงินสำหรับการใช้บริการเว็บยังไม่ได้นำมาใช้โดยนักพัฒนา เนื่องจากยังมีบริการบนเว็บน้อยเกินไป บริษัทส่วนใหญ่จึงพยายามสร้างความประทับใจที่ดีต่อผู้มีโอกาสเป็นลูกค้าด้วยการจงใจลดต้นทุนบริการและเสนอเงื่อนไขการอนุญาตที่เอื้ออำนวย ยังต้องใช้เวลาอีกระยะหนึ่งก่อนที่จะมีการชี้แจงค่าใช้จ่ายที่แท้จริงของบริการบริการเว็บ
เมื่อบริการเว็บเข้ามาแทนที่และพร้อมใช้งานสำหรับทุกคน บริการเหล่านั้นจะกลายเป็นความช่วยเหลืออันล้ำค่าสำหรับนักพัฒนาเว็บ สิ่งเหล่านี้จะทำให้เราสามารถเข้าถึงพลังของคอมพิวเตอร์ทุกเครื่องบนเว็บได้อย่างยืดหยุ่น ถึงเวลาแล้วที่ผู้ทำเว็บไซต์จะต้องหันมาสนใจบริการเว็บและเรียนรู้เพิ่มเติมว่าจะได้อะไรจากบริการเหล่านั้น
คำอธิบายประกอบ: พื้นที่ใช้งาน. ข้อดี. คุณลักษณะของการพัฒนาบริการเว็บสำหรับแพลตฟอร์ม .NET คำอธิบายและการค้นพบบริการเว็บ
XML Web Service คืออะไร?
ด้วยการพัฒนาเทคโนโลยีสารสนเทศ แนวทางต่างๆ ในการเขียนโปรแกรมได้เกิดขึ้น: แบบโมดูลาร์ การเขียนโปรแกรมขับเคลื่อนเหตุการณ์ การเขียนโปรแกรม, เชิงองค์ประกอบ การเขียนโปรแกรมและการออกแบบ ความต่อเนื่องเชิงตรรกะของวิธีการเหล่านี้คือการบริการที่มุ่งเน้น การพัฒนาซอฟต์แวร์.
การใช้วิธีการเชิงบริการช่วยให้เราสามารถพูดคุยเกี่ยวกับการใช้ซ้ำ ( การใช้ซ้ำ ) ในระดับมหภาค (ระดับบริการ) ซึ่งตรงข้ามกับระดับจุลภาค (ระดับวัตถุ) วิธีการที่มุ่งเน้นการบริการเกี่ยวข้องกับการใช้มาตรฐานที่เรียบง่ายและเป็นที่ยอมรับโดยทั่วไป ซึ่งช่วยให้แอปพลิเคชันต่างๆ สามารถใช้ฟังก์ชันการทำงานของกันและกันได้ สามารถเขียนบริการโดยใช้ภาษาโปรแกรมที่หลากหลายบนแพลตฟอร์มที่หลากหลาย นอกจากนี้ยังสามารถปรับใช้บริการแยกต่างหากหรือเป็นส่วนหนึ่งของแพ็คเกจซอฟต์แวร์ได้ทุกที่ในโลก และด้วยเหตุนี้จะทำให้สามารถเข้าถึงฟังก์ชันการทำงานผ่านเครือข่ายได้
โทรเลย บริการทรัพยากรที่ใช้ฟังก์ชันทางธุรกิจและมีคุณสมบัติดังต่อไปนี้:
- ใช้ซ้ำได้;
- กำหนดโดยอินเทอร์เฟซที่ไม่ขึ้นกับเทคโนโลยีที่ชัดเจนอย่างน้อยหนึ่งรายการ
- เชื่อมต่ออย่างหลวมๆ กับทรัพยากรอื่นๆ ที่คล้ายคลึงกัน และสามารถเรียกใช้ผ่านโปรโตคอลการสื่อสารที่อนุญาตให้ทรัพยากรโต้ตอบกันได้
กรณีพิเศษของบริการคือบริการเว็บ XML
บริการเว็บ XMLเป็นเว็บแอปพลิเคชันประเภทพิเศษที่:
- ปรับใช้บนเว็บเซิร์ฟเวอร์
- เผยแพร่วิธีการทางเว็บที่สามารถเรียกใช้โดยไคลเอนต์ภายนอก
- รอรับคำขอ HTTP ซึ่งเป็นคำสั่งสำหรับเรียกใช้เมธอดเว็บ
- รันเมธอดบนเว็บและส่งคืนผลลัพธ์
บริการเว็บไม่มีส่วนต่อประสานกับผู้ใช้ แต่มี API นั่นคือบริการเว็บมีฟังก์ชัน (เมธอดเว็บ) ที่สามารถเรียกใช้จากระยะไกลได้ (เช่น ผ่านทางอินเทอร์เน็ต) บริการเว็บไม่ได้ออกแบบมาเพื่อให้บริการผู้ใช้ปลายทาง หน้าที่ของมันคือการให้บริการแก่แอปพลิเคชันอื่นๆ ไม่ว่าจะเป็นเว็บแอปพลิเคชัน แอปพลิเคชัน GUI หรือแอปพลิเคชันคอนโซล
บริการบนเว็บสามารถให้ข้อมูลตามเวลาจริงเกี่ยวกับราคาหุ้น ตรวจสอบบัตรเครดิต หรือรายงานสภาพอากาศ บริการบนเว็บมีความหลากหลายเช่นเดียวกับแอปพลิเคชันทั่วไป
บริการเว็บไม่ใช่ทรัพย์สินของบริษัทใดบริษัทหนึ่ง เป็นมาตรฐานอุตสาหกรรมที่ใช้โปรโตคอลแบบเปิด (SOAP, HTTP ฯลฯ) บริการเว็บถูกปรับใช้บนแพลตฟอร์มต่างๆ (รวมถึงเซิร์ฟเวอร์ที่ใช้ Windows หรือ UNIX) บริการเว็บสามารถพัฒนาโดยใช้เครื่องมือในการพัฒนามากมาย (ตั้งแต่โปรแกรมแก้ไขข้อความไปจนถึงตระกูล Microsoft Visual Studio)
วิธีการของบริการบนเว็บส่วนใหญ่ถูกเรียกใช้โดยคำขอ HTTP ที่มีข้อความ SOAP SOAP เป็นภาษา XML ( คำศัพท์ XML ) สำหรับการเรียกขั้นตอนระยะไกลผ่าน HTTP และโปรโตคอลอื่นๆ (คำอธิบายแบบเต็มของ SOAP http://www.w3.org/TR/SOAP) .
สถานที่บริการเว็บท่ามกลางเทคโนโลยีการโทรทางไกลอื่น ๆ
มีโปรโตคอลและเทคโนโลยีการเรียกใช้ระยะไกลมากมาย: Microsoft Distributed Component Object Model ( DCOM ), Common Object Request Broker Architecture ( CORBA ), Sun's Remote Method Invocation ( RMI ), NET ระยะไกล บริการเว็บ XML
เทคโนโลยีเชิงส่วนประกอบทั้งหมดเหล่านี้ (DCOM, CORBA และ RMI) ถูกนำมาใช้อย่างประสบความสำเร็จในแอปพลิเคชันอินทราเน็ตเป็นเวลาหลายปี พวกเขาให้สถาปัตยกรรมที่แข็งแกร่งและปรับขนาดได้ อย่างไรก็ตาม มีปัญหาสำคัญสองประการในการใช้เทคโนโลยีเหล่านี้บนอินเทอร์เน็ต ประการแรกพวกเขาไม่ได้มีปฏิสัมพันธ์ซึ่งกันและกัน เทคโนโลยีทั้งหมดทำงานบนออบเจกต์ แต่มีรายละเอียดแตกต่างกันอย่างมาก: การจัดการวงจรชีวิต การสนับสนุนสำหรับตัวสร้าง และระดับของการสนับสนุนการสืบทอด ประการที่สอง สิ่งที่สำคัญกว่าคือการมุ่งเน้นที่การโต้ตอบของ RPC นำไปสู่การสร้างระบบที่เชื่อมต่ออย่างแน่นหนาตามการเรียกเมธอดอ็อบเจกต์ที่ชัดเจน
ซึ่งแตกต่างจากเทคโนโลยีเหล่านี้ XML Web Services และ . NET ระยะไกลใช้งานอย่างเต็มที่ วิธีการเชิงวัตถุสำหรับเขียนโปรแกรมเว็บ
บริการเว็บ XML- คอมโพเนนต์ที่ให้ไคลเอนต์อินเทอร์เน็ตด้วยชุดฟังก์ชัน API หรือเมธอดบนเว็บ XML เป็นส่วนหนึ่งของชื่อเนื่องจากบริการเว็บและไคลเอนต์ใช้เพื่อแลกเปลี่ยนข้อมูล บริการบนเว็บยึดตามมาตรฐานเปิด เช่น HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol - มาตรฐานอินเทอร์เน็ตที่อธิบายวิธีที่แอปพลิเคชันสามารถโต้ตอบได้ นั่นคือ เรียกใช้เมธอดของกันและกัน โดยใช้ HTTP และโปรโตคอลอื่นๆ ) งานหลักของบริการเว็บคือการให้ปฏิสัมพันธ์ระหว่างโปรแกรม จำนวนมากทำงานบนเซิร์ฟเวอร์ UNIX และเข้าถึงได้โดยไคลเอนต์ Windows ข้อมูลที่ส่งผ่านไปยังบริการบนเว็บจะถูกทำให้เป็นอนุกรมกับ XML และส่งเป็นแพ็กเก็ต SOAP ข้อมูลเมตาเกี่ยวกับเนื้อหาของข้อความดังกล่าวจะถูกจัดเก็บไว้ในสัญญา WSDL และ XSD schema ของบริการเว็บ ข้อได้เปรียบหลักของแนวทางนี้คือความสามารถในการอ่านข้อมูลเมตา นักพัฒนาสามารถดูคำอธิบายทั้งหมดของบริการบนเว็บได้อย่างง่ายดาย และสร้างโมดูลของตัวเองที่แยกวิเคราะห์แพ็กเก็ต SOAP
.NET ระยะไกลจัดเตรียมโครงสร้างพื้นฐานสำหรับวัตถุแบบกระจาย มันซับซ้อนกว่าสถาปัตยกรรมบริการเว็บทั่วไปที่อาศัยการส่งข้อความ . NET Remoting รวมถึงการส่งผ่านพารามิเตอร์ตามการอ้างอิงและค่า การเรียกกลับ การเปิดใช้งานหลายวัตถุ และนโยบายการจัดการวงจรชีวิต หากต้องการใช้คุณลักษณะเหล่านี้ แอปพลิเคชันไคลเอนต์ต้องมีความเชี่ยวชาญในเทคโนโลยีทั้งหมด ข้อมูลใน. NET Remoting ถูกส่งในรูปแบบไบนารีหรือ SOAP อย่างไรก็ตาม ไม่ว่าในกรณีใด ข้อมูลเมตาเกี่ยวกับโครงสร้างของข้อมูลที่ส่งจะอยู่ในรันไทม์ภาษาทั่วไป หากไม่มีรันไทม์ภาษากลาง (CLR) แอปพลิเคชันไคลเอ็นต์จะไม่สามารถแยกวิเคราะห์ไฟล์ . NET ส่วนหัว SOAP ระยะไกล นั่นคือ. NET Remoting มีความต้องการสูงกว่าบริการบนเว็บอย่างมาก
การพัฒนาเว็บเซอร์วิสบนแพลตฟอร์ม .NET
มีหลายวิธีในการเขียนเว็บเซอร์วิส สามารถพัฒนาด้วยมือหรือใช้เครื่องมือ SOAP ที่ให้บริการโดย Microsoft, IBM และอื่นๆ เขียนบริการบนเว็บด้วย Microsoft NET มีข้อดีสองประการ:
- .NET Framework ช่วยให้กระบวนการพัฒนาง่ายขึ้นอย่างมากโดยจัดเตรียมไลบรารีคลาสและทำให้ขั้นตอนการพัฒนาแต่ละขั้นตอนเป็นแบบอัตโนมัติ
- บริการเว็บที่เขียนด้วย .NET Framework เป็นแอปพลิเคชันที่มีการจัดการ นั่นคือในแอปพลิเคชันดังกล่าวจะไม่มีปัญหาหน่วยความจำรั่ว ตัวชี้เริ่มต้นไม่ถูกต้อง และปัญหาการเขียนโปรแกรมทั่วไปอื่นๆ
การสร้าง
มาพัฒนาบริการเว็บ AdditionService อย่างง่ายที่ทำการบวกเลขสองตัว มันจะมีวิธีเพิ่มเพียงวิธีเดียวที่รับจำนวนเต็มสองตัวเป็นพารามิเตอร์และส่งกลับจำนวนเต็มเช่นกัน AdditionService สาธิตหลักการสำคัญหลายประการสำหรับการเขียนโปรแกรมเว็บเซอร์วิสโดยใช้ Microsoft .NET Framework
- บริการเว็บถูกนำมาใช้เป็นไฟล์ ASMX ASMX เป็นนามสกุลไฟล์พิเศษที่ลงทะเบียนกับ ASP .NET (โดยเฉพาะอย่างยิ่ง ASP.NET HTTP Handler) ในไฟล์การกำหนดค่า ASP .NET Machine.config หลัก
- ไฟล์ ASMX เริ่มต้นด้วยคำสั่ง @WebService คำสั่งนี้ต้องมีแอตทริบิวต์ Class เป็นอย่างน้อย ซึ่งระบุคลาสที่เว็บเซอร์วิสประกอบด้วย
- คลาสบริการเว็บสามารถมีแอตทริบิวต์ WebService ที่เป็นทางเลือก ใน ตัวอย่างนี้แอตทริบิวต์ดังกล่าวระบุชื่อของบริการเว็บและคำอธิบายที่แสดงบนหน้า HTML เมื่อผู้ใช้เรียก AdditionService.asmx ในเบราว์เซอร์
- เมธอดของเว็บถูกประกาศโดยกำหนดแอ็ตทริบิวต์ WebMethod ให้กับเมธอดสาธารณะของคลาสบริการเว็บ สำหรับวิธีการช่วยเหลือที่ใช้ภายในแต่ไม่สามารถใช้ได้กับไคลเอ็นต์ภายนอก คุณลักษณะนี้จะถูกข้ามไป
- HTTP, XML และ SOAP นั้น "มองไม่เห็น" ข้อมูล XML และข้อความ SOAP ได้รับการจัดการโดย .NET Framework
AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>การใช้ระบบโดยใช้คลาส System.Web.Services AddService ( public int Add (int a, int b) ( return a + b ) )
แม้จะมีขนาดเล็ก AdditionService.asmx เป็นบริการเว็บที่สมบูรณ์เมื่อติดตั้งบนเว็บเซิร์ฟเวอร์ ASP.NET วิธีการเรียกใช้ด้วย SOAP, HTTP GET และ HTTP POST และสามารถส่งคืนผลลัพธ์เป็นการตอบสนอง SOAP หรือเป็นห่อ XML แบบธรรมดา
เมื่อใช้รหัสพื้นหลัง คลาสบริการเว็บสามารถนำออกจากไฟล์ asmx เป็นไฟล์แยกต่างหากได้
บริการเว็บรองรับการใช้งาน ชนิดข้อมูลที่ซับซ้อนเป็นพารามิเตอร์อินพุตหรือเอาต์พุต รองรับประเภทข้อมูลที่ซับซ้อนเนื่องจาก XML ทำให้ง่ายต่อการทำให้เป็นอนุกรมประเภทข้อมูลส่วนใหญ่ อย่างไรก็ตาม เมื่อทดสอบบริการบนเว็บโดยอัตโนมัติ ASP .NET จะไม่สร้างหน้าทดสอบสำหรับวิธีการที่ยอมรับ ประเภทที่ซับซ้อนข้อมูล. นี่เป็นเพราะคุณไม่สามารถส่งผ่านประเภทข้อมูลที่ซับซ้อนไปยังเมธอดเว็บโดยใช้ HTTP GET และ POST
บริการบนเว็บอนุญาตให้คุณเรียกใช้เมธอดของคุณเอง อะซิงโครนัส. การโทรแบบอะซิงโครนัสจะส่งคืนทันที โดยไม่คำนึงว่าบริการเว็บจะใช้เวลานานเท่าใดในการประมวลผลการโทร การโทรแบบอะซิงโครนัสมีประโยชน์เมื่อการโทรใช้เวลานานในการประมวลผล แอปพลิเคชันทำการโทร จากนั้นทำงานต่อไปโดยไม่รอผลการโทร และรับผลการโทรแบบอะซิงโครนัสในภายหลัง ผลลัพธ์จะได้รับเมื่อมีการเรียกใช้เมธอดเว็บอีกครั้งในเวลาที่สะดวกสำหรับแอปพลิเคชัน หรือโดยสมัครรับการแจ้งเตือนเกี่ยวกับการสิ้นสุดการประมวลผลการโทรโดยบริการเว็บ (กลไกการมอบหมาย)
สามารถสร้างบริการเว็บโดยใช้เครื่องมือเช่น ไมโครซอฟท์ วิชวล สตูดิโอ 2005. ในการสร้างเว็บเซอร์วิสก็มี แยกประเภทโครงการ ASP .NET Web Service Visual Studio สร้างไฟล์ asmx ซึ่งเป็นไฟล์ที่มีรหัสพื้นหลังสำหรับอธิบายคลาสบริการเว็บ ไฟล์กำหนดค่าบริการเว็บ ฯลฯ เมื่อเปิดโครงการเพื่อดำเนินการ คลาสบริการจะถูกคอมไพล์และเปิดไฟล์ asmx ในหน้าต่างเบราว์เซอร์
อธิบายบริการเว็บโดยใช้สัญญา
เพื่อให้นักพัฒนารายอื่นใช้ AdditionService ได้ พวกเขาจำเป็นต้องรู้ว่าวิธีใดที่เปิดเผย โปรโตคอลใดที่สนับสนุน ลายเซ็นวิธี และที่อยู่บริการเว็บ (URL) ข้อมูลทั้งหมดนี้และข้อมูลอื่นๆ สามารถอธิบายได้ใน WSDL (ภาษาคำอธิบายบริการเว็บ)
การค้นพบบริการเว็บ
นักพัฒนารายอื่นรู้ได้อย่างไรเกี่ยวกับการมีอยู่ของ AdditionService
ประการแรก ด้วยความช่วยเหลือของ DISCO (ย่อมาจากคำว่า Discovery) ซึ่งเป็นกลไกไฟล์สำหรับค้นหาบริการเว็บในพื้นที่ นั่นคือกลไกในการรับรายการบริการเว็บที่มีอยู่จากไฟล์ DISCO ที่โฮสต์บนเว็บเซิร์ฟเวอร์ นอกจากนี้ ไฟล์ DISCO ยังมีบันทึกตำแหน่งของสัญญา WSDL ของบริการที่มีอยู่ ไฟล์ DISCO เป็นไฟล์ XML ที่มีบันทึก
นอกจากนี้ยังสามารถใช้ไฟล์ VSDISCO ซึ่งคล้ายกับไฟล์ DISCO แต่เนื้อหาของไฟล์นั้นเป็นผลมาจากการค้นหาบริการเว็บแบบไดนามิกในไดเร็กทอรีที่ระบุและไดเร็กทอรีย่อยที่ซ้อนกันทั้งหมด ASP .NET จับคู่ส่วนขยายชื่อไฟล์ .vsdisco กับตัวจัดการ HTTP ที่ค้นหาไดเร็กทอรีที่กำหนดและไดเร็กทอรีย่อยสำหรับ asmx และ disco และส่งคืนเอกสาร DISCO ที่สร้างขึ้นแบบไดนามิก ด้วยเหตุผลด้านความปลอดภัย การค้นหาแบบไดนามิกถูกปิดใช้งานใน .NET Framework บางเวอร์ชัน แต่คุณสามารถเปิดใช้งานได้โดยแก้ไขรายการในไฟล์ Machine.config
แต่การค้นหาบริการเว็บในเครือข่ายทั่วโลกเป็นอย่างไร? เพื่อค้นหาบริการบนเว็บในเครือข่ายทั่วโลก Microsoft, IBM และ Ariba ได้ร่วมกันพัฒนา UDDI (Universal Description Discovery and Integration) ซึ่งเป็นข้อกำหนดสำหรับการสร้างฐานข้อมูลแบบกระจายที่ช่วยให้คุณสามารถค้นหาบริการบนเว็บได้ UDDI ได้รับการสนับสนุนจากหลายร้อยบริษัท ไซต์ UDDI เป็นบริการบนเว็บ ทุกคนสามารถเผยแพร่รีจิสทรีตาม UDDI ได้ นักพัฒนาส่วนใหญ่ไม่เคยใช้ UDDI API โดยตรง เครื่องมือการพัฒนาเข้าถึงการลงทะเบียน UDDI แทน พวกเขายังสร้างคลาส wrapper สำหรับบริการเว็บที่ค้นพบและเลือก
ผลลัพธ์
บริการเว็บ XML เป็นส่วนประกอบของซอฟต์แวร์ที่มีฟังก์ชันการทำงานที่มากที่สุด ระบบที่แตกต่างกันรองรับมาตรฐานต่างๆ เช่น XML และ HTTP Web service ไคลเอ็นต์สามารถเป็นได้ทั้งแบบโลคัลหรือรีโมตแอ็พพลิเคชัน บริการบนเว็บช่วยให้คุณสร้างโครงสร้างที่ช่วยให้รวมระบบต่างๆ ได้ง่ายขึ้นตามมาตรฐานที่เรียบง่ายและเป็นที่ยอมรับกันทั่วไป
เราได้ตรวจสอบ แนวคิดทั่วไปกลไก « เว็บ-บริการ".มาเติมความรู้กันหน่อย
บริการเว็บใช้เพื่อแลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์และไคลเอนต์ รูปแบบ XML ใช้เพื่อ "จัดแพ็คเกจ" ข้อมูลเพื่อความเข้าใจร่วมกันระหว่างผู้เข้าร่วมทั้งสองฝ่ายในการสื่อสาร
บทฉัน
ตัวอย่างการดำเนินการเว็บ-บริการในระบบ "1C: ENTERPRISE"
งาน:จำเป็นต้องสร้างบริการบนเว็บโดยอ้างอิงถึงไคลเอนต์ที่สามารถกำหนดข้อมูลที่จำเป็นทั้งหมดสำหรับแอปพลิเคชันของตนได้
งานนี้เป็นการสาธิตและเป็นเพียงตัวอย่างเพื่อความเข้าใจและเรียนรู้กลไกเท่านั้นเว็บ- บริการ
สารละลาย:
ขั้นตอนที่ 1.มาสร้างฐานข้อมูลใหม่โดยไม่มีการกำหนดค่าเพื่อพัฒนาการกำหนดค่าใหม่
ขั้นตอนที่ 2มาเพิ่มวัตถุใหม่ให้กับการกำหนดค่า
ไดเรกทอรี "ลูกค้า";
เอกสาร "ใบสมัคร";
การแจงนับ "สถานะของแอปพลิเคชัน"
ขั้นตอนที่ 3มาสร้างแพ็คเกจ XDTO ใหม่กันเถอะ
ทำไมและเหตุใดเราจึงสร้างแพ็คเกจ XDTO คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการใช้กลไก XDTO ได้ใน "บทที่ 16 คู่มือนักพัฒนา" และ
ขอให้เราทราบโดยสังเขปว่ากลไก XDTO เป็นวิธีสากลในการนำเสนอข้อมูลสำหรับการโต้ตอบกับแหล่งข้อมูลภายนอกและระบบซอฟต์แวร์ต่างๆ
ในกรณีของเรา แพ็คเกจ XDTO ถูกสร้างขึ้นเพื่ออธิบายค่าส่งคืนของบริการเว็บ
ขยายสาขา “ทั่วไป” → “แพ็คเกจ XDTO” → เพิ่ม...
ระบุชื่อแพ็คเกจ XDTO " เอกสารข้อมูล” และเนมสเปซ http://localhost/request หรือ http://192.168.1.76/request (เพื่อความสะดวกในการทำความเข้าใจและกระบวนการเรียนรู้ เราระบุที่อยู่ IP ในเครื่องของคอมพิวเตอร์ที่ติดตั้งเว็บเซิร์ฟเวอร์ (เว็บเซิร์ฟเวอร์ที่รองรับ: IIS หรือ Apache)) แต่ละบริการบนเว็บสามารถระบุได้โดยไม่ซ้ำกันโดยใช้ชื่อและ URI ของเนมสเปซที่เป็นของบริการนั้นๆ
แพ็คเกจของเรามีวัตถุ XDTO สองประเภท:
1) ลูกค้า- เพื่อถ่ายโอนข้อมูลขององค์ประกอบไดเร็กทอรี "ไคลเอนต์"
- ชื่อ ;
2) เอกสาร- เพื่อถ่ายโอนข้อมูลของเอกสาร "ใบสมัคร"
วัตถุ XDTO ประเภทนี้จะมีคุณสมบัติดังต่อไปนี้:
- ลูกค้า- ประเภทลูกค้าจากเนมสเปซ http://192.168.1.76/request เป็นการอ้างอิงถึงวัตถุ XDTO ที่เรากำหนดไว้ข้างต้น
- สถานะ- ประเภทสตริงจาก http://www.w3.org/2001/XMLSchema เนมสเปซ
- จำนวน- ประเภทสตริงจากเนมสเปซ http://www.w3.org/2001/XMLSchema
ขั้นตอนที่ 4เพิ่มบริการเว็บใหม่ในการกำหนดค่า
ขยายสาขา "ทั่วไป" → "บริการบนเว็บ" → เพิ่ม ...
สำหรับเว็บเซอร์วิส ระบุค่าคุณสมบัติต่อไปนี้:
ชื่อ - เอกสารข้อมูล
เนมสเปซ URI - http://192.168.1.76/request
แพ็คเกจ XDTO - เอกสารข้อมูลหรือhttp://192.168.1.76/request
ชื่อไฟล์สิ่งพิมพ์ - ขอ.1cws
ขั้นตอนที่ 5สำหรับบริการเว็บที่สร้างขึ้น เรากำหนดการดำเนินการ " รับข้อมูล»
ค่าคุณสมบัติการดำเนินการ:
ประเภทการคืนสินค้า - เอกสาร (http://192.168.1.76/request)
อาจมีค่าว่าง - จริง
ชื่อขั้นตอน - รับข้อมูล.
ขั้นตอนที่ 6การดำเนินการ รับข้อมูลกำหนดพารามิเตอร์ลูกค้าด้วย ค่าต่อไปนี้คุณสมบัติ:
ประเภทค่า - ประเภท สตริงจากเนมสเปซ http://www.w3.org/2001/XMLSchema;
ทิศทางการถ่ายโอน - ป้อนข้อมูล.
ขั้นตอนที่ 7มาเปิดโมดูลของบริการเว็บที่สร้างขึ้นและวางฟังก์ชัน Get() ไว้ ซึ่งจะถูกเรียกใช้งานเมื่อเรียกใช้บริการเว็บนี้
ฟังก์ชัน GetData(ลูกค้า) // รับประเภทของวัตถุ XDTO ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "ลูกค้า"); RequestType = FactoryXDTO.Type("http://192.168.1.76/request", "เอกสาร"); // รับลูกค้า ClientReference = Directories.Clients.FindByName (ลูกค้า); ถ้าไม่ใช่ ValueFilled (ClientReference) ให้ส่งคืน Undefined; สิ้นสุดถ้า; คำขอ = คำขอใหม่; Request.Text = "เลือก FIRST 1 | Ticket.Reference, | REPRESENTATION(Ticket.Status) AS Status, | Ticket.Number |FROM | Document.Ticket AS Ticket |WHERE | Ticket.Client = &Client"; Request.SetParameter("ไคลเอ็นต์", ClientReference); QueryResult = Query.Execute(); ถ้า QueryResult.Empty() ให้คืนค่า Undefined; สิ้นสุดถ้า; Selection = QueryResult.Select(); Selection.Next(); เอกสาร = Selection.Reference.GetObject(); // สร้างวัตถุตั๋ว XDTO Ticket = FactoryXDTO.Create(TicketType); Application.Numder = ตัวอย่างหมายเลข; ลูกค้า = FactoryXDTO.Create (ClientType); Client.Name = ClientReference.Name; Application.Customer = ลูกค้า; Application.Status = Selection.Status; // คำขอส่งคืน คำขอส่งคืน; EndFunctions
ขั้นตอนที่ 8มาเผยแพร่บริการเว็บที่สร้างขึ้นบนเว็บเซิร์ฟเวอร์
รายการเมนู Configurator: "Administration" → "Publishing on a Web server"
บนแท็บ "บริการบนเว็บ" ให้ตั้งค่าสถานะ "เผยแพร่บริการบนเว็บ" และทำเครื่องหมายที่ช่องถัดจากบริการบนเว็บใหม่ของเรา
บทครั้งที่สอง
ตัวอย่างการอ้างอิงถึงเว็บ- 1C:บริการระดับองค์กรจากแอปพลิเคชันของบุคคลที่สาม
วัตถุประสงค์หลักของกลไกบริการเว็บใน 1C: Enterprise คือการถ่ายโอนข้อมูลที่จำเป็นไปยังแอปพลิเคชันบุคคลที่สาม
ลองพิจารณาตัวอย่างการพัฒนาแอปพลิเคชันใน Delphi ที่เรียกใช้บริการเว็บของเราจากส่วนแรกของบทความนี้
ขั้นตอนที่ 1.มาสร้างกันเถอะ โครงการใหม่และวางตัวควบคุมต่างๆ บนฟอร์ม
ช่องข้อความ - ใช้เพื่อแสดงข้อมูลที่ได้รับจากบริการเว็บ
สองปุ่ม - ล้างฟิลด์ข้อความและเข้าถึงบริการเว็บ
ฟิลด์อินพุตเป็นพารามิเตอร์ที่ส่งไปยังบริการเว็บ
ขั้นตอนที่ 2การนำเข้าไฟล์ WSDL
เป็นผลให้เราได้รับโมดูลใหม่ ขอ(เรากำหนดชื่อดังกล่าวโดยตรงใน 1C) โมดูลนี้ประกอบด้วยข้อมูลที่จำเป็นทั้งหมดบนบริการเว็บ
ขั้นตอนที่ 3เขียนตัวจัดการการโทรบริการเว็บ
ตัวแปร DocumentDataPortType ถูกกำหนดไว้แล้วในโมดูล ขอ
ขั้นตอนที่ 4เปิดแอปพลิเคชันและตรวจสอบ
บทสาม
ตัวอย่างการอ้างอิงถึงเว็บ-บริการในระบบ "1C: ENTERPRISE"
ขั้นตอนที่ 1.มาสร้างการประมวลผลภายนอกใหม่ที่ชื่อว่า "WEB_Service"
ขั้นตอนที่ 2สำหรับการประมวลผล เรากำหนดแบบฟอร์มใหม่
ขั้นตอนที่ 3ระบุรายละเอียดหลายอย่างสำหรับแบบฟอร์ม
ลูกค้า - พิมพ์ "สตริง"
ClientReturn - พิมพ์ "สตริง"
NumberReturn - พิมพ์ "สตริง"
StatusReturn - ประเภท "สตริง"
เราจะแสดงรายละเอียดในแบบฟอร์ม
ขั้นตอนที่ 4มาเพิ่มคำสั่ง form " เพื่อรับข้อมูล»
ระบุตัวจัดการคำสั่ง
ขั้นตอน &OnClient GetData(คำสั่ง) GetDataOnServer(ไคลเอนต์); สิ้นสุดขั้นตอน ขั้นตอน GetDataOnServer(ไคลเอ็นต์) // สร้างพร็อกซี WS ตามลิงก์และดำเนินการ Get() การดำเนินการ คำนิยาม = WSDefinitions ใหม่ ("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl") ; พร็อกซี = WSProxy ใหม่ (คำจำกัดความ "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); RequestData = Proxy.GetData(ลูกค้า); ถ้า OrderData = Undefined แล้ว ClientReturn = "Undefined"; StatusReturn = "ไม่ได้กำหนด"; ReturnNumber = "ไม่ได้กำหนด"; กลับ; สิ้นสุดถ้า; CustomerReturn = RequestData.Customer.Name; StatusReturn = RequestData.Status; ReturnNumber = RequestData.Numder; จบขั้นตอน
1C:Enterprise สามารถใช้บริการเว็บที่ให้บริการโดยผู้ให้บริการรายอื่นได้สองวิธี:
โดยใช้ คงที่ลิงก์ที่สร้างขึ้นในแผนผังการกำหนดค่า
"บวก":ความเร็วสูงในการทำงาน
"ลบ":นำเข้าคำอธิบาย WSDL อีกครั้งโดยใช้ตัวกำหนดค่าและบันทึกการกำหนดค่าที่เปลี่ยนแปลง
โดยใช้ พลวัตลิงค์ที่สร้างขึ้นโดยใช้ภาษาในตัว
(ตามลำดับ "ข้อเสีย" ของสแตติกสำหรับไดนามิกคือ "ข้อดี")
บทIV
การดีบักบริการเว็บในระบบ 1C:Enterprise
สำหรับบริการเว็บในพื้นที่ คุณต้อง:
ขั้นตอนที่ 1.ใส่ไคลเอนต์ที่ไฟล์เปิดตัวระบบ 1C บริการเว็บ cfg.xmlโดยมีเนื้อหาดังนี้
ขั้นตอนที่ 2เพื่อยื่น ค่าเริ่มต้น. วเผยแพร่ config add line
ขั้นตอนที่ 3ในตัวกำหนดค่า เลือกรายการเมนู
"ดีบัก" → "การเชื่อมต่อ" → "การเชื่อมต่ออัตโนมัติ" → "บริการบนเว็บบนเซิร์ฟเวอร์"
ขั้นตอนที่ 4คลิกที่ปุ่ม "ตกลง"
สำหรับเวอร์ชันเซิร์ฟเวอร์ คุณต้องเรียกใช้เซิร์ฟเวอร์ 1c ในโหมดดีบักด้วยคีย์ /debug
แนวคิดของบริการบนเว็บได้รับการพัฒนาโดยยักษ์ใหญ่ในอุตสาหกรรมคอมพิวเตอร์เช่น Sun, Oracle, HP, Microsoft และ IBM แนวคิดนี้ไม่ใช่เรื่องใหม่ แต่เป็นก้าวสำคัญในการทำให้โปรแกรมต่างๆ เข้าถึงได้ง่ายขึ้นผ่านทางเว็บ ตามรูปแบบการสื่อสารมาตรฐาน โดยทั่วไป บริการบนเว็บสามารถเปลี่ยนความเข้าใจของเราเกี่ยวกับวิธีการสร้างเว็บไซต์
บริการเว็บคืออะไร?
ด้วยบริการบนเว็บ ฟังก์ชันต่างๆ ของโปรแกรมต่างๆ สามารถใช้งานได้ทางอินเทอร์เน็ต ดังนั้น โปรแกรมต่างๆ เช่น PHP, ASP, สคริปต์ JSP, JavaBeans, ออบเจ็กต์ COM และเครื่องมือการเขียนโปรแกรมอื่นๆ ที่เราชื่นชอบทั้งหมดสามารถเข้าถึงบางโปรแกรมที่ทำงานบนเซิร์ฟเวอร์อื่น (เช่น บริการเว็บ) และใช้การตอบสนองที่ได้รับจากเธอบนเว็บไซต์หรือแอปพลิเคชันของเธอ
สมมติว่าถ้าฉันจำเป็นต้องทำงานด้านการเขียนโปรแกรมและฉันยุ่งเกินไป (หรือคิดไม่ออกว่าจะประดิษฐ์วงล้อใหม่ด้วยตัวเอง) ฉันสามารถใช้บริการของบริการเว็บที่ไซต์ของฉันจะเข้าถึงผ่านอินเทอร์เน็ตได้ เมื่อส่งคำขอพร้อมพารามิเตอร์ไปยังบริการบนเว็บ ฉันคาดว่าจะได้รับการตอบกลับซึ่งจะประกอบด้วยผลลัพธ์ของคำขอของฉัน
ใครที่เคยร่วมงานด้วย จดหมายร้อนได้พบบริการบนเว็บบางอย่างแล้ว: ระบบยืนยันตัวตนผู้ใช้ Passport เป็นหนึ่งในบริการที่รวมอยู่ในโครงการริเริ่ม Microsoft .NET ในขณะที่มีให้ใช้งานฟรี เพื่อให้ผู้สร้างเว็บไซต์สามารถใช้การรับรองความถูกต้องของผู้ใช้บนไซต์ของตนได้อย่างง่ายดาย
พื้นฐาน
หลักการเบื้องหลังบริการเว็บนั้นเรียบง่ายอย่างน่าทึ่ง และพวกเขาไม่ได้เพิ่มอะไรใหม่ให้กับโลกของการประมวลผลแบบกระจายและอินเทอร์เน็ต:
- ผู้รับผิดชอบบริการเว็บกำหนดรูปแบบคำขอไปยังบริการเว็บของตนและการตอบสนอง
- คอมพิวเตอร์ทุกเครื่องในเครือข่ายส่งคำขอไปยังบริการเว็บ
- บริการเว็บประมวลผลคำขอ ดำเนินการบางอย่าง แล้วส่งการตอบกลับ
การดำเนินการนี้อาจเป็นเช่น การแสดงราคาหุ้น การแสดงราคาของผลิตภัณฑ์เฉพาะ บันทึกรายการปฏิทินนัดหมาย แปลข้อความจากภาษาหนึ่งเป็นอีกภาษาหนึ่ง หรือตรวจสอบหมายเลขบัตรเครดิต
มาตรฐานที่แกนกลาง
เหตุผลที่เราทุกคนสนใจในบริการบนเว็บอย่างกระทันหันก็เพราะพวกเขาใช้มาตรฐาน โปรโตคอลแบบเปิดสำหรับการแลกเปลี่ยนและส่งข้อมูล
ก่อนหน้านี้ หลายๆ บริษัทได้พัฒนามาตรฐานและรูปแบบที่เป็นกรรมสิทธิ์ของตนเอง และตอนนี้ ในการทำงาน เราเพียงต้องรู้ XML (eXtensible Markup Language) อย่างง่าย ซึ่งส่งผ่านโปรโตคอล HTTP เดิมที่คุ้นเคย ซึ่งหมายความว่าทุกคนสามารถเข้าถึงข้อมูลเกี่ยวกับวิธีการทำงานของบริการเว็บได้ และนักพัฒนาเว็บที่คุ้นเคยกับเทคโนโลยีเหล่านี้ตามอาชีพสามารถเริ่มเล่นบริการเว็บได้แล้ววันนี้
ความแตกต่างระหว่างบริการบนเว็บและเทคโนโลยีอื่นๆ ที่นักพัฒนาพบ (เช่น DCOM, NamedPipe - Name Pipe, RMI) คือบริการบนเว็บนั้นอิงตามมาตรฐานเปิด เรียนรู้ได้ง่าย และมาตรฐานเหล่านี้ได้รับการสนับสนุนอย่างกว้างขวางบน แพลตฟอร์ม Unix และ Windows ทั้งหมด
Simple Object Access Protocol (SOAP) เป็นโปรโตคอลมาตรฐานที่พัฒนาโดย W3C กำหนดรูปแบบการร้องขอบริการเว็บ
ข้อความระหว่างบริการเว็บและผู้ใช้จะถูกบรรจุลงในซองจดหมาย SOAP (ซองจดหมาย SOAP) ข้อความมีทั้งคำขอให้ดำเนินการบางอย่าง หรือการตอบสนอง - ผลลัพธ์ของการดำเนินการนี้ ซองจดหมายและเนื้อหาถูกเข้ารหัสด้วย XML และค่อนข้างเข้าใจง่าย นี่คือลักษณะของคำขอ SOAP อย่างง่าย ซึ่งส่งผ่าน HTTP ไปยังบริการบนเว็บ:
xmlns:m="http://www.somesite.com/postcode">
องค์ประกอบหลักของซองจดหมาย SOAP นั้นง่ายต่อการจดจำ: นี่คือพารามิเตอร์สองตัว (
และคำตอบจะมีลักษณะดังนี้:
xmlns:m="http://www.somesite.com/postcode">
ข้อความนี้ยิ่งง่ายต่อการถอดรหัส องค์ประกอบ
ตอนนี้เกี่ยวกับ UDDI
แม้จะมีความเรียบง่ายของโปรโตคอล SOAP แต่ก็ยังมีการใช้เพียงเล็กน้อยในบริการเว็บหากเราไม่สามารถค้นหาได้ โชคดีที่ IBM, Microsoft และ Ariba ได้ริเริ่มและสร้างโครงการ Universal Description, Discovery and Integration (UDDI) ซึ่งพวกเขาหวังว่าจะกลายเป็นแค็ตตาล็อกทั่วไปของบริการเว็บทั้งหมดบนเว็บ
ระบบ UDDI ช่วยให้บริษัทสามารถเปิดเผยบริการเว็บของตนสู่สาธารณะได้ ไดเร็กทอรีนี้ทำหน้าที่เป็นสมุดโทรศัพท์สำหรับบริการบนเว็บทั้งหมด การลงทะเบียนในไดเร็กทอรี UDDI นั้นไม่มีค่าใช้จ่าย และผู้ก่อตั้งโปรเจกต์หวังว่าไดเร็กทอรีนี้จะมีคำอธิบายของบริการแบบ all-all-all ทั่วทั้งเว็บ เพื่อให้ไดเร็กทอรี UDDI เพียงไดเร็กทอรีเดียวก็เพียงพอที่จะค้นหาบริการบนเว็บที่ต้องการ
วิธีการทำงานทั้งหมด
ฉันจะค้นหาบริการเว็บที่เหมาะสมได้อย่างไร
สมมติว่าฉันเป็นนักพัฒนาเว็บไซต์และลูกค้าขอให้ฉันเพิ่มคุณลักษณะใหม่ลงในไซต์: ฉันต้องเพิ่มการตรวจสอบรหัสไปรษณีย์ในแบบฟอร์มลงทะเบียน
ในการดำเนินการตรวจสอบนี้ ฉันต้องสร้างฐานข้อมูลรหัสไปรษณีย์ทั้งหมดของทั้ง 30 ประเทศที่บริษัทของเราทำธุรกิจ จากนั้นตรวจสอบว่ารหัสไปรษณีย์ตรงกับเมืองที่ระบุในการลงทะเบียนระหว่างการลงทะเบียน แต่ฉันไม่มีข้อมูลนี้ และฉันคิดว่าการรวบรวมข้อมูลดังกล่าวจะต้องใช้เงินจำนวนมาก
แทนที่จะออกไปซื้อฐานข้อมูล เขียนโค้ดของตัวเอง ตรวจสอบให้แน่ใจว่าข้อมูลทั้งหมดสอดคล้องและถูกต้อง และแก้ไขสคริปต์ ฉันแค่ไปที่ไดเร็กทอรี UDDI และมองหาบริการเว็บที่สามารถทำงานให้ฉันได้ . เมื่อฉันไปที่ www.uddi.org ฉันทำการค้นหาและพบบริการที่ยอดเยี่ยมจาก XYZ Corp.
ฉันตรวจสอบคำจำกัดความของรูปแบบบริการเว็บอย่างละเอียด (คำจำกัดความเขียนด้วย WSDL (Web Services Description Language)) ตรวจสอบให้แน่ใจว่าบริการทำในสิ่งที่ฉันต้องการ จากนั้นฉันถามเพื่อนร่วมงานเกี่ยวกับชื่อเสียงของ XYZ Corp. ฉันพบว่า มั่นคง จากนั้นฉันติดต่อ XYZ Corp. เพื่อสอบถามราคา หากราคาสำหรับการเข้าถึงบริการอยู่ในงบประมาณของฉัน ฉันจะเขียนหน้า JSP ง่ายๆ สำหรับไซต์ของฉันที่เรียกใช้บริการเว็บของ XYZ Corp และเดี๋ยวก่อน การชำระเงินทันทีจะปรากฏบน เว็บไซต์. รหัสไปรษณีย์.
ใช้เวลาให้คุ้มค่า
แม้ว่าคุณจะไม่มีอะไรเกี่ยวข้องกับเทคโนโลยีการเขียนโปรแกรมหรือการพัฒนาเว็บไซต์ แต่บริการบนเว็บก็คุ้มค่าที่จะเรียนรู้เพิ่มเติม ลองนึกภาพว่าคุณกำลังพูดคุยเรื่องเว็บไซต์ใหม่กับลูกค้า พูดถึงการทำงานทั้งหมดของโครงการใหม่อย่างไร ทุกอย่างเป็นไปได้ด้วยดี: งบประมาณเป็นไปตามความคาดหวังของลูกค้า เขาชอบเค้าโครงของแผนไซต์ เขาชอบตัวอย่างอินเทอร์เฟซ ทุกอย่างดูเหมือนจะทำงาน
และทันใดนั้นพวกเขาก็จำฟังก์ชันที่ซับซ้อนมากได้ เพียงแค่พูดถึงมัน ใบหน้าของนักพัฒนาเว็บของคุณเปลี่ยนเป็นสีเขียว และตัวเขาเองก็เริ่มสำลักไอ นี่คือนักพัฒนาที่ส่งสัญญาณให้คุณทราบว่าการพัฒนาคุณลักษณะนี้จะต้องใช้เงินและเวลาจำนวนมาก หรือเป็นไปไม่ได้ด้วยงบประมาณดังกล่าว
เลิกกลัว! ฉันพนันได้เลยว่ามีบริการเว็บบนเว็บที่พร้อมให้ฟังก์ชันที่จำเป็นแก่คุณ และค่าใช้จ่ายในการใช้บริการเว็บนี้จะต่ำกว่าต้นทุนในการพัฒนาอะนาล็อกด้วยตัวเองมาก ด้วยวิธีนี้ คุณจะช่วยนักพัฒนาของคุณไม่ต้องปวดหัวโดยไม่จำเป็น ลูกค้าของคุณไม่ต้องเสียเงิน เพียงแค่ใช้เวลาสองสามนาทีในการเรียกดูแค็ตตาล็อก UDDI
การพัฒนาบริการ
แน่นอน นักพัฒนาไม่จำเป็นต้องชำระเพียงบริการเว็บที่สร้างโดยผู้อื่น ด้วยความช่วยเหลือจากหนึ่งในชุดเครื่องมือต่อไปนี้ คุณสามารถสร้างบริการเว็บของคุณเองและให้บริการแก่ผู้อาศัยในเครือข่ายคนอื่นๆ
ทางเลือกของเครื่องมือในการพัฒนาบริการเว็บมีมากมาย ประกอบด้วยชุดเครื่องมือจากบริษัทต่างๆ เช่น Sun (Open Net), Microsoft (.NET), (e-services) และ IBM (Web Services) นอกจากนี้ยังมีกรอบโอเพ่นซอร์ส ตัวอย่างเช่น โครงการโมโนพยายามแทนที่ชุดเครื่องมือ Microsoft .NET โดยจัดหาระบบการคอมไพล์ (คอมไพเลอร์) การดำเนินการโค้ด (รันไทม์) และไลบรารี (ไลบรารี่) เพื่อเรียกใช้บริการเว็บเดียวกันบนทุกแพลตฟอร์ม รวมถึง Unix
แม้จะมีเซิร์ฟเวอร์และเครื่องมือพัฒนาเว็บเซอร์วิสที่หลากหลาย แต่ทั้งหมดก็สนับสนุนโปรโตคอล SOAP, ภาษา XML และระบบ UDDI เดียวกัน
ข้อเสีย
ก่อนที่ฉันจะละทิ้งอาชีพการเป็นโปรแกรมเมอร์และอุทิศตัวให้กับการใช้บริการเว็บ ฉันต้องถามตัวเองว่า "ภาพนี้สีชมพูเกินไป เกิดอะไรขึ้น?" น่าเสียดายที่มีราคาที่ต้องจ่ายสำหรับศักยภาพที่ยอดเยี่ยมของบริการบนเว็บ:
- การใช้ XML เป็นรูปแบบการถ่ายโอนข้อมูลส่งผลให้ข้อความของคุณมีขนาดใหญ่มาก: แท็ก XML เองใช้พื้นที่มาก และสิ่งนี้ทำให้เรามีภาระบางอย่างในการสร้าง ส่ง และตีความข้อความ
- เนื่องจากเราใช้คอมพิวเตอร์ระยะไกลเพื่อทำหน้าที่บางอย่าง เราจึงพึ่งพาอินเทอร์เน็ตทั้งหมด ซึ่งสร้างลิงก์ที่ไม่น่าเชื่อถือมากเกินไปในห่วงโซ่ระหว่างเว็บเซิร์ฟเวอร์และบริการบนเว็บของเรา
- ปัจจุบัน มีบริษัทเพียงไม่กี่แห่งที่สร้างบริการบนเว็บ และมีเพียงไม่กี่บริษัทที่ใช้บริการเหล่านี้ ยังต้องใช้เวลาอีกนานในการแก้ไขข้อบกพร่องและปรับปรุงระบบบริการเว็บ
- ระบบการอนุญาตและการเรียกเก็บเงินสำหรับการใช้บริการเว็บยังไม่ได้นำมาใช้โดยนักพัฒนา เนื่องจากยังมีบริการบนเว็บน้อยเกินไป บริษัทส่วนใหญ่จึงพยายามสร้างความประทับใจที่ดีต่อผู้มีโอกาสเป็นลูกค้าด้วยการจงใจลดต้นทุนบริการและเสนอเงื่อนไขการอนุญาตที่เอื้ออำนวย ยังต้องใช้เวลาอีกระยะหนึ่งก่อนที่จะมีการชี้แจงค่าใช้จ่ายที่แท้จริงของบริการบริการเว็บ
เมื่อบริการเว็บเข้ามาแทนที่และพร้อมใช้งานสำหรับทุกคน บริการเหล่านั้นจะกลายเป็นความช่วยเหลืออันล้ำค่าสำหรับนักพัฒนาเว็บ สิ่งเหล่านี้จะทำให้เราสามารถเข้าถึงพลังของคอมพิวเตอร์ทุกเครื่องบนเว็บได้อย่างยืดหยุ่น ถึงเวลาแล้วที่ผู้ทำเว็บไซต์จะต้องหันมาสนใจบริการเว็บและเรียนรู้เพิ่มเติมว่าจะได้อะไรจากบริการเหล่านั้น
การใช้งานเว็บเซอร์วิสใน IBM Lotus Domino 7
บริการเว็บคืออะไรและเหตุใดจึงสำคัญ
ชุดเนื้อหา:
เนื้อหานี้เป็นส่วนหนึ่งของ # ชุดบทความ: การใช้งานเว็บเซอร์วิสใน IBM Lotus Domino 7
https://www..jsp?series_title_by=ปฏิบัติ+ใช้+เว็บเซอร์วิส+in+ibm+lotus+domino+7
คอยติดตามบทความใหม่ในชุดนี้
คุณอาจพบการอ้างอิงถึงบริการเว็บในบทความทางเทคนิค ผลิตภัณฑ์ซอฟต์แวร์หรือแม้แต่ในบทสนทนากับเพื่อนร่วมงาน เห็นได้ชัดว่ามีคนต้องการบริการบนเว็บและมีความสำคัญ อย่างไรก็ตาม เมื่อได้พบกับคำจำกัดความเช่น "ไวยากรณ์ XML สำหรับการกำหนดชุดปลายทางสำหรับการส่งข้อความ" คุณตัดสินใจว่าไม่ควรแตะต้องสิ่งที่ซับซ้อนเช่นนี้
โชคดีที่สามารถอธิบายบริการบนเว็บในแบบที่ทุกคนเข้าใจได้โดยไม่ต้องลงรายละเอียดว่ามันทำงานอย่างไร คุณควรพยายามทำความเข้าใจว่า Web Services คืออะไร เนื่องจากขอบเขตของแอปพลิเคชัน (และสถาปัตยกรรมเชิงบริการที่เกี่ยวข้อง SOA) ในโลกไอทีนั้นขยายตัวอย่างต่อเนื่อง
บริการบนเว็บสามารถเปรียบได้กับรถยนต์: คุณไม่จำเป็นต้องรู้ในระดับเทคนิคว่าลูกสูบ เพลาลูกเบี้ยว และหัวฉีดเชื้อเพลิงทำงานอย่างไร คุณสามารถซื้อรถ ขับ และพูดคุยเกี่ยวกับรถกับเพื่อนได้ (เว้นแต่ของ แน่นอนพวกเขาเป็นช่างเครื่อง) . เช่นเดียวกับบริการบนเว็บ ในฐานะผู้เชี่ยวชาญด้านไอที คุณเพียงแค่ต้องเข้าใจว่าบริการเหล่านี้คืออะไรและทำงานอย่างไรเพื่อทำความเข้าใจว่าเหตุใดคุณจึงต้องการบริการเหล่านั้น
ขณะนี้การทำงานกับบริการบนเว็บง่ายขึ้นมากโดยไม่ต้องสัมผัสกับเทคโนโลยีระดับต่ำที่ซ่อนอยู่ เนื่องจากผู้จำหน่ายซอฟต์แวร์และชุมชนโอเพ่นซอร์สได้ดำเนินการหลายอย่างในช่วงไม่กี่ปีที่ผ่านมาเพื่อแยกส่วนต่อประสานบริการบนเว็บออกจากงานระดับต่ำ สิ่งนี้จะช่วยให้คุณทำงานโดยเพียงแค่เชื่อมต่อส่วนประกอบเข้าด้วยกันโดยไม่ต้องเจาะลึกเอกสารการจัดรูปแบบข้อความ XML ที่มีความยาว
บทความชุดนี้จะช่วยให้นักพัฒนา Domino เข้าใจและใช้บริการเว็บใน IBM Lotus Domino V7.0 บทความเบื้องต้นนี้มีเพียงพอ ข้อมูลที่เป็นประโยชน์และเป็นประโยชน์สำหรับทุกคนที่ต้องการเข้าใจว่าบริการบนเว็บคืออะไร เทคโนโลยีใน Lotus Domino V7.0 ช่วยให้นักพัฒนาสามารถสร้างและใช้บริการเว็บได้ง่าย และเราจะกล่าวถึงรายละเอียดในภายหลัง
ก่อนอื่นมาทำความเข้าใจกันก่อนว่าบริการบนเว็บคืออะไร
บริการเว็บคืออะไร?
พูดง่ายๆ ก็คือ บริการบนเว็บอนุญาตให้โปรแกรมคอมพิวเตอร์สื่อสารระหว่างกันด้วยวิธีที่เป็นมาตรฐาน
การสื่อสารระหว่างสามเครื่องขึ้นไป
แม้ว่าตัวอย่างจะขึ้นอยู่กับการทำธุรกรรมภายในเครื่องหนึ่งหรือสองเครื่อง แต่ยังสามารถใช้บริการเว็บเพื่อสื่อสารระหว่างเครื่องหลายเครื่อง ตัวอย่างเช่น ธุรกรรมสามารถส่งต่อหรือจัดเก็บโดยอุปกรณ์ระดับกลาง หรือการเรียกไปยังบริการบนเว็บบนเซิร์ฟเวอร์เครื่องหนึ่งอาจทริกเกอร์การเรียกไปยังบริการอื่น
ในตอนท้ายของบทความนี้ เมื่อเราดู SOA จริง เราจะพูดถึงบริการบนเว็บที่โต้ตอบกับเครื่องหลายเครื่อง เพราะนั่นเป็นวิธีที่ SOA ทำงานอยู่เสมอ
บริการเว็บเป็นองค์ประกอบที่เป็นนามธรรม เช่นเดียวกับแนวคิดของการสนทนาของมนุษย์ที่เป็นนามธรรม บทสนทนาเกี่ยวข้องกับคนสองคนขึ้นไปที่พูดภาษาที่พวกเขารู้จัก ภาษาของพวกเขากำหนดคำที่พวกเขาใช้และคำเหล่านั้นสร้างประโยคอย่างไร โดยปกติแล้ว บทสนทนาจะมีโครงสร้างแบบคำถาม-คำตอบ เมื่อมีคนถามคำถามหรือแถลง และคู่สนทนาจะตอบ ผู้คนสามารถอยู่ใกล้ๆ คุยโทรศัพท์ ส่งข้อความหากันทางไปรษณีย์หรือแชท
บทสนทนาก็มี โครงสร้างที่ซับซ้อนและอาจเกิดขึ้นในรูปแบบต่างๆ ขึ้นอยู่กับจำนวนคนที่สื่อสารกัน ภาษาที่ใช้ในการสื่อสารสำหรับเทคโนโลยีการสื่อสาร แน่นอนว่าหากมีการใช้
โครงสร้างของการสื่อสารโดยใช้บริการเว็บประกอบด้วยองค์ประกอบหลายอย่างที่เราจะกล่าวถึงในบทความนี้ อย่างไรก็ตาม แนวคิดยังคงเหมือนกับการสนทนาปกติ นั่นคือ โปรแกรมสื่อสารโดยใช้ภาษาที่พวกเขารู้จัก บางครั้งผ่านเครือข่าย โปรแกรมสามารถอยู่บนคอมพิวเตอร์เครื่องเดียวกันหรือโฮสต์บนเครื่องต่างๆ ในส่วนต่างๆ ของโลก โดยเชื่อมต่อผ่านอินเทอร์เน็ตโดยเราเตอร์และเซิร์ฟเวอร์ ข่าวดีก็คือโปรแกรมและคอมพิวเตอร์ไม่จำเป็นต้องเหมือนกัน ด้วยบริการเว็บ โปรแกรม Microsoft .NET สองโปรแกรมบนแล็ปท็อปเครื่องเดียวกันสามารถสื่อสารได้ เช่นเดียวกับโปรแกรม Java บนเซิร์ฟเวอร์ iSeries ของแคนาดากับโปรแกรม C++ บนคอมพิวเตอร์ Linux จากประเทศจีน
การสื่อสารบริการเว็บใช้เทคโนโลยีมาตรฐานต่อไปนี้:
- xmlภาษา (รูปแบบข้อมูล) ที่ใช้โดยส่วนประกอบบริการเว็บ
- โปรโตคอล SOAPข้อความ XML แลกเปลี่ยนระหว่างโปรแกรม
- ไลบรารีคำอธิบายบริการเว็บ (WSDL)ไฟล์ XML ที่กำหนดรูปแบบของข้อความ SOAP และวิธีการส่ง
นอกจากนี้ยังสามารถใช้เทคโนโลยีมาตรฐานที่เรียกว่า Universal Description, Discovery และ Integration (UDDI) เพื่อสื่อสารระหว่างบริการบนเว็บ เราจะพูดถึงเรื่องนี้ในบทความต่อไป แต่เนื่องจาก UDDI เป็นทางเลือก บริการเว็บจำนวนมากจึงไม่ใช้
คำศัพท์บางคำ: การเผยแพร่และการใช้บริการเว็บ
ก่อนที่เราจะเริ่มอธิบายคำศัพท์ของเรา มาดูคำศัพท์บางคำที่เกี่ยวข้องกับบริการบนเว็บกันก่อน
เมื่อเราพูดถึงการเผยแพร่บริการบนเว็บ เราหมายถึงโปรแกรมที่เผยแพร่ไฟล์ WSDL และอนุญาตให้โปรแกรมอื่นใช้บริการที่เกี่ยวข้อง โปรแกรมที่เผยแพร่บริการเว็บเรียกว่าผู้ให้บริการ
เมื่อเราพูดถึงการใช้บริการเว็บ เราหมายถึงโปรแกรมที่โทรไปยังบริการเว็บบนเครื่องอื่น ผู้ใช้บริการเว็บเรียกว่าไคลเอนต์
XML: ภาษาพื้นเมือง
XML ใช้เพื่อสื่อสารระหว่างส่วนประกอบบริการเว็บ ข้อความที่ส่งระหว่างแอปพลิเคชัน ตลอดจนไฟล์ที่กำหนดบริการเว็บจะอยู่ในรูปแบบ XML รูปที่ 1 แสดงโครงสร้างของไฟล์ XML อย่างง่าย
รูปที่ 1 โครงสร้าง XML พื้นฐาน
อย่างที่คุณเห็น ข้อมูลบางอย่างในไฟล์ (เช่น ชื่อ นามสกุล) จะถูกล้อมรอบด้วยแท็กที่อยู่ในวงเล็บสามเหลี่ยม ชื่อจอห์นแสดงเป็น
การเขียน Web Services ใน XML มีประโยชน์มากมาย ได้แก่ :
- โครงสร้างและไวยากรณ์ของ XML คล้ายกับภาษาการเขียนโปรแกรมอื่นๆ ดังนั้นโปรแกรมที่โต้ตอบกับบริการบนเว็บจึงไม่จำเป็นต้องแยกวิเคราะห์ไฟล์ XML โดยตรง
- ไฟล์ XML เป็นไฟล์ข้อความและมนุษย์สามารถอ่านได้ (หรืออีกนัยหนึ่ง ถ้าคุณรู้ภาษา XML คุณสามารถเปิดไฟล์ XML ได้ใน โปรแกรมแก้ไขข้อความและเข้าใจเนื้อหา) สิ่งนี้อาจช่วยในการดีบัก
- XML ช่วยให้คุณใช้การเข้ารหัสมาตรฐานใดๆ ในข้อความ คุณจึงสามารถเขียนข้อความเป็นภาษาอังกฤษ รัสเซีย หรือญี่ปุ่นได้
- XML อนุญาตให้คุณใช้สิ่งที่เรียกว่าเนมสเปซ ซึ่งคุณสามารถกำหนดโครงสร้างที่ต้องการล่วงหน้าขององค์ประกอบไฟล์ด้วยชื่อเฉพาะได้ ตัวอย่างเช่น คุณสามารถกำหนดองค์ประกอบราคา ซึ่งต้องเป็นทศนิยมเสมอ หรือชื่อบุคคล ซึ่งมีองค์ประกอบย่อยของสตริงสองรายการ ได้แก่ FirstName และ LastName
นอกจากนี้ หากจำเป็น เนมสเปซจะอนุญาตให้องค์ประกอบหลายรายการที่มีชื่อเดียวกันมีคำจำกัดความต่างกัน ตัวอย่างเช่น องค์ประกอบราคาหุ้นในเนมสเปซหนึ่งอาจมีสัญลักษณ์ย่อหุ้นและราคา ในขณะที่อีกเนมสเปซหนึ่งอาจประกอบด้วยสัญลักษณ์แสดงราคา ราคา ต่ำสุดและสูงสุดรายวัน และสูงสุดในรอบ 12 เดือน
ข้อเสียเพียงอย่างเดียวของ XML หากเป็นข้อเสียจริงๆ คือ:
- ภาษา XML เข้มงวด ดังนั้นการจัดรูปแบบข้อความ XML ที่ไม่ถูกต้องจะทำให้การแยกวิเคราะห์ข้อความทั้งหมดล้มเหลว (แม้ว่าปัญหาจะตีความได้ง่ายหรือพลาดไปก็ตาม) อย่างไรก็ตาม หากคุณใช้ไลบรารีมาตรฐานเพื่อสร้างไฟล์ XML (ซึ่งเป็นสิ่งที่คุณทำเมื่อคุณสร้างบริการบนเว็บ) ไลบรารีจะตรวจสอบการจัดรูปแบบที่เหมาะสมเอง
- ข้อความ XML ถูกจัดเก็บไว้ในไฟล์ข้อความธรรมดา ดังนั้นจึงใช้พื้นที่มากกว่ารูปแบบอื่นที่เทียบเท่า (เช่น แบบแยก ไบนารี หรือรูปแบบ "สร้างเอง")
แต่ประเด็นเหล่านี้ไม่เกี่ยวข้องเมื่อเทียบกับประโยชน์ของรูปแบบ XML
SOAP: ข้อความที่ส่ง
คุณทราบดีว่าบริการบนเว็บสื่อสารในรูปแบบ XML แต่นั่นช่วยแก้ปัญหาได้เพียงครึ่งเดียวเท่านั้น แอปพลิเคชันสามารถแยกวิเคราะห์ข้อความได้ แต่พวกเขารู้ได้อย่างไรว่าจะทำอย่างไรกับผลลัพธ์ที่แยกวิเคราะห์
คำสั่งที่อธิบายกฎการจัดรูปแบบข้อความ XML สำหรับบริการเว็บเรียกว่า SOAP กำหนดโครงสร้างข้อความเพื่อให้โปรแกรมทราบวิธีการส่งและตีความข้อมูล โครงสร้างพื้นฐานของข้อความ SOAP แสดงในรูปที่ 2
รูปที่ 2 โครงสร้างข้อความ SOAP พื้นฐาน
ใน XML จะมีลักษณะดังนี้:
ในกรณีพื้นฐาน คุณมีแพ็กเก็ต SOAP ที่มีเนื้อหา SOAP และเนื้อหาที่มีข้อมูลที่จะถ่ายโอน บางครั้งยังมีส่วนหัว SOAP ที่เป็นทางเลือก (ภายในแพ็กเก็ตก่อนเนื้อหา) ที่มีข้อมูลเพิ่มเติม
คำแนะนำสบู่
แม้ว่ารูปแบบ SOAP จะเป็นมาตรฐานและมีคำแนะนำเหมือนกัน แต่โปรดจำไว้ว่าผู้ผลิตแต่ละรายอาจนำคำแนะนำเหล่านี้ไปใช้ในวิธีที่ต่างกันเล็กน้อย ตัวอย่างเช่น โครงสร้างของเนมสเปซและ XML ในข้อความ SOAP ที่สร้างโดย Apache Axis อาจแตกต่างจากโครงสร้างที่สร้างโดย Microsoft .NET อย่างมาก อย่างไรก็ตาม ไคลเอ็นต์หรือเซิร์ฟเวอร์ที่เขียนดีสามารถประมวลผลข้อความใดๆ ที่เขียนได้ดีตามคำสั่ง SOAP
นอกจากนี้ยังมีข้อแตกต่างที่สำคัญบางประการระหว่างคำสั่ง WSDL 1.1 และ WSDL 2.0 แม้ว่าคำสั่ง 2.0 จะยังอยู่ในขั้นตอนสุดท้าย ณ เวลาที่เขียน แต่ในไม่ช้ามันจะเริ่มแทนที่เวอร์ชัน 1.1
หากคุณไม่เคยเจอไฟล์ WSDL มาก่อนและกำลังพยายามเปิดและอ่าน มันจะเป็นเรื่องยากสำหรับคุณที่จะดึงข้อมูลทั้งหมดจากที่นั่น เนื่องจากโครงสร้างของไฟล์ดังกล่าวอาจค่อนข้างซับซ้อน ข้อมูลทั้งหมดเกี่ยวกับเมธอด (ชื่อ พารามิเตอร์ โปรโตคอล ฯลฯ) กระจายอยู่ตามส่วนต่างๆ ของไฟล์ และต้องรวบรวมโดยแอปพลิเคชันไคลเอ็นต์เพื่อสร้างข้อความ SOAP คำอธิบายของส่วนต่าง ๆ ของไฟล์ WSDL และส่วนต่าง ๆ ทำงานร่วมกันจะไม่อยู่ในบทความนี้
นี่คือสิ่งที่เทคโนโลยีเข้ามาช่วยเหลืออีกครั้ง ในฐานะนักพัฒนา คุณไม่จำเป็นต้องอ่าน แยกวิเคราะห์ และทำความเข้าใจเนื้อหาของไฟล์ WSDL เครื่องมือจะรับข้อมูลนี้ให้คุณ ดังนั้นคุณเพียงแค่ต้องหาว่าจะส่งอะไรไปยังบริการ และตำแหน่งที่จะใส่ผลลัพธ์ คุณไม่เพียงเท่านั้น คุณสามารถใช้ไลบรารีและเครื่องมือต่างๆ แต่เพื่อความแน่ใจ คุณจะ. มีข้อยกเว้น ข้อขัดข้อง และความซับซ้อนมากมายสำหรับส่วนประกอบบริการเว็บทั้งหมด และคุณควรพิจารณา โดยใช้บริการเว็บไม่ใช่การแยกส่วน ตามด้วยการศึกษารายละเอียดของแต่ละองค์ประกอบ
โปรโตคอล: วิธีการส่งข้อความ
เรายังไม่ได้พูดถึงคำถาม ข้อความเหล่านี้ส่งผ่าน SOAP ได้อย่างไร
และมักจะส่งผ่านเครือข่าย (และ / หรืออินเทอร์เน็ต) โดยใช้โปรโตคอล HTTP ในลักษณะเดียวกับที่เพจถูกส่งจากเซิร์ฟเวอร์ไปยังเบราว์เซอร์ของคุณ ไม่ได้ใช้ HTTP เสมอไป (คู่แข่งหลักคือ SMTP แต่ตามหลังอยู่มาก) โปรโตคอลที่ใช้โดยบริการเว็บถูกกำหนดไว้ในไฟล์ WSDL
โดยทั่วไป ในไฟล์ WSDL โปรโตคอลที่ใช้ในการส่งข้อความ SOAP ถูกกำหนดเป็น HTTP ไคลเอนต์ SOAP ส่งข้อความตามโปรโตคอลที่ระบุ
ข้อกำหนดบริการเว็บอื่น ๆ ที่คุณอาจพบ
เราได้ครอบคลุมคำศัพท์พื้นฐานแล้ว แต่คุณอาจได้ยินอีกเล็กน้อยเมื่อพูดถึงบริการบนเว็บ
ความสัมพันธ์ที่อ่อนแอ
โปรแกรมที่ใช้บริการเว็บมักเชื่อมโยงกับบริการอย่างหลวมๆ นั่นคือ บริการที่จำเป็นสำหรับโปรแกรมที่จะเรียกใช้ไม่ได้ถูกผูกไว้โดยตรง เช่นเดียวกับที่โปรแกรมไม่ผูกพันกับบริการ โปรแกรมสามารถใช้บริการใด ๆ ที่ต้องการได้อย่างง่ายดาย และพวกเขากำลังรอการโทรจากโปรแกรม - จากโปรแกรมใด ๆ ที่ต้องการคำตอบ
ตัวอย่างในชีวิตจริงของความสัมพันธ์ที่อ่อนแอคือการรับประทานอาหารกลางวันกับเพื่อน เพื่อนหลายคนเห็นพ้องต้องกัน (ด้วยตนเองทางโทรศัพท์ผ่าน อีเมลฯลฯ). ทุกคนไปที่ร้านอาหารของตัวเองและหลังอาหารเย็นทุกคนจ่ายค่าอาหารของตัวเอง ไม่ว่ามื้อกลางวันจะดำเนินไปอย่างไร ผลลัพธ์ก็ยังเหมือนเดิม นั่นคือมื้อเที่ยงที่เป็นมิตร
แต่การขับรถเป็นการกระทำที่มีสายสัมพันธ์ที่แน่นแฟ้นยิ่งขึ้น คุณมีชุดเครื่องมือที่ตายตัวเพื่อให้บรรลุเป้าหมายที่กำหนดไว้ล่วงหน้า ออกจากโรงรถคุณเปิดเกียร์ถอยหลังและกดแก๊ส เมื่อเลี้ยวซ้ายคุณหมุนพวงมาลัยไปทางซ้าย คุณไม่มีโอกาสทำสิ่งเดียวกันในรูปแบบต่างๆ เนื่องจากระบบทั้งหมดมีความแม่นยำและมีการประสานงานกันอย่างมาก และแต่ละองค์ประกอบจะเชื่อมต่อกับองค์ประกอบอื่นๆ
อู๊ดดี้
UDDI เป็นมาตรฐานสำหรับการสร้างแค็ตตาล็อกของบริการบนเว็บที่ให้บริการโดยโปรแกรมจำนวนเท่าใดก็ได้ มันเหมือนกับสมุดโทรศัพท์สำหรับผู้ให้บริการเว็บ ลูกค้าสามารถค้นหาข้อมูลที่ต้องการได้ในรีจิสทรี UDDI และรีจิสทรีจะส่งคืนข้อมูลที่จำเป็นในการเชื่อมต่อกับบริการ
แม้ว่า UDDI จะเป็นมาตรฐานที่ค่อนข้างสำคัญสำหรับการกำหนดบริการบนเว็บ แต่ความสำคัญของมันก็ลดลงอย่างมากเนื่องจากเป็นองค์ประกอบทางเลือกของบริการบนเว็บ และเมื่อได้รับตัวเลือกให้ใช้หรือไม่ หลายคนเลือกที่จะไม่ใช้
สภาพแวดล้อมองค์กรส่วนใหญ่ที่มีบริการเว็บภายในจำนวนมากมีการลงทะเบียน UDDI การมีไซต์ของบริษัท UDDI ที่มีข้อมูลเกี่ยวกับบริการบนเว็บที่มีอยู่ในบริษัทของคุณถือเป็นเรื่องดี ด้วยการรวมบริการทั้งหมดเข้าด้วยกัน UDDI ช่วยให้คุณสามารถเปลี่ยนผู้ให้บริการได้อย่างราบรื่นและไร้รอยต่อ หากลูกค้าค้นหาบริการผ่าน UDDI การโทร SOAP จะถูกส่งไปยังผู้ให้บริการรายใหม่โดยอัตโนมัติ
อย่างไรก็ตาม ส่วนประกอบนี้ไม่จำเป็นในสถาปัตยกรรมบริการเว็บ
ความปลอดภัยของบริการเว็บ
เมื่ออ่านเกี่ยวกับ SOAP และ WSDL คุณอาจสังเกตเห็นว่าไม่ครอบคลุมหัวข้อความปลอดภัย การตรวจสอบความถูกต้องดำเนินการอย่างไรเมื่อเรียกใช้บริการ หากผู้ให้บริการทำงานกับข้อมูลที่ละเอียดอ่อน ท้ายที่สุดเป็นที่ชัดเจนว่าบริการบนเว็บบางอย่างนั้นไม่พร้อมให้บริการแก่บุคคลทั่วไปใช่ไหม
นี่เป็นคำถามที่สำคัญซึ่งไม่ง่ายที่จะตอบอย่างชัดเจน มีรูปแบบต่างๆ ที่คุณสามารถใช้ได้ขึ้นอยู่กับสถานการณ์ ตัวอย่างเช่น:
- ข้อความ SOAP สามารถเป็นข้อความธรรมดาได้หรือไม่ หรือจำเป็นต้องเข้ารหัสหรือไม่
- การเข้าสู่ระบบและการตรวจสอบรหัสผ่านอย่างง่ายเพียงพอสำหรับคุณหรือไม่ หรือควรเป็นแบบรัดกุมและใช้เครื่องหมาย
- หากมีการใช้โทเค็น จำเป็นต้องเซ็นชื่อหรือไม่ และวิธีที่ถูกต้องในการรวมโทเค็นไว้ในข้อความ SOAP คืออะไร
- แต่จะเป็นอย่างไรหากไคลเอ็นต์ไม่ส่งข้อความ SOAP โดยตรง แต่ผ่านโครงสร้างระดับกลางบางอย่าง เช่น คิวข้อความหรือผ่านบริการเว็บอื่นๆ
นอกจากนี้ การส่งข้อความไม่สามารถใช้ HTTP ได้เสมอ ดังนั้นคุณจึงไม่สามารถใช้การรักษาความปลอดภัยบริการเว็บนอกเหนือจากการรักษาความปลอดภัย HTTP ที่มีอยู่เท่านั้น
มีแนวทางหลายประการที่ครอบคลุมสิ่งเหล่านี้และแง่มุมอื่นๆ ของการรักษาความปลอดภัยบริการเว็บ: WS-Security, WS-Policy, WS-Trust และ WS-Privacy ผู้จำหน่ายซอฟต์แวร์และคณะกรรมการบางส่วนได้ดำเนินการแก้ไขปัญหาเหล่านี้มาเป็นเวลาหลายปีแล้ว แม้ว่าการใช้งานเว็บเซอร์วิสทั้งหมดจะไม่สนับสนุนคำแนะนำด้านความปลอดภัยทั้งหมด แต่โดยทั่วไปแล้วมาตรฐานความปลอดภัยที่มีอยู่จะใช้พาธความปลอดภัยพื้นฐานอย่างน้อยสองสามพาธ
Middleware และ Enterprise Service Bus
มีชุดมาตรฐานที่ค่อนข้างใหญ่อีกชุดหนึ่งสำหรับบริการบนเว็บ ซึ่งรวมเข้าด้วยกันเป็นชุดเดียวที่ค่อนข้างใหญ่ ซึ่งเรียกกันโดยทั่วไปว่าคำสั่ง WS-* เมื่อรวมกันแล้วจะครอบคลุมปัญหาการออกแบบมากมายที่เกิดขึ้นเมื่อคุณรวบรวมบริการเว็บจำนวนมากไว้ในสภาพแวดล้อมเดียว มาตรฐาน WS-* จัดการกับปัญหาต่างๆ เช่น:
- ความปลอดภัย
- ความน่าเชื่อถือ
- การแลกเปลี่ยนข้อความ
- ธุรกรรม
- คุณภาพของการบริการ
จำนวนมาตรฐานนี้จำเป็นเนื่องจากการส่งข้อความระหว่างไคลเอนต์บริการเว็บและเซิร์ฟเวอร์ในสภาพแวดล้อมการผลิตอาจซับซ้อนกว่าคำขอ/ตอบกลับธรรมดามาก ตัวอย่างเช่น คุณจะแน่ใจได้อย่างไรว่าข้อความไปถึงผู้ให้บริการและส่งกลับไปยังลูกค้า จะเกิดอะไรขึ้นหากคำขอ SOAP มีหลายส่วน คุณจัดการกระบวนการที่เกี่ยวข้องกับบริการเว็บที่เข้าถึงบริการเว็บอื่นได้อย่างไร จะเกิดอะไรขึ้นถ้าโปรแกรมส่งลำดับคำขอพร้อมข้อกำหนดด้านเวลาตอบสนอง
สำหรับผู้จำหน่ายซอฟต์แวร์รายใหญ่ การทำงานกับมาตรฐานเหล่านี้มีทั้งความท้าทายและโอกาส ผู้ค้าหลายรายกำลังทำการตลาดแพ็คเกจมิดเดิลแวร์บริการเว็บทั้งหมด ซึ่งมักเรียกว่า Enterprise Service Bus หรือ ESB ซึ่งจัดการกับงานด้านบนทั้งหมดหรืออย่างน้อยบางส่วนพร้อมกัน ESB เหล่านี้ยังมีประโยชน์เนื่องจากสามารถเชื่อมโยงบริการเว็บต่างๆ ภายในองค์กรเดียวกันและจัดเตรียมฟังก์ชันการทำงาน บันทึกการดำเนินการ และจัดเก็บข้อความในคิว
สถาปัตยกรรมเชิงบริการ
และสุดท้าย สถาปัตยกรรมเชิงบริการ ในกรณีส่วนใหญ่ เป็นเพียงการรวมกันของทั้งหมดข้างต้น: บริการเว็บที่เชื่อมโยงกันอย่างหลวมๆ จากผู้ขายหลายราย การโต้ตอบตามมาตรฐานที่ยอมรับ (บางทีกับ ESB) และรวมเข้าด้วยกันโดยโปรแกรมต่างๆ ที่รับข้อมูลจากบริการและใช้งานในรูปแบบต่างๆ .
เนื่องจาก SOA เป็นสถาปัตยกรรมซอฟต์แวร์ จึงมีการประสานงานและการวางแผนมากมายในการสร้างมันขึ้นมา ไม่ใช่แค่บริการหลายอย่างที่ผสมผสานกัน เป็นองค์กรของวิธีการรวบรวมและเผยแพร่บริการ เครื่องมือการจัดการและมิดเดิลแวร์ใดที่ใช้ และวิธีการตรวจสอบและจัดการบริการและระบบโดยรวม
หากคุณมองโลกในแง่ดีมากขึ้น SOA ก็เป็นวิธีคิดประเภทหนึ่งเช่นกัน มันบังคับให้เราไม่คิดถึงโปรแกรมขนาดใหญ่ที่เป็นอิสระ แต่ให้มองว่าทุกอย่างเป็นส่วนประกอบที่เป็นไปได้ที่สามารถเผยแพร่และใช้ในการผลิตได้ แทนที่จะนึกถึงแอปพลิเคชันที่หลากหลาย คุณนึกถึงบริการเฉพาะและมีการกำหนดไว้อย่างดี ซึ่งก็คือบริการบนเว็บนั่นเอง
ทำไมมันถึงสำคัญ?
ถึงตอนนี้ คุณรู้เรื่องหนึ่งหรือสองเกี่ยวกับวิธีการทำงานของบริการเว็บแล้ว - ไคลเอนต์จะอ่านไฟล์ WSDL ของผู้ให้บริการ จัดรูปแบบและส่งข้อความ SOAP ตามนั้น และได้รับข้อความ SOAP อื่นตอบกลับ เหตุใดจึงสำคัญนัก เกิดอะไรขึ้น?
ส่วนหนึ่งของความสำคัญของบริการอยู่ที่การจัดเตรียมวิธีมาตรฐานสำหรับโปรแกรมในการสื่อสาร โดยไม่คำนึงถึงภาษาที่เขียนหรือแพลตฟอร์มที่ใช้งาน ก่อนหน้านี้ เราต้องทำงานกับรูปแบบข้อมูลเฉพาะของโปรแกรมต่างๆ หรือกับฟังก์ชันระดับ API ที่โปรแกรมในภาษาอื่นไม่สามารถทำงานได้ จากการใช้ XML ในมาตรฐานบริการเว็บทั้งหมด หมายความว่าบริการทั้งหมดสามารถเข้าถึงได้และมีการกำหนดไว้อย่างชัดเจน
ในความเป็นจริง สิ่งนี้ทำให้โปรแกรมที่แตกต่างกันอย่างสิ้นเชิงสามารถสื่อสารกันในภาษาที่พวกเขาเข้าใจได้ง่าย หนึ่งในความท้าทายหลักในการทำงานกับเทคโนโลยีต่างๆ จากผู้ผลิตหลายรายคือความต้องการใช้โปรแกรมต่างๆ เหล่านี้เพื่อสื่อสารระหว่างกันและแลกเปลี่ยนข้อมูล เมื่อแอปพลิเคชันทั้งหมดของคุณสามารถจัดหาและ/หรือใช้บริการเว็บได้แล้ว การสื่อสารระหว่างกันจึงเป็นเรื่องง่ายอย่างเหลือเชื่อ
ข้อดีอีกประการของบริการบนเว็บคือลูกค้าและผู้ขายสามารถใช้งานเครื่องที่แตกต่างกัน โดยใช้ฮาร์ดแวร์และซอฟต์แวร์ที่แตกต่างกัน โดยไม่รบกวนการสื่อสาร สามารถใช้โปรแกรมโดยโปรแกรมอื่นภายในเครื่องเดียวกันหรือจากเครื่องอื่นได้ แต่ใช้รูปแบบการถ่ายโอนข้อมูลเฉพาะ บริการบนเว็บต้องการเพียงการเชื่อมต่อเครือข่ายและตัวจัดการ XML
เมื่อนำปัจจัยเหล่านี้มาพิจารณารวมกัน ผลลัพธ์ที่ได้ก็มีนัยสำคัญ เมื่อเรามี การรักษามาตรฐานสำหรับการสื่อสารระหว่างแอปพลิเคชันบนเครือข่าย เราสามารถสร้างโปรแกรมของเราด้วยวิธีอื่นได้ แทนที่จะเขียนโปรแกรมแบบเสาหินซึ่งวงล้อถูกประดิษฐ์ขึ้นใหม่ทุกครั้ง เราสามารถเขียนโปรแกรมที่ประกอบด้วยโมดูล
ตัวอย่างเช่น แทนที่จะเป็นโปรแกรมขนาดใหญ่ที่รวบรวมข้อมูลเกี่ยวกับกระบวนการต่างๆ เปลี่ยนเป็นกราฟและแสดงให้ผู้ใช้เห็น เราสามารถสร้างแดชบอร์ดที่จะแสดงข้อมูลที่ได้รับจากบริการบนเว็บต่างๆ ได้รับข้อมูลที่คอมไพล์แล้วจากบริการอย่างน้อยหนึ่งบริการ และแปลงผลลัพธ์จะถูกสร้างขึ้นโดยบริการบนเว็บอื่นที่รับข้อมูลและสร้างพล็อตบางประเภท
แดชบอร์ดถูกแปลงจากโปรแกรมขนาดใหญ่เป็นอินเทอร์เฟซที่เรียบง่าย เมื่อเราต้องการเพิ่มส่วนประกอบใหม่ เราก็เพียงแค่เรียกใช้บริการเพิ่มเติม หากเราต้องการแผนภูมิอื่น เราจะหันไปใช้บริการแผนภูมิอื่น หากเราต้องการแดชบอร์ดที่มีการโต้ตอบมากขึ้น พร้อมความสามารถในการเรียนรู้หรือจัดเรียง แดชบอร์ดก็สามารถส่งข้อความจากผู้ใช้ไปยังบริการที่เหมาะสมได้ เรายังสามารถเปลี่ยนบริการที่เรียกใช้โดยที่ผู้ใช้ไม่สังเกตเห็น (จนกว่าไฟล์ WSDL จะเปลี่ยนแปลง) และแผงควบคุมยังคงเหมือนเดิม
ในฐานะผู้เชี่ยวชาญด้าน IT คุณสามารถพัฒนาส่วนหน้า พัฒนาบริการ หรือทั้งสองอย่าง การทำความเข้าใจว่ามันทำงานร่วมกันอย่างไร (หรืออย่างน้อยก็รู้ว่ามันคืออะไร) เป็นสิ่งสำคัญสำหรับการทำงานในโครงการเช่นนี้
ยังดีที่มีเครื่องมือมากมายที่จะช่วยให้คุณส่งและใช้บริการเว็บและสามารถทำงานอย่างหนักให้กับคุณได้ ในส่วนต่อไปนี้ของบทความนี้ เราจะดูว่าคุณสามารถให้บริการเว็บแก่ไคลเอนต์หรือระบบโดยใช้ IBM Lotus Domino V7.0 ได้อย่างไร
