ฉันอ่าน Wikipedia และเว็บไซต์อื่น ๆ เกี่ยวกับOSGiแล้ว แต่ฉันไม่เห็นภาพรวม มันบอกว่ามันเป็นแพลตฟอร์มที่ใช้ส่วนประกอบและคุณสามารถโหลดโมดูลใหม่ได้ที่รันไทม์ นอกจากนี้ "ตัวอย่างการปฏิบัติ" ที่ให้ทุกที่คือ Framework Eclipse Plugin

คำถามของฉันคือ:

1. คำจำกัดความที่ชัดเจนและเรียบง่ายของ OSGi คืออะไร?

2. ปัญหาที่พบทั่วไปแก้ไขได้อย่างไร

โดย "ปัญหาทั่วไป" ฉันหมายถึงปัญหาที่เราเผชิญอยู่ทุกวันเช่น "OSGi ทำอะไรได้บ้างเพื่อทำให้งานของเรามีประสิทธิภาพ / สนุก / ง่ายขึ้น"

ระบบองค์ประกอบของ OSGi ให้ประโยชน์กับคุณอย่างไร?
ดีนี่คือรายการค่อนข้าง:

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

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

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

การปรับใช้อย่างง่ายดาย -เทคโนโลยี OSGi ไม่ได้เป็นเพียงมาตรฐานสำหรับส่วนประกอบ นอกจากนี้ยังระบุวิธีการติดตั้งและจัดการส่วนประกอบ API นี้มีการใช้งานโดยหลายกลุ่มเพื่อให้ตัวแทนการจัดการ เอเจนต์การจัดการนี้สามารถทำได้ง่ายเหมือนเชลล์คำสั่งไดรเวอร์โปรโตคอลการจัดการ TR-69, OMA DM โปรโตคอลไดรเวอร์, อินเทอร์เฟซการคำนวณแบบคลาวด์สำหรับ EC2 ของ Amazon หรือระบบการจัดการ IBM Tivoli API การจัดการที่ได้มาตรฐานทำให้ง่ายต่อการรวมเทคโนโลยี OSGi ในระบบปัจจุบันและอนาคต

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

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

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

การกำหนดเวอร์ชัน -เทคโนโลยี OSGi แก้ปัญหานรก JAR JAR hell เป็นปัญหาที่ library A ทำงานกับ library B; version = 2 แต่ library C สามารถทำงานกับ B; version = 3 เท่านั้น ใน Java มาตรฐานคุณไม่มีโชค ในสภาพแวดล้อม OSGi บันเดิลทั้งหมดมีการกำหนดเวอร์ชันอย่างระมัดระวังและมีการรวมกลุ่มเท่านั้นที่สามารถทำงานร่วมกันได้ในสายคลาสเดียวกัน สิ่งนี้ทำให้ทั้งกลุ่ม A และ C สามารถทำงานกับไลบรารีของตัวเองได้ แม้ว่าจะไม่แนะนำให้ออกแบบระบบที่มีปัญหาเกี่ยวกับการกำหนดรุ่นนี้ แต่ก็สามารถช่วยชีวิตได้ในบางกรณี

เรียบง่าย - OSGi API นั้นเรียบง่ายอย่างน่าประหลาดใจ API หลักเป็นเพียงแพ็คเกจเดียวและน้อยกว่า 30 คลาส / อินเตอร์เฟส API หลักนี้เพียงพอที่จะเขียนบันเดิลติดตั้งเริ่มหยุดอัปเดตและถอนการติดตั้งรวมถึงผู้ฟังและคลาสความปลอดภัยทั้งหมด มี API น้อยมากที่ให้การทำงานมากมายสำหรับ API เพียงเล็กน้อยเท่านั้น

ขนาดเล็ก - OSGi Release 4 Framework สามารถนำไปใช้กับไฟล์ 300KB JAR นี่เป็นค่าใช้จ่ายเล็กน้อยสำหรับปริมาณการใช้งานที่เพิ่มลงในแอปพลิเคชันโดยรวมถึง OSGi OSGi ทำงานบนอุปกรณ์หลากหลายประเภทตั้งแต่ขนาดเล็กไปจนถึงขนาดเล็กจนถึงเมนเฟรม จะขอให้ Java VM ขั้นต่ำเรียกใช้และเพิ่มเพียงเล็กน้อยเท่านั้น

