แปลมาจาก 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 ในตอนหน้า
