สมมติว่าคุณกำลังมองหาการแยกแอปพลิเคชันของคุณลงในบริการ มีเหตุผลที่ดีบ้างไหมในการนำแนวทาง SOA มาใช้กับการสร้างไลบรารี่ API ที่สามารถโหลดได้โดยแอพพลิเคชั่นที่ต้องการ
คำตอบ:
ความแตกต่างอาจบอบบางระหว่างทั้งสอง ตัวอย่างเช่นใน. NET world คุณอาจมีแอพพลิเคชั่นที่จะรู้สึกเหมือนเสาหินสำหรับผู้ใช้และจะทำงานบนเครื่องเดียวกัน แต่ภายในจะถูกแยกออกเป็นบริการ WCF คุณอาจมีสถาปัตยกรรมที่ห้องสมุดไม่ได้เชื่อมโยงอย่างแน่นหนา (addins / ปลั๊กอิน) และกำลังติดตามโพรโทคอลเมื่อพูดคุยกัน
หากเราหลีกเลี่ยงการพูดคุยเกี่ยวกับกรณีตัวกลางเหล่านั้นและจัดการเฉพาะกับไลบรารี API ที่เชื่อมโยงอย่างมากกับบริการ REST แยกต่างหากคุณอาจต้องพิจารณาประเด็นต่อไปนี้:
API ไลบรารีถูกเรียกใช้ในเครื่องเดียวกัน บริการสามารถโฮสต์ได้ทุกที่และถูกเรียกจากที่ใดก็ได้ หากคุณกำลังนับการโฮสต์แอปพลิเคชันบนเครื่องหลายเครื่องเพื่อเหตุผลด้านประสิทธิภาพ / ความสามารถในการปรับขนาด / ความปลอดภัยโอกาสที่คุณจะต้องใช้บริการ
สถานการณ์คล้ายกันเมื่อไปใช้หนึ่งบริการโดยแอปพลิเคชันที่ปรับใช้กับเครื่องหลายเครื่อง ตัวอย่างเช่นหากคุณกำลังทำแอปพลิเคชันสำหรับธนาคารที่ทำการคำนวณทางการเงินวิธีหนึ่งคือการปรับใช้แอพพลิเคชั่นขนาดใหญ่ทั้งหมดไปยังเดสก์ท็อปทุกเครื่องและถูกบังคับให้ทำการอัปเดตขนาดใหญ่ อีกวิธีหนึ่งก็คือการโฮสต์ส่วนการคำนวณบนเซิร์ฟเวอร์และปรับใช้กับเดสก์ท็อปเฉพาะแอพเบา ๆ ที่มีเพียง UI และการโทรไปยังเซิร์ฟเวอร์เหล่านั้น
หากคุณกำลังโฮสต์บริการ REST ทุกคนสามารถใช้งานได้: ผู้ใช้ Mac บุคคลที่ใช้ Linux ฯลฯ หากคุณสร้างไลบรารี C # ด้วย Visual Studio และคุณแจกจ่ายเป็น DLL ให้ลืมผู้ใช้ (ลูกค้า) ?) ใครไม่มี Windows
ข้อดีอีกประการของบริการคือเมื่อคุณอัปเดตบริการจะมีการปรับใช้กับผู้ใช้บริการทุกรายทันที ดังนั้นหากคุณแก้ไขข้อผิดพลาดหรือปัญหาด้านประสิทธิภาพทุกคนจะได้รับประโยชน์ทันทีที่บริการที่อัปเดตเริ่มทำงานแทนที่จะต้องเผยแพร่การอัปเดตที่คนอาจเลือกเพิกเฉย
ข้อดีห้องสมุด
ข้อดีบริการ:
วิธี SOA ช่วยให้บริการต่างๆสามารถโฮสต์และดูแลรักษาแยกกัน นอกจากรหัสแล้วการปรับใช้บริการเฉพาะอาจต้องการการกำหนดค่าพิเศษจำนวนมาก (รหัสผ่านพอร์ตใบรับรอง ฯลฯ ) การใช้เซอร์วิส REST มีความซับซ้อนจำนวน จำกัด ซึ่งสามารถจัดทำเป็นเอกสารและเข้าใจได้ง่าย นอกจากนี้ยังมีความปลอดภัยมากขึ้นเนื่องจากคุณไม่จำเป็นต้องให้สิทธิ์การเข้าถึงฐานข้อมูลหรือทรัพยากรอื่น ๆ แก่ลูกค้า
หากมีการเปลี่ยนแปลงบริการ SOA บริการ SOA นั้นจะต้องได้รับการพัฒนาใหม่ทดสอบซ้ำและปรับใช้ใหม่ แอปพลิเคชันทั้งหมดที่ใช้บริการนั้นสามารถดำเนินการต่อได้ การเปลี่ยนแปลงไลบรารีใน DLL จะหมายถึงผู้บริโภคทั้งหมดของไลบรารีนั้นจะต้องได้รับการพัฒนาใหม่เพื่ออ้างอิง DLL นั้นพวกเขาทั้งหมดจะต้องได้รับการทดสอบซ้ำและพวกเขาทั้งหมดจะต้องถูกปรับใช้ใหม่ นอกจากนี้ยังมีอันตรายที่อาจเกิดขึ้นไม่ถูกต้องและแอปพลิเคชันที่แตกต่างกันจะมี DLL รุ่นที่แตกต่างกัน บางครั้งสิ่งนี้อาจไม่เป็นปัญหา - บางทีทุกระบบควรมีเวอร์ชันของไลบรารีที่มีอยู่ ณ เวลาที่ใช้งาน (คุณอาจปรับปรุงระบบการบันทึกของคุณให้มีคุณสมบัติใหม่ที่เป็นประโยชน์จริง ๆ หรือไม่จำเป็นต้องอัปเดตทุกระบบด้วยหรือไม่) ในกรณีนี้ไลบรารีใช้ได้ แต่สมมติว่าคุณมีบริการสำหรับการคำนวณอัตราภาษีและการเปลี่ยนแปลงกฎหมายภาษี คุณไม่ต้องการอัปเดตทุกระบบเพื่อรวมการเปลี่ยนแปลงนี้จะเป็นการดีกว่าที่จะทำในที่เดียว ในกรณีนี้บริการเป็นตัวเลือกที่ดีกว่า
มีคำตอบที่ดีหลายอย่าง แต่ฉันต้องการเพิ่มสิ่งเพิ่มเติมในคำตอบที่ให้:
วิธีการไลบรารี API มีประโยชน์มากเมื่อคุณต้องการโต้ตอบกับสิ่งต่าง ๆ ด้วยค่าใช้จ่ายน้อยที่สุดเท่าที่จะทำได้ ผลที่ตามมาคือมีการเชื่อมต่อที่สูงขึ้นระหว่าง API และแอปพลิเคชันที่ใช้งาน บางครั้งมันก็โอเคสำหรับแอพพลิเคชั่นและจำเป็นอย่างไรก็ตามถ้าคุณมีระบบการกระจายที่มากหรือคุณคิดว่าการทำงานร่วมกันเป็นปัญหาใหญ่คุณอาจต้องก้าวไปข้างหน้าในสิ่งที่เป็นนามธรรมและใช้วิธีการสื่อสารอื่น ๆ โดยเฉพาะอย่างยิ่งถ้าคุณต้องการมีระบบกระจาย SOAP เป็นขั้นตอนต่อไปใน SOA แต่คุณจะยังคงพึ่งพาการพึ่งพาระหว่างหน่วยเนื่องจากพวกเขาต้องรู้ขั้นตอนของกันและกัน ส่วนที่เหลือนำไปสู่ระดับใหม่โดยอนุญาตให้เครื่องเรียนรู้บางอย่างเกี่ยวกับเนื้อหาในบริการอื่น ๆ ในลักษณะที่เป็นหนึ่งเดียว
ในกรณีของคุณหากใบสมัครของคุณไม่ได้รับการเผยแพร่ฉันไม่เห็นเหตุผลที่จะเปลี่ยนแอปพลิเคชันของคุณเป็น SOA