รวดเร็ว - หนึ่งในความรับผิดชอบหลักของกรอบงาน OSGi คือการโหลดคลาสจากบันเดิล ใน Java แบบดั้งเดิม JARs จะมองเห็นได้อย่างสมบูรณ์และวางไว้ในรายการเชิงเส้น การค้นหาคลาสต้องการการค้นหาผ่านรายการ (มักจะยาวมาก, 150 ไม่ใช่เรื่องแปลก) ในทางตรงกันข้าม OSGi มีการมัดสายล่วงหน้าและรู้สำหรับแต่ละชุดว่าชุดใดให้ชั้นเรียน การขาดการค้นหานี้เป็นตัวเร่งความเร็วที่สำคัญเมื่อเริ่มต้น

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

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

Non Intrusive -แอปพลิเคชั่น (บันเดิล) ในสภาพแวดล้อม OSGi นั้นเป็นของตัวเอง พวกเขาสามารถใช้เครื่องมืออำนวยความสะดวกใด ๆ ของ VM ได้โดยไม่ต้อง จำกัด OSGi แนวปฏิบัติที่ดีที่สุดใน OSGi คือการเขียน Plain Java Objects แบบธรรมดาและด้วยเหตุนี้จึงไม่มีอินเตอร์เฟสพิเศษที่จำเป็นสำหรับบริการ OSGi แม้แต่วัตถุ Java String ก็สามารถทำหน้าที่เป็นบริการ OSGi ได้ กลยุทธ์นี้ทำให้รหัสแอปพลิเคชันง่ายต่อการพอร์ตไปยังสภาพแวดล้อมอื่น

วิ่งได้ทุกที่ -ดีขึ้นอยู่กับว่า เป้าหมายดั้งเดิมของ Java คือการทำงานทุกที่ เห็นได้ชัดว่าเป็นไปไม่ได้ที่จะเรียกใช้รหัสทั้งหมดในทุกที่เพราะความสามารถของ Java VMs แตกต่าง VM ในโทรศัพท์มือถืออาจไม่รองรับไลบรารีเดียวกับเมนเฟรมของ IBM ที่ใช้แอปพลิเคชันธนาคาร มีสองประเด็นที่ต้องดูแล ก่อนอื่น OSGi API ไม่ควรใช้คลาสที่ไม่สามารถใช้ได้กับทุกสภาพแวดล้อม ประการที่สองมัดไม่ควรเริ่มถ้ามันมีรหัสที่ไม่สามารถใช้ได้ในสภาพแวดล้อมการดำเนินการ ปัญหาทั้งสองนี้ได้รับการดูแลในข้อกำหนดของ OSGi

ที่มา: www.osgi.org/Technology/WhyOSGi

ฉันพบประโยชน์ดังต่อไปนี้จาก OSGi:

• แต่ละปลั๊กอินเป็นสิ่งประดิษฐ์รุ่นที่มี classloader ของตัวเอง
• ปลั๊กอินแต่ละตัวขึ้นอยู่กับขวดเฉพาะทั้งที่มีอยู่และปลั๊กอินรุ่นอื่น ๆ ที่เฉพาะเจาะจง
• เนื่องจากการกำหนดเวอร์ชันและ classloaders แบบแยกจึงสามารถโหลดเวอร์ชันต่าง ๆ ของสิ่งประดิษฐ์เดียวกันได้ในเวลาเดียวกัน หากส่วนประกอบหนึ่งของแอปพลิเคชันของคุณอาศัยปลั๊กอินเวอร์ชันหนึ่งและอีกองค์ประกอบหนึ่งขึ้นอยู่กับเวอร์ชันอื่นทั้งสองนั้นสามารถโหลดได้ในเวลาเดียวกัน

