Java EE OSGi Applications: Design and Deployment for On-Premises and Cloud

Jeg (Nikolaj Brinch) havde her til morgen valgt min 2. OSGi session. En session som startede med reklame for talerens firma (cognizant) – det tog 3-5 minutter, ikke ok!

Han startede med at gennemgå OSGi 101, så alle kunne lære og forstå hvad OSGi er og hvad det bringer til Java platformen. En god gennemgang, men fuldstndigt den samme gennemgang som Sun lavede i deres OSGi indlæg mandag morgen, næsten med de samme slides.

Nu kom en kvinde!!! på banen og skulle fortælle om hvordan OSGi passer ind i Java EE (OSGi R4 4.2 Enterprise specification). Hun startede med at fortælle om Blueprint Container Specification som er baseret på Spring Dynamic Modules – så også her er SpringSource på forkant med udviklingen.

Nu skal vi så til at kunne deploye WAB (WAR or OSGi) og EBA (EAR for OSGi – men kun EBA på WebSphere???).

IBM har allerede lavet plugins til eclipse så man kan lave OSGi projekter som kan deployes. Desuden nævnte hun at WepShere, Spring DM server og Glassfish allerede understøtter OSGi R4 4.2 (JOnAS understøtter plain R4 4.0).

Det fine ved det her er øjensynligt, at der nu ikke er dependencies på vendor implementationer, men på specifikationer, gennem OSGi dependencies på services, vil disse så blive stillet til rådighed af een eller anden container i OSGi eco systemet. OSGi giver en løsere kobling, hvis man følger best practices og udstiller specifikationer (interfaces) og lader ander services implementere interfacene. Desuden kan man have flere implementationer i samme container, for man kan depende på en specifikation fra en specifik vendor hvis man vil.

Det ser ud til at OSGi er rigtig godt for fremtiden af Java EE, og classpath hell som vi kender det i dag på de forskellige container bliver om end ikke overstået, så i hvert fald konsolideret så det ikke virker ens på tværs af vendors. Desværre ser det ud til at de forskellige vendors ikke helt kan lade være med at allerede i “version 1.0″ af det her at smide vendor specifikke (læs: lock-in) features ind i deployment specifikationen.

Nu skulle vi så høre om OSGi in the Cloud. En demo hvor JPPF skulle køre et batch job hos Amazon EC2 som et single node job og bagefter som et multi node job.

Crash-Bang! Det røg på gulvet under første prøve. Her var de vildt dårligt forberedte og havde ikke sørget for at de hurtigt kunne launche igen, så vi måtte tålmodigt sidde og vente på at der blev fundet ip adresser frem og skrevet ind i hånden mm.

Efter 10 minutter var vi tilbage og nu kørte deres programmer på denne ene node. Nu skulle vi så se det smarte, nemlig hvordan JPPF kunne launche en masse instanser hos Amazon for dem og bruge dem som processing nodes. (Hvordan OSGi havde noget med at kunne launche alle disse noder eller det var JPPF der gjorde det, er jeg lidt usikker på, i hvert fald blev det ikke forklaret særlig godt). I øvrigt var det sjovt at se fordelingen af deres 100 tasks på de 2 noder, 99 tasks på den ene og 1 task på den anden

Konklusionen var således fra taleren:

• No special benefits of OSGi in moving to cloud
• From a PaaS/Saas perspective, no OSGi support yet from providers

Så det var lidt sært at der var devoted 30 min af de 60 til cloud, når nu OSGi i dette tilfælde ar irrelevant???.