Vra

Ek het gekyk na OSGi onlangs en dink dit lyk na 'n baie goeie idee vir modulêre Java-toepassings.

Ek het egter gewonder hoe OSGi in 'n webtoepassing sal werk, waar jy nie net kode het om oor bekommerd te wees nie - ook HTML, beelde, CSS, daardie soort ding.

By die werk bou ons 'n toepassing wat veelvuldige 'oortjies' het, elke oortjie is een deel van die toepassing.Ek dink dit kan regtig baat by die neem van 'n OSGi-benadering - maar ek is regtig nie seker wat die beste manier sal wees om al die gewone webtoepassingsbronne te hanteer nie.

Ek is nie seker of dit enige verskil maak nie, maar ons gebruik JSF en IceFaces (wat nog 'n laag probleme byvoeg, want jy het navigasiereëls en jy moet alle gesigkonfigurasielêers in jou web.xml spesifiseer...doh!)

Wysig:Volgens hierdie draad, faces-config.xml-lêers kan vanaf JAR-lêers opgelaai word - so dit is eintlik moontlik om veelvuldige faces-config.xml-lêers in te sluit sonder om web.xml te wysig, mits jy in JAR-lêers verdeel.

Enige voorstelle sal baie waardeer word :-)

Was dit nuttig?

Oplossing

Jy is baie reg in denke is daar sinergieë hier, ons het 'n modulêre web app waar die jeug self outomaties is saamgestel uit onafhanklike komponente (OSGi bundels) waar elke bundel dra sy eie bladsye, hulpbronne, css en opsioneel javascript.

Ons het nie (hier Lente MVC) gebruik JSF so ek kan nie kommentaar lewer oor die bykomende kompleksiteit van daardie raamwerk in 'n OSGi konteks.

Die meeste raamwerke of benaderings wat daar is nog voldoen aan die "ou" manier van dink. Een WAR-lêer wat u webapp en dan baie OSGi bundels en dienste, maar byna niemand kommer hulself met die modularisering van die GUI self

Voorvereistes vir 'n Ontwerp

Met OSGi die eerste vraag op te los is: wat is jou ontplooiing scenario en wat is die primêre houer? Wat ek bedoel is dat jy jou aansoek op 'n OSGi runtime kan sit en gebruik sy infrastruktuur vir alles. Alternatiewelik kan jy 'n OSGi runtime insluit in 'n tradisionele app bediener en dan sal jy nodig het om te her-gebruik sommige infrastruktuur, spesifiek wat jy wil die APPSERVER se Servlet enjin gebruik.

Ons ontwerp is tans gebaseer op OSGi as die houer en ons gebruik die HTTPService aangebied deur OSGi as ons Servlet houer. Ons is op soek na die verskaffing van 'n soort van deursigtige brug tussen 'n eksterne Servlet houer en die OSGi HTTPService maar dat werk is aan die gang.

Architectural Skets van 'n Lente MVC + OSGi modulêre webapp

So die doel is nie om net te dien 'n web-program oor OSGi maar om ook OSGi se komponent model toe te pas om die web UI self, te maak dit composable, weer bruikbaar, dinamiese.

Dit is die komponente in die stelsel:

  • 1 sentrale bundel wat sorg vir die oorbrugging van die lente MVC met OSGi, spesifiek dit gebruik kode deur Bernd Kolb om jou toelaat om die lente DispatcherServlet met OSGi registreer as 'n Servlet.
  • 1 persoonlike URL Mapper wat in die DispatcherServlet ingespuit en wat voorsiening maak die kartering van inkomende HTTP-versoek om die korrekte kontroleerder.
  • 1 sentrale Sitemesh gebaseer versierder JSP dat die globale uitleg van die terrein, asook die sentrale CSS en Javascript biblioteke wat ons wil aan te bied as standaard definieer.

  • Elke bundel wat wil bladsye aan ons web UI het by te dra tot 1 of meer Controllers as OSGi Services publiseer en maak seker dat jy registreer sy eie Servlet en sy eie hulpbronne (CSS, JSP, beelde, ens ) met die OSGi HTTPService. Die registrasie is gedoen met die HTTPService en die sleutel metodes is:

    httpService.registerResources () en httpService.registerServlet ()

As 'n web ui by te dra bondel aktiveer en publiseer sy leiers, word dit outomaties opgetel deur ons sentrale web ui bundel en die voorgenoemde persoonlike URL Mapper versamel hierdie Controller dienste en hou 'n up to date kaart van URLs om gevalle kontroleerder.

Toe 'n HTTP-versoek kom in vir 'n sekere URL, dit vind die verband kontroleerder en versendings die versoek daar.

