DE10203774A1 - Verfahren zum Empfang und zur Weiterleitung beliebiger Client-Anfragen in einem Client/Server System - Google Patents

Verfahren zum Empfang und zur Weiterleitung beliebiger Client-Anfragen in einem Client/Server System

Info

Publication number
DE10203774A1
DE10203774A1 DE2002103774 DE10203774A DE10203774A1 DE 10203774 A1 DE10203774 A1 DE 10203774A1 DE 2002103774 DE2002103774 DE 2002103774 DE 10203774 A DE10203774 A DE 10203774A DE 10203774 A1 DE10203774 A1 DE 10203774A1
Authority
DE
Germany
Prior art keywords
client
server
servlet
request
call
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE2002103774
Other languages
English (en)
Inventor
Silvia Maczey
Oliver Gramberg
Rolf Merte
Peter Froehlich
Holger Hofmann
Jin Shen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ABB Patent GmbH
Original Assignee
ABB Patent GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ABB Patent GmbH filed Critical ABB Patent GmbH
Priority to DE2002103774 priority Critical patent/DE10203774A1/de
Priority to PCT/EP2003/000463 priority patent/WO2003065144A2/de
Publication of DE10203774A1 publication Critical patent/DE10203774A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/465Distributed object oriented systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Die Erfindung bezieht sich auf ein Verfahren zum Aufrufen einer objektorientierten Methode eines serverseitigen Objektes (52) auf Grund einer Client-Anfrage in einem Client-Server-System, das einen Client-Rechner (10), einen Web Browser (50) und einen Web Server (80) aufweist, in dessen Objekten (52) mehrere Methoden gespeichert sind, die mittels eines Servlets aufrufbar sind. DOLLAR A Zum Aufrufen einer Methode mittels einer Client-Anfrage aus dem Client-Rechner (10) - unter Anwendung des Java-Sprachkonzepts "Reflection" - wird ein einziges für alle Methoden gemeinsames Servlet (D) verwendet, das aus der Client-Anfrage den jeweiligen Methodennamen ausliest, den Aufruf an genau die Methode mit dem übergebenen Methodennamen weiterleitet und die zugehörigen Daten dem Client-Rechner (10) zur Anzeige bringt.

