Mehmet Gursul

    Türkiye Bilişim Derneği (TBD)’nin  çıkardığı Bilişim Dergisi’nin 2009 Aralık sayısı çıktı.  Bu sayıda Hakan Faruk Safi Bey ile birlikte hazırladığımız “Hastane Bilgi Sistemlerinde OSGi Teknolojisinin Dinamikliğinin Kullanılması”  adlı makale yayımlandı.

    Bu makalede;  modülerlik, Java daki JAR dosyaları ve problemleri ile OSGi teknolojisinin getirdiği çözümlere değinerek, OSGi teknolojisinin dinamikliğinin Hastane Bilgi Sistemi yazılımlarında kullanılmasının getireceği faydalardan bahsettik.

    Makaleye erişmek için Bilişim Dergisi arşivinden 2009 Aralık sayısına tıklayarak  124-129 arasındaki sayfalara bakabilirsiniz.

Bir OSGi gerçekleştirimi olan Equinox da kullanabileceğimiz bazı komutlar ve açıklamaları aşağıdaki gibi :

• help – Tüm komutları listeler
• ss – Yüklenen bundle ları listeler.
• start <Bundle ID> – Verilen ID li bundle ı başlatır. (start 1 gibi)
• stop <Bundle ID> – Verilen ID li bundle ı durdurur. (stop 1 gibi)
• install <url> – Sisteme bundle ı ekler.
• uninstall <Bundle ID> – Verilen ID li bundle ı sistemden çıkarır.
• diag <Bundle ID> – Verilen ID li bundle ın sağlanamayan kısıtlamalarını (constraint) gösterir.
• status – Yüklenen bundle ları ve kayıtlı oldukları servisleri gösterir.
• shutdown – Tüm bundle ları durdurur.
• exit –  Bundle ları durdurmadan OSGi framework ü (Equinox) kapatır.
• close – shutdown ve exit komutlarının birleşimidir.

     OSGi da bildiğimiz gibi modüllere “bundle” denilmektedir. Bundle lar birbirlerine ihtiyaç duymakta dolayısı ile bağımlı olmaktadırlar. Klasik JAR dosyalarında bu bağımlılıklar tam olarak belirtilememektedir. OSGi bu probleme güzel bir çözüm sunmaktadır. Bunun nasıl olduğunu 2 tane bundle oluşturup, birini diğerine bağımlı yaparak sizlere göstermeye çalışacağım.

Aşağıdaki gibi bir Film sınıfımız olsun.

Yine aynı pakette aşağıdaki gibi bir arayüz tanımlayalım.

      Şimdi bu iki sınıfı içeren bundle ımızı oluşturmadan önce aşağıdaki gibi FilmManifest.mf dosyamızı oluşturalım. Unutmayalım son satırda boş bir satır olmalı.

     Bu dosyada önceki derslerimizde görmediğimiz yeni bir satır geldi dikkat ederseniz : Export-Package. Bu satır bundle dan dışarıya açık olan yani başka bundle lar tarafından erişilebilecek paketleri göstermektedir.

     Eskiden JAR dosyamız içerisindeki tüm paketler dışarıya açık hale gelmekteydi. Bazı paketlerimiz sadece JAR içindeki paketler tarafından kullanılsın ama bu paketler dışarıdan erişilmesin diyebileceğimiz durumlar olabilmektedir. OSGi bu duruma çözüm bulmaktadır. Export-Package satırında belirtilmeyen tüm paketler sadece kendi bundle ı içindeki paketler tarafından erişilebilmektedir.

     Ayrıca dikkat ettiyseniz pakete versiyon numarasıda verdik. Biraz sonra bu versiyonun öneminden bahsedeceğim. Versiyon numarası verme zorunluluğumuz yok aslında. Vermediğimiz zaman OSGi otomatik olarak “0.0.0″ olarak versiyon numarası atamaktadır.

