Modularisierung in Java

[thousands]

Hallo,

ich würde gerne eines meiner Programme modularisieren, bin auf dem Gebiet aber kompletter Neuling.

Ich stelle mir das Ganze so vor, dass ich anstatt einer einzigen jar Datei, in der die komplette Funktionalität des Programmes enthalten ist, mehrere jar Dateien (Module) mit jeweils bestimmten Teilfunktionalitäten habe. Eine weitere jar könnte zudem eine Art Basisapplikation darstellen, welche eine GUI umsetzt und sich um die "Verwaltung" meiner Module kümmert.

Ein möglichst einfaches Beispiel wäre etwa ein Modul A.jar, welches Daten einliest und diese den anderen Modulen mittels einer Schnittstelle A1 (provided Interface) bereitstellt. Ein zweites Modul B.jar würde diese Daten mittels einer Schnittstelle B1 (required Interface) regelmäßig von A1 auslesen und daraufhin auf der Konsole ausgeben.
Die konkrete Aufgabe der Basisapplikation wäre es dabei, vor der tatsächlichen Ausführung der Module sicherzustellen, dass für jedes in den Modulen vorkommende required Interface immer jeweils (genau) ein zugehöriges provided Interface in einem anderen Modul existiert. Dadurch will ich sicherstellen, dass bei einem zukünftigen Austausch von Modulen nicht plötzlich einige required Interfaces "in der Luft hängen" und Exceptions werfen.

Wenn man sich ein bisschen im Internet zum Thema Java-Modularisierung umsieht, stößt man ja recht schnell auf OSGi. Mit kommts allerdings ein wenig so vor, als würde ich damit, bezogen auf mein Problem, gewissermaßen "mit Kanonen auf Spatzen schießen". Gibts denn eine etwas weniger einschüchternde Alternative, die für meine Belange ebenfalls ausreichend wäre, oder komme ich um OSGi nicht herum?

Danke und Gruß,
thousands

 

[tagedieb]

Ich kenn mich mit OSGi zwar nicht aus, aber ich denke es waere auch mit "Spring Autowired Annotations" machbar.

Dabei sucht er sicht fuer jedes required Interface eine passende Implementierung (provided Interface). Kann das passende Bean nicht gefunden werden bricht die Initialisierung der Applikation ab. Auch hier kann die Implementierung ausgetauscht werden ohne die Konfiguration Aendern zu muessen.

siehe Beispiel

 

[Gast2]

Wenn du komplett dynmaisch jars (evtl. in unterschiedlichen Versionen) im laufenden Betrieb installieren und deinstallieren willst, ist OSGi die richtige Wahl.
Ich denke auch so machst du keinen Fehler dir OSGi mal anzuschauen.
Hier werden die Grundlagen ziemlich gut vermittel:
OSGi Modularity - Tutorial

 

[thousands]

Danke schonmal für die Antworten!

Eine Verständnisfrage: was genau spricht eigentlich dagegen, meine Module einfach als Plugins über den Classpath mit zu laden und mittels ServiceLoader anzusprechen? Meine Basisapplikation könnte z.B. ein Interface ModuleInterface bereitstellen, welches von den jeweiligen Plugins implementiert wird (die Plugins haben also eine Dependency zur Basisapplikation, das wäre für meine Belange kein Problem).

Also in der Basisapplikation:

package Basisapplikation;

public interface ModuleInterface 
{
	public String getModuleID();
}

Und in jedem der Module:

import Basisapplikation.ModuleInterface;

public class ImplementedModuleInterface implements ModuleInterface 
{
	public String getModuleID() 
	{
		return "abcd";
	}
}

In meiner Basisapplikation könnte ich meine Plugins dann (meinem Verständnis nach) einfach folgendermaßen benutzen

public class Basisapp 
{
	public static void main(String[] args) 
	{
		Iterator moduleIterator = ServiceLoader.load(ModuleInterface.class).iterator();
		
		while (moduleIterator.hasNext()) 
		{
			ModulInterface module = moduleIterator.next();
			System.out.print(module.getModuleID());
		}
	}
}

Der Vorteil den ich in dieser Lösung sehen würde, ist dass ich mir den ganzen "Ballast" aufwändiger Modularisierungs-Lösungen sparen würde. Der Nachteil wäre, dass meine Module/Plugins nicht dynamisch zur Laufzeit hinzugefügt werden können, sondern von Anfang an im Classpath stehen müssen. Das wäre für meine Zwecke allerdings nicht weiter von Belang. Außerdem müssten sich alle Module zwangsweise an die Schnittstellenspezifikation des ModuleInterface halten, auch dies wäre kein Problem bzw. sogar wünschenswert.

Gibts denn weitere Einwände, die klar gegen eine derartige, bewusst einfach gehaltene, Umsetzung sprechen und die ich bisher nicht bedacht habe?

Danke im Vorraus!

Gruß,
thousands