DE10332470B4 - Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken - Google Patents

Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken Download PDF

Info

Publication number
DE10332470B4
DE10332470B4 DE10332470.4A DE10332470A DE10332470B4 DE 10332470 B4 DE10332470 B4 DE 10332470B4 DE 10332470 A DE10332470 A DE 10332470A DE 10332470 B4 DE10332470 B4 DE 10332470B4
Authority
DE
Germany
Prior art keywords
server
application system
client
file
communication component
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.)
Expired - Lifetime
Application number
DE10332470.4A
Other languages
English (en)
Other versions
DE10332470A1 (de
Inventor
Jürgen Strohmeyer
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.)
Volkswagen AG
Original Assignee
Volkswagen AG
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
Priority claimed from DE10301106A external-priority patent/DE10301106A1/de
Application filed by Volkswagen AG filed Critical Volkswagen AG
Priority to DE10332470.4A priority Critical patent/DE10332470B4/de
Publication of DE10332470A1 publication Critical patent/DE10332470A1/de
Application granted granted Critical
Publication of DE10332470B4 publication Critical patent/DE10332470B4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H04L63/0218Distributed architectures, e.g. distributed firewalls
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Abstract

Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmesnetzwerken, wobei mindestens ein Anwendungssystem in einem internen Unternehmensnetzwerk und mindestens ein Anwendungssystem in einem externen Unternehmensnetzwerk eingebunden ist, mindestens dem internen Unternehmensnetzwerk eine Firewall zugeordnet ist und die Firewall mindestens eine innere und äußere Firewall umfasst, wobei in einer demilitarisierten Zone DMZ (2) zwischen der inneren und äußeren Firewall (201, 202) ein Verbindungsserver (20) angeordnet ist und die Unternehmensnetzwerke (1, 5) mit jeweils mindestens einem Client-Rechner (10, 50) ausgebildet sind,einem Client-Rechner (10, 50) mindestens ein Anwendungssystem (101-103, 501-503) zugeordnet ist, unddie Kommunikation zwischen den Anwendungssystemen (101-103, 501-503) jeweils als Client-Server-Interaktion über den Verbindungsserver (20) erfolgt, dadurch gekennzeichnet, dassdurch ein Upload einer Datei auf dem Verbindungsserver (20) eine Funktion aktivierbar ist, mittels derer ermittelbar ist, an welche Anwendungssysteme die Datei verteilt werden soll.

