เรากำลังเขียนแอปพลิเคชันไคลเอนต์เซิร์ฟเวอร์ SOAP ใน PHP บริการเว็บ XML โปรโตคอลสบู่

ประวัติความเป็นมาของการทรงสร้าง

ด้วยการถือกำเนิดของคอมพิวเตอร์ส่วนบุคคล ความจำเป็นในการรวมเข้าด้วยกันก็ปรากฏขึ้นเช่นกัน ในตอนแรกมีการเชื่อมต่อผ่านสายเคเบิลแบบธรรมดา จากนั้นโปรโตคอลเครือข่ายก็ปรากฏว่าคอมพิวเตอร์ที่รวมกันทำงานบนระบบปฏิบัติการเดียวกัน เมื่อมีการพัฒนาเทคโนโลยี ความจำเป็นที่จะต้องมีระบบปฏิบัติการเดียวในคอมพิวเตอร์ทุกเครื่องหายไป และเป็นไปได้ที่จะรวมคอมพิวเตอร์ที่ใช้ระบบปฏิบัติการที่แตกต่างกัน อินเทอร์เน็ตได้เปลี่ยนความเร็วของการเคลื่อนไหวไปตามเส้นทางแห่งการรวมเป็นหนึ่ง

แต่แม้กระทั่งทุกวันนี้ ปัญหาการรวมระบบยังไม่ได้รับการแก้ไขทั้งหมด น่าเสียดายที่ไม่มีโปรโตคอลเดียวสำหรับการสื่อสารระหว่างแอปพลิเคชันอินเทอร์เน็ตและบริการ เพื่อแก้ไขปัญหานี้ บริษัทต่างๆ เช่น Microsoft, DevelopMentor, UserLand Software, IBM และ Lotus Development ได้ร่วมมือกัน และจากกิจกรรมร่วมกันของพวกเขา จึงได้สร้าง Simple Object Access Protocol ซึ่งเป็นโปรโตคอลการเข้าถึงวัตถุอย่างง่ายที่อธิบายมาตรฐานสำหรับขั้นตอนระยะไกล การโทรตามภาษา XML (Extensible Markup Language - ภาษามาร์กอัปที่ขยายได้) SOAP ได้รับการออกแบบมาเพื่อทำให้การพัฒนาแอปพลิเคชันข้ามภาษาและเครื่องมือบูรณาการธุรกิจง่ายขึ้นอย่างมาก จุดเริ่มต้นสร้างด้วย SOAP 1.0 ซึ่งต้องใช้โปรโตคอล HTTP จึงจะทำงาน

หลังจากการปรากฏตัวของ SOAP เวอร์ชันเริ่มต้นซึ่งสร้างขึ้นตามที่ระบุไว้แล้วโดยความพยายามร่วมกันของ Microsoft, DevelopMentor และ UserLand, IBM และ Lotus ได้เข้าร่วมในการพัฒนาผลิตภัณฑ์ ด้วยเหตุนี้ ข้อมูลจำเพาะดังกล่าวจึงได้รับการยกเครื่องใหม่อย่างมีนัยสำคัญเพื่อให้เหมาะสมกับการบูรณาการสภาพแวดล้อมที่แตกต่างกันมากขึ้น ความแตกต่างที่สำคัญระหว่าง SOAP 1.1 เวอร์ชันถัดไปและเวอร์ชันเริ่มต้นคือการเปลี่ยนจาก XML-Data ของ Microsoft ไปเป็น XML Schema นอกจากนี้ ในเวอร์ชันใหม่ ข้อมูลจำเพาะไม่ขึ้นอยู่กับโปรโตคอลการขนส่งอีกต่อไป SOAP 1.0 ต้องใช้โปรโตคอล HTTP ในขณะที่ SOAP 1.1 ประเภทของการขนส่งไม่สำคัญ คุณสามารถใช้อีเมลหรือลิงก์คิวนวดเพื่อส่งต่อข้อความได้ บริษัทต่างๆ ที่ใช้ SOAP 1.0 อยู่แล้วพบว่าตนเองเชื่อมโยงกับเทคโนโลยีที่ไม่ได้มาตรฐานของ Microsoft อย่างไรก็ตาม ผลิตภัณฑ์มีแนวโน้มจำนวนหนึ่งจากบริษัทนี้ รวมถึง BizTalk Server และ SQL Server 7.0 ก็ใช้ XML-Data เช่นกัน ด้วยการมาถึงของเวอร์ชัน 1.1 วงกลมของผู้สนับสนุนโปรโตคอล SOAP กำลังขยายตัว

SOAP 1.1 เวอร์ชันดั้งเดิมที่ส่งไปยัง IETF Internet Technical Task Force ใช้เทคโนโลยี XML-Data ที่เสนอโดย Microsoft ในเดือนมกราคม พ.ศ. 2541 อย่างไรก็ตาม ในระหว่างกระบวนการตรวจสอบมาตรฐาน W3C โครงสร้างพื้นฐานถูกแทนที่ด้วย XML Schema World Wide Web Consortium ถูกขอให้พิจารณา SOAP 1.1 ว่าเป็นมาตรฐานที่เป็นไปได้

