แปลมาจาก OSGi in a nutshell

อีกบทความที่เนื้อหาในส่วนี้คือการแสดงให้เห็นภาพกว้างๆของ OSGi รายละเอียดเชิงลึกสามารถอ่านได้จากเอกสาร OSGi specification

OSGi specification 

เอกสาร OSGi Spec นี้อธิบายว่า OSGi Service Platform ประกอบไปด้วยสองส่วนใหญ่ๆคือ OSGi Framework และอีกส่วนคือการกำหนดเซอร์วิสมาตรฐาน โดยที่ตัวเฟรมเวิร์คนั้นจะทำงานอยู่บน JVM ซึ่ง JVM นี้ถือเป็นสภาพแวดล้อมที่ใช้ทำงาน (Execution Environment) สำหรับเซอร์วิส ที่ ณ จุดเริ่มต้นนั้น OSGi framework ถูกกำหนดให้ถูกใช้งานอยู่ในสภาวะแวดล้อมการทำงานที่จำกัด เช่น set-top box ในภาพประกอบที่ 1 อย่างไรก็ตาม OSGi ยังสามารถถูกใช้งานในโดเมนอื่นๆได้อีกเช่นกันยกตัวอย่างเช่นทำเป็นโครงสร้างพื้นฐานของ Eclipse 3.0 

Figure 1. OSGi overview

The OSGi framework

ภายในเฟรมเวิร์คเองยังถูกแบ่งออกเป็นสองส่วนด้วยกันคือ:

• เซอร์วิสแพลทฟอร์ม (Service Platform) 

• โครงสร้างพื้นฐานการเพื่อการติดตั้ง(Deployment infrastructure)

Services Platform

นิยามของคำว่าเซอร์วิสแพลทฟอร์มคือแพลทฟอร์มที่รองรับการทำงานเชิงเซอร์วิสตามภาพประกอบที่ 2 โดยที่มีเพียง Sevice Registry เท่านั้นที่ผูกติดอยู่กับ เซอร์วิสแพทฤอร์ม โดยที่ส่วนประกอบทั้งสามอันประกอบด้วย Service Registry, Service Provider และ Service Request นั้นมีปฏิสัมพันธ์กันดังนี้ Service Provider ทำการ publish เซอร์วิส หลังจากนั้น Service Requester จะทำการ discover และ  bind เซอร์วิสเข้ากับ Service Provider โดยที่กระบวนการการทำ Publication และ Discovery นั้นจะทำอยู่บน Service Description

Figure 2. Service orientation interaction

โดยที่ในโลกของ OSGi นั้นตัวเซอร์วิสเองก็คือ Java คลาสหรืออินเทอร์เฟส โดยที่เซอร์วิสอินเทอร์เฟสนั้นจะประกอบไปด้วยแอททริบิวท์ ที่เรียกว่าเซอร์วิสพรอพเพอร์ตี้ ที่มีค่าประกอบมาด้วยพร้อมกัน การมีอยู่ของเซอร์วิสพรอพเพอร์ตี้ทำให้เราสามารถสร้างเซอร์วิสหลายตัวที่มีเซอร์วิสอินเทอร์เฟสเดียวกันให้มีความต่างได้ ส่วนหนึ่งในหน้าที่ของ Service Registry คือเตรียมคำสั่งพื้นฐานที่ใช้ในการค้นหาที่มีลักษณะเดียวกันกับ LDAP เพื่อใช้ในการค้นหา Service Provider และอีกหน้าที่หนึ่งก็คือการเตรียมการเรื่อง เมสเสจเตือน ในกาณีที่เกิดการเปลี่ยนแปลงใดๆใน Service Registry ไปยังผู้รับจากภาพประกอบที่สองเราจะเห็นว่าจริงๆแล้ว Service Provider และ Requester นั้นประกอบกันขึ้นมาเป็นสิ่งๆหนึ่งที่ในโลกของ OSGi เรียก Bundle โดยที่เซอร์วิสอินเทอร์เฟสนั้นจะถูกอิมฟลีเมนท์โดยออบเจคที่ถูกสร้างโดย Bundle และในมาตรฐาน OSGi นั้นตัว Bundle เองมีหน้าที่รับผิดชอบหลักคือการทำ การจัดการและบริหารภาวะความสัมพันธ์ ณ ขณะรันไทม์ (run-time service dependency management activity) ซึ่งในที่นี้จะรวมไปถึงการทำ publication, discovery, binding และการรับรู้สภาวะการเปลี่ยนแปลงเมื่อเกิดการทำ dynamic availability เช่นเมื่อเซอร์วิสที่เราลงชื่อใช้ไว้เปิดให้ใช้งานหรือปิดไม่ให้ใช้งาน bundle จะต้องรับรู้สภาวะนั้นๆได้  