Description

  • Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken (Intranets).
  • Für eine interne Kommunikation zwischen Anwendungssystemen eines Unternehmens sind Unternehmensnetze (Intranets) nutzbar. Bei einer unternehmensübergreifenden und/oder standortübergreifenden Kommunikation - beispielsweise im Rahmen der Abwicklung unternehmensübergreifender Geschäftsprozesse - besteht die Anforderung, Daten zwischen Anwendungssystemen verschiedener Unternehmensnetzwerke auszutauschen, um die Daten an unterschiedlichen Stellen zu verarbeiten und/oder zu analysieren. Anwendungssystem in diesem Sinne kann beispielsweise ein Marktplatz im B2X Umfeld sein, der mit Basisdaten versorgt wird. Der weltweite Datenaustausch gewinnt aufgrund der Globalisierung zunehmend an Bedeutung. Die Verbindung zwischen den Unternehmensnetzen erfolgt über das Internet.
  • Der Austausch von Daten zwischen Anwendungssystemen innerhalb eines Unternehmensnetzwerkes, kann bereits ohne größere Sicherheitsprobleme realisiert werden. Die Sicherheit eines Intranets ist unter anderem abhängig vom Aufwand der in eine Sicherheitssoftware, beispielsweise eine Firewall, investiert wurde. Firewalls verbinden Intranets mit dem Internet und schützen die Intranets vor nicht erlaubten Zugriffen aus dem Internet. Sie sind im Regelfall mit einer inneren und einer äußeren Firewall ausgebildet. Dazwischen liegt die „Demilitarisierte Zone“ (DMZ). Die Funktionen der inneren und äußeren Firewall und der Komponenten der DMZ wird durch die Firewall Policy und/oder Strategie bestimmt. Die Sicherheit des Intranets ist daher weiter abhängig von der Strategie mit der die Firewall oder eine andere Sicherheitssoftware betrieben wird. Die DMZ kann je nach Sicherheitsanforderungen verschieden aufwendig strukturiert werden. Sie kann beispielsweise eine Struktur Portal Zone, eine Application Zone und/oder eine Content Security Zone umfassen. Hat man beim Aufbau und der Strategie die notwendige Sorgfalt walten lassen, ist das Intranet relativ sicher.
  • Befinden sich die kommunizierenden Anwendungssysteme hingegen in unterschiedlichen Unternehmensnetzwerken, welche beispielsweise über das Internet Daten austauschen, ist eine starke Verschlüsselung der Daten und eine strenge Authentifikation der Anwendungssysteme erforderlich.
  • In die Geschäftsprozesse großer Unternehmen sind weltweit verteilte Firmen eingebunden. Sollen Anwendungssysteme, die in diesen Firmen betrieben werden, automatisch Daten miteinander austauschen, so muss der Aufwand für die Installation von Kommunikations-Software und die Investition in Kommunikations-Software gering gehalten werden, um effizient und wirtschaftlich zu bleiben.
  • Aus der US 2002 / 0 091 798 A1 ist eine gattungsgemäße Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken bekannt.
  • Aus KNUDSEN, J.: Java Cryptography. Ist Edition.Sebastopol: O'Reilly, 1998. - ISBN: 1-56592-402-9 ist bekannt, Java Applets in einer sogenannten Sandbox auszuführen, d.h. das Java Applet hat aus Sicherheitsgründen in der Regel keinen Zugriff auf das lokale Dateisystem des Host-Rechners, noch kann es Netzwerkverbindungen zu Rechnern außer dem Host-Rechner aufbauen, auf dem es ausgeführt wird.
  • Aus der WO 00/70 839 A2 ist ein System und ein Verfahren zum Sichern von Hosts eines Dienstanbieters bekannt, sodass ein unbefugter Zugriff von Hosts verhindert wird. Das System erfordert keine Installation einer speziellen Software auf den Terminals der Benutzer und ermöglicht es, die Hosts des Dienstanbieters logisch und physisch an geeigneten Stellen innerhalb des privaten Netzwerk des Dienstanbieters zu lokalisieren. Benutzer können sich überall in einem globalen öffentlichen, wie dem Internet, befinden. Das System verwendet einen ersten Server, der mit dem ersten Netzwerk verbunden ist, in dem der erste Server eine Sitzungsaufbauanforderung vom Benutzerendgerät empfängt und eine Verbindungsanforderung als Antwort auf die Sitzungsaufbauanforderung generiert. Ein zweiter Server, der mit dem ersten Server und dem zweiten Netzwerk verbunden ist, empfängt die Verbindungsanforderung und stellt die Kommunikation mit dem Host gemäß der Verbindungsanforderung her. Der zweite Server initiiert die Kommunikation, in dem er eine Kommunikationssteuersitzung mit dem ersten Server aufbaut, bevor der erste Server die Verbindungsanforderung an den zweiten Server sendet.
  • Aus RÖHRIG, Bernhard: Linux im Netz, C&L Verlag, Vaterstetten, 1997, Abschn. 15.3 (insbes., 15.3.3 u. 15.3.5) sind Sicherheitsstrukturen für Intranets mit Firewall und Proxy-Servern bekannt.
  • Der Erfindung liegt daher das technische Problem zugrunde, ein Verfahren und eine Vorrichtung zur verbesserten Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken (Intranets) zu schaffen.
  • Die Lösung des technischen Problems ergibt sich durch die Gegenstände mit den Merkmalen der Patentansprüche 1, 20, 37 und 38. Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den Unteransprüchen.
  • Hierzu ist zwischen einem internen und einem externen Unternehmensnetzwerk eine Netzinfrastruktur aufgebaut, die mindestens eine dem internen Unternehmensnetzwerk zugeordnete äußere und eine innere Firewall umfasst. Vorzugsweise ist zwischen dem internen Unternehmensnetzwerk und dem externen Unternehmensnetzwerk eine Netzinfrastruktur umfassend Firewall-Internet-Firewall aufgebaut, wobei jede Firewall mit innerer und äußerer Firewall ausgebildet ist. In einer demilitarisierten Zone zwischen der dem internen Unternehmensnetzwerk zugeordneten inneren und äußeren Firewall ist ein Verbindungsserver angeordnet und jedes der Unternehmensnetzwerke (Intranets) ist mit mindestens einem Client-Rechner ausgebildet, wobei einem Client-Rechner mindestens ein Anwendungssystem zugeordnet ist. Die Kommunikation zwischen den Anwendungssystemen erfolgt jeweils als unabhängige Client-Server-Kommunikation über den Verbindungsserver. Der Verbindungsserver trennt die Kommunikation in zwei entkoppelte Übertragungsstrecken auf, so dass die Verfügbarkeit des empfangenden Anwendungssystems für das sendende Anwendungssystem und umgekehrt ohne Bedeutung ist. Für die Übertragung logged sich ein Anwendungssystem des Client-Rechners auf den Verbindungsserver ein. Zwischen den Client-Rechnern und dem Verbindungsserver findet jeweils ein hochverschlüsselter Datentransfer statt. Anwendungssysteme sind derart ausgebildet, dass sie Kommunikationsanforderungen (Requests) formulieren können und Informationen über das Ergebnis der Datenübertragung und/oder des Datenverarbeitungsprozesses im empfangenden Anwendungssystem (Response) empfangen können. Die Verbindungsserver Funktionalität wird vorzugsweise auf einem Unix Rechner installiert.
  • Dabei wird nach dem Upload einer Datei auf dem Verbindungsserver eine Funktion aktiv, die feststellt, an welches oder an welche Anwendungssystem(e) die Datei übertragen werden soll. Für das/die entsprechende(n) Anwendungssystem(e) wird/werden dann ADRs - eingebettet in andere Stereotypen - in die zugehörigen, dynamisch erstellten Server Download Verzeichnisse gespeichert.
  • In einer bevorzugten Ausführungsform ist einem Anwendungssystem auf dem Client-Rechner eine Client-Kommunikationskomponente zugeordnet, wobei die Client-Kommunikationskomponenten dynamisch aufgebaut werden.
  • Für die Übertragung von Daten und/oder Dateien logged sich eine Einheit des Client-Rechners - umfassend „Client-Kommunikationskomponente und Anwendungssystem“ - auf den Verbindungsserver ein.
  • In einer bevorzugten Ausführungsform wird die gesamte Kommunikationssoftware zentral vom Verbindungsserver zur Verfügung gestellt. Das Anwendungssystem ist vorzugsweise auf einem Client-Rechner mit Browser installiert, der eine JAVA Virtual Machine unterstützt und/oder einmalig von zentraler Stelle eine JAVA Virtual Machine auf den Client Rechner herunter lädt. Über eine Browser Software kann dann ein Applet an den Client-Rechner des Anwendungssystems übertragen und auf diesem automatisch installiert werden. Dabei wird der Browser für die dynamische Integration des Clients in die Anwendungssystem Infrastruktur genutzt. Ein Teil dieser Funktionalität kann allerdings auch durch eine Java Runtime Umgebung herbeigeführt werden. Eine Erst-Installation wird über einen Browser gestützten Login Prozess durchgeführt. Ein Update der Kommunikationssoftware ist automatisch über den Login Prozess der Client-Kommunikationskomponente durchführbar. Neue Anwendungssysteme sind dadurch jederzeit in die Kommunikation integrierbar.
  • In einer weiteren Ausführungsform werden auf dem Verbindungsserver zu den einzelnen aktiven Einheiten „Anwendungssystem - Client-Kommunikationskomponente“ Server-Kommunikationskomponenten dynamisch aufgebaut.
  • In einer bevorzugten Ausführungsform umfasst eine Client-Kommunikationskomponente für die Kommunikation zum Anwendungssystem ein permanentes Verzeichnis, das im Browser gestützten Login Prozess angelegt wurde und für die Kommunikation zum Verbindungsserver ein Verzeichnis, das in der Initiierungsphase des Datenübertragungsprozesses dynamisch angelegt wird. Die Server-Kommunikationskomponente hat ihrerseits ein Verzeichnis für die Kommunikation zur Client-Kommunikationskomponente, das in der Initiierungsphase des Datenübertragungsprozesses dynamisch angelegt wurde. In diese Verzeichnisse ist mindestens je ein Stereotyp mit Kontrollinformationen speicherbar. Als Stereotypen werden in der objektorientierten Systementwicklung Datenschnittstellen bezeichnet. Über diese Stereotypen kommunizieren Anwendungssystem und Client-Kommunikationskomponente und/oder Client-Kommunikationskomponente und Server-Kommunikationskomponente miteinander.
  • Vorzugsweise generieren die Client-Kommunikationskomponente und/oder die Server-Kommunikationskomponente ihre zugehörigen Verzeichnisse dynamisch. In einem Verzeichnis der Client-Kommunikationskomponente ist beispielsweise der Stereotyp des Anwendungssystems mit den Übertragungsanforderungen (Dateiverzeichnis, Dateiname und Quellen- und Ziel-Anwendungssytem, ...) gespeichert. Die Übertragungsanforderung wird als AUR (Applicationsystem Upload Request) in der systeminternen Kommunikation bezeichnet.
    Ein einer bevorzugten Ausführungsform sind Stereotypen mit ihren Kontrollinformationen In einer bevorzugten Ausführungsform sind Stereotypen mit ihren Kontrollinformationen ineinander verschachtelt speicherbar (Enveloping). Gemäß der Envelope-Technik erweitern der Client-Rechner des sendenden und/oder des empfangenden Anwendungssystems und/oder der Verbindungsserver den Request des Anwendungssystems AUR entsprechend ihrer Bedürfnisse.
  • In einer bevorzugten Ausführungsform umfasst die Einheit „Anwendungssystem - Client-Kommunikationskomponente“ und/oder die Server-Kommunikationskomponente mindestens ein Datei-Verzeichnis und ein Control-Verzeichnis. In das Datei-Verzeichnis kann das Anwendungssystem beispielsweise zu übertragende Dateien einstellen. Die Control-Verzeichnisse dienen der Kommunikation und Steuerung zwischen den Anwendungssystemen, den Client-Kommunikationskomponenten und den Server-Kommunikationskomponenten und damit der Kommunikation und Steuerung der Anwendungssysteme untereinander. Die Server-Kommunikationskomponenten werden alle gleich strukturiert, d.h., die Statusschnittstellen der verschiedenen Server-Kommunikationskomponenten werden dynamisch gleich aktualisiert. Daneben ist es denkbar, in einem Status-Verzeichnis Informationen über die Datenübertragung zu sammeln, die z.B. zu Abrechnungszwecken genutzt werden können.
  • Die Client-Kommunikationskomponente, beispielsweise das Applet und die Verzeichnisse, und/oder die Server-Kommunikationskomponente, beispielsweise ein Servlet und den Anwendungssystemen zugeordnete Verzeichnisse, werden vorzugsweise dynamisch aufgebaut. Sie existieren somit zu Beginn des Kommunikationsprozesses nicht. Sie werden auf dem Client Rechner - vorzugsweise einmalig initiiert durch einen Login Prozess - dynamisch in die Anwendungssystem - Infrastruktur integriert und auf dem Server Rechner - vorzugsweise initiiert durch einen Upload- Download- Datenübertragungsprozess - erstellt.
  • In einer bevorzugten Ausführungsform ist ein LDAP-Server vorgesehen, auf dem für die einzelnen Anwendungssysteme Identifier mit zugehörigen Passwörtern abgelegt sind. LDAP (Lightweight Directory Access Protocol) ist eine funktionell reduzierte Version des in iTU-T X.500 spezifizierten DAP für den einfachen Zugang zu Verzeichnisdiensten über TCP/iP-Netze.
  • In einer weiteren bevorzugten Ausführungsform ist auf dem LDAP-Server ein Policy Director installiert, in dem die Passwörter gespeichert sind und eine Authentisierungsprüfung für jedes Anwendungssystem durchgeführt wird.
  • In einer weiteren bevorzugten Ausführungsform wird zur Kommunikation mit verschiedenen externen Unternehmensnetzwerken jedem externen Unternehmensnetzwerk jeweils ein eigener Verbindungsserver zugeordnet.
  • Es ist denkbar, einen zentralen LDAP-Server zu verwenden, der mit den verschiedenen Verbindungsservern verbunden ist. Vorzugsweise werden jedoch aufgrund organisatorischer Probleme mehrere LDAP-Server eingesetzt.
  • Auf dem oder den LDAP-Server(n) werden zu den Identifiern der Anwendungssysteme Attribute abgelegt, in denen die zugehörige Adresse des externen Kommunikations Servers gespeichert ist, über die ein externes Anwendungssystem erreichbar ist.
  • Zum automatischen Dateitransfer von einem Anwendungssystem an den Verbindungsserver (Upload) stellt das Anwendungssystem eine Datei zum Upload vorzugsweise in sein Upload-Datei-Verzeichnis, und in Verbindung mit der Datei wird ein Applicationssytem Upload-Request (AUR) vorzugsweise in das Upload-Control-Verzeichnis geschrieben, wobei der Inhalt des AUR mindestens das Verzeichnis und/oder der Name der zu übertragenden Datei, die Origin ASID (Application System ID) und/oder mindestens eine Destination ASID eines empfangenden Anwendungssystems, zu dem die Datei übertragen werden soll, ist. Die Identifikation einer Datei kann beispielsweise durch ihr Verzeichnis, ihren Namen, ihren Datei Typ und durch die ASID des erstellenden Anwendungssystems erfolgen. Darüber hinaus sind zusätzliche Informationen wie Zeitpunkt der Erstellung, Größe der Datei etc. denkbar.
  • In einem weiteren Schritt wird mittels einer Upload-Funktion des Client-Rechners des Daten sendenden Anwendungssystems von der Client-Kommunikationskomponente, vorzugsweise das entsprechende Control-Verzeichnis gescanned und der AUR gelesen, eine Verbindung zum Verbindungsserver aufgebaut und die Datei von der Client-Kommunikations-komponente, vorzugsweise dem entsprechenden Datei-Verzeichnis an den Verbindungsserver übertragen. Die Datei wurde vorzugsweise zuvor komprimiert und/oder für die Übertragung in Unterdateien gesplittet, die zeitparallel übertragen werden. Bei Abbruch der Übertragung wird automatisch festgestellt wie viele Unterdateien richtig übertragen wurden. Mit den noch nicht übertragenen Unterdateien wird die Übertragung wieder aufgesetzt. Die Übertragung der Dateien erfolgt bevorzugt mit dem Datentransportprotokoll https.
  • Zum automatischen Dateitransfer von der Server-Kommunikationskomponente über die Client-Kommunikationskomponente an das empfangende Anwendungssystem (Download) wird auf dem Server Rechner ein Download Verzeichnis erstellt, in dem eingebettet in andere Stereotypen ein Applicationsystem Download-Request (ADR) gespeichert wird. Über die Downloadfunktion der Client-Kommunikationskomponente des empfangenden Anwendungssystems wird dieses Verzeichnis gescanned und so der ADR erkannt.
  • Daraufhin wird für die Dateiübertragung eine Verbindung von der Client-Kommunikationskomponente zur Server-Kommunikationskomponente aufgebaut und die Datei auf den Client-Rechner übertragen. Dabei wird der Stereotyp ADR in das von der Client-Kommunikationskomponente dynamisch erstellte Client- Download Verzeichnis geschrieben.
  • In einem weiteren Schritt wird das Anwendungssystem automatisch aktiviert und liest den ADR Stereotypen, aus dem Dwonload Verzeichnis und beginnt mit der Verarbeitung der übertragenen Datei deren Verzeichnis- und Dateiname aus dem ADR entnommen wurde.
  • In einer weiteren bevorzugten Ausführungsform wird bei einem Abbruch der Client-Server-Verbindung die Verbindung automatisch wieder aufgebaut. Es wird verfahren wie im Datei Upload Prozess mit dem Unterschied, dass die aus den Unterdateien zusammengesetzte Datei expandiert wird.
  • In einer bevorzugten Ausführungsform ist zu einem vom Anwendungssystem generierten Application System Upload Request (AUR) - der einen Dateiübertragungsprozess initiiert - ein - durch das Anwendungssystem festgelegtes - Verfallsdatum zugeordnet. Das Verfallsdatum bezieht sich auf alle Verzeichnisse und Dateien, die Client- und Serverseitig - initiiert durch den Dateiübertragungsprozess - dynamisch angelegt wurden. Diese Ressourcen werden nach Ablauf des Verfallsdatums automatisch gelöscht.
  • Daneben ist es auch denkbar, dass die Verzeichnisse und/oder Dateien nach abgeschlossener Übertragung der Daten gelöscht werden.
  • Mit dem dynamischen Aufbau der Kommunikationsinfrastruktur
    • - automatisches herunterladen der Upload- und Download- Client-Kommunikationskomponenten auf die Client-Rechner
    • - automatisches Generieren der Verzeichnisinfrastruktur - auf die Anwendungssystem und Client-Kommunikationskomponente - gemeinsam zugreifen, um Stereotypen zu speichern oder zu lesen
    integrieren sich die Client-Kommunikationskomponenten automatisch in die Anwendungssystem Infrastruktur.
  • Die Erfindung wird nachfolgend anhand eines bevorzugten Ausführungsbeispiels näher erläutert. Die einzige Fig. zeigt:
    • 1 ein schematisches Blockschaltbild einer Vorrichtung zur Kommunikation zwischen Anwendungssystemen in verschiedenen Netzwerken.
  • Das Gesamtsystem umfasst im wesentlichen fünf Bereiche, nämlich ein internes Unternehmensnetzwerk (Intranet) 1, ein externes Unternehmensnetzwerk 5, eine dem internen Unternehmensnetzwerk 1 zugeordnete demilitarisierte Zone 2, das Internet 3 und eine dem externen Unternehmensnetzwerk 5 zugeordnete demilitarisierte Zone 4. Zwischen der demilitarisierten Zone 2 und dem Internet 3 ist eine äußere Firewall 202 und zwischen der demilitarisierten Zone 2 und dem Intranet 1 ist eine innere Firewall 201 aufgebaut. Zwischen der inneren Firewall 201 und der äußeren Firewall 202 sind ein Verbindungsserver 20 und ein LDAP-Server 21 angeordnet. Zur Abwicklung eines oder mehrerer Geschäftsprozesse werden interne Anwendungssysteme 101-103 sowie externe Anwendungssysteme 501-503 eingesetzt. Bei den Geschäftsprozessen handelt es sich beispielsweise um Geschäftsprozesse des B2X, aber auch jede andere Art von Prozessen ist denkbar. Die Anwendungssysteme 101-103 des Intranets 1 laufen beispielsweise auf einem gemeinsamen Rechner ab. Dieser Rechner ist gleichzeitig Client-Rechner 10 für die Kommunikation mit dem Verbindungsserver 20. Daneben ist es denkbar, dass die Anwendungssysteme 101-103 mit je einer Client-Kommunikationskomponente versehen auf unterschiedlichen Rechnern laufen.
  • Auf dem Client-Rechner 10 ist ein nicht dargestellter Browser installiert, welcher beispielsweise eine JAVA Virtual Machine unterstützt. Für eine Kommunikation mit dem Verbindungsserver 20 sind auf dem Client-Rechner 10 spezielle Client-Kommunikationskomponenten 1011, 1021, 1031 dynamisch aufbaubar oder fest installierbar. Für jedes Anwendungssystem 101, 102, 103, welches dem Client-Rechner 10 zugeordnet ist, ist vorzugsweise eine eigene Client-Kommunikationskomponente 1011, 1021, 1031 vorhanden. In dem externen Unternehmensnetzwerk 5 ist mindestens ein externer Client-Rechner 50 angeordnet. Dem Client-Rechner 50 sind die Anwendungssysteme 501, 502, 503 zugeordnet. Dabei können die Anwendungssysteme 501-503 des externen Unternehmensnetzwerks 5 ebenfalls auf einem gemeinsamen Rechner und/oder getrennten Rechnern ablaufen. Das externe Unternehmensnetzwerk 5 kann außerdem ebenfalls als Intranet ausgebildet sein und ist vorzugsweise auch durch eine Sicherungssoftware, bestehend aus einer äußeren Firewall 402 und einer inneren Firewall 401 gegen unerlaubte Zugriffe aus dem Internet 3 geschützt. Weiter ist dem Client-Rechner 50 ein nicht dargestellter Browser zugeordnet und für jedes Anwendungssystem 501, 502, 503 ist eine Client-Kommunikationskomponente 5011, 5021, 5031 für eine Kommunikation aufbaubar. Vorzugsweise ist auf dem Verbindungsserver 20 für jede adressierbare Einheit bestehend aus einem Anwendungssystem 101-103, 501-503 und einer Client-Kommunikationskomponente 1011-1031, 5011-5031 eine zugehörige Server-Kommunikationskomponente 2101-2103, 2501 - 2503 aufgebaut.
  • Die Kommunikation zwischen dem Anwendungssystem 101 im Intranet 1 und dem Anwendungssystem 501 im externen Unternehmensnetzwerk 5 wird in zwei voneinander entkoppelte Client-Server-Interaktionen aufgespalten, nämlich zwischen einem dem Anwendungssystem 101 zugeordneten Client-Rechner 10 und dem Verbindungsserver 20 und einem dem Anwendungssystem 501 zugeordneten Client-Rechner 50 und dem Verbindungsserver 20. Die Kommunikation erfolgt über die entsprechenden Client- und Server-Kommunikationskomponenten. Unter Client-Server-Interaktion wird dabei allgemein die Art und Weise der Zusammenarbeit gemäß vereinbarter Regeln zwischen einem Client-Rechner und einem Server zur Lösung einer Aufgabe in einem Client-Server-System verstanden. Zwischen der Client-Kommunikationskomponente und der Kommunikationskomponente des Verbindungsservers findet ein hoch verschlüsselter Datentransfer statt, der vorzugsweise auf dem https-Protokoll basiert. Der Datentransfer zwischen Client-Kommunikationskomponente und Anwendungssystem erfolgt unverschlüsselt über eine Schnittstelle (Stereotyp).
  • Das System arbeitet vorzugsweise mit der signed Applet Technologie. Dadurch können die Client-Kommunikationskomponenten 1011, 1021, 1031, 5011, 5021, 5031 automatisch in die Anwendungssysteminfrastruktur integriert werden.
  • Für die automatische Integration jeder Client-Kommunikationskomponente wird einmalig über einen Browser Dialog mit dem Verbindungsserver 20 die Gültigkeit eines anwendungssystembezogenen Accounts verifiziert. Dieser Account wird von einem zentralen Verwaltungssystem vergeben und steht in der Datenbasis des LDAP Servers 21. In den Browser werden ASID (Application System Identification) und Password eingegeben. Der Browser authentifiziert sich mit dieser Eingabe via Verbindungsserver gegen die Datenbasis des LDAP Servers 21.
  • Bei der Nutzung von Client-Server-Zertifikaten kann der einmalige Browser Dialog entfallen. In diesem Fall steht der Account zur Authentifikation der Einheit „Anwendungssystem - Client-Kommunikationskomponente“ in einem Client Init File. Die Authentifikation des Browsers gegenüber dem Verbindungsserver und des Verbindungsservers gegenüber dem Browser erfolgt über die Zertifikate.
  • Bei Gültigkeit des Accounts sendet der Verbindungsserver 20 eine HTML Seite mit „Tags“ an den Browser zurück. In den „Tags“ steht, woher Module mit bestimmten Funktionen geladen werden.
  • Die Module sind: die Java Virtul Machine (JVM), das Init Applet, das Applet „Client-Kommunikationskomponente“ und/oder mögliche Plugins. Die JVM und das Init Applet werden über den Browser geladen und aktiviert. Das Init Applet stellt fest, ob die Infrastruktur zum Starten des Datentransfers zwischen den Anwendungssystemen (Start Icon) vorhanden ist und ob das Applet „Client-Kommunikationskomponente“ 1011, 1021, 1031 auf dem Client Rechner 10 existiert und wenn es existiert, ob die aktuelle Version vorliegt. Ist das nicht der Fall, werden der Start Icon automatisch installiert und das Applet geladen und aktiviert. Das Applet initiiert eine Session zum Verbindungsserver 20 und erhält in dieser Session seine Identität vom Verbindungsserver 20. Dem Applet wird hier seine ASID zugeordnet. Mit dieser ASID authentifiziert sich die Client-Kommunikationskomponente 1011, 1021, 1031 bei zukünftigen File Transfer Prozessen gegenüber dem Verbindungsserver.
  • Die Client-Kommunikationskomponente 1011, 1021, 1031 sieht nach, ob die Upload- und Download- Verzeichnisinfrastruktur existiert, wenn nicht wird sie nach einem definierten Algorithmus generiert. Über diese Verzeichnisinfrastruktur kommunizieren Anwendungssystem 101, 102, 103 und Client-Kommunikationskomponente 1011, 1021, 1031. Anwendungssystem 101, 102, 103 und Client-Kommunikationskomponente 1011, 1021, 1031 bilden jetzt eine über die ASID adressierbare Einheit.
  • Damit ist die Integration der Client-Kommunikationskomponente in die Anwendungssystem Infrastruktur abgeschlossen.
  • Beim Starten des Kommunikationsprozesses über den Start Icon befinden sich auf dem Client Rechner 10, 50 eine Java Virtual Machine, die Client-Initial-Komponente, die Client- Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 und gegebenenfalls Plugins. Die JVM ist aktiv. Die Client-Initial- Komponente wird durch klicken des Start Icons aktiviert. Sie baut mit der ASID aus dem Start Icon eine Session zum Verbindungsserver 20 auf und holt sich das aktuelle Release der Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 und der möglichen Plugins. Sind die Releases der Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 und der möglichen Plugins nicht aktuell, so werden die aktuellen Applets vom Verbindungsserver 20 geladen. Die bestehende Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 und die möglichen Plugins werden upgedated. Die Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 wird aktiviert und prüft, ob die Upload- und Download Verzeichnisse vorhanden sind. Wurden sie durch nicht erlaubte Maßnahmen gelöscht, werden sie automatisch nachgeneriert.
  • Das Anwendungssystem 101, 102, 103, 501, 502, 503 und die Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 speichern ihre Schnittstellen (Stereotypen) in den generierten Verzeichnissen und/oder lesen diese Stereotypen. Mit der ASID authentifiziert sich die Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 gegenüber dem Verbindungsserver 20.
  • Durch eine Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 ist dabei mindestens ein Datei-Verzeichnis und mindestens ein Control-Verzeichnis erzeugbar, die mit der Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 assoziiert sind. Bevorzugt werden für Upload und Download jeweils ein Datei-Verzeichnis und ein Control-Verzeichnis erzeugt. Nach dem Ende eines Datenübertragungsprozesses können die mit diesem Prozess assoziierten Verzeichnisse auf den Rechnern 10, 20 und/oder 50 wieder gelöscht werden. Es können aber auch von den Anwendungssystemen Zeiten vorgegeben werden, zu denen das Löschen automatisch erfolgt.
  • Für einen dynamischen Aufbau einer Client-Kommunikationskomponente 1011, 1021, 1031, 5011, 5021, 5031 ist keine spezielle Kommunikationssoftware in Verbindung mit dem Anwendungssystem 101-103, 501-503 notwendig. Daher kann jedes berechtigte Anwendungssystem jederzeit in die Kommunikation eingebunden werden. Gleichzeitig sind verwendete Programme schnell und einfach aktualisierbar. Dabei müssen nur hinsichtlich der verwendeten Browser gewisse Abstimmungen getroffen werden.
  • Für Anwendungssysteme auf einem Rechner ohne Browser oder Java runtime Umgebung ist kein dynamischer Client-Aufbau durch ein Applet denkbar. Derartige Anwendungssysteme können über einen NFS-Rechner mit einem Client-Rechner verbunden werden. Aus Sicherheitsaspekten ist ein dynamischer Aufbau der Client-Kommunikationskomponenten auf dem Client-Rechner des Anwendungssystems jedoch zu bevorzugen.
  • Prinzipiell kann alternativ oder kumulativ zu der signed Applet Technologie ein Programm mit Installations-Skript zur Verfügung gestellt werden, das vom Verbindungsserver 20 herunter geladen und installiert werden kann. Das Programm hat dabei die Funktionalität des Applets.
  • Der Datentransfer lässt sich in folgende Schritte unterteilen:
  • Das Anwendungssystem 101 mit einer ASID „ASID1“, welches eine Datei an das Anwendungssystem 501 mit einer ASID „ASID2“ übertragen möchte, generiert einen Applicationsystem Upload Request (AUR). Dem AUR ist mindestens das Ziel-Anwendungssystem 501 und eine Kennung der zu übertragenden Datei zu entnehmen. Gemäß der Envelope-Technik erweitern der Client-Rechner 10 des sendenden Anwendungssystems 101 und der Verbindungsserver 20 den Request AUR des Anwendungssystems 101 entsprechend ihrer Bedürfnisse.
  • Der AUR wird durch die Client-Kommunikationskomponente 1011 auf Richtigkeit überprüft. Außerdem wird ein Client Upload Response (CURES) generiert und an das Anwendungssystem 101 zurückgeschickt. Besteht Richtigkeit, wird ein Client Upload Request (CUR) erstellt und der AUR wird in den CUR eingebettet CUR(AUR). Der CUR(AUR) wird von der Client-Kommunikationskomponente 1011 gelesen. Die Client-Kommunikationskomponente 1011 prüft, ob eine Session zwischen der Client-Kommunikationskomponente 1011 und dem Verbindungsserver 20 besteht. Ist das nicht der Fall, wird eine Session aufgebaut. Der Verbindungsserver 20 generiert eine Unique Communication Id (COMID). Mit der ASID1 des Anwendungssytems 101 und dieser COMID werden client- und serverseitig eindeutige übertragungsspezifische Verzeichnisse erstellt.
  • Die Client-Kommunikationskomponente 1011 baut einen Stereotypen zum Speichern der Client Session Kontrolldaten auf, das sogenannte Client Upload Communication Interface (CUCI). In den Stereotypen CUCI werden CUR(AUR) eingebettet. Es entsteht der Stereotyp CUCI(CUR(AUR)), der im dynamisch generierten Client Verzeichnis gespeichert wird.
  • Auf dem Verbindungsserver 20 generiert eine Server-Kommunikationskomponente 2101 ein Server Upload Communication Interface (SUCI) zum Speichern der Server Session Kontrolldaten. In den Stereotypen SUCI werden CUCI(CUR(AUR)) eingebettet. Es entsteht der Stereotyp SUCI(CUCI(CUR(AUR))) der im dynamisch generierten Server Verzeichnis gespeichert wird.
  • Die Client-Kommunikationskomponeten 1011 startet den Datei Upload Prozess. Alle Daten der Upload Session werden in den Stereotypen des Client Rechners 10 und den Stereotypen des Verbindungsservers 20 gespeichert. Nach dem Upload der Datei wird ein Server Upload Response generiert und an das Anwendungssystem 101 zurückgeschickt.
  • Ein Servlet mit Verteilungs-Funktionalität prüft in bestimmten Zeitzyklen ob ein aktiver Stereotyp SUCI(CUCI(CUR(AUR))) auf dem Verbindungsserver 20 existiert. Liegt ein derartiger aktiver Stereotyp vor, so wird der ursprüngliche Request AUR ausgelesen. Dem AUR ist zu entnehmen, an wie viele Ziel-Anwendungssysteme die Datei zu übertragen ist. Für jedes Ziel-Anwendungssystem wird ein Download Verzeichnis aus ASID, COMID und Name erstellt. Pro Verzeichnis wird ein aktiver Stereotyp der Struktur SDCI(CDCI(CDR(ADR))) generiert. Hier werden Server- und Client- Session Kontrolldaten des Download Prozesses gespeichert. Der Stereotyp AUR wird mit der entsprechenden ASID in den ADR Stereotypen kopiert. Der Stereotyp SUCI(CUCI(CUR(AUR))) wird inaktiviert.
  • Für die Übertragung an das Anwendungssystem 501 wird auf dem Verbindungsserver 20 ein Stereotyp, welcher dem Anwendungssystem 501 zugeordnet ist, aktualisiert. Die Client-Kommunikationskomponente 5011 des Anwendungssystems logged sich in bestimmten Zeitzyklen in den Verbindungsserver 20 ein und stellt fest, ob ein aktiver Stereotyp der Struktur SDCI(CDCI(CDR(ADR))) für die eigene ASID - Destination ASID - generiert wurde.
  • Wird ein entsprechender Request erkannt, so baut die Client-Kommunikationskomponente 5011 eine Verbindung zum Verbindungsserver 20 auf und lädt den Request auf den Client-Rechner 50 herunter. Gemäß der ASID und der COMID wird auf dem Client Rechner ein Verzeichnis generiert, in das der Stereotyp CDCI(CDR(ADR)) gespeichert wird. Der File Download Prozess wird initiiert. Die Daten der Download Session werden auf dem Verbindungsserver 20 und Client Rechner 50 in den entsprechenden Stereotypen gespeichert. Nach dem erfolgreichen Download der Datei wird ein Client Download Response (CDRES) generiert und an das Anwendungssystem 101 zurückgeschickt.
  • Die Client-Kommunikationskomponente 5011 des Download Prozesses schreibt den aktiven Stereotypen ADR in das gemeinsame Verzeichnis von Client-Kommunikationskomponente 5011 und Anwendungssystem 501. Ein Plugin liest den Stereotypen ADR und aktiviert das Anwendungssystem. Das Anwendungssystem 501 liest den ADR und inaktiviert ihn. Das Anwendungssystem 501 informiert sich aus dem AUR, welche Datei zur Verarbeitung bereit steht und verarbeitet diese.
  • Das Ergebnis der Verarbeitung wird im Application Download Response (ADRES) gespeichert und im Response Transferprozess an das Anwendungssystem 101 übertragen und dort ausgewertet.
  • Erfolgt ein Abbruch der Client-Server-Verbindung, so ist es denkbar, dass die Verbindung automatisch neu gestartet wird. Dazu wird festgestellt, wie viel Übertragungen zum Zeitpunkt des Abbruchs innerhalb der Verbindung aktiv waren. Von den aktiven empfangenen Dateien wird der Bytecount an den oder die Sender, d.h. entweder den Client-Rechner für einen Upload oder den Verbindungsserver bei einem Download, übermittelt. Die Sender stellen die zu sendenden Dateien auf diese Counts ein und aktivieren die Verbindung.
  • Eine weitere Funktion auf dem Verbindungsserver 20, die vom Anwendungssystem über den Application Upload Request (AUR) initiierbar und/oder steuerbar ist, prüft in der Initiierungsphase eines Application Upload Requests (AURs), ob alle im AUR definierten ASIDs externer, empfangender Anwendungssysteme 501-503 auf dem LDAP-Server definiert worden sind. Ist das nicht der Fall, wird dem Anwendungssystem 101 zurückgemeldet, welche ASIDs bisher auf dem LDAP Server noch nicht definiert worden sind. Der Upload der Datei wird nicht durchgeführt.
  • Wurde diese Funktion vom Anwendungssystem 101 im AUR nicht aktiviert, so erfolgt vorzugsweise ein Upload der Datei auf den Verbindungsserver 20 unabhängig davon, ob die Datei komplett an alle Anwendungssysteme 501 - 503 verteilt werden kann. Noch nicht im LDAP Server definierten Anwendungssysteme 501 - 503 können nachdefiniert werden.
  • Wurden im AUR empfangende Anwendungssysteme 501 - 503 nicht komplett aufgeführt, so können die fehlenden Anwendungssysteme unter Angabe des selben AUR-IDs nachgereicht werden.
  • Die Übertragungsstrecke zwischen zwei Anwendungssystemen 101 - 103, 501 - 503 ist hinsichtlich der Datentransferaktivitäten transparent - sowohl für den Beobachter auf der Sendeseite als auch für den Beobachter auf der Empfangsseite. Jedes Ereignis auf dieser Strecke (Bereitstellung des Files, Start und Ende Komprimierung, Start und Ende der Session, ...) wird vorzugsweise mit einem Timestamp versehen. Diese Informationen sind dann Bestandteil der Stereotypen und können über eine https Browser Session zum Verbindungsserver 20 über einen speziellen Account ausgelesen werden.
  • Für die Übertragung wird eine Datei vorzugsweise komprimiert und Unterdateien gesplittet. Die erzeugten Unterdateien werden zeitparallel zwischen Client-Rechner 10, 50 zum Verbindungsserver 20 übertragen und auf den empfangenden Rechnern in der richtigen Sequenz wieder zusammengesetzt. Pro Subfile wird ein Thread zwischen Client-Kommunikationskomponente und Server-Kommunikationskomponente aufgebaut. Jedes übertragene Subfile wird nach Standardalgorithmen auf richtige Übertragung überprüft. Bei fehlerhafter Übertragung wird die Übertragung des Subfiles wiederholt. Im Falle eines Session Abbruchs, wird die Session automatisch wieder aufgebaut. Danach werden die noch nicht übertragenen Subfiles übertragen. Erst wenn alle Subfiles richtig übertragen und zu einer Datei zusammengesetzt worden sind, wird ein weiteres Servlet aktiv, das die Verteilung der upgeloadeten Datei auf ein oder mehrere empfangende Anwendungssysteme durchführt.
  • Es ist denkbar, die Verzeichnisstriktur mit einem Datei-Verzeichnis, einem Control-Verzeichnis und einem Status-Verzeichnis auszubilden. In das Datei-Verzeichnis werden Dateien für eine Übertragung und/oder empfangenen Dateien abgelegt. Das Datei-Verzeichnis ist mindestens durch das zugehörige Anwendungssystem 101-103, 501-503 zugänglich. Teilweise kann weiter ein Zugriff durch andere Programme des zugehörigen Client-Rechners 10, 50 sinnvoll sein. Das Datei-Verzeichnis ist gegen einen unberechtigten Zugriff geschützt. Ein Request für einen Upload oder einen Download einer im Datei-Verzeichnis abgelegten Datei wird in das Control-Verzeichnis geschrieben. Informationen über den Verlauf der Übertragung, beispielsweise eine Antwort des Verbindungsservers auf erfolgreichen Upload oder Fehlermeldungen werden in das Status-Verzeichnis geschrieben. Je nach Detaillierungsgrad eines Requests ist ein Schutz des Control-Verzeichnisses gegen unberechtigten Zugriff notwendig. Das Status-Verzeichnis unterliegt in der Regel keinen Sicherheitsvorkehrungen.