ข้อกำหนด Simple Object Access Protocol (SOAP) เวอร์ชันล่าสุดพร้อมใช้งานบนเว็บเซิร์ฟเวอร์ที่ให้บริการสมาชิก MSDN™ Developer Program (http://msdn.microsoft.com/) SOAP เป็นโปรโตคอลแบบเปิดตามมาตรฐานที่กำหนดตาม XML (Extensible Markup Language) ซึ่งเป็นรูปแบบทั่วไปสำหรับการสื่อสารระหว่างแอปพลิเคชันและบริการอินเทอร์เน็ตใดๆ เวอร์ชันนี้ขยายขีดความสามารถของ SOAP สำหรับการสื่อสารแบบอะซิงโครนัสให้ครอบคลุมการรองรับไม่เพียงแต่สำหรับ HTTP เท่านั้น แต่ยังรวมไปถึงอินเทอร์เน็ตโปรโตคอล เช่น SMTP, FTP และ TCP/IP ข้อกำหนด SOAP เวอร์ชันล่าสุดได้รับการสนับสนุนอย่างกว้างขวางจากบริษัทต่างๆ เช่น ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, ซอฟต์แวร์ UserLand และ Zveno Pty. บจ. ข้อมูลจำเพาะ SOAP จัดให้มีกลไกทั่วไปสำหรับการรวมบริการผ่านอินเทอร์เน็ตและ/หรืออินทราเน็ต โดยไม่คำนึงถึงระบบปฏิบัติการ โมเดลออบเจ็กต์ หรือภาษาการเขียนโปรแกรมที่ใช้ ตามมาตรฐานอินเทอร์เน็ต XML และ HTTP นั้น SOAP อนุญาตให้แอปพลิเคชันใหม่หรือที่มีอยู่สามารถสื่อสารระหว่างกันได้ เว็บไซต์ที่รองรับ SOAP สามารถกลายเป็นบริการทางเว็บที่สามารถเข้าถึงได้โดยทางโปรแกรมเท่านั้น และไม่ต้องการการแทรกแซงจากมนุษย์ โครงสร้างพื้นฐานเดียวที่ช่วยให้สามารถโต้ตอบโดยตรงระหว่างแอปพลิเคชันที่เชื่อมต่อกับอินเทอร์เน็ตเปิดโอกาสใหม่ในการบูรณาการบริการและอุปกรณ์—ไม่ว่าพวกเขาจะอยู่ที่ใดบนอินเทอร์เน็ต

บริการบนเว็บและ SOAP

บริการบนเว็บและ SOAP ได้รับการออกแบบมาเพื่อแก้ไขปัญหาการสื่อสารของแอปพลิเคชันข้ามแพลตฟอร์ม บทความนี้จะช่วยให้คุณได้รับข้อมูลเชิงลึกเกี่ยวกับเทคโนโลยีใหม่ๆ ที่มีแนวโน้มดีเหล่านี้

สบู่คืออะไร

เทคโนโลยีที่ใช้ในปัจจุบันสำหรับการเรียกวิธีการระยะไกล (DCOM, CORBA/IIOP และ RMI) ค่อนข้างยากในการกำหนดค่าและจัดระเบียบการโต้ตอบ สิ่งนี้นำมาซึ่งปัญหาในการทำงานและการทำงานของระบบแบบกระจาย (ปัญหาด้านความปลอดภัย การขนส่งผ่านไฟร์วอลล์ ฯลฯ) ปัญหาที่มีอยู่ได้รับการแก้ไขได้สำเร็จโดยการสร้าง SOAP (Simple Object Access Protocol) ซึ่งเป็นโปรโตคอลที่ใช้ XML อย่างง่ายสำหรับการแลกเปลี่ยนข้อความในสภาพแวดล้อมแบบกระจาย (WWW) ได้รับการออกแบบมาเพื่อสร้างบริการเว็บและวิธีการโทรจากระยะไกล SOAP สามารถใช้ได้กับโปรโตคอลการขนส่งที่แตกต่างกัน รวมถึง HTTP, SMTP เป็นต้น

บริการเว็บคืออะไร

บริการบนเว็บคือฟังก์ชันการทำงานและข้อมูลที่เปิดเผยสำหรับการใช้งานโดยแอปพลิเคชันภายนอกที่มีการโต้ตอบกับบริการผ่านโปรโตคอลมาตรฐานและรูปแบบข้อมูล บริการบนเว็บมีความเป็นอิสระอย่างสมบูรณ์จากภาษาและแพลตฟอร์มการใช้งาน เทคโนโลยีบริการเว็บเป็นรากฐานสำคัญของโมเดลการเขียนโปรแกรม .NET ของ Microsoft เพื่อสาธิตความสามารถของ SOAP ฉันใช้การติดตั้ง SOAP Toolkit เวอร์ชัน 2.0 ที่เพิ่งเปิดตัวล่าสุดจาก Microsoft ควรสังเกตว่า Toolkit เวอร์ชันปัจจุบันแตกต่างอย่างเห็นได้ชัดจากเวอร์ชันก่อนหน้า (Microsoft SOAP Toolkit สำหรับ Visual Studio 6.0) และจาก SOAP Toolkit 2.0 เวอร์ชันเบต้า

กลไกการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์

  1. แอปพลิเคชันไคลเอนต์สร้างอินสแตนซ์วัตถุ SOAPClient
  2. SOAPClient อ่านไฟล์คำอธิบายวิธีการบริการเว็บ (WSDL และ Web Services Meta Language - WSML) ไฟล์เหล่านี้สามารถจัดเก็บไว้บนไคลเอนต์ได้
  3. แอปพลิเคชันไคลเอนต์ที่ใช้ความสามารถในการผูกล่าช้าของวัตถุ SOAPClient เรียกวิธีการบริการ SOAPClient สร้างแพ็กเก็ตคำขอ (SOAP Envelope) และส่งไปยังเซิร์ฟเวอร์ สามารถใช้โปรโตคอลการขนส่งใดก็ได้ แต่โดยทั่วไปจะใช้ HTTP
  4. แพ็กเก็ตใช้แอปพลิเคชันเซิร์ฟเวอร์ Listener (อาจเป็นแอปพลิเคชัน ISAPI หรือเพจ ASP) สร้างวัตถุ SOAPServer และส่งแพ็กเก็ตคำขอไป
  5. SOAPServer อ่านคำอธิบายบริการเว็บ โหลดคำอธิบายและคำขอแพ็คเกจลงในแผนผัง XML DOM
  6. SOAPServer เรียกเมธอดของวัตถุ/แอปพลิเคชันที่ใช้บริการ
  7. ผลลัพธ์ของการดำเนินการเมธอดหรือคำอธิบายข้อผิดพลาดจะถูกแปลงโดยอ็อบเจ็กต์ SOAPServer ให้เป็นแพ็กเก็ตตอบกลับและส่งไปยังไคลเอนต์
  8. วัตถุ SOAPClient แยกวิเคราะห์แพ็กเก็ตที่ได้รับและส่งกลับไปยังแอปพลิเคชันไคลเอนต์ผลลัพธ์ของบริการหรือคำอธิบายของข้อผิดพลาดที่เกิดขึ้น

ไฟล์ WSDL เป็นเอกสาร XML ที่อธิบายวิธีการให้บริการเว็บ รวมถึงพารามิเตอร์ของวิธีการ ประเภท ชื่อ และตำแหน่งของบริการ Listener วิซาร์ด SOAP Toolkit จะสร้างเอกสารนี้โดยอัตโนมัติ

SOAP Envelope (แพ็คเกจ) - เอกสาร XML ที่มีการร้องขอ/ตอบกลับสำหรับการดำเนินการเมธอด จะสะดวกที่สุดที่จะพิจารณาว่าเป็นซองไปรษณีย์ที่มีการแนบข้อมูลไว้ แท็ก Envelope ต้องเป็นองค์ประกอบรากของแพ็กเกจ องค์ประกอบส่วนหัวเป็นทางเลือก แต่ต้องมีองค์ประกอบเนื้อหาอยู่และเป็นองค์ประกอบย่อยโดยตรงขององค์ประกอบซองจดหมาย หากเกิดข้อผิดพลาดในการดำเนินการเมธอด เซิร์ฟเวอร์จะสร้างแพ็กเก็ตที่มีองค์ประกอบ Fault ในแท็ก Body ซึ่งมีคำอธิบายโดยละเอียดของข้อผิดพลาด หากคุณใช้อินเทอร์เฟซระดับสูง SOAPClient, SOAPServer คุณไม่จำเป็นต้องเข้าไปในความซับซ้อนของรูปแบบแพ็คเกจ แต่หากต้องการคุณสามารถใช้อินเทอร์เฟซระดับต่ำหรือแม้แต่สร้างแพ็คเกจด้วยมือได้

โมเดลออบเจ็กต์ SOAP Toolkit ทำให้สามารถทำงานกับออบเจ็กต์ API ระดับต่ำได้:

  • SoapConnector - จัดเตรียมการทำงานกับโปรโตคอลการขนส่งสำหรับการแลกเปลี่ยนแพ็กเก็ต SOAP
  • SoapConnectorFactory - จัดเตรียมวิธีการสร้างตัวเชื่อมต่อสำหรับโปรโตคอลการขนส่งที่ระบุในไฟล์ WSDL (แท็ก)
  • SoapReader - อ่านข้อความ SOAP และสร้างแผนผัง XML DOM
  • SoapSerializer - มีวิธีการสร้างข้อความ SOAP
  • IsoapTypeMapper, SoapTypeMapperFactory - อินเทอร์เฟซที่ช่วยให้คุณทำงานกับประเภทข้อมูลที่ซับซ้อน

เมื่อใช้ออบเจ็กต์ API ระดับสูง คุณสามารถถ่ายโอนข้อมูลประเภทธรรมดาเท่านั้น (int, srting, float ...) แต่ข้อกำหนด SOAP 1.1 ช่วยให้คุณสามารถทำงานกับประเภทข้อมูลที่ซับซ้อนมากขึ้น เช่น อาร์เรย์ โครงสร้าง รายการ และประเภทข้อมูลที่ซับซ้อนมากขึ้น การรวมกัน หากต้องการทำงานกับประเภทดังกล่าว คุณต้องใช้อินเทอร์เฟซ IsoapTypeMapper และ SoapTypeMapperFactory

ส่วนโคลงสั้น ๆ

ลองนึกภาพว่าคุณได้ดำเนินการหรือกำลังใช้ระบบบางอย่างที่ควรสามารถเข้าถึงได้จากภายนอก เหล่านั้น. มีเซิร์ฟเวอร์บางตัวที่คุณต้องสื่อสารด้วย ยกตัวอย่างเว็บเซิร์ฟเวอร์

เซิร์ฟเวอร์นี้สามารถดำเนินการได้หลายอย่าง ทำงานกับฐานข้อมูล ดำเนินการคำขอของบุคคลที่สามไปยังเซิร์ฟเวอร์อื่น ทำการคำนวณบางอย่าง ฯลฯ มีชีวิตอยู่และอาจพัฒนาตามสถานการณ์ที่เขารู้จัก (เช่น ตามสถานการณ์ของนักพัฒนา) มันไม่น่าสนใจสำหรับบุคคลที่จะสื่อสารกับเซิร์ฟเวอร์ดังกล่าว เพราะเขาอาจไม่สามารถ/ต้องการให้เพจที่สวยงามพร้อมรูปภาพและเนื้อหาที่เป็นมิตรต่อผู้ใช้อื่นๆ มันถูกเขียนขึ้นและทำงานและให้ข้อมูลเมื่อถูกถาม โดยไม่ต้องกังวลว่ามนุษย์จะอ่านได้ ลูกค้าจะจัดการกับมันเอง

ระบบอื่นที่เข้าถึงเซิร์ฟเวอร์นี้สามารถกำจัดข้อมูลที่ได้รับจากเซิร์ฟเวอร์นี้ได้ตามดุลยพินิจของตนเอง - ดำเนินการ สะสม ออกให้กับลูกค้า ฯลฯ

หนึ่งในตัวเลือกสำหรับการสื่อสารกับเซิร์ฟเวอร์ดังกล่าวคือ SOAP โปรโตคอลการแลกเปลี่ยนข้อความ SOAP xml

ส่วนการปฏิบัติ

บริการเว็บ (นี่คือชื่อของสิ่งที่เซิร์ฟเวอร์ให้และสิ่งที่ลูกค้าใช้) ทำให้สามารถสื่อสารกับเซิร์ฟเวอร์ด้วยข้อความที่มีโครงสร้างชัดเจน ความจริงก็คือบริการเว็บไม่ยอมรับข้อมูลใดๆ บริการเว็บจะตอบกลับพร้อมข้อผิดพลาดต่อข้อความใด ๆ ที่ไม่เป็นไปตามกฎ ข้อผิดพลาดจะอยู่ในรูปแบบ xml พร้อมโครงสร้างที่ชัดเจน (ซึ่งไม่เป็นความจริงเกี่ยวกับข้อความ)

WSDL (ภาษาคำอธิบายบริการเว็บ) กฎที่ใช้ประกอบข้อความสำหรับบริการเว็บนั้นอธิบายโดยใช้ xml และมีโครงสร้างที่ชัดเจนด้วย เหล่านั้น. หากบริการเว็บมีความสามารถในการเรียกใช้เมธอด จะต้องอนุญาตให้ไคลเอ็นต์ทราบว่าพารามิเตอร์ใดที่ใช้สำหรับเมธอดนี้ ถ้าบริการเว็บคาดหวังสตริงสำหรับ Method1 เป็นพารามิเตอร์ และสตริงควรตั้งชื่อ Param1 จากนั้นกฎเหล่านี้จะถูกระบุในคำอธิบายบริการเว็บ

ไม่เพียงแต่ประเภทธรรมดาเท่านั้น แต่ยังสามารถส่งอ็อบเจ็กต์และคอลเลกชันของอ็อบเจ็กต์เป็นพารามิเตอร์ได้อีกด้วย คำอธิบายของออบเจ็กต์ลงมาจนถึงคำอธิบายของแต่ละองค์ประกอบของออบเจ็กต์ หากวัตถุประกอบด้วยหลายฟิลด์ แต่ละฟิลด์จะถูกอธิบาย ประเภท ชื่อ (ค่าที่เป็นไปได้คืออะไร) ฟิลด์อาจเป็นประเภทที่ซับซ้อนได้และต่อ ๆ ไปจนกว่าคำอธิบายของประเภทจะลงท้ายด้วยรายการแบบง่าย - สตริง, บูลีน, ตัวเลข, วันที่... อย่างไรก็ตาม บางประเภทอาจกลายเป็นเรื่องง่าย สิ่งสำคัญคือลูกค้า สามารถเข้าใจคุณค่าที่อาจมีได้

สำหรับลูกค้าก็เพียงพอที่จะทราบ URL ของบริการบนเว็บ Wsdl จะอยู่ใกล้เคียงเสมอซึ่งคุณสามารถทราบวิธีการและพารามิเตอร์ที่บริการบนเว็บนี้มีให้

ข้อดีของระฆังและนกหวีดเหล่านี้คืออะไร:

  • ในระบบส่วนใหญ่ คำอธิบายของวิธีการและประเภทจะเกิดขึ้นโดยอัตโนมัติ เหล่านั้น. โปรแกรมเมอร์บนเซิร์ฟเวอร์เพียงแค่ต้องบอกว่าวิธีนี้สามารถเรียกผ่านบริการเว็บได้ และคำอธิบาย wsdl จะถูกสร้างขึ้นโดยอัตโนมัติ

    • คำอธิบายซึ่งมีโครงสร้างที่ชัดเจน ลูกค้าสบู่ทุกคนสามารถอ่านได้ เหล่านั้น. ไม่ว่าจะเป็นบริการเว็บใดก็ตาม ลูกค้าจะเข้าใจว่าบริการเว็บได้รับข้อมูลใดบ้าง การใช้คำอธิบายนี้ ไคลเอ็นต์สามารถสร้างโครงสร้างภายในของคลาสอ็อบเจ็กต์ของตนเอง ที่เรียกว่า การผูกมัด" และด้วยเหตุนี้โปรแกรมเมอร์ที่ใช้บริการเว็บจึงต้องเขียนอะไรประมาณนี้ (pseudocode):

    ผู้ใช้ใหม่:=TSoapUser.Create("Vasya", "Pupkin", "ผู้ดูแลระบบ"); soap.AddUser(ผู้ใช้ใหม่);

  • การตรวจสอบอัตโนมัติ

    • การตรวจสอบ xml xml ต้องมีรูปแบบที่ถูกต้อง xml ไม่ถูกต้อง - เกิดข้อผิดพลาดกับไคลเอนต์ทันที ให้เขาจัดการมัน
    • การตรวจสอบสคีมา xml ต้องมีโครงสร้างที่แน่นอน xml ไม่ตรงกับสคีมา - เกิดข้อผิดพลาดกับไคลเอนต์ทันที ให้เขาจัดการมันซะ
    • การตรวจสอบข้อมูลดำเนินการโดยเซิร์ฟเวอร์สบู่เพื่อให้ประเภทข้อมูลและข้อจำกัดตรงกับคำอธิบาย
  • การอนุญาตและการรับรองความถูกต้องสามารถทำได้โดยใช้วิธีการแยกต่างหาก โดยกำเนิด หรือใช้การอนุญาต http
  • บริการเว็บสามารถทำงานได้ทั้งบนโปรโตคอลสบู่และบน http นั่นคือผ่านคำขอรับ นั่นคือหากพารามิเตอร์เป็นข้อมูลธรรมดา (ไม่มีโครงสร้าง) คุณสามารถเรียกตามปกติได้ www.site.com/users.asmx/GetUser?Name=Vasia หรือโพสต์ อย่างไรก็ตาม นี่ไม่ใช่ทุกที่และไม่เสมอไป
  • ... ดูในวิกิพีเดีย

นอกจากนี้ยังมีข้อเสียมากมาย:

  • ขนาดข้อความใหญ่เกินสมควร ตรงนี้ธรรมชาติของ xml คือรูปแบบที่ซ้ำซ้อน ยิ่งแท็กมาก ข้อมูลก็ยิ่งไร้ประโยชน์ พลัสสบู่เพิ่มความซ้ำซ้อน สำหรับระบบอินทราเน็ต ปัญหาการรับส่งข้อมูลจะรุนแรงน้อยกว่าอินเทอร์เน็ต ดังนั้นสบู่สำหรับเครือข่ายท้องถิ่นจึงเป็นที่ต้องการมากกว่า โดยเฉพาะอย่างยิ่ง Sharepoint มีบริการเว็บสบู่ที่คุณสามารถสื่อสารได้อย่างประสบความสำเร็จ (และข้อจำกัดบางประการ)
  • การเปลี่ยนคำอธิบายของบริการเว็บโดยอัตโนมัติอาจทำให้ไคลเอนต์ทั้งหมดเสียหายได้ มันก็เป็นเช่นนี้สำหรับระบบใดๆ ก็ตาม หากไม่รองรับความเข้ากันได้แบบย้อนหลังกับวิธีการแบบเก่า ทุกอย่างจะล้มเหลว...
  • ไม่ใช่ข้อเสีย แต่เป็นข้อเสียเปรียบ การเรียกเมธอดทั้งหมดต้องเป็นอะตอมมิก ตัวอย่างเช่น เมื่อทำงานกับฐานข้อมูล เราสามารถเริ่มธุรกรรม ดำเนินการหลาย ๆ คำสั่ง จากนั้นย้อนกลับหรือคอมมิต ไม่มีธุรกรรมในสบู่ หนึ่งคำขอ หนึ่งคำตอบ บทสนทนาจบลง
  • การจัดการกับคำอธิบายของสิ่งที่อยู่บนฝั่งเซิร์ฟเวอร์ (ทุกอย่างอธิบายอย่างถูกต้องหรือไม่) และสิ่งที่อยู่บนไคลเอนต์ (สิ่งที่อธิบายให้ฉันฟังที่นี่) อาจเป็นเรื่องยาก มีหลายครั้งที่ฉันต้องจัดการกับฝั่งไคลเอ็นต์และโน้มน้าวโปรแกรมเมอร์เซิร์ฟเวอร์ว่าข้อมูลของเขาถูกอธิบายไม่ถูกต้อง แต่เขาไม่เข้าใจอะไรเลยเกี่ยวกับเรื่องนี้เลย เพราะการสร้างอัตโนมัติและเขาไม่ควรทำเช่นนั้น มันเป็นเรื่องของ ซอฟต์แวร์. และแน่นอนว่าข้อผิดพลาดนั้นอยู่ในโค้ดวิธีการนั้นโปรแกรมเมอร์ก็ไม่เห็นมัน
  • การปฏิบัติแสดงให้เห็นว่านักพัฒนาบริการเว็บอยู่ห่างไกลจากผู้ที่ใช้บริการเว็บเหล่านี้อย่างมาก เพื่อตอบสนองต่อคำขอใด ๆ (ถูกต้องจากภายนอก) อาจเกิดข้อผิดพลาดที่ไม่สามารถเข้าใจได้ "ข้อผิดพลาด 5 ทุกอย่างไม่ดี" ทุกอย่างขึ้นอยู่กับจิตสำนึกของนักพัฒนา :)
  • ฉันแน่ใจว่าฉันยังจำอะไรบางอย่างไม่ได้ ...