Deployment infrastructure

สำหรับ OSGi แล้วการติดตั้ง bundle สามารถทำได้ด้วยการแพคคลาสไฟล์ที่เราต้องการทำเป็นเซอร์วิสพร้อมกับรีซอร์สต่างๆและนอกจากนี้ยังมีไฟล์พิเศษที่ใช้ในการอธิบาย bundle นั่นคือ manifest ไฟล์ เข้าเป็น JAR ไฟล์ โดยที่ OSGi เองนั้นรองรับการทำงานแบบ continuous deployment โดยที่รายละเอียดย่อยของการทำ deployment นั้นประกอบไปด้วย installation removal update starting stopping และเมื่อใดก็ตามที่มีการติดตั้ง bundle ลงไปในแพลทฟอร์ม มันจะถูก activate ในทันทีในกรณีที่ส่วนเกี่ยวข้องทั้งหมดที่เราประกาศว่าเราจำเป็นต้องใช้ (deployment dependency) นั้นถูกเตรียมพร้อมอยู่ในแพลทฟอร์มแล้ว

Figure 3. Physical bundle life-cycle

ซึ่งกระบวนการการทำ deployment นั้นสามารถร้อยเรียงออกมาเป็นขั้นตอนที่แน่นอนได้ดังภาพประกอบที่ 3 ซึ่งกระบวนการการ activate และ de-activate ไฟล์ jar ของ bundle นั้นจะส่งผลต่อการสร้างหรือทำลาย เซอร์วิสของ bundle (มุมมองทางโลจิก) ของคลาสที่อยู่ใน bundle นั้นซึ่งกระบวนการนี้เรียกว่า bundle activator 

ซึ่งเราจะเข้สภาพการทำงานของ OSGi มากขึ้นเมื่อเราเริ่มเขียน code ในตอนหน้า 

พยายามหาเอกสารพิ้นฐานเรื่อง OSGi แต่หายากมากมีอยู่ที่เดียวคือที่เวบ http://www.osgi.org/About/WhatIsOSGi อ่านไปงงไปแต่ดีที่สุดเท่าที่หาได้แล้วครับ การถอดความเป็นไปอย่างยากลำบากเพราะสำนวนเทพมากประกอบกับความรู้ยังไม่มากนัก แต่ก็อ่านกันไปก่อนนะครับ คาดว่าเข้าส่วนของ tutorail แล้วคงจะเห็นภาพมากขึ้น
ส่วนประกอบหลักของ OSGi นั้นประกอบไปด้วย 7 ส่วนด้วยกัน

1. Bundles – คือคอมโพเนนท์ของแอพพลืเคชั่นที่สร้างขึ้นเพื่อนำไปติดตั้งบน OSGi
2. Services – ส่วนเชื่อมต่อกับ Bundle ที่ต่อกันแบบพลวัตเพื่อทำให้เกิดสภาพแวดล้อมแบบ publish-find-bind สำหรับการ plain old Java objects.
3. Life-Cycle – เป็น API ที่ถูกติดตั้งเพื่อใช้ในการทำ install, start, stop, update และ uninstall bundles.
4. Modules – ที่ชั้นนี้เป็นชั้นที่ถูกสร้างเพื่อกำหนดกระบวนการว่าโค้ดของ Bundle จะถูก import และ export อย่างไร
5. Security – ชั้นนี้ชัดเจนเรื่องของระบบรักษาความปลอดภัย
6. Execution Environment – สภาพแวดล้อมในการทำงานชั้นนี้จะทำหน้าที่เตรียมและกำหนดว่ามีคลาสและเมธอดใดบ้างที่สามารถใช้งานได้
7. ส่วนต่อไปคือรายละเอียดแบบเจาะลึกของส่วนต่างๆ

