Paketstruktur des OSGI -Bundles

Question

Ich habe einige über "gute Praxis" in Bezug auf die Paketstruktur in OSGI -Bündeln nachgedacht. Derzeit haben wir im Durchschnitt 8-12 Klassen pro Bündel. Einer meiner Initiativen/Vorschläge bestand darin, zwei Pakete zu haben; com.sc.company_name.osgi.services.api (für API-bezogene Klassen/Schnittstellen (die extern exportiert wird) und ein Paket com.osgi.services.impl für die Implementierung (nicht exportiert)). Was sind die Vorschriften davon? Irgendwelche anderen Vorschläge?

Answer 1

Sie können auch in Betracht ziehen, die Schnittstellen einzulegen com.company_name.subsystem, und die Implementierung in com.company_name.subsystem.impl, der OSGI -spezifische Code, falls es welche gibt, könnte sich befinden com.company_name.subsystem.osgi. Manchmal haben Sie möglicherweise mehrere Implementierung derselben Schnittstellen. In diesem Fall könnten Sie in Betracht ziehen - com.company_name.subsystem.impl1 und com.company_name.subsystem.impl2, zum Beispiel:

com.company.scm        // the scm api
com.company.scm.git    // its git implementaton
com.company.scm.svn    // its subversion implementation
com.company.scm.osgi   // the place to put an OSGI Activator

In diesem Sinne könnte die Paketstruktur OSGI Agnostic sein. Wenn Sie später zu einem anderen Container wechseln, setzen Sie nur eine zusätzliche

com.company.scm.sca     // or whatever component model you might think of

Immer haben api und impl In Ihrem Paketnamen könnte nervig sein. Wenn Sie Zweifel verwenden impl aber nicht api.

Answer 2

Es ist nicht die Anzahl der Klassen, die wichtig sind, sondern die Konzepte. Meiner Meinung nach sollten Sie eine konzeptionelle Einheit in einem Bundle haben. In einigen Fällen könnten dies nur ein paar Klassen in anderen Paketen mit 100 -Klassen sein.

Was es wichtig ist, ist, dass Sie die API und die Implementierung trennen. Ein Bundle enthält die API Ihres Konzepts und das andere die Implementierung. So können Sie verschiedene Implementierungen für eine gut definierte API bereitstellen. In einigen Fällen kann dies sogar erforderlich sein, wenn Sie von einem Bundle aus der Ferne auf die Dienste zugreifen möchten (unter Verwendung von EG R-OGSI).

Die API -Bündel werden dann durch Code -Sharing und die Dienste aus den Implementierungsbündeln durch Service Sharing verwendet. Der beste Weg, um diese Möglichkeiten zu erkunden, besteht darin, die Servicetracker zu betrachten.

Answer 3

In Ihrem Fall könnten Sie die Implementierung im selben Paket haben, aber alle Klassen "Paket geschützt". Auf diese Weise können Sie das Paket exportieren und die Implementierung wäre außen nicht sichtbar, selbst wenn Sie OSGI nicht verwenden (sondern als reguläre JAR -Datei).