Claims (38)

  1. Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmesnetzwerken, wobei mindestens ein Anwendungssystem in einem internen Unternehmensnetzwerk und mindestens ein Anwendungssystem in einem externen Unternehmensnetzwerk eingebunden ist, mindestens dem internen Unternehmensnetzwerk eine Firewall zugeordnet ist und die Firewall mindestens eine innere und äußere Firewall umfasst, wobei in einer demilitarisierten Zone DMZ (2) zwischen der inneren und äußeren Firewall (201, 202) ein Verbindungsserver (20) angeordnet ist und die Unternehmensnetzwerke (1, 5) mit jeweils mindestens einem Client-Rechner (10, 50) ausgebildet sind, einem Client-Rechner (10, 50) mindestens ein Anwendungssystem (101-103, 501-503) zugeordnet ist, und die Kommunikation zwischen den Anwendungssystemen (101-103, 501-503) jeweils als Client-Server-Interaktion über den Verbindungsserver (20) erfolgt, dadurch gekennzeichnet, dass durch ein Upload einer Datei auf dem Verbindungsserver (20) eine Funktion aktivierbar ist, mittels derer ermittelbar ist, an welche Anwendungssysteme die Datei verteilt werden soll.
  2. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass mindestens einem Anwendungssystem (101-103, 501-503) auf dem Client-Rechner (10, 50) eine Client-Kommunikationskomponente (1011-1031, 5011-5031) zugeordnet ist, wobei die Client-Kommunikationskomponente (1011-1031, 5011-5031) dynamisch aufbaubar ist.
  3. Vorrichtung nach Anspruch 2, dadurch gekennzeichnet, dass eine Kommunikationssoftware umfassend mindestens die Client-Kommunikationskomponente (1011-1031, 5011-5031) von dem Verbindungsserver (20) an den Client-Rechner (10, 50) downloadbar ist.
  4. Vorrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass auf dem Verbindungsserver (20) zu den einzelnen Client-Kommunikationskomponenten (1011-1031, 5011-5031) Server-Kommunikationskomponenten (2101-2103, 2501-2503) dynamisch aufbaubar sind.
  5. Vorrichtung nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass eine Client-Kommunikationskomponente (1011-1031, 5011-5031) und/oder eine Server-Kommunikationskomponente (2101-2103, 2501-2503) mindestens je ein dynamisch erstelltes Verzeichnis umfasst, in dem mindestens ein Stereotyp mit Kontrollinformationen speicherbar ist.
  6. Vorrichtung nach Anspruch 5, dadurch gekennzeichnet, dass Stereotypen mit Kontrollinformationen ineinander verschachtelt speicherbar sind.
  7. Vorrichtung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Vorrichtung einen LDAP-Server (21) umfasst, auf dem für die einzelnen Anwendungssysteme (101-103, 501-503) Identifier mit zugehörigen Passwords abgelegt sind.
  8. Vorrichtung nach Anspruch 7, dadurch gekennzeichnet, dass auf dem LDAP-Server (21) ein Policy Director installiert ist.
  9. Vorrichtung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass verschiedenen externen Unternehmensnetzwerken (5) jeweils ein eigener Verbindungsserver (20) mit Firewall (201, 202) zugeordnet ist.
  10. Vorrichtung nach Anspruch 9, dadurch gekennzeichnet, dass die verschiedenen Verbindungsserver (20) mit mindestens einem LDAP-Server (21) verbunden sind, wobei auf dem mindestens einen LDAP-Server (21) zu den Identifiern Attribute abgelegt sind, in denen das zugehörige Unternehmensnetzwerk (5) eines Anwendungssystems (501-503) abgelegt ist.
  11. Vorrichtung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass zum automatischen Dateitransfer von einem sendenden Anwendungssystem (101) an den Verbindungsserver (20) eine Datei zum Upload bereit gestellt wird und in Verbindung mit dieser Datei ein Upload-Request in das permanente Verzeichnis der Client-Kommunikationskomponente (1011) geschrieben wird, wobei der Inhalt des Upload-Requests mindestens eine Kennung der zu übertragenden Datei und eine Identifikation des Anwendungssystems (501) beinhaltet, zu dem die Datei übertragen werden soll.
  12. Vorrichtung nach Anspruch 11, dadurch gekennzeichnet, dass mittels einer Upload-Funktion des Client-Rechners des sendenden Anwendungssystems (101) die Client-Kommunikationskomponente (1011) das Verzeichnis scanned und der Upload-Request lesbar ist, eine Verbindung zum Verbindungsserver (20) aufbaubar und die Datei an den Verbindungsserver (20) übertragbar ist.
  13. Vorrichtung nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass zum automatischen Dateitransfer vom Verbindungsserver (20) an ein empfangendes Anwendungssystem (501) eine dem Anwendungssystem (501) zugeordnete Server-Kommunikationskomponente (2501) ein Download-Request generiert, über eine Downloadfunktion des Client-Rechners des empfangenden Anwendungssystems (501) das dynamisch erstellte Verzeichnis der Server-Kommunikationskomponente (2501) scannbar und der Download-Request erkennbar ist, eine Verbindung für den Download der Datei zum Verbindungsserver (20) aufbaubar und die Datei an die Client-Kommunikationskomponente (5011) des dem Anwendungssystems (501) zugeordneten Client-Rechners (50) übertragbar ist und ein Request in das Download Verzeichnis der Client-Kommunikationskomponente (5011) schreibbar ist.
  14. Vorrichtung nach Anspruch 13, dadurch gekennzeichnet, dass ein Plugin das Download Verzeichnis liest und das Anwendungssystem (501) aktiviert.
  15. Vorrichtung nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass das empfangende Anwendungssystem (501) des Client-Rechners (50) das Verzeichnis der Client-Kommunikationskomponente (5011) scanned, den Request ausliest und die empfangene Datei verarbeitet.
  16. Vorrichtung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass bei Abbruch einer Verbindung zwischen Client-Rechner (10, 50) und Verbindungsserver (20) ein automatischer Neuaufbau der Verbindung herstellbar ist.
  17. Vorrichtung nach Anspruch 16, dadurch gekennzeichnet, dass die Anzahl der beim Abbruch aktiven Übertragungen ermittelbar ist und von den aktiven empfangenen Dateien ein Bytecount an die Sender übertragbar ist, wobei durch die Sender die Counts der zu sendenden Dateien auf das übertragene Bytecount einstellbar und die Übertragung aktivierbar ist.
  18. Vorrichtung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass das sendende Anwendungssystem (101) über Responses (CURES, SURES, CDRES, ADRES) von Ereignissen aus dem Dateiübertragungsprozess und/oder aus dem Dateiverarbeitungsprozess informiert wird und diese auswerten kann.
  19. Vorrichtung nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die zu übertragenden Dateien und die zugehörigen, dynamisch erstellten Verzeichnisse, auf den Rechnern (10) (20) (50) speicherbar sind, wobei den Dateien und Verzeichnissen durch das sendende Anwendungssystem ein Verfallsdatum zugeordnet sein kann.
  20. Verfahren zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken, wobei mindestens ein Anwendungssystem in einem internen Unternehmensnetzwerk und mindestens ein Anwendungssystem in einem externen Unternehmensnetzwerk eingebunden ist, mindestens dem internen Unternehmensnetzwerk eine Firewall zugeordnet ist und die Firewall mindestens eine innere und äußere Firewall umfasst, wobei die Kommunikation zwischen den Anwendungssystemen (101-103, 501-503) jeweils als Client-Server-Interaktion über einen Verbindungsserver (20) erfolgt, wobei der Verbindungsserver (20) in einer demilitarisierten Zone DMZ (2) zwischen der inneren und äußeren Firewall (201, 202) angeordnet ist, die Unternehmensnetzwerke (1, 5) jeweils mit mindestens einem Client-Rechner (10, 50) ausgebildet sind und einem Client-Rechner (10, 50) mindestens ein Anwendungssystem (101-103, 501-503) zugeordnet ist, dadurch gekennzeichnet, dass durch ein Upload einer Datei auf dem Verbindungsserver (20) eine Funktion aktiviert wird, mittels derer ermittelt wird, an welche Anwendungssysteme die Datei verteilt werden soll.
  21. Verfahren nach Anspruch 20, dadurch gekennzeichnet, dass mindestens eine Client-Kommunikationskomponente (1011-1031, 5011-5031) dynamisch aufgebaut wird, wobei die Client-Kommunikationskomponente (1011-1031, 5011-5031) mindestens einem Anwendungssystem (101-103, 501-503) auf dem Client-Rechner (10, 50) zugeordnet ist.
  22. Verfahren nach Anspruch 21, dadurch gekennzeichnet, dass eine Kommunikationssoftware umfassend mindestens die Client-Kommunikationskomponente (1011-1031, 5011-5031) von dem Verbindungsserver (20) an den Client-Rechner (10, 50) übertragen wird.
  23. Verfahren nach Anspruch 21 oder 22 dadurch gekennzeichnet, dass auf dem Verbindungsserver (20) zu den einzelnen Client-Kommunikationskomponente (1011-1031, 5011-5031) Server-Kommunikationskomponenten (2101-2103, 2501-2503) erstellt werden.
  24. Verfahren nach einem der Ansprüche 21 bis 23, dadurch gekennzeichnet, dass eine Client-Kommunikationskomponente (1011-1031, 5011-5031) und/oder eine Server-Kommunikationskomponente (2101-2103, 2501-2503) mindestens je ein dynamisch erstelltes Upload-Verzeichnis und/oder Download-Verzeichnis umfasst, in dem mindestens je ein Stereotyp mit Kontrollinformationen speicherbar ist.
  25. Verfahren nach Anspruch 24, dadurch gekennzeichnet, dass Stereotypen mit Kontrollinformationen ineinander verschachtelt speicherbar sind.
  26. Verfahren nach einem der Ansprüche 20 bis 25 mittels eines LDAP-Servers, dadurch gekennzeichnet, dass auf dem LDAP-Server (21) für die einzelnen Anwendungssysteme (101-103, 501 -503) Identifier mit zugehörigen Passwords abgelegt sind.
  27. Verfahren nach Anspruch 26, dadurch gekennzeichnet, dass auf dem LDAP-Server (21) ein Policy/Director installiert ist, in dem die Passwords abgelegt sind und die Zugangsberechtigung eines Anwendungssystems (101-103, 501-503) überprüft wird.
  28. Verfahren nach einem der Ansprüche 20 bis 27, dadurch gekennzeichnet, dass verschiedenen externen Unternehmensnetzwerken (5) jeweils ein eigener Verbindungsserver (20) mit Firewall (201, 202) zugeordnet ist.
  29. Verfahren nach Anspruch 28, dadurch gekennzeichnet, dass die verschiedenen Verbindungsserver (20) mit mindestens einem LDAP-Server (21) verbunden sind, wobei auf dem mindestens einen LDAP-Server (21) zu den Identifiern Attribute abgelegt sind, in denen das zugehörige Unternehmensnetzwerk (5) eines Anwendungssystems (501-503) abgelegt ist.
  30. Verfahren nach einem der Ansprüche 20 bis 29, dadurch gekennzeichnet, dass zum automatischen Dateitransfer von einem sendenden Anwendungssystem (101) an den Verbindungsserver (20) eine Datei zum Upload in einen Upload Request gestellt wird Client-Kommunikationskomponente (1011) des dem sendenden Anwendungssystem (101) zugeordneten Client-Rechners (10) gestellt wird, in Verbindung mit dieser Datei ein Upload-Request in die Client-Kommunikationskomponente (1011) geschrieben wird, wobei der Inhalt des Upload-Requests mindestens ein Kennung der zu sendenden Datei und eine Identifikation des Anwendungssystems ist, zu dem die Datei übertragen werden soll.
  31. Verfahren nach Anspruch 30, dadurch gekennzeichnet, dass mittels einer Upload-Funktion vom Daten sendenden Anwendungssystem (101) die Client-Kommunikationskomponente (1011) das Upload Verzeichnis gescanned wird, der Upload-Request gelesen, eine Verbindung zum Verbindungsserver (20) aufgebaut und die Datei an den Verbindungsserver (20) übertragen wird.
  32. Verfahren nach Anspruch 30 oder 31, dadurch gekennzeichnet, dass zum automatischen Dateitransfer vom Verbindungsserver (20) an ein empfangendes Anwendungssystem (501) eine dem Anwendungssystem (501) zugeordnete Server-Kommunikationskomponente (2501) durch ein Download-Request aktualisiert wird, über die Downloadfunktion des Client-Rechners (50) des empfangenden Anwendungssystems (501) die Server-Kommunikationskomponente (2501)- gescanned wird, der Download-Request erkannt wird, eine Verbindung zum Verbindungsserver (20) aufgebaut wird und die Datei und ein Request in eine Client-Kommunikationskomponente (5011) des Client-Rechners (50) geschrieben werden.
  33. Verfahren nach Anspruch 32, dadurch gekennzeichnet, dass der Client-Rechner (50) des empfangenden Anwendungssystems (501) die Client-Kommunikationskomponente (5011) scanned, den Request ausliest und das Anwendungssystem (501) aktiviert.
  34. Verfahren nach einem der Ansprüche 20 bis 33, dadurch gekennzeichnet, dass bei Abbruch einer Verbindung zwischen Client-Rechner (10, 50) und Verbindungsserver (20) ein automatischer Neuaufbau der Verbindung hergestellt wird.
  35. Verfahren nach Anspruch 34, dadurch gekennzeichnet, dass die Anzahl der beim Abbruch aktiven Übertragungen ermittelt wird, von den aktiven empfangenen Dateien ein Bytecount an die Sender übertragen wird, wobei die Sender die Counts der zu sendenden Dateien auf das übertragene Bytecount einstellen und die Übertragung aktivieren.
  36. Verfahren nach einem der Ansprüche 20 bis 35, dadurch gekennzeichnet, dass die zu übertragenden Dateien auf dem Verbindungsserver (20) gespeichert werden, wobei den Dateien ein Verfallsdatum zugeordnet ist.
  37. Computerprogramm mit Programmcode-Mitteln, um alle Schritte von jedem beliebigen der Ansprüche 20 bis 36 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.
  38. Computerprogrammprodukt mit Programmcode-Mitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um das Verfahren nach jedem beliebigen der Ansprüche 20 bis 36 durchzuführen, wenn das Programmprodukt auf einem Computer ausgeführt wird.