ตัวอย่างเช่น มีบริการเว็บแบบเปิด belvia:

  • http://86.57.245.235/TimeTable/Service.asmx - จุดเริ่มต้น นอกจากนี้ยังมีข้อความคำอธิบายวิธีการสำหรับนักพัฒนาบุคคลที่สาม
  • http://86.57.245.235/TimeTable/Service.asmx?WSDL - คำอธิบาย wsdl ของวิธีการและประเภทของข้อมูลที่ได้รับและส่งคืน
  • http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - คำอธิบายวิธีการเฉพาะพร้อมตัวอย่างประเภทคำขอ xml และการตอบสนอง xml

คุณสามารถสร้างและส่งคำขอได้ด้วยตนเอง เช่น:

POST /TimeTable/Service.asmx โฮสต์ HTTP/1.1: 86.57.245.235 ประเภทเนื้อหา: ข้อความ/xml; charset=utf-8 ความยาวเนื้อหา: ความยาว SOAPAction: "http://webservices.belavia.by/GetAirportsList" รุ

คำตอบจะมา:

HTTP/1.1 200 ตกลง วันที่: จันทร์ 30 กันยายน 2556 00:06:44 GMT เซิร์ฟเวอร์: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 การควบคุมแคช: ส่วนตัว สูงสุด -age=0 ประเภทเนื้อหา: text/xml; charset=utf-8 ความยาวเนื้อหา: 2940

