SprinOne2008 - Adrian Colyerin OSGi sunumu notlarım

Bence Adrian Colyer SpringOne2008’in en iyi sunumlarına imza attı. İkinci gün yaptığı keynote sunumu da oldukça başarılıydı. Adrian’ın OSGi a giriş sunumunda aldığım kısa notları paylaşmaya çalışayım.
Sunumun temel hedefi OSGi servis platformunun temel özelliklerini anlamak ve enterprice uygulama geliştirmede kullanımı durumunda sağlayacağı faydaları ve getireceği güçlükleri açıkça belirtmek.
OSGi nedir? The dynamic module system for Java.
Sistem bundle adı verilen pek çok modülden oluşmakta. Modüller runtime da diğer modülleri etkilemeden install, start, stop, uninstall ve update edilebiliyorlar. Sistemin dinamik olmasını sağlayanda bu zaten. OSGi aynı zamanda servis oriented. Bundle lar servis olarak publish edilebiliyorlar. Service registry diğer bundle ların servisleri bulup kullanmasını sağlıyor.
Çok güzel görünen bu dinamizm aslında çok yeni bir teknoloji değil. 1999 da gömülü java sistemleri ve network cihazları için tasarlanmıştı. 2003 de mobil cihazlara genişletildi, 2004 de open source adaptasyonu sağlandı ve 2006 server-side java uygulamalarında kullanılmaya başlandı.
En çok bilinen implementasyonları Eclipse Equinox, Apache Felix, Makewawe Knopflerfish ve Prosyst mBedded Server Professional Edition.
OSGi teknolojisinin halihzırda kullanıldığı yerler:
• Otomativ (BMW, Siemens, Volvo, ...)
• Mobile (Nokia, Motorola, ...)
• SmartHome (Phlips, Bosch, Siemens, ...)
• Enterprice (IBM, BEA, Oracle, SpringSource, Paremus, ...)

OSGi tarihçesi ve kullanım alanlarından bahsedildikten sonra sunum daha teknik konularla devam etti.
Gerekli konseptler:
• Service Platform: Lightweight containerdır. Standalone veya gömülü
olabilir. Ve OSGi service platform core specification ı R4.1 dir.
• Bundle: OSGi da deploy edilen ve modülariteyi sağlayan temel birimdir.
Sadece bir jar dosyasıdır ama META-INF/MANIFEST.MF dosyasına sahip
olmalıdır. Bu dosyada Bundle-SymbolicName, Bundle-Version, Bundle-
Name, Bundle-ManifestVersion, Bundle-Vendor başlıklarıyla tanımlar
yapılabilir.
• Import-Package: Bundle da paket seviyesindeki bağımlılıkları ayarlamak
için kullanılır. Kullanımı:
Import-Package:com.xyz.foo;
Import-Package:com.xyz.foo;version=”1.0.3”
Import-Package:com.xyz.foo;version=”[1.0.3,1.1.0)”
• Versions and Version Ranges: Version syntax:
major.minor.micro.qualifier şeklindedir. [ ] dahil, ( ) hariç için
kullanılır. Örneğin, com.xyz.foo;version=”[1.0.3,1.1.0)” tanımında
1.0.3 versiyonu dahil ama 1.1.0 versiyonu hariçtir.
• Export Package: Diğer bundle ların import eebilmesi için tipi
tanımlar. Kullanımı:
Export-Package: com.xyz.foo
Export-Package: com.xyz.foo;version="1.0.5"
Export-Package: com.xyz.foo;version="1.0.5" com.xyz.bar;version="2.0.0"
Export-Package: com.xyz.foo; com.xyz.bar;version="1.4.1"
Export-Package: com.xyz.foo;version="1.0.3";uses:="org.bar"
• Service Registry: Bir servisin diğer bundle lar tarafından
kullanılabilmesi için publish edilmiş olması gerekir. Publish edilmiş
bir servisi kullanacak bundle bu servisi önce bulur (find) sonra
bind eder.
o Publish: ServiceRegistration reg = bundleContext.registerService
(Bar.class.getName(),null);
...
reg.unregister();
o Find: ServiceReference ref =
bundleContext.getServiceReference(Bar.class.getName());
o Bind: Bar bar = (Bar) bundleContext.getService(ref);
...
bundleContext.ungetService(ref);
// bar should no longer be used here