Aşağıdaki komutları çalıştırarak bundle ımızı oluşturabiliriz.

     Şimdi de bu bundle a bağlı olan başka bir bundle oluşturalım. FilmBulan sınıfımızı implement eden FilmBulanImpl.java sınıfımızı yazalım.

     Sonra aşağıdaki gibi FilmBulanManifest.mf dosyamızı oluşturalım. Unutmayalım son satırda boş bir satır olmalı.

     Dikkat ettiyseniz osgi.dersler paketini import ettik. Bu paket diğer bundle tarafından export edilmişti. Ayrıca versiyon aralığı ekledik paketin sonuna.

     OSGi framework çalışma zamanında import edilen versiyon numarasına uygun paketi diğer bundle daki export satırında bulmaya çalışacaktır. Versiyon aralığı matematikteki gibidir. Yani "[" ve "]” dahil, “(” ve “)” ise hariç anlamına gelmektedir. “[1.0.0,2.0.0)” -> 1 ile başlayan (1.x) tüm versiyonlar bu paket tarafından kullanılabilir anlamına gelmektedir.

     Import-Package da versiyon aralığı verilebilmesine karşın Export-Package satırında sadece versiyon numarası verilebilmektedir yani Export-Package da versiyon aralığı verilememektedir. Bu arada Import-Package da da aynen Export-Package da olduğu gibi versiyon numarası verme zorunluluğu yoktur. Ama verilmesi güzel bir alışkanlıktır.

Şimdi ikinci bundle ımızı aşağıdaki komutları çalıştırarak oluşturalım.

      Bir OSGi framework olan Equinox da bu bundle larımızı çalıştırmayı deneyelim. Aşağıdaki komut  ile framework ü çalıştıralım.

   java -jar equinox.jar -console

     Sonra aşağıdaki komutla ikinci oluşturduğumuz FilmBulan bundle ımızı yükleyelim.

Son duruma bakalım.

Henüz bundle ımız resolved değil , installed durumunda. Yani framework bundle a sahip ama bağımlılıkları henüz çözümlenmemiş. Bu nedenle FilmBulan bundle ımızı start 1 ile aktif hale getirmeye çalıştığımızda aşağıdaki gibi hata alırız.

org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Import-Package: osgi.dersler; version=”[1.0.0,2.0.0)”

     Çünkü osgi.dersler paketini export eden çözümlenmiş bir bundle a sahip değiliz. Şimdi osgi.dersler paketini export eden bundle ımız olan FilmArayuzu bundle ımızı aşağıdaki komutla yükleyelim.

son duruma tekrar bakalım.

Şimdi tekrar FilmBulan bundle ımızı start 1 ile aktif hale getirmeye çalışalım.

Süper! Artık çalışıyor. Son duruma bakalım.

Bu yazımdaki örnek kodları buraya tıklayarak indirebilirsiniz.

Kaynak : Dependencies between Bundles - Neil Bartlett

Java EE specification; dağıtık ve çok katmanlı bir platform tanımlamaktadır. Java EE mimarisinin nin merkezi özelliği bir çok uygulama bileşenini yöneten ve bu bileşenlere transaction,security gibi kurumsal servisler sunan “uygulama sunucusu” bölümüdür.

Uygulama sunucuları ayrıca; server ı restart etmeden ve diğer uygulamaları etkilemeden uygulamaları deploy etmek, un-deploy etmek için bir deployment-sistemine ihtiyaç duymaktadırlar.

Bu ihtiyacı karşılamak için Java EE uygulama sunucuları her bir deploy edilen uygulama için biraz daha karmaşık, aşağıdakine benzer bir class-loading yapısı kullanmaktadırlar.

• Java EE uygulamaları  EAR dosyaları halinde deploy edilirler. Bu EAR dosyaları aşağıdakileri (ilki ve diğerlerinden bir ya da birkaçını) içeren zip dosyalarıdır;
  • Metadata dosyası, application.xml;
  • Düz Java dosyalarını içeren Jar dosyası
  • EJB uygulamalarını içeren Jar dosyaları (EJB-JARs)
  • Web işlevlerini yerine getiren sınıfları, Servlet-JSP gibi, içeren Web Archive dosyası (WAR)

