บริการเว็บเป็นมาตรฐานที่กำหนดไว้สำหรับการแลกเปลี่ยนข้อมูลผ่านทางเว็บ นี่ไม่ได้เป็นการบอกว่าบริการทางเว็บจะถูกเปิดเผยต่ออินเทอร์เน็ต เพียงแต่มีชุด "มาตรฐานเว็บ" ที่ตกลงร่วมกันซึ่งผลิตภัณฑ์จำนวนมากสนับสนุน เมื่อตัดสินใจว่าจะใช้มาตรฐานใด สิ่งสำคัญที่สุดที่ต้องพิจารณามักเป็นคำแนะนำของเจ้าหน้าที่ด้านเทคนิค
พวกเขาอาจแนะนำให้คุณตามลำดับ มาตรฐานที่นำไปปฏิบัติได้ง่ายที่สุด มีการสนับสนุนทางเทคนิคที่กว้างขวางที่สุดสำหรับผลิตภัณฑ์ และมีแนวโน้มที่จะทำงานได้ดีในสภาพแวดล้อมของคุณ เพื่อให้การใช้งาน SOA ประสบความสำเร็จซึ่งจะยืนหยัดต่อการทดสอบของเวลาและขยายขนาดต่อไปในอนาคต ปัจจัยทั้งสามนี้มีความสำคัญอย่างยิ่ง
WS-I
Web Services Interoperability Organisation (WS-I) เชี่ยวชาญในการพัฒนาแนวทางปฏิบัติที่ดีที่สุดสำหรับมาตรฐานเว็บเพื่อให้แน่ใจว่าสามารถทำงานร่วมกันได้ในระบบปฏิบัติการ แพลตฟอร์ม หรือภาษาการเขียนโปรแกรมที่แตกต่างกัน WS-I มีหน้าที่รับผิดชอบในการกำหนดเอกสารแนวปฏิบัติที่ดีที่สุด เช่น การรักษาความปลอดภัยของบริการบนเว็บ และข้อกำหนดทางเทคนิคในการประมวลผลบริการเว็บ เอกสารนี้ช่วยให้นักพัฒนาและธุรกิจปฏิบัติตามแนวทางปฏิบัติที่ผู้อื่นใช้เพื่อให้มั่นใจถึงความสามารถในการทำงานของผู้ใช้
WS-I ยังเผยแพร่ข้อกำหนดทางเทคนิค ชุดทดสอบ และตัวอย่างเกี่ยวกับวิธีการปรับใช้โปรโตคอลเหล่านี้ ในความเป็นจริง WS-I เป็นหน่วยงานกำกับดูแลที่ก่อตั้งขึ้นโดยองค์กรหลายแห่ง เช่น Microsoft และ IBM และภารกิจของมันคือการส่งเสริมบริการเว็บที่ทำงานร่วมกันได้
ข้อตกลงการใช้งาน
บริการบนเว็บอาศัยโปรโตคอลเพื่อให้แน่ใจว่าการสื่อสารมีความหมาย เนื้อหาของข้อมูลที่ส่งระหว่างบริการจะต้องได้รับการตกลงก่อนหน้านี้เพื่อให้แน่ใจว่าทั้งสองฝ่ายทราบว่าได้รับเนื้อหาใด SOAP เป็นตัวอย่างของโปรโตคอลที่ใช้กันอย่างแพร่หลายในการแลกเปลี่ยนข้อมูล SOAP ใช้ภาษาการเขียนโปรแกรม XML ช่วยให้ทั้งสองฝ่ายสามารถถอดรหัสสิ่งที่ถูกส่งและจัดรูปแบบข้อมูลที่ส่งไปมา
แสดงให้เห็น
เราจะพูดถึงสถาปัตยกรรมบางส่วนเร็วๆ นี้ และยังอ้างอิงถึงโปรโตคอลบริการเว็บบางอย่างด้วย สิ่งสำคัญคือต้องไม่สับสนระหว่างสองสิ่งนี้ เรามาแนะนำสั้นๆ กันด้านล่างนี้เลย
สถาปัตยกรรมซอฟต์แวร์เช่น REST และ RPC ไม่ใช่โปรโตคอล เป็นวิธีการที่ระบุวิธีการปฏิบัติตามข้อตกลง
WSDL (ภาษาคำอธิบายบริการเว็บ) คือภาษาที่ใช้อธิบายบริการเว็บเฉพาะในรูปแบบที่จัดรูปแบบเพื่อให้แอปพลิเคชันสามารถแยกวิเคราะห์บริการได้ WSDL เองไม่มีฟังก์ชันการทำงานใดๆ ในรูปแบบของการโต้ตอบกับบริการบนเว็บ
โปรโตคอลเอง เช่น SOAP, XML-RPC หรือ DCOM จะกำหนดวิธีการส่งข้อความอย่างชัดเจน และวิธีที่โปรแกรมเข้าใจข้อมูลที่ได้รับ
สถาปัตยกรรมใน SOA มีสองประเภทหลัก: โปรโตคอลตระกูล RPC และแนวทาง Representational State Transfer (REST)
อาร์พีซี
วิธีการเรียกขั้นตอนระยะไกล (RPC) ช่วยให้โปรแกรมเมอร์สามารถเรียกทรัพยากรของระบบระยะไกลได้เหมือนกับการ "เรียก" ทรัพยากรในเครื่องเมื่อเขียนโปรแกรมบนระบบ ข้อเสียของบริการสไตล์ RPC คือผู้คนมักจะใช้บริการเหล่านี้ราวกับว่าพวกเขาคุ้นเคยกับภาษาการเขียนโปรแกรมบนแพลตฟอร์มเฉพาะ การเรียกขั้นตอนระยะไกลยังเป็นเรื่องง่ายหากเหมือนกันกับขั้นตอนในเครื่อง
ตรรกะนี้ฝ่าฝืนแนวคิดเรื่อง "การมีเพศสัมพันธ์แบบหลวม" แนวคิดของการมีเพศสัมพันธ์แบบหลวมๆ จริงๆ แล้วหมายความว่ากระบวนการระยะไกลไม่ควรขึ้นอยู่กับระบบปฏิบัติการหรือภาษาการเขียนโปรแกรมเฉพาะใดๆ
SOAP เป็นโปรโตคอลที่สืบทอดมาจาก XML-RPC และเป็นเพียงการเรียกขั้นตอนระยะไกลที่มีข้อมูลในรูปแบบ XML SOAP ใช้โปรโตคอล HTTP ในการส่งข้อมูล ซึ่งดีและเรียบง่าย แต่ก็มีข้อเสียอยู่บ้าง อย่างไรก็ตาม บริการเว็บส่วนใหญ่ในปัจจุบันยังคงใช้โปรโตคอล HTTP เพื่อการสื่อสาร เนื่องจากบริการเหล่านี้สร้างขึ้นโดยใช้โปรโตคอล SOAP
พักผ่อน
วิธีการโอนสถานะการเป็นตัวแทน (REST) โดยพื้นฐานแล้วจะแตกต่างจากการเรียกขั้นตอนระยะไกลเนื่องจากทำงานในระดับที่แตกต่างกัน การเรียก REST ดูเหมือนคำขอเว็บอื่น ๆ ผ่านโปรโตคอล HTTP ในขณะที่การเรียก RPC ดูเหมือนการเรียกฟังก์ชันมาตรฐาน จุดเน้นของ REST คือการทำงานด้วยทรัพยากรที่เสถียรมากกว่าข้อความแต่ละข้อความ ส่งผลให้มีวิธีการโต้ตอบที่เป็นมาตรฐานและเข้าใจกันอย่างแพร่หลายมากขึ้น เหมือนกับโปรโตคอล HTTP นั่นเอง REST จัดการการถ่ายโอนข้อมูลก้อนใหญ่ ในขณะที่ RPC ถ่ายโอนกระบวนการที่ซับซ้อน
ควรใช้ REST หรือ RPC หรือไม่
คำถามที่ว่าจะใช้ REST หรือไม่นั้นเป็นสิ่งที่ดีอย่างแน่นอน ดูเหมือนเป็นหนทางแห่งอนาคต อย่างไรก็ตาม SOA ของคุณจะต้องรวมเข้ากับซอฟต์แวร์ทุกชิ้นที่คุณใช้อยู่ในปัจจุบัน การนำ REST มาใช้นั้นช้า สาเหตุหลักมาจากการสนับสนุนบริการทางเว็บ แม้ว่าระบบ REST สามารถใช้ WSDL เพื่ออธิบายข้อความ SOAP ผ่าน HTTP ได้ แต่ก็ยังไม่มีการสนับสนุนเพียงพอที่จะใช้งานจริง ตัวอย่างเช่น Apache ไม่สนับสนุนวิธีการที่จำเป็นในการใช้ REST โดยไม่ต้องติดตั้งโมดูลปลั๊กอินด้วยซ้ำ
มีมาตรฐานอื่นๆ ที่ไม่ได้เป็นส่วนหนึ่งของกลุ่มบริการเว็บ แต่อย่างที่คุณคาดหวัง มาตรฐานเหล่านี้ไม่ได้รับการรองรับอย่างกว้างขวาง Jini, WCF และ CORBA เป็นตัวอย่างบางส่วน เมื่อผู้ขายเสนอผลิตภัณฑ์ที่รองรับเทคโนโลยีข้างต้นเพียงอย่างเดียว คุณคงอยากจะวิ่งหนี ไม่ใช่เดินจากไป ขณะนี้บริการทางเว็บได้รับการสนับสนุนอย่างกว้างขวางแล้ว การใช้บริการเว็บก็จะยิ่งเพิ่มมากขึ้นเท่านั้น SOA เองก็กล่าวกันว่าเป็นสิ่งใหม่ ไม่เสถียร และมีความเสี่ยง อย่างไรก็ตาม ความเสี่ยงเหล่านี้สามารถบรรเทาลงได้มากเมื่อคุณเลือกมาตรฐานบริการเว็บที่เหมาะสมซึ่งมีการสนับสนุนด้านเทคนิคในวงกว้าง
ท้ายที่สุด การยึดติดกับระบบ SOAP แบบเก่าเหนือระบบสไตล์ RPC บางประเภทในปัจจุบันเป็นกลไกที่ใช้ได้สำหรับการสร้าง SOA โดยใช้บริการเว็บ หากคุณทำเช่นนี้ คุณจะลดโอกาสที่ผู้ขายจะล็อคอินได้อย่างมาก