OSGi ın faydaları:
• Güçlü Modülerlik: Bundle test edilebilir bir black box tır. Bundle bir veya
daha fazla package a export edilebilir. Export edilen bundle ın dışından
bundle a erişim sadece export edildiği package lardandır. Bunun sonucu
olarak modüller arası istenmeden yapılan bağımlılıklar son bulur, bağımsız
geliştirmeye olanak sağlanır ve daha hızlı bir geliştirme döngüsü sağlanır.
• Operational Control: Bütün modüller ve modüllerin durumu görülebilir,
wiring hakkında bilgi alınabilir, bundle lar install, uninstall, activate,
deactivste, update ve stop edilebilir. Tüm bunlar yapılırken çalışan sistemi
durdurmaya veya yeniden başlatmaya gerek yoktur.
• Versioning: Aynı pakette bir bundle ın farklı versiyonları
kullanılabilmekte. Bununla ilgili kısa bir demo da sunum sırasında yapıldı.

Enterprice Uygulamalar için OSGi:

Server Platform olarak OSGi:


Embedded OSGi:



Nested OSGi:



Yukarıdaki grafikleri, OSGi ın enterprice bir uygulama nereye oturduğunu daha iyi kavrayabilmek için ekledim.

Design Kısıtları: Platform dinamik olduğu için kullanılan bir servis herhangi
bir zamanda kaybolabilir, servis bağımlılığının yönetimi gerekli. Test,
uyumluluk ve thread yönetimi de ayrı kısıtlar. OSGi altında enterprise
kütüphanelerin birlikte çalışması class ve resource-loading problemlerine sebep
olmakta.
Enterprise kütüphanelerin OSGi ile çalışabilmelerini sağlamak için SpringSource güzel işler yapmış. Öncelikle Spring 2.5 ve diğer spring projeleri OSGi a hazır durumda. Modüller bundle yapılabiliyor ve OSGi altındaki class loading problemleri çözülmüş durumda. SpringSource Enterprise Bundle Repository ile yüzlerce yaygın kütüphaneyi OSGi bundle olarak sunmuşlar.
SpringSource un son dönemlerde yaptığı işlere ve SpringOne2008 deki sunumlara bakılırsa geleceğin enterprise java dünyası OSGi üzerine dönecek.
Sunum aşağıdakilere dikkat çekerek tamamlandı.
• OSGi is a dynamic module system for Java
• Key concepts: bundles, import/export package, services
• Key benefits: modularity, operational control, versioning
• Key disadvantages: error-prone APIs, integration testing, working with
existing libraries not designed for OSGi
• See Spring Dynamic Modules & the SpringSource Application Platform!

SprinOne2008 Keynote

11,12 Haziran 2008 tarihlerinde Antwerp/Belçika da gerçekleşen SpringOne2008 konferansına katılma imkanım oldu. Sunumlarda aldığım notları kısaca sizlerle paylaşmaya çalışayım.

Seminerin açılışını Spring, SpringSource ve Siz adlı sunumnuyla Rod Johnson yaptı.
İlk olarak spring bilen eleman arayışının artışını aşağıdaki grafikle gösterirken, SpringSource’un verdiği sertifikaların ne kadar faydalı olacağını belirtti.




Daha sonra benim beklediğim şekilde genel hızlı bir bakış yerine sunumuna daha teknik konularda detaylara inerek devam etti. Sunumların hemen hepsinde dikkatimi çeken konfigürasyonların annotation lar yardımıyla yapılması üzerinde epey durdu. Sanırım çok moda olan xml konfigürasyon (en azından benim favorimdi) yerini yavaş yavaş annotation tabanlı konfigürasyona kaptırıyor.

Spring’in dependency injection için gerçekten oldukça iyi bir annotation desteği var. Biraz örneklemek gerekirse:

@Autowired
public void createTemplates(DataSource ds,ConnectionFactory cf) {
this.jdbcTemplate = new JdbcTemplate(ds);
this.jmsTemplate = new JmsTemplate(cf);
}

