Die Middleware Einbindung

NextDie Verwendung technologieneutraler, funktionaler Module und deren zentrale Verwaltung auch auf der Aufrufebene ermöglicht eine völlig neue Art der Nutzung von Middleware Technologien.

Anstelle der konkreten Implementierung aller fachlichen Schnittstellen und Services in der jeweilig gewünschten Middelware-Technologie (z.B. EJB, Servlet, REST etc.) – wird mit dem ISA Modulsystem lediglich eine einzige, universelle Implementierung pro gewünschter Technologie benötigt.

Ein Anwendungssystem mit z.B. 1000 fachlichen Diensten und entsprechend z.B. 1000 konkreten EJBs im Server-Deployment, sowie den notwendigen 1000 Remote Schnittstellen auf der Client Seite – wird reduziert auf 1 EJB auf dem Server und 1 Remote Interface auf dem Client.

Der Technologie- bzw Middleware abhängige Teil einer beliebig großen Enterprise Anwendung wird so reduziert – auf einen wenige Kilobyte kleinen Broker, der vollständig frei und unabhängig von fachlicher Implementierung und Änderungen ist – und gleichzeitig alle gewünschten Middleware Technologien verfügbar macht.

  • Dadurch werden die Turnaround Zeit in Entwicklung und bei der Installation bzw. Update einer Anwendung im Betrieb deutlich gesenkt

AppsForTheEnterpriseArchitecture

WICHTIG:
Der Aufruf auf Client Seite erfolgt natürlich trotzdem über ein voll typisiertes Interface, das automatisch vom System erzeugt und zur Verfügung gestellt wird (siehe Kommunikation oder auch Einbindung in eigene Anwendungen).

Client Service Schnittstelle 

public class Client{

  //das Java Interface des Server Moduls
  //KEIN technologiegebundenes Remote Interface - einfach Java
  //für einen voll typisierten Methodenaufruf vom Client aus
  ModuleBarIFace bar = null;

  ...

  //Service von der Verwaltung beschaffen
  bar = (ModuleBarIFace)handler.getService("ModuleBar[version=1.0.0]", ModuleBarIFace.class);

  //typisierter Methodenaufruf ganz normal aufrufen
  bar.doBizzService(arg1, arg2);

}

Einbindung auf dem Server

//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”.