Modules
แนวคิดพื้นฐานที่ทำให้ระบบของเราสามารถมีความเป็น Modularity ซึ่งเรื่องของ Modularity นั้นก็เป็นเรื่องง่ายๆคือ “assuming less” เป็นเรื่องของการเก็บทุกอย่างให้อยู่ในขอบเขตของตัวเอง ไม่ปล่อยหรือแบ่งใช้อะไร กับคนอื่นมากนัก ซึ่งเรื่อง modularity เป็นหัวใจหลักของ OSGi ในเรื่องของเทคนิคการมัดหรือยึดคอมโพเนนท์เข้าด้วยกัน ซึงในมุมมองของ Java แล้ว bundle มันคือการสร้าง Jar ไฟล์แต่อย่างไรก็ตามข้อเสียคือทุกๆอย่างใน Jar จะสามารถถูกใช้ร่วมกันได้อย่างสมบูรณ์แบบระหว่าง Jar ด้วยกันเอง แต่ในกรณีของ OSGi นั้นจะทำการซ่อนทุกอย่างใน Jar ไว้ยกเว้นแต่จะมีการประกาศให้ใช้อย่างเป็นทางการเท่านั้น ดังนั้ bundle ใดๆที่ต้องการใช้ jar ตัวอื่นจะต้องทำการประกาศการใช้อย่างถูกต้องเท่านั้น
การซ่อนข้อมูลและการเตรียมการ share นั้นทำให้เกิดข้อดีหลายข้อด้วยกันยกตัวอย่างเช่น สามารถทำให้ module ต่างๆที่ถูกติดตั้งใน single JVM นั้นสามารถมีได้หลาย version ได้
Services
เหตุผลที่เราต้องใช้เซอร์วิสโมเดลเนื่องมาจาก Java ได้แสดงให้เราเห็นมานานแล้วว่าการใช้เพียงแค่การแชร์คลาส เพื่อนำมาสร้างงานในเชิง collaborative model เป็นเรื่องที่ยากมาก ซึ่งสิ่งที่จาวาทำได้นั้นคือการใช้ Factories ที่ใช้กระบวนการการทำ dynamic class loading และคุณสมบัติการทำ static ใน java เองยกตัวอย่างเช่นในกรณีที่เราใช้งาน DocumentBuilderFactory เพื่อสร้างอะไรบางอย่างให้เราสิ่งที่เราต้องทำคือการเรียก DocumentBuilderFactory.newInstance() ซึ่งกระบวนการที่เกิดขึ้นข้างหลังคือมันจะสร้าง instance ของคลาสลูก DocumentBuilderFactory ด้วยทุกกรรมวิธีในการใช้ class loader ที่มีในตำรา  Trying to influence what implementation is used is non-trivial (services model, properties, conventions in class name), และแน่นอนสามารถเข้าถึงได้จากทุกๆที่บน VMและ instance นี้ยังทำงานแบบ passive คือมันไม่สารถบอกหรือส่งสัญญาณอะไรออกไปได้ว่าตอนนี้มันพร้อมถูกใช้งานแล้วและอีกเช่นกันที่ผู้ใช้ไใสามารถที่จะเลือกได้ว่า implementation ตัวไหนคือตัวที่เราต้องการกันแน่ และเมื่อ implementation ทำงานเสร็จแล้วมันก็ไม่สามารถที่จะเป็นอิสระได้และที่แย่ที่สุดคือ factory นั้นจะถูกใช้อย่างแพร่หลายใน VM และแต่ละ factory เองก็จะมีกระบวนการทำงานที่ต่างกัน ใช้ไลบรารี่ที่แตกต่างกันอีกเช่นกัน เราไม่สามารถหาศูนย์รวมที่เก็บ implementation ที่เราสามารถเลือกได้ว่าเราจะใช้งานตัวไหนกันแน่
ทางออกสำหรับปัญหานี้คือการใช้ OSGi Service Registry ซึ่งเราสามารถสร้าง bundle ขึ้นมาและลงทะเบียนไว้กับ service registry ว่าเราอยู่ภายใต้อินเทอร์เฟสตัวใด(มากกว่าหนึ่ง) ดังนั้น bundle ตัวอื่นๆจึงสามารถเข้ามาที่ registry และทำการเลือกดูว่ามีออบเจคใดที่มีคุณสมบัติตรงตามที่เราต้องการบ้าง ยกตัวอย่างเช่น เราสามารถเตรียม implementatio คลาสของ DocumentBuilder ไว้เพื่อใช้งานได้โดยจังหวะที่สร้าง instance ของ DocumentBuilderFactoryImpl จะถูกสร้างและลงทะเบียนไว้ภายใต้อินเทอร์เฟส DocumentBuilderFactory ดังนั้น bundle ใดๆก็ตามที่ต้องการใช้ DocumentBuilderFactory สามารถเข้ามาที่ registry และถามหาเซอร์วิสทั้งหมดที่อยู่ภายใต้ DocumentBuilderFactory  แต่ในกรณีที่ไม่พบเซอร์วิสที่ต้องการ bundle สามารถลงทะเบียนเพื่อรอได้และเมื่อใดก็ตามที่เซอร์วิสพร้อมให้บริการจะมีการส่ง callback message  กลับไปที่ bundle นั้นๆ
ดังนั้นภาพที่ออกมาจึงเป็นเชิงที่ bundle สามารถลงทะเบียนเซอร์วิส สามารถเรียกใช้เซอร์วิสและสามารถรอรับฟังความเคลื่อนไหวของเซอร์วิสความสัมพันธ์ระหว่าง bundles กับเซอร์วิสจออกมาในแนวของ many-to-many สามารถดูภาพประกอบได้

