XML Web Services เป็นองค์ประกอบพื้นฐานสำหรับการคำนวณแบบกระจายบนอินเทอร์เน็ต มาตรฐานแบบเปิดและการมุ่งเน้นไปที่การสื่อสารและการทำงานร่วมกันระหว่างผู้ใช้และแอปพลิเคชันได้สร้างสภาพแวดล้อมที่ XML Web Services กลายเป็นแพลตฟอร์มสำหรับการรวมแอปพลิเคชัน แอปพลิเคชันถูกสร้างขึ้นโดยใช้ XML Web Services จากแหล่งต่างๆ มากมายที่ทำงานร่วมกัน โดยไม่คำนึงว่าแอปพลิเคชันเหล่านั้นอยู่ที่ใดหรือใช้งานอย่างไร
มีคำจำกัดความ XML Web Service มากมายพอๆ กับที่มีบริษัทที่สร้าง XML Web Services แต่คำจำกัดความเกือบทั้งหมดมีสิ่งที่เหมือนกันดังต่อไปนี้:
XML Web Services ให้ฟังก์ชันการทำงานที่เป็นประโยชน์แก่ผู้ใช้เว็บผ่านโปรโตคอลเว็บมาตรฐาน ในกรณีส่วนใหญ่ จะใช้โปรโตคอล SOAP
XML Web Services สามารถระบุอินเทอร์เฟซของตนได้อย่างละเอียด ซึ่งช่วยให้ผู้ใช้สามารถสร้างแอปพลิเคชันไคลเอนต์เพื่อสื่อสารกับพวกเขาได้ โดยทั่วไปคำอธิบายนี้จะมีอยู่ในเอกสาร XML ที่เรียกว่าเอกสาร Web Services Description Language (WSDL)
XML Web Services ได้รับการลงทะเบียนเพื่อให้ผู้ใช้ที่มีศักยภาพสามารถค้นหาได้อย่างง่ายดาย ซึ่งทำได้ผ่าน Universal Discovery, Description และ Integration (UDDI)
บทความนี้จะแนะนำเทคโนโลยีทั้งสามนี้ แต่ก่อนอื่น เราต้องอธิบายว่าทำไมคุณจึงควรใส่ใจกับ XML Web Services
ข้อดีหลักประการหนึ่งของสถาปัตยกรรม XML Web Services คือช่วยให้โปรแกรมต่างๆ ที่เขียนในภาษาต่างๆ บนแพลตฟอร์มที่แตกต่างกัน สามารถสื่อสารกันในลักษณะที่เป็นมาตรฐานได้ ผู้ใช้ที่รู้บางอย่างเกี่ยวกับอุตสาหกรรมนี้อาจพูดทันทีว่า: "เดี๋ยวก่อน CORBA และ DCE รุ่นก่อนไม่ได้ให้คำมั่นสัญญาแบบเดียวกันนี้หรือ ความแตกต่างระหว่างสิ่งนี้กับพวกเขาคืออะไร" ความแตกต่างที่สำคัญที่สุดคือ: SOAP ดีกว่าเมื่อก่อน แนวทางนี้ง่ายกว่ามาก ดังนั้นจึงมีอุปสรรคน้อยกว่ามากในการใช้ SOAP ที่เป็นไปตามมาตรฐาน Paul Kulchenko จัดทำรายการการใช้งาน SOAP ไว้ที่ http://www.soapware.org/directory/4/implementations (เป็นภาษาอังกฤษ) สุดท้ายมีรายการทั้งหมด 79 รายการ ตามที่คุณอาจคาดหวัง บริษัทซอฟต์แวร์รายใหญ่ส่วนใหญ่จะจัดเตรียมการใช้งาน SOAP แต่ก็มีการใช้งานจำนวนมากที่สร้างและดูแลรักษาโดยนักพัฒนาแต่ละราย ข้อได้เปรียบที่สำคัญอีกประการหนึ่งของ XML Web Services เหนือโซลูชันก่อนหน้านี้คือการใช้โปรโตคอลเว็บมาตรฐาน - XML, HTTP และ TCP/IP บริษัทหลายแห่งได้สร้างโครงสร้างพื้นฐานของเว็บไว้แล้ว และพนักงานมีความรู้และประสบการณ์ในการดูแลรักษาโครงสร้างพื้นฐานดังกล่าว ดังนั้นค่าใช้จ่ายในการแนะนำ XML Web Services จึงต่ำกว่าการแนะนำเทคโนโลยีก่อนหน้านี้มาก
เรากำหนด XML Web Service เป็นบริการซอฟต์แวร์ที่มีให้บนเว็บผ่าน SOAP ซึ่งอธิบายโดยใช้ไฟล์ WSDL และลงทะเบียนผ่าน UDDI ดังนั้น คุณอาจถามว่า: "คุณสามารถทำอะไรกับ XML Web Services ได้บ้าง" XML Web Services ดั้งเดิมมักเป็นแหล่งข้อมูลที่สามารถรวมเข้ากับแอปพลิเคชันต่างๆ ได้อย่างง่ายดาย เช่น ราคาหุ้น พยากรณ์อากาศ คะแนนกีฬา และอื่นๆ เป็นเรื่องง่ายที่จะจินตนาการถึงแอปพลิเคชันทั้งระดับที่สามารถสร้างขึ้นเพื่อวิเคราะห์และสรุปข้อมูลที่คุณสนใจ และทำให้ข้อมูลนั้นพร้อมใช้งานในหลากหลายวิธี ตัวอย่างเช่น คุณสามารถใช้สเปรดชีต Microsoft® Excel เพื่อสรุปทางการเงินทั้งหมดของคุณ ข้อมูล—หุ้น 401K เงินฝากธนาคาร สินเชื่อ ฯลฯ หากข้อมูลนี้พร้อมใช้งานผ่าน XML Web Services แล้ว Excel จะสามารถอัปเดตข้อมูลได้อย่างต่อเนื่อง ข้อมูลบางส่วนนี้เป็นข้อมูลฟรี และบางส่วนอาจต้องสมัครสมาชิกเพื่อรับบริการที่เกี่ยวข้อง ข้อมูลส่วนใหญ่มีอยู่แล้วบนเว็บ แต่ XML Web Services สามารถทำให้การเข้าถึงทางโปรแกรมง่ายขึ้นและเชื่อถือได้มากขึ้น
แอปพลิเคชันที่มีอยู่จะพร้อมใช้งานในรูปแบบ XML Web Services และแอปพลิเคชันใหม่ที่มีประสิทธิภาพยิ่งขึ้นสามารถสร้างขึ้นได้โดยใช้ XML Web Services เป็นแบบเอกสารสำเร็จรูป ตัวอย่างเช่น ผู้ใช้สามารถพัฒนาแอปพลิเคชันการจัดซื้อเพื่อรับข้อมูลราคาจากซัพพลายเออร์ต่างๆ โดยอัตโนมัติ ทำให้ผู้ใช้สามารถเลือกซัพพลายเออร์ ส่งคำสั่งซื้อ และติดตามการจัดส่งสินค้าจนกระทั่งได้รับสินค้า นอกเหนือจากการให้บริการบนเว็บแล้ว แอปพลิเคชันของซัพพลายเออร์ยังสามารถใช้ XML Web Service เพื่อตรวจสอบเครดิตของลูกค้า เก็บเงิน และจัดการขั้นตอนการขนส่งสินค้ากับบริษัทขนส่งสินค้า
ในอนาคต แอปพลิเคชันที่ขับเคลื่อนด้วย XML Web Services ที่น่าสนใจที่สุดบางส่วนจะสามารถใช้ประโยชน์จากเว็บเพื่อทำงานที่เป็นไปไม่ได้ในปัจจุบันให้สำเร็จได้ ตัวอย่างเช่น บริการปฏิทินเป็นหนึ่งในบริการที่จะได้รับการสนับสนุนโดยโครงการ Microsoft .NET My Services (ภาษาอังกฤษ) หากทันตแพทย์และช่างเครื่องของคุณแจ้งกำหนดการผ่านบริการเว็บ XML นี้ คุณสามารถกำหนดเวลาการนัดหมายกับพวกเขาผ่านทางเว็บได้ หากต้องการ พวกเขายังสามารถกำหนดเวลาการทำความสะอาดและวันที่บำรุงรักษาตามปกติในปฏิทินของคุณได้โดยตรง เป็นเรื่องง่ายที่จะจินตนาการว่าหากคุณสามารถเขียนโปรแกรมเว็บได้ คุณจะสามารถสร้างแอปพลิเคชันได้หลายร้อยรายการ
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ XML Web Services และแอปพลิเคชันที่คุณสามารถสร้างได้ โปรดดูที่โฮมเพจ MSDN Web Services (ภาษาอังกฤษ)
SOAP
SOAP เป็นโปรโตคอลการสื่อสารของ XML Web Service เมื่ออธิบาย SOAP เป็นโปรโตคอลการสื่อสาร คนส่วนใหญ่นึกถึง DCOM หรือ CORBA และถามคำถามเช่น "SOAP เปิดใช้งานวัตถุอย่างไร" หรือ "SOAP ใช้บริการตั้งชื่ออะไร" แม้ว่าการใช้งาน SOAP อาจมีองค์ประกอบเหล่านี้ แต่ก็ไม่ได้ระบุไว้ในมาตรฐาน SOAP SOAP ข้อกำหนดที่กำหนดรูปแบบ XML ของข้อความ - นี่เป็นส่วนที่จำเป็นของข้อกำหนด เซ็กเมนต์ XML ที่มีรูปแบบดีซึ่งอยู่ภายในคู่ขององค์ประกอบ SOAP คือข้อความ SOAP มันไม่ง่ายเหรอ?
ส่วนอื่นๆ ของข้อกำหนด SOAP อธิบายวิธีการแสดงข้อมูลโปรแกรมเป็น XML และวิธีการใช้ SOAP สำหรับการเรียกขั้นตอนระยะไกล (RPC) ส่วนเสริมของข้อกำหนดเหล่านี้ใช้เพื่อใช้แอปพลิเคชันสไตล์ RPC โดยที่ไคลเอ็นต์จะออกข้อความ SOAP (ประกอบด้วยฟังก์ชันที่เรียกใช้ได้ และพารามิเตอร์ที่จะส่งผ่านไปยังฟังก์ชัน) และเซิร์ฟเวอร์จะส่งคืนข้อความที่มีผลลัพธ์ ของการดำเนินฟังก์ชัน ในปัจจุบัน การใช้งาน SOAP ส่วนใหญ่รองรับแอปพลิเคชัน RPC เนื่องจากโปรแกรมเมอร์ที่คุ้นเคยกับการพัฒนาแอปพลิเคชัน COM หรือ CORBA มีความคุ้นเคยกับรูปแบบ RPC SOAP ยังสนับสนุนแอปพลิเคชันรูปแบบเอกสาร ซึ่งข้อความ SOAP เป็นเพียงตัวล้อมรอบเอกสาร XML แอปพลิเคชัน SOAP ที่ใช้เอกสารมีความยืดหยุ่นสูง และบริการเว็บ XML ใหม่จำนวนมากใช้ประโยชน์จากคุณลักษณะนี้เพื่อสร้างบริการที่ยากต่อการนำไปใช้โดยใช้ RPC
ส่วนทางเลือกสุดท้ายของข้อกำหนด SOAP กำหนดรูปแบบของข้อความ HTTP ที่มีข้อความ SOAP การเชื่อมโยง HTTP นี้มีความสำคัญเนื่องจากระบบปฏิบัติการปัจจุบันเกือบทั้งหมด (และระบบปฏิบัติการก่อนหน้านี้จำนวนมาก) รองรับ HTTP แม้ว่าเป็นทางเลือก แต่การเชื่อมโยง HTTP ได้รับการสนับสนุนโดยการใช้งาน SOAP เกือบทั้งหมด เนื่องจากเป็นโปรโตคอลมาตรฐานเพียงตัวเดียวสำหรับ SOAP ด้วยเหตุนี้ ผู้คนจึงมักเข้าใจผิดว่า SOAP ต้องใช้ HTTP การใช้งานบางอย่างยังรองรับการขนส่ง MSMQ, MQ Series, SMTP หรือ TCP/IP ด้วย แต่เนื่องจาก HTTP แพร่หลายมาก XML Web Services ในปัจจุบันเกือบทั้งหมดจึงใช้งาน เนื่องจาก HTTP เป็นโปรโตคอลหลักของเว็บ โครงสร้างพื้นฐานเครือข่ายขององค์กรส่วนใหญ่จึงรองรับ HTTP และพนักงานก็รู้วิธีจัดการอยู่แล้ว ปัจจุบัน โครงสร้างพื้นฐานสำหรับการรักษาความปลอดภัย HTTP การตรวจสอบ และการปรับสมดุลโหลดได้ถูกสร้างขึ้นแล้ว
เมื่อเริ่มใช้ SOAP สิ่งที่น่าสับสนที่สุดคือความแตกต่างระหว่างข้อกำหนด SOAP และการใช้งานหลายอย่าง ผู้ใช้ SOAP ส่วนใหญ่ไม่ได้เขียนข้อความ SOAP โดยตรง แต่ใช้ชุดเครื่องมือ SOAP เพื่อสร้างและวิเคราะห์ข้อความ SOAP โดยทั่วไปชุดเครื่องมือเหล่านี้จะแปลงการเรียกใช้ฟังก์ชันจากภาษาเป็นข้อความ SOAP ตัวอย่างเช่น Microsoft SOAP Toolkit 2.0 แปลงการเรียกฟังก์ชัน COM เป็น SOAP และ Apache Toolkit แปลงการเรียกฟังก์ชัน JAVA เป็น SOAP ประเภทของการเรียกฟังก์ชันและประเภทข้อมูลพารามิเตอร์ที่รองรับจะแตกต่างกันไปตามการใช้งาน SOAP แต่ละครั้ง ดังนั้นฟังก์ชันที่ใช้ได้กับชุดเครื่องมือหนึ่งอาจไม่ทำงานกับชุดเครื่องมืออื่น นี่ไม่ใช่ข้อจำกัดของ SOAP แต่เป็นการใช้งานเฉพาะที่ใช้
คุณลักษณะที่น่าสนใจที่สุดของ SOAP คือสามารถนำไปใช้กับแพลตฟอร์มซอฟต์แวร์และฮาร์ดแวร์ที่แตกต่างกันได้มากมาย ซึ่งหมายความว่า SOAP สามารถใช้เพื่อเชื่อมโยงระบบที่แตกต่างกันทั้งภายในและภายนอกองค์กร ในอดีตมีการลองใช้วิธีการต่างๆ มากมายเพื่อให้ได้โปรโตคอลการสื่อสารทั่วไปที่สามารถใช้สำหรับการรวมระบบ แต่ไม่มีวิธีใดที่ SOAP มีได้รับการยอมรับอย่างกว้างขวาง ทำไม เนื่องจาก SOAP มีขนาดเล็กกว่าและใช้งานง่ายกว่าโปรโตคอลรุ่นก่อนๆ ตัวอย่างเช่น DCE และ CORBA ใช้เวลาหลายปีในการดำเนินการ จึงมีการเปิดตัวการใช้งานเพียงไม่กี่รายการเท่านั้น SOAP สามารถใช้ประโยชน์จากตัวแยกวิเคราะห์ XML และไลบรารี HTTP ที่มีอยู่เพื่อทำงานหนักส่วนใหญ่ ดังนั้นการนำ SOAP ไปใช้จึงจะแล้วเสร็จภายในเวลาไม่กี่เดือน ด้วยเหตุนี้จึงมีการใช้งาน SOAP มากกว่า 70 รายการ แน่นอนว่า SOAP ไม่มีฟังก์ชันทั้งหมดของ DCE หรือ CORBA แม้ว่าฟังก์ชันต่างๆ จะลดลง แต่ SOAP ก็ใช้งานได้ง่ายกว่าเนื่องจากความซับซ้อนลดลงอย่างมาก
ความนิยมของ HTTP และความเรียบง่ายของ SOAP ทำให้คุณสามารถเรียกได้จากเกือบทุกสภาพแวดล้อม ทำให้เป็นรากฐานในอุดมคติสำหรับบริการเว็บ XML สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ SOAP โปรดดูโฮมเพจ MSDN SOAP (ภาษาอังกฤษ)
ปลอดภัยแค่ไหน?
บ่อยครั้ง คำถามแรกที่ผู้ใช้ที่เพิ่งเริ่มใช้ SOAP ถามคือ SOAP แก้ไขปัญหาด้านความปลอดภัยได้อย่างไร ในขั้นตอนการพัฒนาช่วงแรก SOAP ถูกมองว่าเป็นโปรโตคอลที่ใช้ HTTP ดังนั้นความปลอดภัยของ HTTP จึงถือว่าเพียงพอสำหรับ SOAP ท้ายที่สุดแล้ว ขณะนี้มีเว็บแอปพลิเคชันหลายพันรายการที่ใช้ความปลอดภัย HTTP ดังนั้นนี่จึงเพียงพอสำหรับ SOAP อย่างแน่นอน ดังนั้น มาตรฐาน SOAP ปัจจุบันจึงสันนิษฐานว่าความปลอดภัยเป็นปัญหาด้านการขนส่ง และไม่ถือว่าเป็นปัญหาด้านความปลอดภัย
เมื่อ SOAP ขยายไปสู่โปรโตคอลทั่วไปมากขึ้นและทำงานบนการขนส่งจำนวนมาก ปัญหาด้านความปลอดภัยก็มีความสำคัญมากขึ้น ตัวอย่างเช่น HTTP มีหลายวิธีในการตรวจสอบสิทธิ์ผู้ใช้ที่ทำการเรียก SOAP แต่ข้อมูลประจำตัวนั้นจะเผยแพร่อย่างไรเมื่อข้อความถูกกำหนดเส้นทางจากการขนส่ง HTTP ไปยัง SMTP SOAP ได้รับการออกแบบให้เป็นโปรโตคอลแบบเอกสารสำเร็จรูป ดังนั้นโชคดีที่มีข้อกำหนดเฉพาะเพื่อมอบคุณลักษณะด้านความปลอดภัยเพิ่มเติมสำหรับบริการบนเว็บที่ใช้ SOAP ข้อกำหนด WS-Security (ภาษาอังกฤษ) กำหนดระบบการเข้ารหัสที่สมบูรณ์ และข้อกำหนด WS-License (ภาษาอังกฤษ) กำหนดเทคโนโลยีที่เกี่ยวข้องเพื่อให้แน่ใจว่าข้อมูลประจำตัวของผู้โทรและรับรองว่าเฉพาะผู้ใช้ที่ได้รับอนุญาตเท่านั้นที่สามารถใช้บริการเว็บได้
WSDL
WSDL (ภาษาคำอธิบายบริการเว็บ) ย่อมาจากภาษาคำอธิบายบริการเว็บ สำหรับวัตถุประสงค์ของบทความนี้ เราสามารถนึกถึงไฟล์ WSDL ว่าเป็นเอกสาร XML ที่อธิบายชุดของข้อความ SOAP และวิธีการแลกเปลี่ยน กล่าวอีกนัยหนึ่ง WSDL คือ SOAP สิ่งที่ IDL คือ CORBA หรือ COM เนื่องจาก WSDL เป็นเอกสาร XML จึงง่ายต่อการอ่านและแก้ไข แต่โดยส่วนใหญ่แล้ว ซอฟต์แวร์จะสร้างและใช้งาน
หากต้องการดูค่าของ WSDL ลองจินตนาการว่าคุณต้องการเรียกใช้วิธี SOAP ที่พันธมิตรทางธุรกิจรายใดรายหนึ่งของคุณให้มา คุณสามารถขอตัวอย่างข้อความ SOAP จากนั้นเขียนแอปพลิเคชันของคุณเพื่อสร้างและใช้ข้อความที่คล้ายกับตัวอย่าง แต่อาจเกิดข้อผิดพลาดได้ง่าย ตัวอย่างเช่น คุณอาจเห็นรหัสลูกค้า 2837 และถือว่าเป็นจำนวนเต็ม ซึ่งจริงๆ แล้วเป็นสตริง WSDL ระบุผ่านสัญกรณ์ที่ชัดเจนว่าข้อความคำขอต้องมีอะไร และข้อความตอบกลับควรมีลักษณะอย่างไร
สัญกรณ์ที่ใช้โดยไฟล์ WSDL เพื่ออธิบายรูปแบบข้อความเป็นไปตามมาตรฐาน XML Schema ซึ่งหมายความว่าเป็นภาษาโปรแกรมที่ไม่เชื่อเรื่องพระเจ้าและเป็นไปตามมาตรฐาน ทำให้เหมาะสำหรับการอธิบาย XML Web Services ที่สามารถเข้าถึงได้จากแพลตฟอร์มที่แตกต่างกันและในการเขียนโปรแกรมที่แตกต่างกัน ภาษา นอกเหนือจากการอธิบายเนื้อหาของข้อความแล้ว WSDL ยังกำหนดตำแหน่งของบริการและโปรโตคอลการสื่อสารใดที่ใช้ในการสื่อสารกับบริการ นั่นคือไฟล์ WSDL กำหนดทุกสิ่งที่จำเป็นในการเขียนโปรแกรมที่ใช้ XML Web Services มีเครื่องมือหลายอย่างที่สามารถอ่านไฟล์ WSDL และสร้างโค้ดที่จำเป็นในการสื่อสารกับบริการเว็บ XML เครื่องมือที่ทรงพลังที่สุดบางส่วนสามารถพบได้ใน Microsoft Visual Studio® .NET
ปัจจุบัน ชุดเครื่องมือ SOAP จำนวนมากมีเครื่องมือสำหรับสร้างไฟล์ WSDL จากอินเทอร์เฟซโปรแกรมที่มีอยู่ แต่มีเครื่องมือไม่กี่รายการสำหรับการเขียน WSDL โดยตรง และการสนับสนุนเครื่องมือสำหรับ WSDL ยังไม่สมบูรณ์ แต่เร็วๆ นี้จะมีเครื่องมือสำหรับเขียนไฟล์ WSDL ตามมาด้วยเครื่องมือสำหรับสร้างพรอกซีและสตับ (เหมือนกับเครื่องมือ COM IDL) และเครื่องมือเหล่านี้จะกลายเป็นส่วนหนึ่งของการใช้งาน SOAP ส่วนใหญ่ ก่อนหน้านั้น WSDL จะกลายเป็นวิธีการที่ต้องการสำหรับการสร้างอินเทอร์เฟซ SOAP ไปยังบริการเว็บ XML
มีคำอธิบายที่ดีมากเกี่ยวกับ WSDL ที่นี่ (เป็นภาษาอังกฤษ) และคุณสามารถค้นหาข้อกำหนด WSDL ได้ที่ http://www.w3.org/TR/wsdl (เป็นภาษาอังกฤษ)
UDDI
Universal Discovery, Description, and Integration (UDDI) คือสมุดหน้าเหลืองของบริการบนเว็บ เช่นเดียวกับสมุดหน้าเหลืองแบบดั้งเดิม คุณสามารถค้นหาบริษัทที่นำเสนอบริการที่คุณต้องการ อ่านเพื่อเรียนรู้เกี่ยวกับบริการที่นำเสนอ จากนั้นติดต่อบุคคลอื่นเพื่อขอข้อมูลเพิ่มเติม แน่นอน คุณสามารถให้บริการบนเว็บได้โดยไม่ต้องลงทะเบียนใน UDDI ซึ่งเหมือนกับการดำเนินธุรกิจในห้องใต้ดินของคุณและอาศัยการบอกต่อ แต่ถ้าคุณต้องการขยายตลาดของคุณ คุณต้องมี UDDI เพื่อที่คุณจะได้ถูกค้นพบโดยคุณ ลูกค้า
รายการไดเร็กทอรี UDDI คือไฟล์ XML ที่อธิบายบริการและบริการที่มีให้ รายการไดเร็กทอรี UDDI ประกอบด้วยสามส่วน "สมุดหน้าขาว" แนะนำบริษัทที่ให้บริการ: ชื่อ ที่อยู่ ข้อมูลการติดต่อ ฯลฯ "สมุดหน้าเหลือง" รวมถึงหมวดหมู่อุตสาหกรรมตามการจำแนกประเภทมาตรฐาน (เช่น ระบบการจำแนกประเภทอุตสาหกรรมในอเมริกาเหนือ และการจำแนกประเภทอุตสาหกรรมมาตรฐาน) ข้อมูล เข้าถึงอินเทอร์เฟซของบริการเพื่อให้ผู้ใช้สามารถเขียนแอปพลิเคชันเพื่อใช้บริการเว็บได้ คำจำกัดความของบริการสามารถทำได้ผ่านเอกสาร UDDI ที่เรียกว่าโมเดลประเภท (หรือ tModel) ในกรณีส่วนใหญ่ tModel จะมีไฟล์ WSDL ที่อธิบายอินเทอร์เฟซ SOAP เพื่อเข้าถึงบริการเว็บ XML แต่ tModel มีความยืดหยุ่นสูงและสามารถอธิบายบริการได้เกือบทุกประเภท
ไดเร็กทอรี UDDI ยังมีวิธีการหลายวิธีในการค้นหาบริการที่จำเป็นในการสร้างแอปพลิเคชันของคุณ ตัวอย่างเช่น คุณสามารถค้นหาผู้ให้บริการในตำแหน่งทางภูมิศาสตร์ที่เฉพาะเจาะจง หรือค้นหาประเภทธุรกิจที่เฉพาะเจาะจงได้ จากนั้นไดเรกทอรี UDDI จะให้ข้อมูล รายละเอียดการติดต่อ ลิงก์ และข้อมูลทางเทคนิค เพื่อให้คุณสามารถระบุบริการที่ตรงกับความต้องการของคุณได้
UDDI ช่วยให้คุณค้นหาบริษัทที่ให้บริการเว็บที่คุณต้องการ คุณจะทำอย่างไรถ้าคุณรู้อยู่แล้วว่าคุณต้องการทำธุรกิจกับใคร แต่ยังไม่รู้ว่าจะสามารถเสนออะไรได้อีกบ้าง? ข้อกำหนด WS-Inspection (ภาษาอังกฤษ) ช่วยให้คุณสามารถเรียกดูคอลเลกชันของ XML Web Services ที่มีอยู่บนเซิร์ฟเวอร์เฉพาะเพื่อค้นหาบริการที่คุณต้องการ
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ UDDI โปรดไปที่ http://www.uddi.org/about.html (ภาษาอังกฤษ)
เนื้อหาอื่นๆ
จนถึงตอนนี้ เราได้กล่าวถึงวิธีการสื่อสารกับ XML Web Services (SOAP) วิธีอธิบาย XML Web Services (WSDL) และวิธีค้นหา XML Web Services (UDDI) สิ่งเหล่านี้ก่อให้เกิดชุดข้อกำหนดพื้นฐานที่เป็นพื้นฐานสำหรับการรวมและการรวมแอปพลิเคชัน จากข้อกำหนดพื้นฐานเหล่านี้ บริษัทต่างๆ สามารถสร้างโซลูชันที่ใช้งานได้จริงและได้รับประโยชน์จากโซลูชันเหล่านั้น
เราได้ทำงานหนักมากในการปรับใช้ XML Web Services แต่ยังมีงานอีกมากที่ต้องทำ ปัจจุบัน ผู้คนประสบความสำเร็จโดยใช้ XML Web Services แต่สำหรับนักพัฒนา ยังมีลิงก์อีกมากมายที่ต้องปรับปรุง ตัวอย่างเช่น ความปลอดภัย การจัดการการดำเนินงาน การประมวลผลธุรกรรม และการส่งข้อความที่เชื่อถือได้ สถาปัตยกรรมบริการเว็บ XML ทั่วโลกจะช่วยให้ XML Web Services ก้าวเข้าสู่วิวัฒนาการขั้นต่อไปโดยจัดให้มีโมเดลทั่วไปที่สอดคล้องกันสำหรับการเพิ่มความสามารถขั้นสูงใหม่ๆ ให้กับ XML Web Services ในลักษณะโมดูลาร์และขยายได้
โมดูลความปลอดภัยที่กล่าวถึงข้างต้น (WS-Security [ภาษาอังกฤษ] และ WS-License [ภาษาอังกฤษ]) เป็นส่วนหนึ่งของข้อกำหนดสถาปัตยกรรมบริการเว็บทั่วโลก ความต้องการด้านการจัดการการปฏิบัติงาน (เช่น การกำหนดเส้นทางข้อความระหว่างเซิร์ฟเวอร์หลายเครื่องและการกำหนดค่าเซิร์ฟเวอร์เหล่านั้นแบบไดนามิกสำหรับการประมวลผล) ยังเป็นส่วนหนึ่งของสถาปัตยกรรมบริการเว็บทั่วโลกผ่านข้อกำหนด WS-Routing (ภาษาอังกฤษ) และข้อกำหนด WS-Referral (ภาษาอังกฤษ) เพื่อให้บรรลุผล ในขณะที่สถาปัตยกรรมบริการเว็บทั่วโลกมีการพัฒนา ข้อมูลจำเพาะที่ตอบสนองความต้องการเหล่านี้และความต้องการอื่นๆ จะถูกนำเสนอ