Die Middleware Einbindung

NextDie Modularisierung in plattformneutrale funktionale Teile und deren zentrale Verwaltung auch auf der Aufrufebene ermöglicht eine neue Nutzung von beliebigen Middleware Technologien.

Dazu wird lediglich ein von fachlichen Objekten und Bezügen vollständig freier Broker auf Basis der gewünschten Middleware (bei ISA ist es JEE) benötigt, der wie die Modulverwaltung nur eine generische und damit triviale “Call” Schnittstelle für alle gewünschten Technologien (z.B. EJB, Servlet etc.) bereitstellt.

Innerhalb dieser Schnittstelle werden dann alle Aufrufe einfach an eine Modulverwaltung weitergeleitet wodurch die Anwendungsentwicklung vollständig von der jeweiligen Middleware Plattform entkoppelt wird.

AppsForTheEnterpriseArchitecture

WICHTIG:
Der Aufruf auf Client Seite erfolgt natürlich trotzdem über ein voll typisiertes Interface bzw. ein Service Proxy (siehe Kommunikation oder auch Einbindung in eigene Anwendungen)

//leicht vereinfachter Code
//
//Die Broker EJB Stateful Session Bean
//ist der generischen Adapter zur JEE EJB Middleware Plattform
//er ist FREI von jeder konkreten fachlichen Implementierung
//und nur EINMAL vorhanden

@Stateful
public class StatefulBrokerSessionBean{

	private StatefulCallHandler handler = null;

	//Erzeugung einer entsprechenden Verwaltung
	//z.B. in einer Initialisierungsmethode
	public void initSession(Object config)throws Exception{
		handler = Bootstrap.getInstance().getStatefulCallHandler(config);
	}

	//Die Implementierung der generischen Call Schnittstelle
	//
	//mit descr z.B. = "com.my.apl.ModuleFoo:doBizzService[version=1.0.0]"
	//wird die Methode doBizzService
	//des Moduls com.my.apl.ModuleFoo-1.0.0
	//mit args aufgerufen
	//ist das Modul noch nicht geladen wird es automatisch installiert
	public Object call(Object descr, Object args)throws Exception{
		return handler.call(descr, args);
	}
}

Der Broker selbst benötigt vom ISA System lediglich die kleine Bootstrap Bibliothek (ca. 40KB), ist daher selbst sehr klein und muss in der Entwicklung nicht angepasst oder geändert werden. Die aktuelle Broker EAR mit Adaptern für SLB, SFB, Servlet und WebService ist nur ca. 60 KB groß. Der Broker unterstützt

  • Passivierung von Stateful Sessions
  • sowie Container Managed Transactions für EJBs

Durch die Konstruktion entfällt der gesamte Bereich Middleware spezifischer Abhängigkeiten, Paketierung und Deployment.

Gleichzeitig ist die Konstruktion aus sich heraus serviceorientiert und kann mit jeder Technologie (z.B. EJB, Servlet, WebService etc.) genutzt werden. Die Kommunikation der Server-Module untereinander erfolgt nach diesem Tunneling1 wieder ganz normal auf POJO Ebene und unterscheidet sich so in keiner Weise von “normaler” Java Standalone Entwicklung.

Ein Client kommuniziert mit dem Broker über einen generischen Connector für die jeweils gewünschte Middleware Technologie (z.B. EJB, Servlet oder WebService). Auf diese Weise können Module frei, aber sehr wohl gesteuert, über das Netzwerk kommunizieren – genauso als ob sie sich in ein und der selben Java VM befinden würden.

//Export Definition des Server Moduls - ServerServiceFoo
//META-INF/MANIFEST.MF ServerServiceFoo[
//  Exports: ServerServiceFooIFace; BizzObject; OtherBizzObject
//]

//Interface des Server Moduls
//wird einem Client zusammen mit allen exportierten Objekten
//zur Laufzeit automatisch zur Verfügung gestellt (Replikation)
public interface ServerServiceFooIFace{

	public OtherBizzObject doBizzMethod(BizzObject arg);

	}

//Import Definition des Client Moduls
//META-INF/MANIFEST.MF ClientModuleBar[
//  Imports: ServerServiceFoo[version=1.0.0]
//]

//Implementierung Client Modul
public class ClientModuleBar{

	@Service()
	private ServerServiceFooIFace fooService = null;

	private callServerService(){
	BizzObject arg = new BizzObject("4711");

	OtherBizzObject = fooService.doBizzMethod(arg);

	//der Aufruf bewirkt intern:
	//1. Call Aufruf der Client Verwaltung
	//2. automatisches Weiterleiten an den Client Connector
	//3. Call Aufruf auf dem Server Adapter (z.B. EJB)
	//4. Call Aufruf Server Verwaltung
	//5. Aufruf von doBizzMethod auf Server Modul
	}
}

___________________
1: Tunneling
Über die generischen Brokerschnittstelle können Objekte beliebigen Typs transportiert werden ohne dass deren Klassen dem Broker bekannt sein müssen. Die Objekte sind dabei immer nur serialisierte Byte Daten, die erst im Kontext des empfangenden Moduls von der Verwaltung  wieder in die ursprünglichen Objekte deserialisiert werden. Auf diese Weise bleibt der Broker frei von jedem konkreten fachlichen Bezug und gleichzeitig ist auch die Modulintegrität bzgl. Im- und Export von Datentypen gesichert.

Der gesamte Vorgang (Serialisierung/Deserialisierung) wird von der Verwaltung automatisch durchgeführt und ist somit aus Sicht der Anwendungsentwicklung “transparent”.