Die Kontroleur doen sy besigheid en dan terug enige data wat gevolg moet word gelewer en die naam van die oog (a JSP in ons geval). Dit JSP is geleë in bondel die Kontroleur en kan verkry word en wat deur die sentrale web ui bundel juis omdat ons gegaan en geregistreerde die hulpbron plek met die HTTPService. Ons sentrale oog resolver paart dan hierdie JSP met ons sentrale Sitemesh versierder en spoeg uit die gevolglike HTML om die kliënt.

In weet dit is eerder 'n hoë vlak, maar sonder om die volledige implementering is dit moeilik om ten volle te verduidelik.

Ons belangrikste leer punt hiervoor was om te kyk na wat Bernd Kolb het met syByvoorbeeld JPetstore omskakeling na OSGi en om daardie inligting gebruik om ons eie argitektuur te ontwerp.

IMHO is daar tans te veel hype en fokus op kry OSGi een of ander manier ingebed in tradisionele Java EE gebaseerde programme en baie min aandag in werklikheid gebruik te maak van OSGi idiome en sy uitstekende komponent model geplaas om werklik toelaat dat die ontwerp van modulair web aansoeke.

Ander wenke

Kyk bietjie na SpringSource dm Server - 'n aansoek bediener heeltemal gebou in terme van OSGi en ondersteun modulêre web aansoeke. Dit is beskikbaar in 'n vrye, open source, en kommersiële weergawes.

Jy kan begin deur die implementering van 'n standaard WAR-lêer en dan geleidelik jou aansoek te breek in OSGi modules, of 'bundels' in OSGi-praat. As jy van SpringSource sou verwag, die bediener het 'n uitstekende ondersteuning vir die lente raamwerk en verwante Lente portefeulje produkte.

Disclaimer: Ek werk op hierdie produk

.

Wees bewus van die lente DM bediener lisensiëring .

Ons het al met behulp Restlet met OSGi om goeie effek met 'n ingeboude Http diens (onder die dek dit is eintlik Jetty, maar tomcat beskikbaar te).

Restlet het nul tot 'n minimale XML opset behoeftes, en enige opset wat ons doen is in die BundleActivator (registrasie van nuwe dienste).

Wanneer die opbou van die bladsy, het ons net verwerk die betrokke diens implementering van die uitset, versierder styl te genereer. Nuwe bundels om ingeprop in nuwe bladsy versierings te voeg / widgets die volgende keer sy gelewer.

rus gee ons mooi skoon en sinvolle URLs, verskeie vertoë van dieselfde data, en lyk 'n extensible metafoor (paar werkwoorde, baie naamwoorde).

'n bonus funksie vir ons was die uitgebreide ondersteuning vir caching, spesifiek die ETAG.

SpringSource blyk te werk op 'n interessante modulêre web raamwerk gebou op die top van OSGi genoem SpringSource Skywe . Meer inligting kan gevind word in die volgende blog:

Het jy 'n blik op RAP! http://www.eclipse.org/rap/

Neem 'n blik op http://www.ztemplates.org wat is eenvoudig en maklik om te leer. Hierdie een kan jy alle verwante templates, JavaScript en CSS in een pot te sit en gebruik dit deursigtig. Beteken dat jy selfs nie te bekommer oor wat verklaar dat die nodige JavaScript in jou bladsy by die gebruik van 'n voorwaarde komponent, soos die raamwerk doen dit vir jou.

Interessante stel plasings.Ek het 'n webtoepassing wat op 'n per kliënt basis aangepas is.Elke kliënt kry 'n kernstel komponente en bykomende komponente, afhangende van waarvoor hulle ingeteken het.Vir elke vrystelling moet ons die korrekte stel dienste 'saamstel' en die korrekte spyskaartopstelling toepas (ons gebruik struts-kieslys) gebaseer op die kliënt, wat om die minste te sê vervelig is.Dit is basies dieselfde kodebasis, maar ons pas eenvoudig navigasie aan om sekere bladsye bloot te stel of te versteek.Dit is natuurlik nie ideaal nie en ons wil graag OSGi gebruik om dienste te komponentiseer.Alhoewel ek kan sien hoe dit vir diens-API's gedoen word en soort van verstaan ​​hoe hulpbronne soos CSS en java script en beheerders (ons gebruik Spring MVC) ook gebundel kan word, hoe sal jy te werk gaan om 'kruis sny'-kwessies soos bladsynavigasie te hanteer en algemene werkvloei veral in die scenario waar jy 'n nuwe diens dinamies wil ontplooi en navigasie by daardie diens moet voeg.Daar kan ook ander 'deursnyende' bekommernisse wees, soos dienste wat oor ander dienste strek.Dankie, Declan.

Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top