เกิดอะไรขึ้นในกรณีที่มี bundle หลายตัวต้องการลงทะเบียนภายใต้ชื่ออินเทอร์เฟสหรือคลาสเดียวกัน เราจะทำไงดี คำตอบคือพรอพเพอร์ตี้นั่นเอง ทุกๆเซอร์วิสที่ต้องการลงทะเบียนจะมีชุดพรอพเพอร์ตี้มาตรฐานและพิเศษเพื่อใช้สำหรับระบุความแตกต่าง และในมุมของการค้นหาก็สามารถทำได้ด้วยการใช้ filter language เข้ามาช่วยเพื่อให้เราสามารถพบเซอร์วิสที่เราต้องการจริงๆ นอกจากนี้เซอร์วิสทั้งหมดนั้นเป็นแบบพลวัตคือเราใช้งานเรียบร้อยเมื่อไหร่ก็สามารถเลิกใช้งานและถอดออกได้ทันที ในขณะเดียวกัน bundle ก็สามารถที่จะถอดเซอร์วิสของตัวเองออกจาก registry ได้ทุกเวลาเช่นกันแม้กระทั้งขณะนั้นยังมีคนใช้งานมันอยู่ด้วยก็ตาม อย่างไรก็ตามกระบวนการแบบนี้ดูเหมือนจะเป็นเรื่องที่ยุ่งยากและซับซ้อนมากๆแต่ปัญหาเรื่องความยุ่งยากก็สามารถลดลงไปได้มากเพราะมีเครื่องมืออย่าง Service Tracker และเฟรมเวิร์คอย่าง iPojo, Spring, Declarative Service ที่ทำให้เรามองเห็นข้อดีที่มีมากกว่าข้อเสียของการทำงานแบบนี้ได้ เรื่องพลวัตนี้เป็นเรื่องซับซ้อนพอสมควรอย่างไรก็ตามถ้าเราเปรียบเทียบกับสิ่งที่เราสามารถสัมผัสได้เราจะมองเห็นภาพมากขึ้น ยกตัวอย่างเช่นเมื่อเราเพิ่มอุปกรณ์ใหม่เข้าไปในเน็ทเวิร์คเซอร์วิสต่างๆของมันจะต้องสามารถถูกเรียกใช้งานได้ เช่นกันเมื่อเราดึงเอาอุปกรณ์นั้นออกจากเน็ทเวิร์คเซอร์วิสต่างๆก็จะหายไปเช่นกัน ในมุมมองของ OSGi นั้นเซอร์วิสอาจถูกหยุดให้บริการในกรณีที่การเชื่อมต่อจากเครื่องรีโมทขาดหายไป  ซึ่งนี่หมายความว่าความมีพลวัตเข้ามาช่วยแก้ปัญหาเรื่องของการ initial ระบบเพราะ OSGi แอพพลิเคชั่นไม่ต้องการเรื่องของลำดับในการ start
เมื่อ service registry ยอมให้ออบเจคทุกๆตัวกลายเป็นเซอร์วิสได้ แล้วนั้นหนทางที่ดีที่สุดในการทำให้เซอร์วิสเหล่านั้นสามารถถูก reuse มากที่สุดคือต้องลงทะเบียนออบเจคเหล่านั้นภายใต้อินเทอร์เฟสมาตรฐานเพื่อลดการผูกพันระหว่าง implementer และโค้ดของ client นี่คือเหตุผลสำคัญที่ทำให้พันธมิตร OSGi มีการร่างมาตรฐานออกมาเพื่อใช้งาน มาตรฐานนี้ได้กำหนดเซอร์วิสพื้นฐานปริมาณมหาศาลไว้ตั้งแต่ Log, Measurement และ State ได้เรียบร้อยแล้ว ซึ่งปัจจุบันมาตรฐานที่ประกาศออกมาเป็นรุ่นที่ 4 แล้ว

 แปลจาก เโดอกสาร ของ Sunil Patil, JavaWorld.com, 03/04/08  Hello,  OSGi, Part 1: Bundles for beginners

