Nachfolgend ein einfaches Beispiel, wie Enterprise Apps transparent in bestehende Anwendungen eingebunden werden können – um diese z.B. zu erweitern oder sukzessive über Client Server Grenzen hinweg zu modularisieren (siehe auch Service Broker einbinden und Installation).

Die Anwendung instantiiert hierzu einfach einen ServiceHandler über die isa.CoreBootstrap Klasse und kann über dieses Objekt dann mit Standard Java Mitteln auf lokale oder remote Module und Services zugreifen – das ist alles.

Das Projekt als Zip Datei zum Download (Eclipse Kepler) von GitHub.
Eine bestehende Anwendung

package com.example;

//just two imports
//from one library isa.CoreBoostrap.jar
import isa.Bootstrap;
import isa.ServiceHandler;

/**
 * your application class
 * the world's smallest and simplest modular client server application
 * - NO special project
 * - NO special packaging
 * - NO deployment
 * - NO runtime
 * - NO special programming
 *
 * get a service - call it - that's it
 */
public class ThirdPartyApplication {

	//the isa service handler
	protected ServiceHandler handler = null;
	//your module services
	protected TestModuleIFace localService = null;
	protected TestServiceIFace remoteService = null;

	public ThirdPartyApplication() {
	}

	/**
	* Three steps to become modular and service oriented
	* 1. have your own application
	*/
	public static void main(String[] args) {
		ThirdPartyApplication lApl = new ThirdPartyApplication();

		try{
			lApl.go();
		}catch(Exception e){
			e.printStackTrace();
		}
	}

	/**
	*/
	protected void go() throws Exception{
		Object lRet = null;

		//2. get a service handler from isa.Bootstrap
		handler = Bootstrap.getInstance("").getServiceHandler();

		//3. get a service from a module and call it
		localService = (TestModuleIFace)handler.getService(
			"com.example.ThirdPartyTestModule[version=1.0.0]",
			TestModuleIFace.class);
		lRet = localService.sayHello("World");
		System.out.println("Local Service Call returned: "+lRet);

		//just one more step
		//and this is a complete client-server application
		handler.connect("user", "password",
			"http://integrating-architecture.de", "8080",
			"isa.esb.ServiceBrokerWebConnector[version=1.0.*]");

		//get a remote service from a module and call it
		remoteService = (TestServiceIFace)handler.getService(
			"isa.TestService[version=1.0.0.DEV-SNAPSHOT]",
			TestServiceIFace.class);
		lRet = remoteService.run("HELLO WORLD");
		System.out.println("Remote Service Call returned: "+lRet);
	}

	/**
	* the interface definitions
	*/
	/**
	* complex business module interface
	*/
	protected interface TestModuleIFace{
		public String sayHello(String pName);
	}

	/**
	* complex remote business module interface
	*/
	protected interface TestServiceIFace{
		public Object run(Object pIn);
	}
}

Hinweise:

• die Signaturen der Service Interfaces können natürlich beliebig sein und auch beliebige Datentypen verwenden. Die hier verwendeten sind nur Demo Beispiele.
• eine strengere Modularität würde darüber hinaus keine eigenen Interfaces verwenden sondern solche, die von den Modulen selbst definiert und zur Verfügung gestellt werden
• technisch gibt es keinen Unterschied zwischen lokalen und serverbasierten, remoten Modulen. Findet der Handler kein lokales Modul und ist er mit einem Server verbunden dann leitet er die Anfrage automatisch an diesen weiter. (ThirdPartyTestModule könnte unverändert auch auf dem Server liegen)
• welche Techniken und/oder Protokolle (z.B. EJB) das Connector Modul unterstützt hängt allein von diesem selbst ab und hat nichts mit den fachlichen Modulen bzw. den Services zu tun.

Die TestModul Klasse

package com.example;

public class ThirdPartyTestModule {

	public ThirdPartyTestModule() {
	}

	/**
	 */
	public String sayHello(String pName){
		return "Hello "+pName;
	}

}

Das Projekt und die Module

Hinweise

• das Verzeichnis “plugins” ist das Standardverzeichnis für ISA Module, der Ort (Repository) wo dieses Verzeichnis liegt kann jedoch frei gewählt werden
• die Module isa.CoreBootstrap und isa.Core (zusammen ca. 200 KB) sind obligatorisch, sie bilden das Modulsystem wobei lediglich das Bootstrap Modul im Application ClassPath liegen muss
• alle weiteren Module sind optional und können nach Bedarf frei gewählt werden