ป.ล. ก่อนหน้านี้ บริการเว็บ Aeroflot ได้เปิดขึ้นแล้ว แต่หลังจาก 1C เพิ่มการรองรับสบู่ให้กับ 8ku ผู้ทดสอบเบต้า 1C กลุ่มหนึ่งก็ติดตั้งได้สำเร็จ ตอนนี้มีบางอย่างเปลี่ยนแปลงไปที่นั่น (ฉันไม่ทราบที่อยู่ คุณสามารถดูได้หากคุณสนใจ)
ข้อจำกัดความรับผิดชอบ ZZY เขาพูดในระดับชีวิตประจำวัน คุณสามารถเตะได้

สบู่คืออะไร?

SOAP ย่อมาจาก Simple Object Access Protocol ฉันหวังว่าหลังจากอ่านบทความนี้แล้วคุณคงมีแต่สงสัยว่า "ชื่อแปลก ๆ นี้คืออะไร"

SOAP ในรูปแบบปัจจุบันคือวิธีการเรียกขั้นตอนระยะไกล (RPC) ผ่านเครือข่าย (ใช่ มันยังใช้ในการถ่ายโอนเอกสารในรูปแบบ XML ด้วยเช่นกัน แต่เราจะงดเรื่องนั้นไว้ก่อน)