เรื่องของ Open Services Gateway Initiative(OSGi) เป็นสถาปัตยกรรมที่ถูกออกแบบมาเพื่อรองรับการพัฒนาและติดตั้งแอพพลิเคชั่นหรือไลบราลี่ให้อยู่ในรูปแบบของโมดูล เอกสารชุดแรกนี้จะเป็นเรื่องของการแนะนำให้รู้จัก OSGi โดย Sunil Patil จะนำท่านเข้าสู่โลกของการพัฒนาแอพพลิเคชั่นด้วย OSGi ด้วยการสร้างสุดยอดแอพพลิเคชั่นชื่อ HelloWorld ด้วยการใช้ Eclipse OSGi ชื่อ Equinox นอกจากนี้เรายังจะได้รับความรู้เกี่ยวกับ service-oriented application ด้วยการใช้ OSGi และแนะนำเล็กน้อยเกี่ยวกับ OSGi ServiceFactory และ ServiceTracker คลาส

อีกครั้งกับ Open Service Gateway Initative(OSGi) ตัวมันนั้นคือสิ่งที่ทำให้ Java สามารถทำ Dynamic Module ได้หรือเรียกอีกอย่างว่าสถาปัตยกรรมการพัฒนาแอพพลิเคชั่นเชิงมอดูลา ปัจจุบันเองมี container หลายตัวที่ถูกสร้างให้รองรับการทำงานแบบนี้เช่น Knopfilefish, Equinox และ Apache Felix ซึ่งตัว OSGi นั้นเมื่อเราใช้งานมันแล้วเราจะสามารถแตกแอพพลิเคชั่นของเราออกเป็นโมดูลย่อยๆเพื่อให้ง่ายต่อการควบคุม dependency ระหว่างตัวโมดูลได้ง่ายขึ้น

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

1. เราสามารถ เปิด ปิด หยุด โมดูลต่างๆใน container ได้อย่างอิสระและไม่ต้อง restart ตัว container ด้วย
2. แอพพลิเคชั่นของเราสามารถมีได้หลาย เวอร์ชั่น ณ เวลาเดียวกัน
3. OSGi เตรียมโครงสร้างพื้นฐานที่ดีสำหรับการก้าวไปสู่โลกของ Service-Oriented Application และรวมไปถึงเรื่อง Embedded, mobile และ Rich Internet app
4. หลายคนคงสังสัยว่าในเมื่อเรามี Servlet Container สำหรับทำเวบแอพพลิเคชั่นและ EJB Container เอาไว้ทำทรานแซคชั่นแล้ว ทำไมเราต้องมี OSGi อีกล่ะ คำตอบคือด้วยการใช้ OSGi เราสามารถแยกแอพพลิเคชั่นที่ซับซ้อนมากออกเป็นโมดูลเล็กได้อีก แต่ในรายละเอียดแล้วจะใอยู่ในส่วนอื่นของเอกสารนี้

OSGi ในมุมมองของ Enterpise แอพพลิเคชั่น
การกำหนดมาตรฐานของ OSGi นั้นเริ่มราวๆเดือนมีนา ปี 1999 โดยที่เนื้อหาหลักของงานนี้อยู่ที่การสร้างมาตรฐานเปิดขึ้นมาสำหรับการให้บริการเซอร์วิสต่างๆบน network และอุปรณ์ต่างบนนั้น โดยที่แนวคิดที่เป็นพื้นฐานของ OSGi คือเมื่อใดก็ตามที่เราทำการเพิ่ม OSGi เซอร์วิสแพลทฟอร์มเข้าไปในอุปกรณ์เน็ทเวิร์ค (โดยการฝังเข้าไปเหมือน server) แล้วเราควรจะมีสิทธิ์ในการจัดการและบริหารซอฟท์แวร์คอมโพเนนท์ต่างๆบนนั้นได้จากทุกๆที่ในเน็ทเวิร์คนั้น เช่นเราควรที่จะสามารถ ติดตั้ง แก้ไข หรือ ถอด คอมโพเนนท์เหล่านั้นได้กลางอากาศเลย โดยไม่ต้องไปสร้างผลกระทบใดๆต่อการทำงานของเซิร์ฟเวอร์นั้นๆ
ซึ่งหลายปีมานี้เทคโนโลยี OSGi ได้ถูกบรรจุไว้ในอุปกรณ์ระบบและเน็ทเวิร์คต่างๆ และเหนือสิ่งอื่นใดในเรื่องของการพัฒนาแอพพลิเคชั่น Eclipse ได้รวมเอา OSGi เข้ามาไว้ในตัวเองด้วยกัน เราจะเห็นได้ว่า OSGi คือการรวมเอาเทคโนโลยีที่มีอนาคตและมีมูลค่าอย่างยิ่ง มารวมกันเพื่อการสร้างแอพพลิเคชั่นระดับ เอนเทอร์ไพรส์ โดยเฮพาะ