Description

  • Die Erfindung bezieht sich auf ein Verfahren zum Empfang und zur Weiterleitung beliebiger Client-Anfragen in einem Client/Serversystem.
  • Das Internet bzw. das sogenannte world wide web (www) ist zu einem Medium für komplexe verteilte Softwaresysteme geworden. Dynamische Internetseiten bilden dabei die Benutzerschnittstellen dieser Systeme, und können von beliebigen Rechnern, die einen Internetzugang aufweisen, aufgerufen werden. Dazu werden die Internetseiten in Client-Programmen, sogenannten Browsern dargestellt, welche dazu benutzt werden, sich in einem Datensystem oder -netz zu bewegen und zurechtzufinden.
  • Die Benutzeraktionen und die Eingabedaten werden dabei von einem Client-Rechner, der im folgenden als Client bezeichnet wird, an den serverseitigen Teil des Softwaresystems geliefert, der die Verarbeitungsroutinen und Datenspeichermedien enthält.
  • Sicherheitsrelevante Einschränkungen verbieten oft einen direkten Aufruf spezieller serverbasierter Routinen direkt aus der clientbasierten Benutzerschnittstelle heraus. Vielmehr müssen die Anfragen von einem Client mit Hilfe eines Kommunikationsprotokolls, beispielsweise mit einem HTTP-Protokoll (Hypertext Transfer/Transmission Protocol), das für die Übertragung und Verknüpfung der Webseiten zuständig ist, an den Server übermittelt werden, um dann auf dem Server wieder entschlüsselt und in einen sogenannten Methodenaufruf übersetzt zu werden. Das Ergebnis des Methodenaufrufs wird dann wiederum mit Hilfe des HTTP-Protokolls an den Client übermittelt.
  • Um beliebige Methodenaufrufe an beliebige serverseitige Software-Bausteine, sogenannte Objekte, weiterzugeben und die entsprechenden Rückgabewerte an den Client zurückzugeben, wird eine Komponente bereitgestellt, die den Prozeß des HTTP-Tunnelings benutzt. Dabei werden zwei unterschiedliche Protokolle auf einer gleichen Schicht miteinander verkapselt und die Daten des einen Protokolls werden in die Datenpakete eines zweiten Protokolls verpackt. Die Datenpakete eines fremden Protokolls können so mit Hilfe eines "Gastgeberprotokolls" transportiert werden.
  • Die auf der Programmiersprache Java basierenden Internetsysteme setzen sich aus mehreren kleinen Java-Programmen, den sogenannten Applets zusammen, die in einem Browser auf dem Client laufen. Ist der serverseitige Teil des Internetsystems in Java realisiert, so werden diese Java-Programme, die innerhalb des Web-Servers laufen, als Servlets bezeichnet.
  • Jedes Applet wird separat über das Netz an den Client verschickt. Sind die Applets beim Client angekommen, fügen sich die einzelnen Applets wieder zu einem Ganzen zusammen, da der Java-fähige Browser in der Lage ist, die an ein HTML-Dokument (Hyper text mark up language) gekoppelten Applets zu erkennen und in den Arbeitsspeicher des Client-Rechners zu transportieren.
  • Der übliche Weg, das HTTP-Tunneling innerhalb der Java basierten Internetsysteme zu ermöglichen, besteht darin, für jedes serverseitige Objekt, dessen objektorientierte Systemfunktionen vom Client aus aufrufbar sein sollen, einen Stellvertreter, ein sogenanntes Client Proxy Objekt, zur Verfügung zu stellen. Dieses Objekt hat die gleiche Schnittstelle wie das Serverobjekt, d. h. es implementiert die gleichen objektorientierten Systemfunktionen, die im folgenden als Methoden bezeichnet werden. Wird eine dieser Methoden aufgerufen, so wird eine Verbindung zu einem Servlet auf der Serverseite hergestellt, wobei das Servlet je nach Einstellung direkt beim Start oder bei Bedarf von einem Client aus geladen wird.
  • Die Parameter des Methodenaufrufs werden als serialisierte Objekte mit dem HTTP-Anfrage-Objekt (HTTP-Request-Object) an das Servlet übergeben. Das Servlet ruft die entsprechende Methode des serverseitigen Objektes auf und schickt deren Rückgabewert wiederum als serialisiertes Objekt mit dem HTTP-Antwort-Objekt (HTTP-Response- Object) zurück an das clientseitige Client Proxy Objekt, welches den Rückgabewert deserialisiert und zurückgibt.
  • Ein Nachteil dieses Verfahrens ist darin zu sehen, daß für jede Methode eines serverseitigen Objektes, die vom Client aus zugreifbar sein soll, ein eigenes Servlet existieren muß, welches die Parameter der Methode aus dem HTTP-Request liest und den Rückgabewert als HTTP-Response an den Client zurückgibt, wodurch sich die Übertragung als zeitaufwendig gestaltet. Die Programmierung der Servlets ist mit einem hohen Entwicklungsaufwand verbunden, der proportional zur Anzahl der verwendeten Methoden zunimmt. In Abhängigkeit von der Anzahl der verwendeten Servlets wird durch die Zunahme der Systemkomplexität die Wartbarkeit des Systems erschwert.
  • Der Erfindung liegt die Aufgabe zugrunde, ein möglichst einfach auszuführendes Verfahren zum Aufrufen einer Methode eines serverseitigen Objektes auf Grund einer Client- Anfrage in einem Client-Server-System mit einem möglichst geringen Aufwand zu realisieren.
  • Diese Aufgabe wird durch ein Verfahren zum Bereitstellen einer Methode eines serverseitigen Objektes auf Grund einer Client-Anfrage in einem Client-Server-System, in dessen Objekten mehrere Methoden gespeichert sind, die mittels eines Servlets aufrufbar sind, mit den im Anspruch 1 angegebenen Merkmalen gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in weiteren Ansprüchen angegeben.
  • Im erfindungsgemäßen Verfahren wird ein einziges Servlet implementiert, welches aus der Anfrage des Clients den Namen der aufzurufenden Methode ermittelt und dann den Aufruf an genau die Methode mit den übergebenen Namen weiterleitet. Dabei muß der Name der aufzurufenden Methode nicht schon zur Entwicklungszeit feststehen, sondern erst zur Laufzeit des Programms.
  • Beispielsweise läßt sich die Erfindung mittels eines speziellen Sprachkonzepts der Programmiersprache Java realisieren. Dieses Sprachkonzept, "Reflection" genannt, ist in James Gosling, Bill Joy, Guy Steele, Guy L. Steele, "The Java (TM) Language Specification", Addison Wesley Publishing Company, 1996 beschrieben und bietet die Möglichkeit zur Laufzeit eines Programms Informationen über die verwendeten Klassen, also über die Programmstruktur selbst zu ermitteln. So ist es beispielsweise möglich, während eines Programmlaufs den Namen der Klasse eines Objekts oder die Namen der implementierten Methoden einer Klasse zu erfragen. Außerdem ermöglicht dieses Sprachkonzept, Werte von Variablen zu setzten oder zu lesen, deren Namen erst zur Laufzeit des Programms feststehen.
  • Ausgehend vom Sprachkonzept "Reflection" wird die Signatur einer Methode, insbesondere deren Name, Typ, Parameter und Rückgabewert ermittelt, um diese Methode gemäß ihrer Spezifikation aufzurufen. Wendet man dieses Sprachkonzept auf das geschilderte Sachgebiet an, so benötigt man nicht mehr wie bisher pro Methodenaufruf ein Servlet, sondern nur noch ein einziges Servlet, welches den Methodennamen, die Argumente der Methode und die Typen der Argumente aus dem HTTP-Request liest.
  • Durch den neuen Ablauf wird die Systemkomplexität deutlich verringert. Der Entwicklungsaufwand für die Programmierung wird dadurch reduziert, daß für die verwendeten Methoden eines serverseitigen Objektes, die vom Client aus zugreifbar sind, nur noch ein Servlet zu programmieren ist, wodurch sich auch die Wartbarkeit verbessert.
  • Anhand des in den folgenden Zeichnungsfiguren dargestellten Ausführungsbeispieles soll die Erfindung näher erläutert und beschrieben werden.
  • Es zeigen:
  • Fig. 1 einen Verfahrensablauf zum Aufrufen einer Methode eines serverseitigen Objektes,
  • Fig. 2 eine Anordnung zum Empfang und zur Weiterleitung von Clientanfragen in einem Client/Serversystem (Stand der Technik), und
  • Fig. 3 eine erfindungsgemäße Anordnung zum Empfang und zur Weiterleitung von Clientanfragen in einem Client/Serversystem.
  • Fig. 1 zeigt den Verfahrensablauf zum Aufrufen einer Methode eines serverseitigen Objektes in einem Client/Server-System anhand von Verfahrensschritten 1-16.
  • In einem ersten Schritt 1 werden die bestimmten Informationen, die in einer graphischen Benutzerschnittstelle darzustellen sind, von einem Server ermittelt. In einem Schritt 2 wird eine konkrete Methode des Objekts "Client Proxy" aufgerufen, welche genau diese Information liefern soll. Da die Informationen vom Server geliefert werden, ruft das Client Proxy Objekt im Schritt 3 eine Hilfsklasse "Servlet Writer" auf, die ein Request-Objekt erzeugt und in diesem Request-Objekt den Namen der Methode speichert, deren Funktion darin besteht, die gewünschte Information auf dem Server zu beschaffen.
  • Im Schritt 4 wird das Request-Objekt, welches den konkreten Methodennamen, die Argumente der Methode und die Typen der Argumente speichert, generiert.
  • Im Schritt 6 wird die doPost Methode eines Datenbank(DB)-Servlet, welches auf dem Server läuft, aufgerufen und das Request-Objekt mittels der "Serialisierung" an das Servlet übertragen. Dazu wird das Request-Objekt auf der Clientseite serialisiert, d. h. in kleine übertragbare Einheiten zerlegt, und auf der Serverseite deserialisiert, also wieder zusammengebaut. Durch die Serialisierung wird also ein Argument, nämlich das Request- Objekt für die doPost Methode übertragen.
  • Die doPost-Methode ist bei allen HttpServlet Objekten definiert, wobei das HttpServlet eine Unterklasse vom Servlet ist, die speziell für die Entgegennahme von HTTP-Requests geeignet ist. Diese doPost Methode wird automatisch ausgeführt, wenn das Servlet vom Client aus aufgerufen wird. Deshalb enthält sie den Programmcode, der die Funktionalität des Servlets ausmacht, also beispielsweise den Programmcode, der die Informationen über die aufzurufende Methode aus dem Request-Objekt liest und dann diese Methode aufruft.
  • Das Servlet liest nun im Schritt 7 den Namen der Methode, welche die gewünschten Informationen liefert, deren Argumente und deren Argumentetypen aus dem Request-Objekt und ermittelt, welche konkrete Methode beispielsweise eines Datenbank(DB)-Managers mit welchen Argumenten aufgerufen werden soll, wobei der DB-Manager ein Beispiel aus einer definierten Anwendung ist und die Schnittstelle zur Datenbank darstellt. Jedoch ist auch der Aufruf von beliebigen Methoden irgendeines beliebigen Objekts möglich.
  • Mit dieser Information wird die konkrete Methode des DB-Managers im Schritt 8 identifiziert und aufgerufen.
  • Nachdem die Methode im Schritt 9 die gewünschte Information aus der Datenbank gelesen hat, gibt sie die Information im Schritt 12 an das aufrufende Servlet zurück, welches im Schritt 13 ein Response-Objekt generiert, in dem es die Information aus der Datenbank speichert.
  • Im Schritt 15 wird dieses Response-Objekt wieder an den Client mittels der "Serialisierung" übermittelt. Die Klasse ServletWriter, welche das Request-Objekt erzeugt hatte, liest nun die Informationen aus dem Response-Objekt und gibt sie an die aufrufende konkrete Methode des Client Proxy Objektes zurück, welches die Klasse ServletWriter aufgerufen hatte.
  • In einem letzten Schritt 16 wird die Information aus dem Response-Objekt an die Stelle des Programms zurückgegeben, welches die Informationen benötigt und in einer graphischen Benutzerschnittstelle dargestellt.
  • Das hier dargestellte Verfahren läßt sich nicht nur, wie beschrieben, auf das Abfragen von Informationen aus der Datenbank anwenden, sondern auch auf die Übermittlung von Daten von einem Client an einen Server, welcher die Daten dann verarbeitet oder abspeichert.
  • In den Fig. 2 und 3 ist eine Anwendung zum Empfang und zur Weiterleitung von Client- Anfragen in einem Client/Serversystem am Beispiel eines internetbasierten Softwaresystems zur Konfiguration einer Windkraftanlage bzw. eines Windparkes zur Gewinnung von Windenergie dargestellt, die einen Zugriff auf relevante Daten über eine Internet-basierte Benutzerschnittstelle ermöglicht.
  • Die Benutzeraktionen und die Eingabedaten werden dabei von einem Client 10, einem Server 20 zur Verfügung gestellt, wobei die Anfragen vom Client 10 mit Hilfe eines HTTP- Protokolls 30 an den Server 20 übermittelt werden, um dann auf dem Server 20 wieder entschlüsselt und in einen sogenannten Methodenaufruf übersetzt zu werden. Das Ergebnis des Methodenaufrufs wird dann wiederum mit Hilfe eines HTTP-Protokolls 30 an den Client 10 übermittelt.
  • Im aufgezeigten Beispiel stellt ein Applet 51, welches im Web-Browser 50 abgelegt ist, in einer Auswahlliste aller Windparks einer Datenbank 92, also Javaklassen aus der Wind- Center Anwendung dar, wobei die Daten der Datenbank 92 in Projektdaten, die sich bei jedem Projekt unterscheiden und in Standarddaten, auf die alle Projekte zurückgreifen, unterteilt sind.
  • Der Benutzer wählt nun einen bestimmten Windpark aus der Datenbank 92 aus und läßt sich dazu die entsprechenden Finanzdaten und technische Daten anzeigen. Die Klasse DB-Manager 91, die wie die Datenbank 92 zum serverseitigen Teil der Java Applikation 90 gehört, implementiert dafür die folgenden drei Methoden:
    public List GetAllWindParks( );
    public FinancialData GetFinancialData(WindPark ID);
    public TechnicalData GetTechnicalData(WindPark ID).
  • Dabei bezeichnet ID den Namen eines Arguments, wobei das Argument eines Windparks im beschriebenen Beispiel als Zahl vom Typ "long" übergeben wird. Der Methodenname ist dabei beispielsweise "getFinancialData" und das Argument eine Zahl, unter der in der Datenbank die Windparkdaten abgelegt sind.
  • Die drei aufgeführten Methoden sind vom Applet 51 aus aufrufbar. Ein Proxy, d. h. ein Stellvertreter eines andern Objekts, das den DB-Manager 91 im Applet 51 repräsentiert, implementiert ebenfalls diese drei Methoden.
  • Eine Klasse mit dem Namen ClientProxy 52 vertritt auf der Clientseite das Serverobjekt DB-Manager 91.
  • Die Klasse Servlet Writer 53, welche das Request-Objekt erzeugt, liest die Informationen aus dem Response-Objekt und gibt sie an die aufrufende konkrete Methode des Client Proxy Objektes 52 zurück, welches die Klasse Servlet Writer 53 aufgerufen hatte. Anstelle eines Zugriffs auf die Datenbank 92 wird allerdings ein entsprechende Servlet A, B, C auf einem Web-Server 80 aufgerufen, der dann die entsprechende DB-Manager-Methode aus dem DB-Manager 91 aufruft.
  • Bei den üblicherweise verwendeten Architekturen wie sie in Fig. 2 dargestellt sind, müssen dafür drei Servlets A, B, C implementiert werden. Jede der Methoden des Client Proxy Objektes 52 ruft ein anderes Servlet A, B, C auf.
  • Bei der in Fig. 3 dargestellten Architektur, rufen alle drei Methoden das gleiche Servlet D im DB-Manager 91 auf, geben aber gleichzeitig den Methodennamen als Parameter mit an das Servlet D. Das Servlet D ruft jetzt die Methode mit dem übergebenen Namen beim DB-Manager 91 auf.
  • Der folgende Programmcode zeigt, wie der Methodenaufruf einer beliebigen Methode des DB-Managers 91 realisiert ist:
    / / Read the name of the method to be called String methodName = userReq.getMethodName( );
    / / read the arguments for the method call Serializable arguments = userReq.getArguments(( ));
    / / read the classes of the arguments for the method call Class argumentTypes = userReq.getArgumentTypes(( ));
    / / find the matching method of dbManager Method method = dbManager.getClass( ).getMethod(methodName,argumentTypes);
    / / invoke the method Object result = method.invoke(dbManager,arguments).