ด้วยสิ่งนี้คุณสามารถจัดโครงสร้างแอปพลิเคชันของคุณเป็นชุดของส่วนปลั๊กอินเวอร์ชันที่โหลดตามต้องการ ปลั๊กอินแต่ละตัวเป็นองค์ประกอบแบบสแตนด์อโลน เช่นเดียวกับที่ Maven ช่วยคุณจัดโครงสร้างงานสร้างของคุณดังนั้นจึงสามารถทำซ้ำได้และกำหนดโดยชุดของสิ่งประดิษฐ์เฉพาะรุ่นที่สร้างโดย OSGi ช่วยให้คุณทำสิ่งนี้ได้ในขณะทำงาน

ฉันไม่สนใจมากเกินไปเกี่ยวกับ hotplugability ของโมดูล OSGi (อย่างน้อยปัจจุบัน) มันเป็นโมดุลที่บังคับใช้มากขึ้น ไม่มีคลาส "สาธารณะ" ที่มีอยู่ใน classpath เมื่อใดก็ได้ปกป้องได้ดีจากการพึ่งพาแบบวนรอบ: คุณต้องคิดถึงอินเทอร์เฟซสาธารณะของคุณจริงๆ - ไม่ใช่แค่ในแง่ของภาษาจาวาสร้าง "สาธารณะ" แต่ในแง่ของห้องสมุดของคุณ / module: อะไรคือองค์ประกอบที่คุณต้องการให้คนอื่นได้ใช้? อินเทอร์เฟซ (โมดูลอื่น ๆ ) คืออะไรที่คุณต้องการใช้ในการใช้งานจริง ๆ

เป็นเรื่องดีที่ hotplug นั้นมาพร้อมกับมัน แต่ฉันต้องการรีสตาร์ทแอปพลิเคชันปกติของฉันมากกว่าที่จะทดสอบ hotplugability ทั้งหมดที่รวมกัน ...

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

มีประโยชน์มากมาย (ฉันเตือนเพียงแค่ตอนนี้) พร้อมใช้งานสำหรับทุกคนที่ใช้ Java

แก้ไขเพื่อความชัดเจน หน้า OSGi ให้คำตอบที่ง่ายกว่าของฉัน

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

ในโครงสร้างแอปพลิเคชันเดียวพูด Eclipse IDE ไม่ใช่เรื่องใหญ่ที่จะต้องเริ่มใหม่เมื่อคุณติดตั้งปลั๊กอินใหม่ การใช้การติดตั้ง OSGi อย่างสมบูรณ์คุณควรจะสามารถเพิ่มปลั๊กอินตอนรันไทม์รับฟังก์ชั่นใหม่ แต่ไม่ต้องรีสตาร์ทคราสเลย

ไม่ใช่เรื่องใหญ่สำหรับแอปพลิเคชันขนาดเล็กทุกวัน

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

OSGi แก้ปัญหาทั่วไปหรือไม่ฉันไม่แน่ใจ ฉันหมายความว่ามันทำได้ แต่ค่าใช้จ่ายอาจไม่คุ้มกับปัญหาที่ง่ายขึ้น แต่เป็นสิ่งที่ควรพิจารณาเมื่อคุณเริ่มรับมือกับแอปพลิเคชั่นขนาดใหญ่กว่าเครือข่าย

บางสิ่งที่ทำให้ฉันบ้าบน OSGi:

1) การปลูกฝังและบริบทของพวกเขามีนิสัยแปลก ๆ มากมายและอาจจะค่อนข้าง async (เราใช้เฟลิกซ์ในการบรรจบกัน) เมื่อเปรียบเทียบกับสปริงบริสุทธิ์ (ไม่มี DM) ที่ [main] นั้นวิ่งผ่านทุกอย่างที่ซิงค์กันอยู่

2) คลาสไม่เท่ากันหลังจากโหลดร้อน ตัวอย่างเช่นคุณมีเลเยอร์แคช tangosol ที่จำศีล มันเต็มไปด้วย Fork.class นอกขอบเขต OSGi คุณโหลดไห้ไห้ใหม่และ Fork ไม่เปลี่ยน Class [Fork]! = คลาส [Fork] นอกจากนี้ยังปรากฏในระหว่างการทำให้เป็นอนุกรมสำหรับสาเหตุพื้นฐานเดียวกัน