DE10332470.4A 2003-01-09 2003-07-16 Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken Expired - Lifetime DE10332470B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE10332470.4A DE10332470B4 (de) 2003-01-09 2003-07-16 Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10301106.4 2003-01-09
DE10301106A DE10301106A1 (de) 2002-01-24 2003-01-09 Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Netzwerken
DE10332470.4A DE10332470B4 (de) 2003-01-09 2003-07-16 Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken

Publications (2)

Publication Number Publication Date
DE10332470A1 DE10332470A1 (de) 2004-07-29
DE10332470B4 true DE10332470B4 (de) 2020-01-16

Family

ID=32602524

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10332470.4A Expired - Lifetime DE10332470B4 (de) 2003-01-09 2003-07-16 Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken

Country Status (1)

Country Link
DE (1) DE10332470B4 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019111553B3 (de) * 2019-05-03 2020-07-16 Holger Fecht Hochsicherheitsnetzwerk sowie Verfahren zum Aufbau eines Hochsicherheitsnetzwerks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000070839A2 (en) 1999-05-18 2000-11-23 Jpmorgan Chase Bank Secured session sequencing proxy system and method therefor
US20020091798A1 (en) 2000-07-10 2002-07-11 Joshi Vrinda S. Providing data to applications from an access system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000070839A2 (en) 1999-05-18 2000-11-23 Jpmorgan Chase Bank Secured session sequencing proxy system and method therefor
US20020091798A1 (en) 2000-07-10 2002-07-11 Joshi Vrinda S. Providing data to applications from an access system

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Design the firewall system.In:CERT, 1999, http://web.archive.org/web/20010331192853/www. cert.org/security-improvement/practices/p053.html *
KNUDSEN, J.: Java Cryptography. 1st Edition. Sebastopol: O'Reilly, 1998. - ISBN: 1-56592-402-9 *
RÖHRIG,Bernhard:Linux im Netz, C&L Verlag, Vaterstetten, 1997, Abschn.15.3 (insbes.,15.3.3 u. 15.3.5); *
SCHLESIONA,Michael:Firewalls für sichere Netze.In: Funkschau, 1999, H.14,S.74-79; *