Claims (8)

1. Verfahren zum Aufrufen einer objektorientierten Methode eines serverseitigen Objektes (52) auf Grund einer Client-Anfrage in einem Client-Server-System, das einen Client-Rechner (10), einen Web Browser (50) und einen Web Server (80) aufweist und in dessen Objekten (52) mehrere Methoden gespeichert sind, die mittels eines Servlets aufrufbar sind, dadurch gekennzeichnet, daß zum Aufrufen einer Methode mittels einer Client-Anfrage aus dem Client-Rechner (10) ein einziges für alle Methoden gemeinsames Servlet (D) verwendet wird, das aus der Client-Anfrage den jeweiligen Methodennamen ausliest, den Aufruf an genau die Methode mit dem übergebenen Methodennamen weiterleitet, und die zugehörigen Daten dem Client-Rechner (10) zur Anzeige bringt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das serverseitige Objekt (52) ein Client Proxy Objekt ist, welches eine Klasse aufruft, die ein Request- Objekt erzeugt und in diesem Request-Objekt den Methodennamen speichert.
3. Verfahren nach Anspruch 1 und 2, dadurch gekennzeichnet, daß das Request- Objekt - unter Anwendung des Java-Sprachkonzeptes "Serialisierung" - an das Servlet (D) übergeben wird.
4. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß bei der Übergabe von Argumenten an die Methode, die Argumente sowie die Typen der Argumente im Request-Objekt gespeichert werden.
5. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Übermittlung von Daten vom Client-Rechner (10) an den Server, welcher die Daten verarbeitet oder abspeichert, mittels eines einzigen Servlets (D) realisierbar ist.
6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Namen der Klasse eines Objekts und die Namen der aufzurufenden Methode zur Laufzeit des Programms festgelegt werden.
7. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Werte von Variablen festgelegt und gelesen werden, deren Namen erst zur Laufzeit des Programms feststehen.
8. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß zum Aufrufen der Methode mittels einer Client-Anfrage aus dem Client-Rechner (10) das Java-Sprachkonzept "Reflection" angewendet wird.
DE2002103774 2002-01-30 2002-01-30 Verfahren zum Empfang und zur Weiterleitung beliebiger Client-Anfragen in einem Client/Server System Withdrawn DE10203774A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE2002103774 DE10203774A1 (de) 2002-01-30 2002-01-30 Verfahren zum Empfang und zur Weiterleitung beliebiger Client-Anfragen in einem Client/Server System
PCT/EP2003/000463 WO2003065144A2 (de) 2002-01-30 2003-01-18 Verfahren zum empfang und zur weiterleitung beliebiger client-anfragen in einem client/serversystem

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2002103774 DE10203774A1 (de) 2002-01-30 2002-01-30 Verfahren zum Empfang und zur Weiterleitung beliebiger Client-Anfragen in einem Client/Server System