• Düz Java dosyalarını içeren Jar dosyaları; EAR içindeki tüm EJB-JAR ları ve WARları tarafından erişilmesi düşünülen sınıfları içermektedirler. Bu nedenle EAR Class Loader tarafından bu sınıflar yüklenmektedir.
  • Önceden anlattığımız class loading mekanizmasını bir daha hatırlayacak olursak. Bir class loader sadece, kendisi ya da atası tarafından  tanımlanmış  sınıfları yükleyebilmektedir. Yani ek olarak kardeşlerini (siblinglerini) yükleyememektedir. Bu nedenle EJB ve WAR tarafından paylaşılan ya da kullanılan sınıflar EAR Class Loader a konulması gerekmektedir.
  • Ayrıca eğer deploy edilen birçok uygulama tarafından bir sınıf kullanılacaksa bu sınıfın system application loader seviyesine konulması gerekmektedir. Bu da application server ın restart edilmesine ve JAR dosyasının global classpath e eklenmesine neden olmaktadır.
  • system application loader seviyesine çıkarılan libraryler;
    •  kullanabilmek için restart gerekli
    • Biz sadece deploy edilen bir kaç uygulamanın kullanmasını diğerlerinin kullanmamasını istediğimiz halde, deploy edilen tüm uygulamalar için kullanılabilir hale gelecektir.
    • Sınıf çakışmalarına (Class conflict) neden olacaktır.
      • Üst seviyede bunulan sınıflar daima alt tarafta bulunan aynı sınıflara göre öncelikliği olduğundan alttaki sınıflar ezilecektir.
      • Serverda bulunan tüm uygulamalar üstte bulunan kütüphanenin aynı versiyonunu kullanmak zorunda kalacaktır.

Bu nedenlerden dolayı Java EE geliştiricileri farklı uygulamalar tarafından kullanılan ortak sınıflar tanımlamaktan uzak durmaya çalışmaktadırlar. Birden fazla uygulama tarafından ortak kullanılacak bir kütüphane olduğunda da bu kütüphane herbir EAR içine ayrı ayrı  konularak çoğaltılmaktadır. Sonuç olarak “boru” şeklinde düşey olarak etkileşim kurmakta yatayda etkileşim kuramamaktadırlar.

Kaynak : OSGi In Practice - Neil Bartlett

Yazılımda modül neye benzer olmalıdır? Aşağıdaki özelliklere sahip olmalıdır.

Self-Contained : Modül bir bütün olarak mantıksaldır. Tek bağımsız bir birim halinde install, uninstall edilebilir. Atom değildir yani daha küçük parçalardan oluşmuştur, fakat bu parçalar kendi başlarına olamazlar. Eğer herhangi bir parçası kaldırılırsa da modülün işlevselliği sona erebilir.

Highly-Cohesive : Cohesion, modülün sorumlulukları ile ne kadar ilgili ya da odaklandığı ile ölçülür. Modül ilgisiz şeyler yapmamalıdır. Bir tane mantıksak amaca bağlı kalmalı ve bu amacı tam olarak yapmaya odaklanmalıdır.

Loosely Coupled : Modül etkileşimde olduğu diğer modüllerin gerçekleştirim (implementation) detaylarına bağımlı olmamalıdır. Loose Coupling bizlere şu imkanı vermektedir: Bir modülün gerçekleştirimini değiştiririz. Fakat bunu yaparken bu modülü kullanan diğer modüllerde herhangi bir güncelleme gereksinimine ihtiyaç duymayız.

Bu üç özelliği de modülde sağlamak için modülün çok iyi tanımlanmış arayüzlere ihtiyacı vardır.
Kararlı arayüzler;

• Modüller arasında mantıksal sınırlamaları sağlamakta
• İç gerçekleştirim detaylarına erişimi engellemektedir.

İdeal olarak arayüzler;

• Her bir modülün diğer modüllere neleri sunduğunu ,
• Ve her bir modülün de diğer modüllerden nelere gereksinimi olduğunu belirtir biçimde olmalıdır.

Kaynak  : OSGi In Practice - Neil Bartlett