ลองคิดดูสิ ลองนึกภาพว่าคุณมีบริการที่ส่งคืนราคาหุ้นสำหรับสัญลักษณ์ที่กำหนด (สัญลักษณ์หุ้น) โดยจะส่งข้อมูลไปยังเว็บไซต์ Nasdaq และสร้างผลลัพธ์ที่ต้องการตาม HTML ที่ส่งคืน ถัดไป เพื่อให้นักพัฒนารายอื่นสามารถใช้ภายในแอปพลิเคชันของตนได้ คุณจึงสร้างส่วนประกอบจากบริการนี้ซึ่งจะค้นหาข้อมูลเกี่ยวกับการเสนอราคาผ่านทางอินเทอร์เน็ต มันใช้งานได้ดีจนกระทั่งวันหนึ่ง Nasdaq เปลี่ยนเลย์เอาท์ของเพจต่างๆ คุณต้องพิจารณาตรรกะทั้งหมดของส่วนประกอบอีกครั้ง และส่งการอัปเดตไปยังนักพัฒนาทุกคนที่ใช้งานส่วนประกอบนั้น และในทางกลับกัน พวกเขาจำเป็นต้องส่งการอัปเดตไปยังผู้ใช้ทุกคน หากสิ่งนี้เกิดขึ้นอย่างต่อเนื่องไม่มากก็น้อย คุณสามารถสร้างศัตรูมากมายในหมู่นักพัฒนาคนอื่นๆ ได้ และอย่างที่ทราบกันดีว่าโปรแกรมเมอร์ไม่ควรล้อเล่นด้วย พรุ่งนี้คุณคงไม่อยากถ่ายรูปแมวตัวโปรดจากเครื่องทำลายเอกสารในออฟฟิศใช่ไหม

จะทำอย่างไร? มาดูกัน... สิ่งที่คุณต้องทำก็แค่จัดเตรียมฟังก์ชันเดียวที่จะใช้เป็นอินพุตสัญลักษณ์ย่อหุ้น (ชนิดสตริง) และส่งกลับราคาหุ้น (ชนิดลอยหรือสองเท่า) จะดีกว่าไหมถ้าปล่อยให้นักพัฒนาของคุณเรียกใช้ฟังก์ชันนี้ทางอินเทอร์เน็ต? ยอดเยี่ยม! ข่าวสำหรับฉันเช่นกัน มี COM และ Corba และ Java ที่ทำสิ่งนี้มาหลายปีแล้ว... สิ่งที่เป็นจริงก็คือความจริง แต่วิธีการเหล่านี้ไม่ได้ไร้ข้อบกพร่อง การกำหนดค่า COM ระยะไกลไม่ใช่เรื่องเล็กน้อย นอกจากนี้ คุณต้องเปิดพอร์ตจำนวนมากในไฟร์วอลล์จนคุณไม่สามารถจัดการเบียร์ได้เพียงพอสำหรับผู้ดูแลระบบ ใช่แล้วคุณจะต้องลืมผู้ใช้ระบบปฏิบัติการทั้งหมดยกเว้น Windows แต่บางครั้งผู้ใช้ Linux ก็สนใจการแลกเปลี่ยนเช่นกัน

แม้ว่าดูเหมือนว่าผู้ใช้ Linux จะไม่สูญหายไปทั้งหมดหากพวกเขาใช้ DCOM อ่านเพิ่มเติมได้ที่นี่: http://www.idevresource.com/com/library/res/articles/comonlinux.asp

ฉันไม่สามารถพูดอะไรได้มากนักเกี่ยวกับ Corba และ Java ดังนั้นเพื่อเป็นแบบฝึกหัด ฉันขอเชิญชวนผู้อ่านให้ค้นหาข้อเสียในแนวทางเหล่านี้

SOAP เป็นมาตรฐานที่ช่วยให้คุณสามารถอธิบายการโทรระยะไกลและรูปแบบที่จะส่งคืนผลลัพธ์ ดังนั้นคุณจึงต้องโฮสต์ฟังก์ชันของคุณในแอปพลิเคชันที่เข้าถึงได้ผ่านเครือข่ายและรับสายเป็นแพ็กเก็ต SOAP จากนั้นคุณตรวจสอบอินพุต รันฟังก์ชันของคุณ และส่งคืนผลลัพธ์ในแพ็กเก็ต SOAP ใหม่ กระบวนการทั้งหมดสามารถทำงานบน HTTP ได้ ดังนั้นคุณจึงไม่จำเป็นต้องเปิดพอร์ตจำนวนมากบนไฟร์วอลล์ของคุณ มันง่ายจริงๆเหรอ?

บทความนี้เกี่ยวกับอะไร?

นี่เป็นบทความแรกในชุดบทความที่เราเขียนเกี่ยวกับ SOAP ที่ Agni Software ในบทความนี้ฉันจะพยายามให้คุณเข้าใจว่า SOAP คืออะไรและจะเขียนแอปพลิเคชันที่สื่อสารกับเซิร์ฟเวอร์ SOAP ได้อย่างไร

สบู่และ XML

หาก SOAP ยังดูเหมือนง่ายสำหรับคุณ มาเพิ่ม XML กัน ตอนนี้ แทนที่จะเป็นชื่อฟังก์ชันและพารามิเตอร์ เราได้รับเอนเวโลป XML ที่ค่อนข้างซับซ้อน ราวกับว่าได้รับการออกแบบมาเพื่อให้คุณสับสน แต่อย่ารีบร้อนที่จะกลัว ยังมีอะไรมากกว่านั้น และคุณต้องเห็นภาพรวมทั้งหมดจึงจะเข้าใจถึงความซับซ้อนของ SOAP
หากคุณไม่ทราบว่า XML คืออะไร ก่อนอื่นให้อ่านบทความของฉันเกี่ยวกับ XML ที่นี่: http://www.agnisoft.com/white_papers/xml_delphi.asp