Publications (1)

Publication Number Publication Date
DE10203774A1 true DE10203774A1 (de) 2003-08-28

Family

ID=27634745

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2002103774 Withdrawn DE10203774A1 (de) 2002-01-30 2002-01-30 Verfahren zum Empfang und zur Weiterleitung beliebiger Client-Anfragen in einem Client/Server System

Country Status (2)

Country Link
DE (1) DE10203774A1 (de)
WO (1) WO2003065144A2 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105260179A (zh) * 2015-09-24 2016-01-20 浪潮(北京)电子信息产业有限公司 一种实现flex与servlet交互的方法

Also Published As

Publication number Publication date
WO2003065144A2 (de) 2003-08-07

Similar Documents

Publication Publication Date Title
DE69724877T2 (de) Verfahren und Vorrichtung zum Betrieb einer Aggregation von Serverrechnern mittels eines Doppelzweck-Proxy-Servers
DE69838262T2 (de) Allgemeine benutzer-authentifizierung für netz-rechner
DE69832406T2 (de) Kombiniertes internet-und datenzugangssystem
DE69812899T2 (de) Webagent zur anforderung von mehreren prozessen
DE102008019040B4 (de) Verfahren und Steuergerät zur Steuerung eines Automatisierungssystems
DE69814900T2 (de) Verfahren und system zur unterstützung verteilter software- entwicklung ohne bewusstsein der verteilten charakteristik der software
DE69734432T2 (de) Verfahren und Vorrichtung zur Absendung von Clientverfahrenanrufen in einem Server Rechnersystem
DE69912317T2 (de) Vorrichtung und verfahren zur bestimmung einer programmnachbarschaft für einen kundenknoten in einem kundenbedienernetzwerk
DE60211254T2 (de) Fernereignis Behandlung in ein Paketnetzwerk
DE60207155T2 (de) Objektorientiertes Internetschnittstellensystem für eine industrielle Steuereinrichtung
DE69630480T2 (de) Verfahren, Vorrichtung und Datenstrukturen zur Objektverwaltung
DE60106124T2 (de) Verfahren und System zum Empfehlen eines verfügbaren Netzwerkprotokolls
DE10051021A1 (de) System, Verfahren und Computerprogramm zur Veröffentlichung interaktiver Web-Inhalte in einer statisch verknüpften Web-Hierarchie
DE69814697T2 (de) Vorrichtung, methode und computer programm produkt für client/server rechner mit vom client auswählbarer lokalisierung von transaktionsobjekten
EP3977668B1 (de) System zur erzeugung von kryptografischem material
DE19957235A1 (de) Vorrichtung, Prozeß und Produkt für den Zugriff auf Java-Anwendungen
DE10222361C2 (de) Verfahren zum Betreiben eines verteilten Rechnernetzwerks umfassend mehrere verteilt angeordnete Rechner
EP3200034B1 (de) Zugriff auf daten oder funktionen einer speicherprogrammierbaren steuerung mittels eines webdienstes
DE10352400A1 (de) Netzwerkdienst-Abfangvorrichtung
EP2648094A2 (de) Verfahren und System zum Erzeugen eines Quellcodes für ein Computerprogramm zur Ausführung und Simulation eines Prozesses
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
DE60001743T2 (de) Erweiterung der attribute eines anwendungsprogrammes hergestellt mit einem programmierwerkzeug der vierten generation
DE10024347B4 (de) Sicherheitsservice-Schicht
EP1005216A2 (de) Verfahren und Vorrichtung zur Validierung von Konfigurationsdaten für Telekommunikationssysteme
DE102006033863A1 (de) Verschaltungsschnittstelle für flexibles Online/Offline-Deployment einer n-schichtigen Softwareapplikation

Legal Events

Date Code Title Description
OR8 Request for search as to paragraph 43 lit. 1 sentence 1 patent law
8105 Search report available
8139 Disposal/non-payment of the annual fee