3) การจัดกลุ่ม

คุณสามารถแก้ไขสิ่งเหล่านี้ได้ แต่มันเป็นความเจ็บปวดครั้งใหญ่และทำให้สถาปัตยกรรมของคุณดูมีข้อบกพร่อง

และสำหรับพวกคุณที่โฆษณาฮอตปลั๊ก .. ลูกค้าอันดับ 1 ของ OSGi คราส. Eclipse ทำอะไรหลังจากโหลดบันเดิล?

มันเริ่มใหม่

OSGi ทำให้รหัสของคุณโยนNoClassDefFoundErrorและClassNotFoundExceptionไม่มีเหตุผลที่ชัดเจน (ส่วนใหญ่อาจเป็นเพราะคุณลืมที่จะส่งออกแพคเกจในไฟล์การกำหนดค่า OSGi); เนื่องจากมันมี ClassLoaders มันสามารถทำให้คลาสของคุณcom.example.Fooล้มเหลวในการส่งcom.example.Fooเนื่องจากจริง ๆ แล้วมีสองคลาสที่แตกต่างกันโหลดโดย classloaders ที่แตกต่างกันสอง มันสามารถทำให้การบูต Eclipse ของคุณเป็นคอนโซล OSGi หลังจากติดตั้งปลั๊กอิน Eclipse

สำหรับฉันแล้ว OSGi เพิ่มความซับซ้อนเท่านั้น (เพราะมันเพิ่มโมเดลจิตอีกหนึ่งสำหรับฉันที่จะ grok) เพิ่มความรำคาญเพราะข้อยกเว้น; ฉันไม่เคยต้องการความไดนามิกที่มัน "เสนอ" มันเป็นการล่วงล้ำเนื่องจากต้องมีการกำหนดค่าบันเดิลของ OSGi สำหรับโมดูลทั้งหมด มันไม่ง่ายอย่างแน่นอน (ในโครงการขนาดใหญ่)

เนื่องจากประสบการณ์ที่ไม่ดีของฉันฉันมักจะอยู่ห่างจากสัตว์ประหลาดนั้นขอบคุณมาก ฉันควรทนทุกข์ทรมานจากนรกพึ่งพา jar เนื่องจากเป็นวิธีที่เข้าใจได้ง่ายกว่า Hell classloader ที่ OSGi แนะนำ

ฉันยังไม่ได้เป็น "แฟน" ของ OSGi ...

ฉันทำงานกับแอปพลิเคชันระดับองค์กรที่ บริษัท Fortune 100 เมื่อเร็ว ๆ นี้ผลิตภัณฑ์ที่เราใช้มี "อัปเกรด" เป็นการนำ OSGi ไปใช้

เริ่มต้นการปรับใช้ cba ในพื้นที่ ... [2/18/14 8: 47: 23: 727 EST] 00000347 CheckForOasis

ในที่สุดปรับใช้และ "บันเดิลต่อไปนี้จะถูก quiesced แล้วรีสตาร์ท" [2/18/14 9: 38: 33: 108 EST] 00000143 AriesApplicat ฉัน CWSAI0054I: เป็นส่วนหนึ่งของการดำเนินการปรับปรุงสำหรับแอปพลิเคชัน

51 นาที ... การเปลี่ยนแปลงรหัสเวลาแต่ละครั้ง ... รุ่นก่อนหน้า (ที่ไม่ใช่ OSGi) จะปรับใช้ในเวลาน้อยกว่า 5 นาทีสำหรับเครื่องพัฒนารุ่นเก่า

บนเครื่องที่มี 16 gig ram และ 40 gig disk ฟรีและ Intel i5-3437U 1.9 GHz CPU