แพ็คเกจ SOAP ทั้งหมดอยู่ในรูปแบบ XML มันหมายความว่าอะไร? มาดูกัน. ดูฟังก์ชั่นนี้ (Pascal):
ฟังก์ชั่น GetStockQuote (สัญลักษณ์: สตริง) : สองครั้ง;
มันดูดี แต่ปัญหาคือมันเป็นปาสคาล การใช้คำจำกัดความง่ายๆนี้สำหรับนักพัฒนา Java คืออะไร? หรือสำหรับคนที่ทำงานกับ VB? เราต้องการบางสิ่งที่จะเข้าใจได้สำหรับทุกคน แม้แต่โปรแกรมเมอร์ VB ดังนั้น ให้ XML ที่มีข้อมูลเดียวกัน (พารามิเตอร์ มูลค่าราคาหุ้น ฯลฯ) ให้พวกเขา คุณสร้างแพ็คเกจ SOAP ซึ่งโดยพื้นฐานแล้วเป็นการเรียกใช้ฟังก์ชันของคุณ ซึ่งรวมอยู่ใน XML เพื่อให้แอปพลิเคชันใด ๆ บนแพลตฟอร์มใด ๆ สามารถเข้าใจได้ ตอนนี้เรามาดูกันว่าการเรียก SOAP ของเรามีลักษณะอย่างไร:
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"


xmlns:xsd="http://www.w3.org/1999/XMLSchema">


ไอบีเอ็ม

ข้อมูลใช่ไหม? สบู่กลายเป็นเรื่องง่ายต่อหน้าต่อตาเรา เอาล่ะ ทิ้งเรื่องตลกไว้ ตอนนี้ฉันจะพยายามอธิบายให้คุณทราบว่าจะเข้าใจการเรียก SOAP นี้ได้อย่างไร

การถอดรหัสแท็ก แท็กแรกที่ดึงดูดสายตาของคุณคือ

