แปลมาจาก Spring DM Ref Manual
แนวคิดพื้นฐานขอ Spring DM
ก่อนอื่นขอทบทวนเล็กน้อยเรื่องพื้นฐานอย่าง bundle และ services
โมดูลต่างๆใน OSGi จะรู้จักกันในชื่อของ bundles โดยที่แต่ละ bundles จะเป็นการประกอบกันของ jar ไฟล์ (กระจุกของคลาสไฟล์) และมี manifest ไฟล์ (MEA-INF/MANIFEST.MF) และรีซอร์ซต่างๆที่จำเป็นต้องใช้
เฟรมเวิร์คนั้นมีหน้าที่ทำให้ bundles ถูกติดตั้งและทำงานได้ OSGi จะสามารถระบุตัวตนของ bundles ได้สองวิธีคือจากชื่อและid ของ bundles ซึ่งโดยปกติแล้ว bundle สามารถประกาศชื่อได้ในลักษณะนี้
Bundle-SymbolicName: org.foo.bundle
นอกจากนี้ OSGi เฟรมเวิร์คยังทำหน้าที่แจกหมายเลขที่เราเรียกว่า “bundle id” ให้กับทุกๆ bundle ที่ถูกติดตั้งโดยที่ตัว OSGi เฟรมเวิร์คนั้นจะมีหมายเลขประจำตัวคือ 0
เรื่องต่อไปคือเรื่องการขึ้นต่อกัน(dependencies) ระหว่า bundle ต่างๆสามารถอธิบายได้สองมุมมองคือในเชิงของสถิตย์(statically)คือ package ส่วนในเชิงพลวัต(dynamically)คือ services
เรื่อง package นั้นคนที่เป็น java programmer คงคุ้นเคยกันดีอยู่แล้วยกตัวอย่างเช่นในกรณีที่เราต้องใช้ org.foo.X ในโปรแกรมของเราเราสามารถทำได้สองวิธีคือเราต้องมีคลาสนี้อยู่ในโปรแกรมของเราหรือ
เราต้องอ้างอิงไปหาแพกเกจ org.foo ใน bundles นั้นดราสามารถระบุได้ด้วย menifest ดังตัวอย่าง
Import-Package: org.foo
ดังนั้นจะเห็นได้ว่าเราระบุการใช้งานแพกเกจนั้นไปแล้วต่อไปคือต้องมีใครสักคนระบุว่ายอมให้ใช้แพกเกจนี้
Export-Package: org.foo
ซึ่งกระบวนการในการตรวจสอบความมีตัวตนของ package ที่ต้องใช้นั้นจะถูกกระทำก่อนที่ bundle จะเริ่มทำงานและกระบวนการนี้เรียกว่า resolution
หลังจากที่ bundle ถูก resolve แล้วคลาสและresource ต่างๆก็พร้อมที่จะถูกโหลด และสำหรับ OSGi แล้ว bundle และ package จะไม่สามารถมองเห็นได้จาก application classpath เนื่องจากทุก bundle จะมี
class loader เป็นของตัวเองเพื่อเอาไว้โหลดคลาสของตัวเองและคลาสที่ต้องใช้งานจะที่อื่นๆที่ถูกอ้างอิงถึง
Services
bundles เองสามารถเผยแพร่ java ออบเจคออกมาในรูปแบบของ services ให้กับ registry ที่ถูกจัดการโดย OSGi เฟรมเวิร์ค จะส่งผลให้ bundle ตัวอื่นๆสามาารถเรียกใช้ service ตัวนั้นๆได้ซึ่งจริงๆแล้ว
services ก็คือ Java instance ที่ถูกใช้ร่วมกันนั่นเอง ดังนั้น bundle ที่เป็นผู้ให้บริการ service ไม่จำเป็นจะต้อง export คลาสจริงๆของเซอร์วิสนั้นๆก็ได้ ตัวอย่างด้านล่าคือการ export แพกกเกจที่เป็นแพกเกจอินเทอร์เฟส
Export-Package: org.bar
คลาส implement ของอินเทอร์เฟสนี้คือ SomeImpl:
package org.bar.impl;
class SomeImpl implements SomeInterface {
…
}
OSGi เองได้เตรียม API สำหรับการเผยแพร่และค้นหา services ไว้ให้แต่ Spring DM ได้เตรียมสิ่งที่ง่ายกว่าไว้ใด้ด้วยเช่นกัน
Spring DM เป็นโปรเจคที่ทำให้เราสามารถเผยแพร่และใช้งานเซอร์วิสโดยการใช้ description ที่เขียนด้วย XML เนื่องจาก DM Server นั้นมี Spring DM ฝังอยู่ภายในแล้ว โดยที่ description นั้นจะถูกเก็บไว้มี่ META-INF/spring และใช้นามสกุลเป็น .xml
การเผยแพร่เซอร์วิส นั้นจะใช้ <osgi:service> เพื่อระบุ implementation คลาสของเซอร์วิสและอินเทอร์เฟสที่จะถูกใช้งาน สิ่งที่ Spring DM จะทำคือการสร้าง instance ของคลาสนั้นๆ
เหมือนกกับการ spring bean ทั้วๆไปและจะนำไปเผยแพร่ที่ OSGi service registry ภายใต้ interface ที่ระบุไว้เมื่อ bundle นั้นถูกสั่งให้ทำงาน
ในทางกลับกันในกรณีที่เราต้องการใช้งาน service เราจะใช้ <osgi:service> ซึ่งเซอร์วิสนี้อาจถูกส่งผ่านไปยัง Spring bean ตัวอื่นโดยการทำ Dependency Injection
Spring DM เองยังทำการสร้าง proxy แบบอัตโนมัติด้วยดังนั้นเซอร์วิสจริงๆอาจมีหรือไม่มีก็ได้ ณ ขณะ runtime ในกรณีที่ service หายไป proxy ทุกตัวที่ต้องการใช้เซอร์วิสนั้นต้องรอจนกระทั่งเซอร์วิสนั้นกลับขึ้นมาอีกครั้ง เราเรียกปรากฎการณ์นี้ว่า Damping
เมื่อ bundle ถูกสั่งให้เริ่ม Spring DM จะทำการสร้าง application context ตามที่ระบุไว้ใน XML และสร้าง proxy สำหรับเซอร์วิสนั้นๆและทำการส่งเซอร์วิสเหล่านั้นไปที่ SOGi Service Registry
เมื่อ bundle ถูกสั่งให้หยุด Spring DM จะทำการดึงเซอร์วิสทั้งหมดที่ถูกเผยแพร่ไว้ และทำการปิด application context โดยที่ dm Server จะทำการปิด damping ในขณะที่ application context กำลังถูกปิดอยู่