"ประโยชน์" ของการอัปเกรดนี้ขายเป็นการปรับปรุง (การผลิต) การปรับใช้ - กิจกรรมที่เราทำประมาณ 4 ครั้งต่อปีโดยอาจมีการปรับใช้ขนาดเล็ก 2-4 ครั้งต่อปี เพิ่ม 45 นาทีต่อวันให้กับ 15 คน (QA และนักพัฒนาซอฟต์แวร์) ฉันไม่สามารถจินตนาการได้ว่าจะได้รับการพิสูจน์ ในแอปพลิเคชันขององค์กรขนาดใหญ่หากแอปพลิเคชันของคุณเป็นแอปพลิเคชันหลักการเปลี่ยนแปลงนั้นเป็นสิ่งที่ถูกต้องดังนั้น (การเปลี่ยนแปลงเล็กน้อยมีศักยภาพในการเข้าถึงผลกระทบได้ - ต้องมีการสื่อสารและวางแผนกับผู้บริโภคทั่วทั้งองค์กร) OSGi หากแอปพลิเคชันของคุณไม่ใช่แอปพลิเคชันระดับองค์กร - เช่นผู้บริโภคแต่ละรายสามารถมีโมดูลที่ปรับแต่งเองของพวกเขาน่าจะโดนไซโลข้อมูลของตัวเองในฐานข้อมูลไซโลของตัวเองและทำงานบนเซิร์ฟเวอร์ที่โฮสต์แอปพลิเคชั่นจำนวนมาก อย่างน้อย,

หากแอปพลิเคชันที่ใช้ Java ต้องการเพิ่มหรือลบโมดูล (ขยายการทำงานพื้นฐานของแอปพลิเคชัน) โดยไม่ต้องปิด JVM คุณสามารถใช้ OSGI ได้ โดยปกติถ้าค่าใช้จ่ายในการปิด JVM นั้นมากขึ้นเพียงเพื่อปรับปรุงหรือเพิ่มประสิทธิภาพการทำงาน

ตัวอย่าง :

1. Eclipse : จัดเตรียมแพลตฟอร์มสำหรับปลั๊กอินเพื่อติดตั้งถอนการติดตั้งอัพเดตและพึ่งพาระหว่างกัน
2. AEM : แอปพลิเคชัน WCM ซึ่งการเปลี่ยนแปลงการทำงานจะขับเคลื่อนธุรกิจซึ่งไม่สามารถลดเวลาในการบำรุงรักษาได้

หมายเหตุ : Spring framework หยุดการสนับสนุนบันเดิลสปริง OSGI โดยพิจารณาว่าเป็นความซับซ้อนที่ไม่จำเป็นสำหรับแอปพลิเคชันที่ใช้งานธุรกรรมหรือสำหรับบางจุดในบรรทัดเหล่านี้ ฉันไม่พิจารณา OSGI เป็นการส่วนตัวเว้นแต่จะจำเป็นจริงๆในบางสิ่งที่ยิ่งใหญ่เช่นการสร้างแพลตฟอร์ม

ฉันทำงานกับ OSGi มาเกือบ 8 ปีแล้วและฉันต้องบอกว่าคุณควรพิจารณา OSGi เฉพาะเมื่อคุณมีธุรกิจที่จำเป็นต้องอัปเดตลบติดตั้งหรือเปลี่ยนส่วนประกอบในรันไทม์ นอกจากนี้ยังหมายความว่าคุณควรมีความคิดแบบแยกส่วนและเข้าใจความหมายแบบโมดูล มีข้อโต้แย้งบางประการที่ว่า OSGi นั้นมีน้ำหนักเบาใช่ว่าเป็นเรื่องจริง แต่ก็มีบางกรอบที่มีน้ำหนักเบาและง่ายต่อการบำรุงรักษาและพัฒนา กันแล้วจะปลอดภัย java blah blah

OSGi ต้องการสถาปัตยกรรมที่แข็งแกร่งที่จะใช้อย่างถูกต้องและมันค่อนข้างง่ายที่จะทำให้ระบบ OSGi นั้นสามารถเป็น jar แบบสแตนด์อโลนที่ทำงานได้โดยไม่ต้องมี OSGi เข้ามาเกี่ยวข้อง

OSGi ให้ประโยชน์ดังต่อไปนี้:

■สภาพแวดล้อมการดำเนินการแบบพกพาและปลอดภัยบนพื้นฐานของ Java

