Erläuterungen:
Die Datenbank enthält alle geschäftsrelevanten Daten. Der Applikationsserver JBoss enthält die Verfahrensanweisungen für die jeweiligen Transaktionen bzw. Geschäftsvorfälle. Die auf XML basierenden Applikationsdefinitionen des Swing-Client sind unabhängig von der Anwendung. Dadurch wird eine individuelle Ablauf- und Präsentationsgestaltung ermöglicht, ohne die Standard-Geschäftslogik zu verändern. Sämtliche Menüs und Bildschirmlayouts können so frei gestaltet werden.
Der Swing-Client greift per JNDI auf einen JBoss 4.0.5 (läuft auf Vista) zu. Um die Dienste auszuführen, lädt der Client die Klassen vom JBoss und führt die Dienste /Methoden aus.
Beim Verbindungsaufbau nutzen der Swing-Client und JBoss die Ports Naming 2001, RmiPort 2000, RMIObjectPort 4444 und WebService 8083.
Aber wir haben ein merkwürdiges Phänomen:
Bei einigen WinXP-Rechnern scheitert die Kommunikation, wenn sie per VPN-Client aus einer anderen Firma via Internet auf das interne Netzwerk zugreifen, bei anderen WinXP funktioniert das unter den gleichen Bedingungen tadellos. Wenn sich alle diese Rechner im internen Netzwerk befinden, funktioniert die Kommunikation. Erst hatte ich gedacht, der VPN-Client blockt einen oder mehrere Ports (explizit den Port 8083), hab aber ein Tool geschrieben, mit dem die Kollegen die Sockets testen konnten, wenn sie per VPN-Client zugreifen. Die Sockets waren erreichbar.
Der SecurityManager ist wie folgt gesetzt:
Die Datenbank enthält alle geschäftsrelevanten Daten. Der Applikationsserver JBoss enthält die Verfahrensanweisungen für die jeweiligen Transaktionen bzw. Geschäftsvorfälle. Die auf XML basierenden Applikationsdefinitionen des Swing-Client sind unabhängig von der Anwendung. Dadurch wird eine individuelle Ablauf- und Präsentationsgestaltung ermöglicht, ohne die Standard-Geschäftslogik zu verändern. Sämtliche Menüs und Bildschirmlayouts können so frei gestaltet werden.
Der Swing-Client greift per JNDI auf einen JBoss 4.0.5 (läuft auf Vista) zu. Um die Dienste auszuführen, lädt der Client die Klassen vom JBoss und führt die Dienste /Methoden aus.
Code:
Object ref=initial.lookup("ProjektName_KlassenName");
Class classS=ref.getClass().getClassLoader().loadClass("service.KlassenName");
…
Method meth=classS.getMethod("_SrvName",classTypes);Beim Verbindungsaufbau nutzen der Swing-Client und JBoss die Ports Naming 2001, RmiPort 2000, RMIObjectPort 4444 und WebService 8083.
Aber wir haben ein merkwürdiges Phänomen:
Bei einigen WinXP-Rechnern scheitert die Kommunikation, wenn sie per VPN-Client aus einer anderen Firma via Internet auf das interne Netzwerk zugreifen, bei anderen WinXP funktioniert das unter den gleichen Bedingungen tadellos. Wenn sich alle diese Rechner im internen Netzwerk befinden, funktioniert die Kommunikation. Erst hatte ich gedacht, der VPN-Client blockt einen oder mehrere Ports (explizit den Port 8083), hab aber ein Tool geschrieben, mit dem die Kollegen die Sockets testen konnten, wenn sie per VPN-Client zugreifen. Die Sockets waren erreichbar.
Der SecurityManager ist wie folgt gesetzt:
Code:
SetSecurityManager sm=new SetSecurityManager();
System.setSecurityManager(sm);
…
public class SetSecurityManager extends SecurityManager{
public SetSecurityManager() {
}
//Eigenschaften
public void checkPermission(){}
public void checkPermission(Permission perm){}
public void checkPermission(Permission perm,Object context){}
}