Annotation autowiring için daha kullanışlı bir yapı sağlıyor. @Autowired default by type wiring yapar. Tip autowiring bazen işimizi görmez, bu durumda @Qualifier annotation ını kullanarak by name wiring yapabiliriz. Annotation ile constructor, metod ve field seviyelerinde injection yapılabilmekte. Örneklerde metod seviyesinde injection var.

public class JdbcOrderRepositoryImpl implements OrderRepository {
@Autowired
public void init(
@Qualifier("myDS")
DataSource orderDataSource,
@Qualifier("otherDS")
DataSource inventoryDataSource,
MyHelper autowiredByType) {
// ...
}


Spring de aynı zamanda stereotype annotation lar da var. Bunlar @Sevice, @Repository, @Aspect ve @Controller, bunların haricinde kendi annotationlarımızı da tanımlayabiliyoruz. Xml’ de



Tanımını yapmak yerine sınıfın başına aşağıdaki gibi @Service yazmamız yeterli.

@Service
public class DefaultAccountService { ...

Annotationlar üzerinde epey durduktan sonra spring in diğer güzellikleriyle sunum devam etti. Sırada spring security vardı. Spring security basit ve güçlü olarak tanımlandı ve tabii ki acegi security ile karşılaştırıldı. Verilen acegi security konfigürasyon dosyası ile spring security konfigürasyon dosyası arasındaki boyut ve anlaşılabilirlik farkı güvenliğin ne kadar kolaylaştığına açık bir delildi.

Spring in temelinde yatan güzelliklerinden biride test edilebilir kod yazmaya yazılımcıları özendirmesi. Integration testing başlığı da sunumdaki yerini aldı haliyle. Spring 2.5 ile annotation tabanlı test framework yeniden gözden geçirilmiş, Junit 4.4 ve TestNG desteği sağlanmış ve JUnit 3.8 in annotation cehenneminden kurtulunmuş. Ayrıca Springin @Autowired ve @Transactional gibi core annotationlarının test sınıflarında kullanılabilmesi sağlanmış. Aşağıdaki örnek test sınıfı kodu bulunmaktadır.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
// defaults to MyTests-context.xml in same package
public class MyTests {
@Autowired
private MyService myService;
@Test
public void myTest() {...}
@Test
@Transactional
public void myOtherTest() { ... }
}

Sıra geldi Spring’in web katmanında aldığı role. Spring 2.0 daki ve 2.5 daki iki ayrı kontroller örneği web katmanındaki annotation desteğini ortaya koyuyor.

Spring 2.0 controller örneği:

public class HotelsController extends
MultiActionController {public ModelAndView index(HttpServletRequest req,
HttpServletResponse res) {…}
public ModelAndView search(HttpServletRequest req,HttpServletResponse res) {…}
public ModelAndView show(HttpServletRequest req,HttpServletResponse res) {…}
}


Spring 2.5 controller örneği:

@Controller
public class HotelsController {
@RequestMapping
public void index() {…}
@RequestMapping
public void search(SearchCriteria criteria, BindingResult result) {…}
@RequestMapping
public void show(@RequestParam("id") Long id)
{…}
}

Spring Web Flow 2.0 da ise tanımlama dili sadeleştirilmiş bununla birlikte daha güçlü hale gelmiş. EL kullanımı genişletilmiş ve flow definition inheritance eklenmiş, ayrıca asenkron event lere ve parçalı update lere destek sağlanmış. Basit bir web flow örneği aşağıdaki gibidir.




JSF üzerine geliştirilen Spring Faces’a da kısaca değinildi.

Sunumun bu aşamadan sonraki kısmı SpringSource reklamı tadında geçti. SpringSource Tool Suite demosu yapıldı. Sunumun sonunda ise geleceğe dair 4 tahmin sıralandı. Bunlar:
• Asıl rekabet application server piyasasında olacak.
• Yarının application server ı daha lightweight ve modüler olacak.
• Application server ile ESB arasındaki boşluk bir köprüyle bağlanacak.
• EJB ölecek.