■ระบบการจัดการบริการซึ่งสามารถใช้ในการลงทะเบียนและแบ่งปันบริการข้ามกลุ่มและแยกผู้ให้บริการจากผู้ใช้บริการ

■ระบบโมดูลแบบไดนามิกซึ่งสามารถใช้ในการติดตั้งและถอนการติดตั้งโมดูล Java ซึ่ง OSGi เรียกชุดรวม

■โซลูชันที่มีน้ำหนักเบาและปรับขนาดได้

นอกจากนี้ยังใช้เพื่อเพิ่มความสามารถในการพกพาของมิดเดิลแวร์และแอพพลิเคชั่นบนมือถือ ด้านมือถือพร้อมใช้งานสำหรับ WinMo, Symbian, Android เป็นต้น ทันทีที่เกิดการรวมกับคุณสมบัติของอุปกรณ์สามารถแยกส่วนได้

อย่างน้อยที่สุด OSGi ทำให้คุณคิดเกี่ยวกับโมดูล, การนำโค้ดกลับมาใช้, การกำหนดเวอร์ชันและโดยทั่วไปการวางท่อของโครงการ

คนอื่น ๆ ได้อธิบายถึงประโยชน์ในรายละเอียดแล้วฉันขออธิบายการใช้งานจริงที่ฉันได้เห็นหรือใช้ OSGi

1. ในหนึ่งในแอปพลิเคชันของเราเรามีการไหลตามเหตุการณ์และการไหลถูกกำหนดไว้ในปลั๊กอินตามแพลตฟอร์ม OSGi ดังนั้นในวันพรุ่งนี้หากลูกค้าบางคนต้องการการไหลที่แตกต่างกัน / เพิ่มเติมจากนั้นเขาก็ต้องปรับใช้ปลั๊กอินอีกหนึ่งกำหนดค่าจากคอนโซลของเรา .
2. มันถูกใช้สำหรับการปรับใช้ตัวเชื่อมต่อ Store ที่แตกต่างกันตัวอย่างเช่นสมมติว่าเรามีตัวเชื่อมต่อ Oracle DB อยู่แล้วและพรุ่งนี้จะต้องเชื่อมต่อ MongoDB จากนั้นจึงเขียนตัวเชื่อมต่อใหม่และปรับใช้และกำหนดรายละเอียดผ่านคอนโซล การปรับใช้คอนเน็กเตอร์ได้รับการจัดการโดยกรอบงานปลั๊กอิน OSGi

มีข้อความที่น่าเชื่ออยู่แล้วในเว็บไซต์อย่างเป็นทางการของฉันฉันอาจพูดได้ว่า

เหตุผลหลักที่ทำให้เทคโนโลยี OSGi ประสบความสำเร็จอย่างมากคือมันมีระบบองค์ประกอบที่สมบูรณ์แบบซึ่งทำงานได้จริงในสภาพแวดล้อมที่น่าประหลาดใจ ระบบคอมโพเนนต์ OSGi นั้นใช้ในการสร้างแอปพลิเคชันที่มีความซับซ้อนสูงเช่น IDEs (Eclipse), แอพพลิเคชันเซิร์ฟเวอร์ (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), กรอบงานแอพพลิเคชั่น (สปริง, Guice), ระบบอัตโนมัติอุตสาหกรรม โทรศัพท์และอีกมากมาย

ในฐานะที่เป็นประโยชน์ต่อการพัฒนา?

ผู้พัฒนา: OSGi ลดความซับซ้อนด้วยการจัดหาสถาปัตยกรรมแบบแยกส่วนสำหรับระบบกระจายขนาดใหญ่ในปัจจุบันรวมถึงแอปพลิเคชันขนาดเล็กที่ฝังตัว การสร้างระบบจากโมดูลภายในและนอกชั้นวางช่วยลดความซับซ้อนและลดค่าใช้จ่ายในการพัฒนาและบำรุงรักษา รูปแบบการเขียนโปรแกรม OSGi ตระหนักถึงคำมั่นสัญญาของระบบที่อิงองค์ประกอบ

กรุณาตรวจสอบรายละเอียดในประโยชน์ของการใช้ OSGi