- แท็กนี้เป็น wrapper ภายนอกของแพ็คเกจ SOAP ซึ่งมีการประกาศเนมสเปซหลายรายการที่เราไม่สนใจเป็นพิเศษ แต่มีความสำคัญมากสำหรับภาษาโปรแกรมหรือโปรแกรมแยกวิเคราะห์ใดๆ เนมสเปซถูกกำหนดไว้เพื่อให้แน่ใจว่าคำนำหน้าต่อมา เช่น "SOAP-ENV:" หรือ "xsd:" เป็นที่เข้าใจโดย parser แท็กถัดไป – - (เราพลาดแท็กที่ไม่แสดงที่นี่ - - ไม่ได้อยู่ในตัวอย่างนี้โดยเฉพาะ แต่หากคุณต้องการอ่านเพิ่มเติม โปรดดูข้อกำหนด SOAP ที่นี่: http://www.w3.org/TR/SOAP/) แท็ก

มีการเรียก SOAP จริงๆ แท็กถัดไปในรายการคือ

หมายเหตุเกี่ยวกับเนมสเปซ: เนมสเปซทำให้มีคุณสมบัติแท็ก XML ตัวอย่างเช่น คุณไม่สามารถมีตัวแปรสองตัวที่มีชื่อเดียวกันในขั้นตอนเดียวได้ แต่ถ้าตัวแปรเหล่านั้นอยู่ในสองขั้นตอนที่แตกต่างกัน ก็ไม่มีปัญหา ดังนั้น โพรซีเดอร์จึงเป็นเนมสเปซ เนื่องจากชื่อทั้งหมดในโพรซีเดอร์ไม่ซ้ำกัน ในทำนองเดียวกัน แท็ก XML มีขอบเขตภายในเนมสเปซ ดังนั้น เมื่อระบุเนมสเปซและชื่อแท็ก คุณจึงสามารถระบุได้โดยไม่ซ้ำกัน เราจะกำหนดเนมสเปซเป็น URI เพื่อแยกความแตกต่าง NS1 ของเราจากการเลียนแบบ ในตัวอย่างข้างต้น NS1 เป็นนามแฝงที่ชี้ไปที่ urn:xmethods-quotes

ให้ความสนใจกับแอตทริบิวต์ encodingStyle ด้วย - คุณลักษณะนี้จะกำหนดวิธีการเรียก SOAP ให้เป็นอนุกรม

ภายในแท็ก มีพารามิเตอร์ ในกรณีที่ง่ายที่สุด เรามีพารามิเตอร์เพียงตัวเดียวเท่านั้น - แท็ก - สังเกตบรรทัดนี้ถัดจากแท็ก:
xsi:type="xsd:สตริง"
นี่คือวิธีการกำหนดประเภทโดยประมาณใน XML (โปรดสังเกตว่าฉันใช้คำว่า "ประมาณ" อย่างชาญฉลาดเพียงใดในการสรุปเกี่ยวกับเทคโนโลยีที่อาจเปลี่ยนแปลงได้เมื่อบทความถูกตีพิมพ์) สิ่งนี้หมายความว่าอย่างไร: ประเภทที่กำหนดไว้ในเนมสเปซ xsi ซึ่งคุณจะสังเกตได้ว่าถูกกำหนดไว้ในแท็ก – xsd:สตริง. และในทางกลับกัน นี่คือสตริง ที่กำหนดไว้ในเนมสเปซ xsd ซึ่งกำหนดไว้ก่อนหน้านี้อีกครั้ง (ฉันแน่ใจว่าทนายความจะต้องตื่นเต้นกับเรื่องทั้งหมดนี้)

ภายในแท็ก มีการระบุ "IBM" นี่คือค่าของพารามิเตอร์สัญลักษณ์ของฟังก์ชัน GetStockQuote

ในที่สุด เราก็ปิดแท็กทั้งหมดเช่นเดียวกับคนดี

ดังนั้นเราจึงพบแพ็กเก็ต SOAP ที่กำหนดการเรียกไปยังเซิร์ฟเวอร์ SOAP และเซิร์ฟเวอร์ SOAP ที่ใช้ตัวแยกวิเคราะห์ XML ปุ่มสีแดงและสถานีอวกาศ MIR จะถอดรหัสการโทรนี้และพิจารณาว่าคุณต้องการราคาหุ้น เขาจะค้นหาใบเสนอราคาที่ถูกต้องทันทีและส่งคืนให้คุณในรูปแบบนี้:
สบู่-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>


34.5


หลังจากแกะซอง SOAP ฉีกริบบิ้นออก และทำให้กระดาษห่อเกิดสนิม เราได้เรียนรู้ว่าราคาหุ้น IBM อยู่ที่ 34.5

เซิร์ฟเวอร์เชิงพาณิชย์ส่วนใหญ่จะส่งคืนข้อมูลเพิ่มเติม เช่น สกุลเงินใด และราคาที่ซื้อหุ้นล่าสุด และราคาหุ้นบางทีอาจจะแม่นยำกว่านี้

วิธีนี้ทำให้เรารู้ว่าเซิร์ฟเวอร์ SOAP คาดหวังอะไรและจะกลับมาเป็นอย่างไร แล้วคุณจะส่งข้อมูลนี้อย่างไร? คุณสามารถใช้การขนส่งใด ๆ ที่ครอบคลุมมากที่สุดคือ HTTP ฉันจะไม่ลงรายละเอียดเกี่ยวกับ HTTP สำหรับผู้ที่ไม่ทราบ นี่คือสิ่งที่เบราว์เซอร์ของคุณใช้เพื่อสื่อสารกับไซต์ที่คุณเยี่ยมชม

คำขอ HTTP ที่จำเป็นจะมีลักษณะดังนี้:
โพสต์ /StockQuote HTTP/1.1
โฮสต์: www.stockquoteserver.com

ความยาวของเนื้อหา: nnnn
SOAPAction: "Some-URI"

แพ็กเก็ตคำขอสบู่ที่นี่... สิ่งเดียวที่ควรสังเกตคือส่วนหัว SOAPAction ส่วนหัวนี้ระบุวัตถุประสงค์ของคำขอและจำเป็น เซิร์ฟเวอร์ SOAP แต่ละตัวสามารถมีฟังก์ชันได้ไม่จำกัดจำนวน และสามารถใช้ส่วนหัว SOAPAction เพื่อกำหนดว่าฟังก์ชันใดที่ถูกเรียกใช้ ไฟร์วอลล์และมัลติเพล็กเซอร์สามารถกรองเนื้อหาตามส่วนหัวนี้ได้

การตอบสนอง SOAP จากเซิร์ฟเวอร์ HTTP จะมีลักษณะดังนี้:
HTTP/1.1 200 ตกลง
ประเภทเนื้อหา: text/xml; ชุดอักขระ = "utf-8"
ความยาวของเนื้อหา: nnnn

แพ็กเก็ตการตอบสนองของสบู่ที่นี่... ทำไมต้อง HTTP? ประการแรก ผู้ดูแลระบบเครือข่ายไม่จำเป็นต้องเปิดพอร์ตแยกต่างหากจำนวนมากสำหรับการโทร SOAP... เว็บเซิร์ฟเวอร์สามารถจัดการการโทรได้อย่างง่ายดาย เนื่องจาก โดยปกติแล้วพอร์ต 80 จะเปิดให้ทุกคนรับคำขอที่เข้ามา ข้อดีอีกประการหนึ่งคือความสามารถในการขยายของเว็บเซิร์ฟเวอร์โดยใช้ CGI, ISAPI และโมดูลเนทีฟอื่นๆ ความสามารถในการขยายนี้ทำให้คุณสามารถเขียนโมดูลที่ประมวลผลคำขอ SOAP โดยไม่ส่งผลกระทบต่อเนื้อหาเว็บอื่นๆ

แค่นั้นแหละ

ฉันหวังว่าบทความนี้จะช่วยให้ความกระจ่างเกี่ยวกับ SOAP หากคุณยังคงอยู่ที่นี่และต้องการอ่านเพิ่มเติมเกี่ยวกับหัวข้อนี้ โปรดไปที่เว็บไซต์ของผู้เขียน: http://www.agnisoft.com/soap

โปรโตคอลการเข้าถึงวัตถุอย่างง่าย (SOAP)เป็นโปรโตคอลแบบ XML ที่กำหนดกฎสำหรับการส่งข้อความผ่านอินเทอร์เน็ตระหว่างระบบแอปพลิเคชันต่างๆ ส่วนใหญ่จะใช้สำหรับการเรียกขั้นตอนระยะไกล เดิม SOAP ได้รับการออกแบบมาให้ทำงาน "เหนือ" HTTP (เพื่อทำให้การรวม SOAP เข้ากับเว็บแอปพลิเคชันง่ายขึ้น) แต่ตอนนี้สามารถใช้โปรโตคอลการขนส่งอื่น ๆ เช่น SMTP ได้เช่นกัน

สมมติว่าคุณกำลังสร้างบริการการเข้าถึงแอปพลิเคชันบนอินเทอร์เน็ต ผู้บริโภคโต้ตอบกับบริการนี้โดยการให้ข้อมูล เซิร์ฟเวอร์ของคุณประมวลผลข้อมูลและส่งคืนผลลัพธ์ให้กับผู้บริโภค วิธีที่ดีที่สุดในการรักษาการสื่อสารกับระบบคืออะไร?

คุณสามารถสร้างแอปพลิเคชันไคลเอนต์-เซิร์ฟเวอร์แบบกำหนดเองได้ และกำหนดให้ผู้บริโภคต้องใช้โปรแกรมไคลเอนต์แบบกำหนดเองเพื่อเข้าถึงบริการของคุณ แต่ถ้าคุณจริงจังกับการค้นหาตัวเองในธุรกิจอินเทอร์เน็ต คุณจะต้องสร้างไคลเอนต์ที่ทำงานบนแพลตฟอร์มไคลเอนต์ที่เป็นไปได้ทั้งหมด - Windows, Macintosh, Unix, Linux ฯลฯ กล่าวอีกนัยหนึ่ง คุณจะต้องเขียนไคลเอนต์ที่แตกต่างกันมากมาย .

คุณรู้สึกอย่างไรกับการใช้เว็บ? แน่นอนว่าโซลูชันนี้ค่อนข้างยอมรับได้ แต่มีความเชื่อมโยงอย่างแน่นหนากับการใช้งานเบราว์เซอร์ และอีกครั้งคุณจะต้องสร้างโครงสร้างพื้นฐานเพื่อส่งและรับข้อมูลขาเข้าและขาออก รวมถึงจัดรูปแบบและแพ็คเกจข้อมูลสำหรับการแลกเปลี่ยนดังกล่าว คุณสามารถเลือก Java หรือ ActiveX เพื่อใช้แอปพลิเคชันที่ซับซ้อนได้ แต่ผู้ใช้บางรายจะปฏิเสธบริการของคุณเนื่องจากความต้องการแบนด์วิธที่สูงเกินจริงและการรักษาความปลอดภัยที่ไม่เพียงพอ

สิ่งที่จำเป็นต้องมีคือโปรโตคอลง่ายๆ ที่ทำให้การบรรจุข้อมูลแอปพลิเคชันง่ายขึ้น และถ่ายโอนข้อมูลผ่านทางเว็บโดยใช้ XML ที่ปรับตามเนื้อหา การทำเช่นนี้ช่วยให้มั่นใจได้ว่าทั้งผู้ส่งและผู้รับสามารถตีความเนื้อหาของข้อความได้อย่างง่ายดาย ในเวลาเดียวกัน ด้วยการใช้โปรโตคอลเว็บ HTTP เป็นพาหนะ จึงสามารถขจัดความจำเป็นในการลดระดับการป้องกันไฟร์วอลล์ได้

Simple Object Access Protocol (SOAP) ที่อธิบายไว้อย่างดีเป็นโปรโตคอล "กาว" ธรรมดาที่ช่วยให้โฮสต์สามารถเรียกใช้ออบเจ็กต์แอปพลิเคชันจากระยะไกลและส่งกลับผลลัพธ์ SOAP เสนอชุดเงื่อนไขขั้นต่ำที่อนุญาตให้แอปพลิเคชันส่งข้อความ: ไคลเอนต์สามารถส่งข้อความเพื่อเรียกใช้วัตถุโปรแกรม และเซิร์ฟเวอร์สามารถส่งคืนผลลัพธ์ของการโทรนั้น

SOAP ค่อนข้างง่าย: ข้อความคือเอกสาร XML ที่มีคำสั่ง SOAP แม้ว่าในทางทฤษฎี SOAP จะสามารถเชื่อมโยงกับโปรโตคอลการขนส่งใดๆ สำหรับแอปพลิเคชันได้ แต่โดยทั่วไปแล้วจะใช้ร่วมกับ HTTP

เคนนาร์ด สคริบเนอร์ หนึ่งในผู้เขียนหนังสือเล่มนี้ ทำความเข้าใจกับ SOAP: โซลูชันที่เชื่อถือได้(Macmillan USA, 2000) กล่าวว่า SOAP ทำงานโดยการแปลงข้อมูลที่จำเป็นในการเรียกเมธอด (เช่น ค่าอาร์กิวเมนต์และ ID ธุรกรรม) ให้เป็นรูปแบบ XML

ข้อมูลถูกห่อหุ้มใน HTTP หรือโปรโตคอลการขนส่งอื่นๆ และส่งไปยังผู้รับ ซึ่งโดยปกติคือเซิร์ฟเวอร์ เซิร์ฟเวอร์นี้จะแยกข้อมูล SOAP ออกจากแพ็กเก็ต ดำเนินการประมวลผลที่จำเป็น และส่งกลับผลลัพธ์เป็นการตอบสนอง SOAP

Scribner ตั้งข้อสังเกตว่า SOAP ทำหน้าที่เป็นโปรโตคอลการเรียกขั้นตอนระยะไกล เหมือนกับโปรโตคอล Remote Method Invocation ใน Java หรือ General Inter-ORB Protocol ใน CORBA

เนื่องจากมีการใช้ HTTP และ XML แทบทุกที่ ดังนั้น SOAP จึงดูเหมือนจะเป็นโปรโตคอลการเรียกกระบวนการระยะไกลที่ปรับขนาดได้มากที่สุดที่สร้างขึ้นจนถึงปัจจุบัน Scribner กล่าว SOAP ไม่ได้ออกแบบมาเพื่อทำหน้าที่เป็นสถาปัตยกรรมออบเจ็กต์ที่สมบูรณ์

SOAP ไม่ได้แทนที่โปรโตคอลการเรียกใช้เมธอดระยะไกลใน Java, Distributed Component Object Model และ CORBA มันมีกฎเกณฑ์ที่โมเดลเหล่านี้สามารถใช้ได้ SOAP ไม่ใช่วิธีแก้ปัญหาที่สมบูรณ์ ไม่รองรับการเปิดใช้งานหรือการป้องกันวัตถุ จากข้อมูลของ Scribner นักพัฒนา SOAP "เชื่อมั่นว่าผู้ใช้จะเพิ่มโค้ดนี้ด้วยตนเอง" โดยการสร้างมันไว้บน SOAP แทนที่จะทำให้มันเป็นส่วนหนึ่งของโปรโตคอล

รูปภาพนี้แสดงตัวอย่างที่นำมาจากข้อกำหนด SOAP 1.1 ซึ่งโฮสต์ร้องขอบริการเสนอราคาสำหรับราคาหุ้นหนึ่งๆ คำขอ SOAP ถูกฝังอยู่ใน HTTP POST และเนื้อหาคำขอจะระบุประเภทของคำขอและพารามิเตอร์ - สัญลักษณ์หุ้น การตอบสนองยังจัดให้มีวัตถุ XML ที่ห่อหุ้มในการตอบสนอง HTTP ด้วยค่าส่งคืนเดียว (34.5 ในกรณีนี้)

คุณสมบัติของสบู่

ด้วย SOAP นักพัฒนาสามารถสร้างบริการบนเว็บได้อย่างรวดเร็วเท่ากับที่สามารถเขียนข้อความ SOAP เพื่อเรียกใช้โปรแกรมสำหรับแอปพลิเคชันที่มีอยู่ จากนั้นจึงเพิ่มแอปพลิเคชันเหล่านั้นลงในเว็บเพจธรรมดา นอกจากนี้ นักพัฒนายังมีความสามารถในการใช้การเรียก SOAP ในแอปพลิเคชันเฉพาะ และสร้างแอปพลิเคชันที่สามารถพอร์ตไปยังเว็บเพจของผู้อื่นได้ ดังนั้นจึงหลีกเลี่ยงกระบวนการพัฒนาที่ใช้เวลานานและมีราคาแพง

ตามที่ Mark Stiver ผู้เขียนหนังสือทำความเข้าใจ SOAP อีกคนหนึ่งกล่าวไว้ นี่คือเป้าหมายที่ Microsoft กำลังดำเนินการด้วยแพลตฟอร์ม .Net ที่มีแนวโน้มดี “นี่คือจุดที่สบู่เปล่งประกาย มันทำให้นักพัฒนามีวิธีที่ยอดเยี่ยมมากในการสร้างแอพพลิเคชั่นโดยไม่ต้องกังวลกับความไม่เข้ากันที่อาจเกิดขึ้น” เขากล่าว

ตัวอย่างสบู่

ตัวอย่างต่อไปนี้แสดงคำขอ SOAP ที่เรียกว่า GetLastTradePrice ซึ่งช่วยให้ลูกค้าสามารถส่งคำขอราคาล่าสุดสำหรับหุ้นที่ระบุได้

โพสต์/ราคาหุ้น HTTP/1.1
เจ้าภาพ: stockquoteserver.com
ประเภทเนื้อหา:ข้อความ/xml; ชุดอักขระ = "utf-8"
ความยาวของเนื้อหา:นะ
สบู่การกระทำ:"บาง URI"

ห้าบรรทัดแรก (ส่วนหนึ่งของส่วนหัว HTTP) ระบุประเภทข้อความ (POST) โฮสต์ ประเภทเพย์โหลด และความยาวของเพย์โหลด และส่วนหัว SOAPAction ระบุวัตถุประสงค์ของคำขอ SOAP ข้อความ SOAP นั้นเป็นเอกสาร XML ที่มีซองจดหมาย SOAP ตัวแรก จากนั้นจึงเป็นองค์ประกอบ XML ที่ระบุเนมสเปซและคุณลักษณะของ SOAP ถ้ามี ซอง SOAP สามารถมีส่วนหัว (แต่ไม่ใช่ในกรณีนี้) ตามด้วยเนื้อความ SOAP ในตัวอย่างของเรา ส่วนเนื้อหาประกอบด้วยคำขอ GetLastTradePrice และสัญลักษณ์ของหุ้นที่มีการร้องขอราคาล่าสุด คำตอบสำหรับคำถามนี้อาจมีลักษณะดังนี้:

HTTP/1.1 200 ตกลง
ประเภทเนื้อหา:ข้อความ/xml; ชุดอักขระ = "utf-8"
ความยาวของเนื้อหา:นะ

ขอย้ำอีกครั้งว่าสามบรรทัดแรกเป็นส่วนหนึ่งของส่วนหัว HTTP ข้อความ SOAP นั้นประกอบด้วยซองจดหมายที่มีการตอบสนองต่อคำขอดั้งเดิม ซึ่งมีป้ายกำกับ GetLastTradePriceResponse และรวมค่าที่ส่งคืน ในกรณีของเรา 34.5

บทความที่เกี่ยวข้อง