การเติบโตของการสนับสนุน
ปี 2003 ทีมพัฒนา Eclipse วางแผนเรื่องของการทำให้ Eclipse มีความยืดหยุ่นและมีพลวัตมากขึ้นในเรื่องของการทำ Rich Client Platform และ เพิ่มความเป็นโมดูลามากขึ้น และแน่นอนทีมได้ตกลงใจใช้ OSGi เฟรมเวิร์คเพื่อการทำโมเดลเรื่องคอมโพเนนท์แบบพลวัต และรุ่นแรกที่ใช้มาตรฐานนี้คือ Eclipse 3.0
แนวทางนี้ยังส่งผลไปถึงการพัฒนา Application Server ด้วยเพราะทีมพัฒนาของบริษัทต่างๆก็เริ่มสางแผนสำหรับเรื่องการรองรับการทำงานกับ OSGi ไว้แล้ว SpringFramework สนับสนุนไปเรียบร้อย โดยการทำโปรเจค Spring Dynamic Module ซึ่งเป็นโปรเจคท่ทำให้เราสามารถใช้ OSGi บนโครงสร้างการทำงานของ Spring เป็นไปอย่างง่ายดาย

Open source OSGi containers
ถ้าเรามอง OSGi จากมุมมองของนักพัฒนา เราสามารถมองมันเป็นส่วนหนึ่งของระบบที่ดูคล่องตัวไม่เทอะทะ สามารถนำไปวางไว้ในระบบงานขนาดใหญ่ได้อย่างง่ายดาย ยกตัวอย่างเช่นในกรณีที่เราพัฒนาเวบแอพพลิเคชั่นที่มีระดับความซับซ้อนสูงมาก และเราต้องการแยกการทำงานออกเป็นโมดูลย่อยๆเช่น มีโมดูลเกี่ยวกับ View มีอีกโมดูลเกี่ยวกับ DAO และอีกโมดูลเกี่ยวกับ Model และเราจัดการความสัมพันธ์ของโมดูลทั้งสามด้วยการใช้ OSGi container ดังนั้นเราจึงสามารถแก้ไขโมดูล DAO (ปรับปรุงประสิทธิภาพให้เร็วขึ้น) ได้โดยไม่ต้องทำการ restart แอพพลิเคชั่นของเราเลย
และแน่นอนตราบเท่าที่เราคงสภาพให้แอพพลิเคชั่นของเราเป็นไปตามมาตรฐาน OSGi แล้วเราสามารถย้ายแอพพลิเคชั่นของเราไปวางไว้บน OSGi Container ตัวใดๆก็ได้ซึ่งปัจจุบันมีอยู่สามตัวคือ
Equinox: เป็น OSGi container ที่สร้างตามมาตรฐาน OSGi Service Platform Release 4 ซึ่งตัวมันเปรียบเสมือนหัวใจของ Eclipse Platform ตัว equinox มีฟังก์ชั่นพื้นฐานที่บังคับทั้งหมดของมาตรฐานและมีฟังก์ชั่นเสริมอีกจำนวนมาก
Knopflerfish: เป็น OSGi container ที่สร้างตามมาตรฐาน OSGi R3 และ R4 โดยที่ Knopflerfish 2 มีฟังก์ชั่นพื้นฐานที่บังคับทั้งหมดของมาตรฐานและมีฟังก์ชั่นเสริมบางตัวใน R4
Apache Felix: เป็น OSGi Container แบบเปิดซอร์สที่ยังไม่สามารถทำได้ตามมาตรฐาน R4 ได้ทั้งหมด

tutorial รอหน่อยนะครับ