สถาปัตยกรรมที่มุ่งเน้นการบริการคืออะไร?

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

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

บทความนี้เป็นภาพรวมของ Java SOA และลักษณะสำคัญของสถาปัตยกรรมที่มุ่งเน้นบริการที่ใช้บริการเว็บที่ใช้ SOAP ฉันจะเปรียบเทียบ SOA และไมโครเซอร์วิสสั้น ๆ และพูดถึงความแตกต่างระหว่างบริการเว็บที่ใช้ RESTful และ SOAP ใน Java

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

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

ทำไมต้องเป็นสถาปัตยกรรมที่เน้นการบริการ?

SOA จัดการกับความท้าทายขององค์กรทั่วไปสามประการ:

  • ตอบสนองต่อการเปลี่ยนแปลงทางธุรกิจได้อย่างรวดเร็ว
  • ใช้ประโยชน์จากการลงทุนโครงสร้างพื้นฐานที่มีอยู่
  • สนับสนุนช่องทางการโต้ตอบใหม่กับลูกค้าคู่ค้าและซัพพลายเออร์

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

SOA และไมโครเซอร์วิส

Microservices เป็นรูปแบบสถาปัตยกรรมที่พัฒนามาจาก SOA ทั้งสองเป็นสถาปัตยกรรมแบบกระจายและทั้งสองมีกระบวนทัศน์ที่แยกออกจากกัน ในขณะที่ architecure ที่มุ่งเน้นการบริการนั้นหนักกว่าในโครงสร้างพื้นฐานไมโครเซอร์วิสนำเสนอรูปแบบการพัฒนาที่ยืดหยุ่นและมีน้ำหนักเบามากขึ้น มีข้อดีข้อเสียทั้งสองอย่างและใช้กันอย่างแพร่หลาย โดยทั่วไปแล้ว SOA จะถูกนำไปใช้หรือดูแลโดยองค์กรที่จัดตั้งขึ้นซึ่งมีทรัพยากรเพื่อสนับสนุนความเป็นทางการมากขึ้น Microservices มักจะดึงดูดองค์กรใหม่หรือองค์กรที่กำลังเติบโตที่ต้องการความคล่องตัว

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

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

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

Matthew Tyson

ลักษณะสำคัญของ SOA

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

โดยไม่คำนึงถึงขนาดหรือความซับซ้อนรูปแบบของสถาปัตยกรรมที่มุ่งเน้นบริการจะเหมือนกันมากหรือน้อย:

  • ผู้ให้บริการเปิดเผยจุดสิ้นสุดและอธิบายการดำเนินการที่มีอยู่ในแต่ละจุดสิ้นสุด
  • ผู้ใช้บริการออกคำขอและใช้การตอบสนอง
  • ผู้ให้บริการสร้างข้อความเพื่อจัดการกับคำขอ

การใช้สถาปัตยกรรมที่มุ่งเน้นการบริการ

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

Matthew Tyson

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

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

SOAP เทียบกับบริการเว็บ RESTful

เป็นไปได้ที่จะนำสไตล์ SOA มาใช้และนำไปใช้กับ REST เช่นใช้ JAX-RS API หรือ Spring Boot Actuator แต่การสนทนานั้นไม่อยู่ในขอบเขตสำหรับบทความนี้ ดู "SOAP vs REST vs JSON" สำหรับการเปรียบเทียบ SOAP กับบริการบนเว็บที่เป็นประโยชน์ นอกจากนี้ยังมีบางส่วนที่ทับซ้อนกันระหว่างบริการเว็บ RESTful และรูปแบบที่มีน้ำหนักเบามากขึ้นซึ่งเกี่ยวข้องกับไมโครเซอร์วิส

บริการเว็บที่ใช้ SOAP

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

SOAP, WSDL และ XSD

SOAP, WSDL และ XSD เป็นโครงสร้างพื้นฐานพื้นฐานของการใช้บริการเว็บที่ใช้ SOAP WSDL ใช้เพื่ออธิบายบริการและ SOAP เป็นชั้นการขนส่งสำหรับการส่งข้อความระหว่างผู้ใช้บริการและผู้ให้บริการ บริการสื่อสารกับข้อความที่กำหนดอย่างเป็นทางการโดยใช้ XML Schema (XSD) คุณสามารถคิดว่า WSDL เป็นอินเทอร์เฟซของบริการ (คล้ายกับอินเทอร์เฟซ Java) การใช้งานทำได้ในคลาส Java และการสื่อสารผ่านเครือข่ายจะเกิดขึ้นผ่าน SOAP ตามหน้าที่แล้วผู้บริโภคจะมองหาบริการรับ WSDL สำหรับบริการนั้นจากนั้นเรียกใช้บริการโดยใช้ SOAP

ความปลอดภัยของบริการเว็บ

ข้อกำหนดคุณสมบัติ WS-I Basic Profile 2.0 ที่อยู่ความปลอดภัยของข้อความ ข้อกำหนดนี้มุ่งเน้นไปที่การแลกเปลี่ยนข้อมูลรับรองความสมบูรณ์ของข้อความและการรักษาความลับของข้อความ

การค้นพบบริการบนเว็บ

เมื่อรากฐานที่สำคัญของการค้นพบบริการเว็บแล้ว UDDI (Universal Description, Definition and Integration) ได้จางหายไปในประวัติศาสตร์ ทุกวันนี้เป็นเรื่องปกติที่จะเปิดเผยบริการเว็บที่ใช้ SOAP ในลักษณะที่คุณใช้กับบริการอื่น ๆ ผ่าน URL ปลายทาง ตัวอย่างเช่นคุณสามารถใช้ JAX-WS Service Endpoint Interface และมัน@WebServiceและ@WebMethodคำอธิบายประกอบ

การสร้างและปรับใช้บริการเว็บ

นักพัฒนา Java มีตัวเลือกมากมายสำหรับการสร้างและปรับใช้เว็บเซอร์วิสที่ใช้ SOAP รวมถึง Apache Axis2 และ Spring-WS อย่างไรก็ตามมาตรฐาน Java คือ JAX-WS, Java API สำหรับ XML Web Services แนวคิดหลักที่อยู่เบื้องหลัง JAX-WS คือการสร้างคลาส Java และใส่คำอธิบายประกอบเพื่อสร้างสิ่งประดิษฐ์ที่ต้องการ ภายใต้ประทุน JAX-WS ใช้แพ็คเกจ Java หลายรายการรวมถึง JAXB ซึ่งเป็นไลบรารีวัตถุประสงค์ทั่วไปสำหรับการผูกคลาส Java กับ XML

JAX-WS ซ่อนความซับซ้อนและโปรโตคอลที่อยู่เบื้องหลังจากผู้พัฒนาดังนั้นจึงทำให้กระบวนการกำหนดและปรับใช้บริการ SOAP ที่ใช้ Java เป็นไปอย่างคล่องตัว Java IDE ที่ทันสมัยเช่น Eclipse มีการสนับสนุนอย่างเต็มที่สำหรับการพัฒนาเว็บเซอร์วิส JAX-WS ข้อกำหนด JAX-WS ยังได้รับการคัดเลือกสำหรับการพัฒนาอย่างต่อเนื่องใน Jakarta EE

สรุป

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

เรื่องนี้ "สถาปัตยกรรมเชิงบริการคืออะไร" เผยแพร่ครั้งแรกโดย JavaWorld