Java >> Java tutorial >  >> Tag >> import

OSGi:Hvad er forskellen mellem Import-pakke/Eksportpakke og Require-Capability/Provide Capability?

import

Da vi startede med OSGi i 1998, havde vi nogle klare krav, men selvfølgelig ingen klar opfattelse af, hvad der ville komme ud af det. Så vi begyndte eksplicit at modellere de krav og muligheder, vi havde:pakker. Import-pakken kræver en kapacitet, og den kapacitet leveres af en eksport-pakke.

I 2003 ville Eclipse begynde at bruge OSGi, men de har brug for en facilitet til at kræve et andet bundt, de kunne ikke lide ideen om at eksportere og importere alle deres pakker. Faktisk kunne de på det tidspunkt ikke se fordelene ved pakker. For at tilfredsstille dem tilføjede vi Require-Bundle og Fragment-Host (endnu et af deres ønsker, som viste sig ikke at være så godt.)

Efter at vi havde specificeret OSGi 4.x med disse udvidelser begyndte vi at tænke på et lager, Richard havde udviklet Oscar Bundle Repository. Ved at analysere situationen med de nye headere i OSGi 4.0 blev det klart, at implementeringen af ​​Import-Package lignede Require-Bundle, og endda lignede Fragment-Host-behandling.

I 2006 skrev Richard S. Hall og jeg RFC 112 og foreslog en mere generisk model, der fangede semantikken i den eksisterende afhængighedsmodel, men som ikke var specifik for hver type af kravet. dvs. til Framework resolver Import-pakken og Require-Bundle adskiller sig kun i deres navneområde . At tænke på Import-Package som et generisk krav og Export-Package som en generisk funktion gjorde lagermodellen ekstremt enkel. Endnu bedre, det kunne udvides, da vi altid kunne tilføje flere navnerum. Dette gjorde resolveren fuldstændig uafhængig af de faktiske anvendte navnerum.

Efter nogle meget ophedede diskussioner besluttede OSGi Core Platform Expert Group at acceptere den grundlæggende idé og udviklede krav- og kapacitetsspecifikationerne. Selvom dette oprindeligt var en model for depotet, viste det sig at være yderst nyttigt for selve rammen. Vi besluttede derfor at tilpasse de eksisterende specifikationer til denne model. OSGi 4.3 modellerer internt Import-pakken, Eksportpakken, Require-Bundle osv. som krav og muligheder for en ressource (bundtet). For bagudkompatibilitet beholdt vi de eksisterende overskrifter, men de er internt oversat til krav og muligheder.

Så til sidst til svaret på dit spørgsmål. Med tiden tilføjede OSGi-specifikationerne flere og flere navneområder . Et navneområde er som en type for et Krav og en Evne. Den definerer semantikken for et sæt egenskaber for en kapacitet i det navneområde. Et krav er et filterudtryk, der hævdes på disse egenskaber. En ressource har et sæt funktioner, der leveres til runtime, når alle dets krav er opfyldt. Det er opgaven for Resolver for at finde et sæt ressourcer, der alle er tilfredse med hinandens muligheder og muligheder leveret af runtime.

For eksempel tilføjede vi osgi.ee navneområde, der definerer præcist på hvilke VM'er bundtet kan køre. Vi tilføjede osgi.extender navneområde, der modellerer en afhængighed af et eksternt program som Service Component Runtime (SCR). De fleste SCR-komponenter kræver ikke nogen pakke fra selve SCR, vi prøvede hårdt på at gøre dem så uafhængige som muligt. En SCR-komponent vil dog sidde ubrugelig, medmindre et bundt i kørselstiden giver SCR-funktionaliteten. Bemærk, at dette ikke kan bruge Require-Bundle, fordi der er flere implementeringer af SCR. Jeg tror, ​​der er omkring 20 navneområder. Hvert navneområde er defineret i en Namespace klasse.

Denne model har givet OSGi en række fordele:

  • Samhørighed Selvom specifikationen har tilføjet mange navneområder, behøvede resolverimplementeringerne aldrig at ændres, da de arbejdede på den generiske model.
  • Finkornet OSGi bundter er unikke i, hvordan de beskriver deres afhængigheder på en meget finkornet måde. Alle modulsystemer, jeg kender, har en tendens til at bruge den simple modul-til-modul-afhængighed, der ikke tillader substitution.
  • Fleksibel Da Framework udjævner afhængighederne mellem bundter, er det muligt i runtime at udnytte disse afhængigheder. For eksempel linkede jeg i OSGi enRoute et bundt til dets webside, der krydsede disse runtime-ledninger.

Jeg anser personligt OSGi's krav og kapacitetsmodel for en af ​​dens bedst bevarede hemmeligheder. Så vidt jeg kan se, kan det bruges på mange områder til at forbedre mange udviklingsprojekter til softwareteknologiens verden.

Den eneste skuffende del i dette spørgsmål er, at jeg troede, at vi havde beskrevet dette ret godt i Core-specifikationen? :-)


Krav- og kapacitetsmodellen er en udvidelse af import/eksportpakkemodellen. Faktisk kan du udtrykke en pakkeimport som et krav og en pakkeeksport som en mulighed.

Eksport/import af pakker giver mulighed for løs kobling. Du eksporterer en API, og klienten importerer den. På denne måde behøver klienten kun at vide om API'et, så løs kobling opnås.

På et senere tidspunkt, når du samler applikationen ud af bundter, gør denne løse kobling det vanskeligt at automatisere processen.

Hvis du bare leverer dit klientbundt til en resolver, kan den kun automatisk finde ud af, at du har brug for bundtet, der leverer API'en. Hvis implementeringen af ​​API'en er i en anden bundt, kan resolveren ikke vide, at du har brug for den.

Det er her krav kan hjælpe. Lad os tage HTTP Whiteboard-modellen. En pakke, der ønsker at udgive en servlet, skal importere servlet api-pakken, men skal også udtrykke, at den ønsker en implementering af osgi http whiteboard.

Dette kan udtrykkes ved kravet med namespace="osgi.implementation", name="osgi.http", version="1.1.0". Da dette er svært at skrive i hånden, er der annotationsunderstøttelse for det.

@HttpWhiteboardServletPattern("/myservlet")
@Component(service = Servlet.class)
public class MyServlet extends HttpServlet {
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
            throws IOException {
        resp.getWriter().println("Hello");
    }
}

Annotationen @HttpWhiteboardServletPattern oversættes indirekte til kravet ovenfor.

Så når du bygger en bundt med denne klasse, vil den importere servlet api-pakken og også have et krav om en http-whiteboard-implementering.

Hvis du nu ser på en implementeringspakke som felix http-tjenesten, vil du se, at den giver mulighed for whiteboard-impl.

Så hvis du har et OSGi-lager med dit bundt, servlet-API'en og felix http-tjenesten. Så kan resolveren give dig en komplet applikation, hvis du kun giver den dit bundt.


Java tag