Also Published As

Publication number Publication date
DE10332470A1 (de) 2004-07-29

Similar Documents

Publication Publication Date Title
DE602004012870T2 (de) Verfahren und system zur benutzerauthentifizierung in einer benutzer-anbieterumgebung
DE60130633T2 (de) Gesicherte Internet-Zwischenablage
DE69830726T2 (de) Verfahren zum betrieb eines systems von authentifizierungsservern sowie ein solches system
DE112011101729B4 (de) Verwaltung von Ressourcenzugriff
DE60222871T2 (de) Anordnung und Verfahren zum Schutz von Endbenutzerdaten
DE602005003314T2 (de) Spezialisierung der Unterstützung für eine Verbandsbeziehung
DE69932003T2 (de) System und Verfahren zur Kontrolle einer Netzwerkverbindung
DE60308692T2 (de) Verfahren und system für benutzerbestimmte authentifizierung und einmalige anmeldung in einer föderalisierten umgebung
DE10196732B4 (de) Verfahren, Speichermedium und System zur Verteilung von Software an prozessorbasierte Systeme
DE69635469T2 (de) Synchronisierung zwischen verschiedenen Computeranbieterumgebungen
DE602004001716T2 (de) Verfahren und System zur Verbindung eines Fernbenutzers mit einer lokalen Rechnerumgebung über einen Intranet-Server
EP2529529B1 (de) Verfahren zum gesicherten download von verteilten downloadsourcen
DE112015005024T5 (de) Öffnen lokaler Anwendungen von Browsern
WO2010034329A1 (de) Verfahren zur konfiguration einer applikation
DE10116640A1 (de) Auf URL beruhende Token für schwierige Verteilungen, die einen serverseitigen Cookiebehälter benutzen
DE60307652T2 (de) Verfahren und System zur gesicherten Inhaltsüberlieferung
DE102014206325A1 (de) Verteiltes Authentifizierungssystem
EP2215806B1 (de) Internet-smart-card
EP1083722B1 (de) Verfahren und Gateway, die einen End-zu-End gesicherten Zugriff auf WAP-Dienste erlauben
DE10332470B4 (de) Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Unternehmensnetzwerken
DE10107883B4 (de) Verfahren zur Übertragung von Daten, Proxy-Server und Datenübertragungssystem
EP1306755A1 (de) Verfahren zur Versorgung eines Gerätes mit Software
EP4107640B1 (de) Verfahren und systeme zum übertragen von software-artefakten aus einem quellnetzwerk zu einem zielnetzwerk
EP2773081A1 (de) Kommunikationsgerät für ein industrielles Kommunikationsnetz und ein Verfahren zur Bereitstellung von Daten, insbesondere Dateien, in einem industriellen Kommunikationsnetz mittels File Transfer Protocol
DE10301106A1 (de) Verfahren und Vorrichtung zur Kommunikation zwischen Anwendungssystemen in unterschiedlichen Netzwerken

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
8110 Request for examination paragraph 44
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012220000

Ipc: H04L0012260000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012220000

Ipc: H04L0012260000

Effective date: 20130624

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R082 Change of representative
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000

R071 Expiry of right