EP1745633A1 - Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen - Google Patents

Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen

Info

Publication number
EP1745633A1
EP1745633A1 EP05707543A EP05707543A EP1745633A1 EP 1745633 A1 EP1745633 A1 EP 1745633A1 EP 05707543 A EP05707543 A EP 05707543A EP 05707543 A EP05707543 A EP 05707543A EP 1745633 A1 EP1745633 A1 EP 1745633A1
Authority
EP
European Patent Office
Prior art keywords
installation
data
local
network
type
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
EP05707543A
Other languages
English (en)
French (fr)
Inventor
Gaël JEANNERET
Horst Studer
Felix Akeret
Pierre De Pascale
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.)
Siemens Schweiz AG
Original Assignee
Siemens Schweiz 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
Application filed by Siemens Schweiz AG filed Critical Siemens Schweiz AG
Priority to EP05707543A priority Critical patent/EP1745633A1/de
Publication of EP1745633A1 publication Critical patent/EP1745633A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]

Definitions

  • the present invention relates to a network and a method for data transmission between applications with proprietary interfaces according to the preamble of claim 1 and claim 4.
  • the present invention is in the field of information and communication technology. Due to the very diverse requirements in this technology, computers and associated applications from a wide variety of manufacturers must be networked in integrated systems.
  • the invention is therefore based on the object to provide a network and a method that allow for disturbances of the network, some even still maintain if necessary. In a functional relationship 'standing applications to ensure their function.
  • this object is achieved according to the invention by a network for data transmission between applications with proprietary interfaces, with a) the applications and / or the data assigned to them being able to be processed at locations with different installation types, b) the applications can be coupled via a data broker for the data transmission c) the data transmission can be carried out by means of requests and responses via the data broker, d) the requests / responses are designed as XML messages, and e) the various locations with different installation types with regard to their integration into the network depend on the type of installation regarding the storage and / or distribution of data for the applications.
  • the functional tasks to be performed within the network can be hierarchically structured by defining locations with installation types according to the requirements for the respective data requirements and the respective prioritization for an exchange of data. In this way it is ensured that the data required for the fulfillment of its intended functional task is clearly available.
  • a first installation type comprising a central server with a central database, a local server with a local database, a central service server and clients integrated into a local network
  • a second type of installation comprises a local server with a local database, possibly both of the above-mentioned units in a redundant design, and clients integrated in a local network
  • a third type of installation includes clients connected to a local network
  • a fourth installation type comprises at least one mobile client, the hierarchical assignment being provided as follows: e) the third and fourth installation types access the second installation type; f) the second installation type comprises a data image of the first installation type, which the second installation type is not authorized to modify; and g) entries in the central database and possibly further redundant central databases can only be made in the first installation type.
  • An additional measure can provide that the service server provides central authentication, naming and notification services.
  • FIG. 1 shows an overview of the arrangement of various applications which exchange data via a CORBA-based data broker
  • FIG. 2 shows a communication network operating according to the arrangement according to FIG. 1 with several locations of different installation types.
  • FIG. 1 shows an overview of the arrangement of different applications that exchange data via a CORBA-based data broker 1.
  • the data broker is trained as a CORBA / ORB data broker.
  • So-called peripheral systems are designated by reference number 10.
  • the individual peripheral systems 101, 102 etc. stand for example for a weather data evaluation system, for a communication system for recording soil air pressure and temperature data, etc.
  • Surround systems are the required subsystems and thus serve to support the task to be performed by the weather service system.
  • So-called engagement systems are designated by reference numeral 20.
  • the individual intervention systems 201, 202 stand for example for the control of the use of mobile weather stations, such as rising weather balloons, and the general control of automatic weather stations. In terms of application, the aforementioned two intervention systems 201, 202 are accessible via a portal 29.
  • Auxiliary systems 30 include, for example, a notification service 301, a workflow engine 302, a name service, etc.
  • the data broker 1 is divided by so-called data guards 2. These data guards 2 have the function of a firewall. This is to be distinguished from encryption, which is described below.
  • the data belonging to the weather service system are kept in a relational database 27; Access and administration take place via a data manager 28.
  • FIG. 2 now shows a schematic representation of a communication network 40 operating according to the arrangement according to FIG. 1 with a plurality of locations 42 to 50, which have different installation types I, Ha, Ilb, III and IV and are connected to one another via a data transmission system 112.
  • this type of stand 42 comprises a central server ZS with a central database ZDB and a central service server ZD.
  • a local server LS which communicates with the central server ZS and local clients LC via a local network LAN, is designed such that the applications required for this location 42 are administered and executed on this local server LS.
  • An essential feature of this type of installation I is the exclusive authorization of the central server ZS to write data to the central database ZS or to read data therefrom.
  • a local database assigned to the local server LS can contain an image of the central database
  • the central database ZDB administered by the central server ZS is decisive.
  • the location 44 is also equipped with an installation type I, this location 44 being designed as redundancy to the location 42 with regard to its central components.
  • the redundant central server RZS, the redundant central database RZDB and the redundant central service server RZD are redundant. If location 102 is partially relevant or total as a result of a malfunction, the communication network can directly access the location 44 with its central functionalities. In such a state, other locations, here still location 46, may possibly be equipped as temporary redundancy to location 44 until location 42 is fully operational again and location 44 is then reset to the redundancy protection.
  • the location 46 already mentioned above is designed with an installation type Ila / b, the installation type Ha referring to equipment without a redundant local database RLDB and the installation type Ilb correspondingly with a redundant local database RLDB.
  • the installation type Ilb is shown.
  • all installation types II include a local area network LAN, in which local clients LC and the local server LS with its local database LDB are integrated.
  • Such a location could be, for example, a regional weather station that collects the relevant weather data for a region, controls the relevant weather stations, creates preliminary regional weather and snow depth and avalanche bulletins, and generally stores this data in the local LDB database and only a certain selection of this data transmitted to the central server ZS in location 42, which in turn decides which of these data are written to the central database ZDB.
  • a regional weather station that collects the relevant weather data for a region, controls the relevant weather stations, creates preliminary regional weather and snow depth and avalanche bulletins, and generally stores this data in the local LDB database and only a certain selection of this data transmitted to the central server ZS in location 42, which in turn decides which of these data are written to the central database ZDB.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

Auf der Architektur CORBA basierende Anordnungen zur Datenübermittlung zwischen proprietären Datenquellen und Datensenken weisen den Nachteil auf, dass für neue anzubindende Applikation (101, 102; 201, 202) ein grosser Aufwand geleistet werden muss. Dazu ist es vorgesehen, dass die Requests/Responses als XML-Nachrichten ausgebildet sind. Erfindungsgemäss ist ein Netzwerk (40) zur Datenübermittlung zwischen Applikationen (101, 102; 201, 202) mit proprietären Schnittstellen vorgesehen, wobei die Applikationen über einen Databroker (1) koppelbar sind und über diesen die Datenübermittlung mittels Requests und Responses im XML-Format durchführbar ist. Die verschiedenen Standorte (42 bis 50) mit unterschiedlichen Installationstypen (I bis IV) haben im Bezug auf ihre Einbindung in das Netzwerk (40) vom Installationstyp (I bis IV) abhängige Kompetenzen im Bezug auf die Speicherung und/oder die Verteilung von Daten für die Applikationen.

Description

Siemens Schweiz AG CH-8047 Zürich
Netzwerk und Verfahren zur Datenübermittlung zwischen Applikationen mit proprietären Schnittstellen
Die vorliegende Erfindung betrifft ein Netzwerk und ein Verfahren zur Datenübermittlung zwischen Applikationen mit proprietären Schnittstellen nach dem Oberbegriff des Patent- anspruchs 1 bzw. des Patentanspruchs 4.
Die vorliegende Erfindung ist auf dem Gebiet der Informa- tions- und o munikationstechnologie angesiedelt. Bedingt durch die sehr vielfältigen Anforderungen in dieser Technologie sind in integrierten Systemen Computer und zugeordnete Anwendungen von verschiedensten Herstellern zu vernetzen.
Vom Gremium OMG wurde dazu die Architektur CORBA spezifi- ziert, über die die verschiedenen Anwendungen - auch
Applikationen genannt - kommunizieren können. Sogenannte CORBA Applikationen bestehen aus einem oder mehreren Objekten, die ein Abbild eines oder mehrer realer Vorgänge - eine Funktion und zugeordnete Daten - repräsentieren. Jedem Objekt ist dabei ein Typ zugeordnet. Üblicherweise gibt es mehrere Instanzen eines Objektes. Eine E-Commerce Web-Applikation besteht aus denjenigen Instanzen, die dem Warenkorb der momentanen Anwender bzw. Kunden dieser Web-Applikation entsprechen. Für die Spezifikation der Architektur CORBA wird auf das Dokument [1] verwiesen.
Für jeden Objekttyp ist abhängig von der jeweiligen Lauf- umgebung eine Schnittstellendefinition notwendig. Die Applikationen haben auf CORBA-Vorgaben abgestützte Schnittstellen, welche in der CORBA-IDL (Interface Definition Language) defi- niert und dann in die verschiedenen Implementationssprachen der Zielsysteme übersetzt und implementiert werden. Der grosse Vorteil der CORBA basierten Produkte ist dabei die sprachenübergreifende, plattformübergreifende und für heterogene Systeme geeignete Funktionsweise.
In der Praxis hat sich gezeigt, dass die vorgenannte Architektur, einen Datenaustausch zwischen verschiedenen Datenquellen und Datensenken auf zuverlässige und zweckmässige Weise erlauben und zwar auch dann, wenn die betreffenden Schnittstellen hochgradig proprietär sind. Nachteilig ist jedoch, dass für neue anzubindende Applikation ein grosser Aufwand geleistet werden muss. r—v
In der internationalen Patentanmeldung PCT/EP03/01982 werden zur Lösung dieser Aufgabe eine Anordnung und ein Verfahren zur Datenübermittlung von Applikationen mit proprietären Schnittstellen vorgeschlagen, bei denen die Applikationen über einen Databroker für die Datenübermittlung koppelbar sind und die Datenübermittlung mittels Requests und Responses über den Databroker durchführbar ist und die Requests/Responses als XML-Nachrichten ausgebildet sind. Auf diese Weise können in einem hohen bedienerfreundlichen Masse Anpassungen und das Einbinden neuer Applikationen in ein bestehendes Netzwerk vorgenommen werden, ohne dass die bestehenden Applikationen genauere Kenntnisse von dem Aufbau der nachfolgend eingebundenen oder angepassten Applikationen haben müssen, wenn sie mit diesen zwecks der Erledigung ihrer bestimmungsgemässen Aufgabe kommunizieren wollen.
Derzeit ungelöst ist es jedoch, in diesem Umfeld die Organisation des Datenaustausches in einer Weise zu lösen, dass bestimmte Applikationen auch autark betrieben werden können, wenn die Datenverbindungen innerhalb des Netzwerks gestört oder gar unterbrochen sind. Der Erfindung liegt daher die Aufgabe zugrunde, ein Netzwerk und ein Verfahren anzugeben, die es bei Störungen des Netzwerkes ermöglichen, bestimmte, ggfs. sogar in einem FunktionsZusammenhang' stehende Applikationen dennoch zur Gewährleistung deren Funktion aufrechtzuerhalten.
Diese Aufgabe wird bezüglich des Netzwerkes erfindungsgemäss gelöst durch ein Netzwerk zur Datenübermittlung zwischen Applikationen mit proprietären Schnittstellen, wobei a) die Applikationen und/oder die ihnen zugeordneten Daten an Standorten mit unterschiedlichen Installationstypen verarbeitbar sind, b) die Applikationen über einen Databroker für die Datenübermittlung koppelbar sind, c) die Datenübermittlung mittels Requests und Responses über den Databroker durchführbar ist, d) die Requests/Responses als XML-Nachrichten ausgebildet sind, und e) die verschiedenen Standorte mit unterschiedlichen Installationstypen im Bezug auf ihre Einbindung in das Netzwerk vom Installationstyp abhängige Kompetenzen im Bezug auf die Speicherung und/oder die Verteilung von Daten für die Applikationen haben.
Die vorstehende Aufgabe wird bezüglich des Verfahrens erfindungsgemäss gelöst durch ein Verfahren zur Datenübermittlung zwischen Applikationen mit proprietären Schnittstellen, wobei a) die Applikationen und/oder die ihnen zugeordneten Daten an Standorten mit unterschiedlichen Installationstypen verarbeitet werden, b) die Applikationen über einen Databroker für die Datenübermittlung gekoppelt werden, c) die Datenübermittlung mittels Requests und Responses über den Databroker erfolgt, d) die Requests/Responses als XML-Nachrichten ausgebildet sind, und e) den verschiedenen Standorten mit unterschiedlichen Installationstypen im Bezug auf ihre Einbindung in das Netzwerk vom Installationstyp abhängige Kompetenzen im Bezug auf die Speicherung und/oder die Verteilung von Daten für die Applikationen zugewiesen werden.
Auf diese Weise werden die verschiedenen Standorte für deren vorgesehene funktionelle Aufgabe definierbar gemacht, so dass einem Standort bestimmte funktionsspezifische Applikationen zugewiesen werden können. Die innerhalb des Netzwerkes zu erfüllenden funktionellen Aufgaben können so durch die Definition von Standorten mit Installationstypen entsprechend der Anforderung an den jeweiligen Datenbedarf und die jeweilige Priorisierung für einen Austausch der Daten hierarchisch gegliedert werden. Auf diese Weise ist es sichergestellt, dass für jeden Standorte die zur Erfüllung seiner bestimmungsgemässen funktioneilen Aufgabe erforderlichen Daten eindeutig zur Verfügung stehen.
In einer zweckmässigen, vergleichsweise einfach administrierbaren Ausgestaltung der Erfindung können vier unterschiedliche Installationstypen vorgesehen sein, wobei a) ein erster Installationstyp einen zentralen Server mit zentraler Datenbank, einen lokalen Server mit einer lokalen Datenbank, einen zentralen Diensteserver sowie in ein lokales Netzwerk eingebundene Clients umfasst; b) ein zweiter Installationstyp einen lokalen Server mit einer lokalen Datenbank, ggfs. beide vorstehend genannten Einheiten in redundanter Ausführung, sowie in ein lokales Netzwerk eingebundene Clients umfasst; c) ein dritter Installationstyp in ein lokales Netzwerk eingebundene Clients umfasst; und d) ein vierter Installationstyp mindestens einen mobilen Client umfasst, wobei die hierarchische Zuordnung wie folgt vorgesehen ist: e) der dritte und der vierte Installationstyp greifen auf den zweiten Installationstypen zu; f) der zweite Installationstyp umfasst ein Datenabbild des ersten Installationstyps, welches der zweite Installationstyp aber nicht berechtigt ist, zu modifizieren; und g) nur im ersten Installationstyp Einträge in die zentrale Datenbank sowie ggfs. weitere redundante zentrale Datenbanken vornehmbar sind.
Eine hierzu ergänzende Massnahme kann es vorsehen, dass der Diensteserver zentrale Authentisierungs-, einen Naming- und einen Notification-Dienste bereitstellt.
Weitere vorteilhafte Ausgestaltungen der Erfindung sind den übrigen Unteransprüche zu entnehmen.
Die Erfindung wird nachfolgend anhand einer Zeichnung beispielsweise näher erläutert. Dabei zeigen: Figur 1 Übersicht der Anordnung von verschiedenen Applikation, die über einen auf CORBA basierenden Databroker Daten austauschen; und
Figur 2 ein gemäss der Anordnung nach Figur 1 arbeitendes Kommunikationsnetzwerk mit mehreren Standorten unterschiedlichen Installationstyps .
Das nachfolgende Ausführungsbeispiel betrifft ein integriertes Wetterdienst-System. Figur 1 zeigt eine Übersicht der Anordnung von verschiedenen Applikation, die über einen auf CORBA basierenden Databroker 1 Daten austauschen, . Der Databroker ist dabei als CORBA/ORB-Datenbroker ausgebildet. Mit dem Bezugszeichen 10 sind sogenannte Umsysteme bezeichnet. Die einzelnen Umsysteme 101, 102 usw. stehen beispielsweise für ein Wetterdatenbewertungssystem, für ein Kommunikationssystem zur Erfassung von Bodenluftdruck- und - temperaturdaten, usw. Umsysteme sind dabei die erforderlichen Teilsysteme und dienen somit der Unterstützung der von dem Wetterdienst-System zu erfüllenden Aufgabe. Mit dem Bezugszeichen 20 sind sogenannte EingriffSysteme bezeichnet. Die einzelnen EingriffSysteme 201, 202 stehen dabei beispielsweise für die Steuerung des Einsatzes von mobilen Wetterstationen, wie aufsteigende Wetterballons, sowie die generelle Steuerung von automatischen Wetterstationen. Von der Anwendung her sind die vorgenannten zwei Eingriffsysteme 201, 202 über ein Portal 29 zugänglich. Hilfssysteme 30 beinhalten z.B. einen Notifikationsdienst 301, eine Workflow Engine 302, einen Namensdienst usw.
Umsysteme und Eingriffsysteme sind dabei natürlich nicht an einem Ort angeordnet, sondern in der Regel über ein Gebiet, wie z.B. ein Land, verteilt. Um den Zugriff auf die Daten wirksam hinsichtlich Integrität der Daten und Wahrung der Vertraulichkeit der Daten zu schützen, ist der Databrokern 1 durch sogenannte Dataguards 2 unterteilt. Diesen Dataguards 2 kommt die Funktion einer Firewall zu. Davon zu unterscheiden ist eine Verschlüsselung, die weiter unten beschrieben wird.
Die dem Wetterdienst-System zugehörigen Daten werden in einer einer relationalen Datenbank 27 gehalten; Zugriff und Administration erfolgen über einen Datamanager 28.
Da die Umsysteme und die Eingriffssysteme in der Regel eben verteilt angeordnet sind und auf ihnen zur Erfüllung ihrer jeweiligen Funktion bestimmte Applikationen durchgeführt werden müssen, auch wenn beispielsweise Datenverbindungen gestört oder unterbrochen sind, ist es vorgesehen, dass bestimmte logische Standorte definiert werden, denen unterschiedliche Installationstypen zugeordnet sind. Mit einem Installationstyp ist dabei sehr allgemein ein in sich abgeschlossenes Gebilde von Hardwaregruppen, Software-Gruppen und Berechtigungen zu verstehen. Ein Standort mit einem bestimmten Installationstyp weist daher eine entsprechende definitionsgemässe Struktur bezüglich der oben genannten Merkmale auf. Figur 2 zeigt nun in schematischer Darstellung ein gemäss der Anordnung nach Figur 1 arbeitendes Kommunikationsnetzwerk 40 mit mehreren Standorten 42 bis 50, die unterschiedliche Installationstypen I, Ha, Ilb, III und IV aufweisen und über ein Datenübertragungssystem 112 miteinander verbunden sind.
Der logische Standort 42 soll für das Wetterdienst-System der Hauptstandort sein, an dem beispielsweise Grossrechner angeordnet sind, die aus den im Standort 42 eingehenden Daten der übrigen Standorte 44 bis 50 Wetterprognosen und
Klimaanalysen errechnet und an die Nutzer (Abonnenten) dieser Ergebnisdaten weiterverteilt werden. Dieser Standtyp 42 umfasst aufgrund seines Installationstyps I einen zentralen Server ZS mit einer zentralen Datenbank ZDB und einem zentralen Diensteserver ZD. Ein lokaler Server LS, der über ein lokales Netzwerk LAN mit dem zentralen Server ZS und lokalen Clients LC kommuniziert, ist dabei so ausgestaltet, dass die für diesen Standort 42 erforderlichen Applikationen auf diesem lokalen Server LS administriert und ausgeführt werde .
Ein wesentliches Merkmal dieses Installationstyps I ist die ausschliessliche Befugnis des zentralen Servers ZS Daten in die zentrale Datenbank ZS zu schreiben bzw. aus ihr auszulesen. Dies heisst zwar, dass eine dem lokalen Server LS zugeordnete lokale Datenbank ein Abbild der zentralen Datenbank enthalten kann, massgeblich ist aber die vom zentralen Server ZS administrierte zentrale Datenbank ZDB.
Der Standort 44 ist ebenfalls mit einem Installationstyp I ausgestattet, wobei dieser Standort 44 hinsichtlich seiner zentralen Komponenten als Redundanz zum Standort 42 ausgestaltet sind. Redundant sind dabei im einzelnen der redundante zentrale Server RZS, die redundante zentrale Datenbank RZDB und der redundante zentrale Diensteserver RZD. Sollte es als aufgrund einer Störung zu einem partiell relevanten oder totalen Ausfall des Standorts 102 kommen, kann das Kommunikationsnetzwerk unmittelbar auf den Standort 44 mit dessen zentralen Funktionalitäten zurückgreifen. Möglicherweise können in einem solchen Zustand auch andere Standorte, hier noch der Standort 46, als vorübergehende Redundanz zum Standort 44 ausgestattet werden bis der Standort 42 wieder voll einsatzfähig ist und der Standort 44 dann wieder in die Redundanzabsicherung zurückgestellt wird.
Der vorstehend bereits angesprochene Standort 46 ist mit einem Installationstyp Ila/b ausgestaltet, wobei sich der Installationstyp Ha auf eine Ausstattung ohne redundante lokale Datenbank RLDB und der Installationstyp Ilb entsprechend mit redundanter lokaler Datenbank RLDB bezieht. Im vorliegenden Fall ist also der Installationstyp Ilb dargestellt. Ansonsten umfassen alle Installationstypen II ein lokales Netzwerk LAN, in das lokale Clients LC und der lokale Server LS mit seiner lokalen Datenbank LDB eingebunden sind. Ein derartiger Standort könnte beispielsweise eine regionale Wetterwarte sein, die die relevanten Wetterdaten einer Region einholt, die diesbezüglichen Wetterstationen steuert, vorläufige regionale Wetter- und Schneehöhen- und Lawinenbulletins erstellt und diese Daten grundsätzlich auf der lokalen Datenbank LDB speichert und nur eine bestimmte Auswahl dieser Daten an den zentralen Server ZS im Standort 42 übermittelt, der wiederum entscheidet, welche dieser Daten in die zentrale Datenbank ZDB geschrieben werden.
Der Standort 48, der mit dem Installationstyp III ausgestattet, verfügt nur noch über ein lokales Netzwerk LAN und daran angeschlossene lokale Clients LC. Die für diesen Standort 48 benötigten Applikationen befinden sich auf einem Standort mit dem Installationstyp Ha oder Ilb, also hier auf dem lokalen Server LS des Standorts 46. Daten dieses Standorts 48, die möglicherweise am Standort 42 benötigt werden, können dorthin nur über den lokalen Server LS des
Standorts 46 gelangen. Daten von der zentralen Datenbank ZDB kann daher der Standort 48 auch nur über den lokalen Server LS des Standorts 46 abrufen. Eine mögliche Funktion für einen derartigen Standort im Rahmen dieses Wetterdienst-Systems könnte die Funktion einer automatischen, vor Ort parametrierbaren Wetterstation sein.
Der vierte in diesem Ausführungsbeispiel vorgesehene Installationstyp IV ist am Standort 50 verwirklicht. Dieser Standort verfügt nur noch über einen (mobilen) lokalen Client LCM, also beispielsweise einen Wetterballon, der zu bestimmten Zeiten an einem abgesetzten Einsatzort zum
Aufsteigen gebracht wird und seine Daten direkt an einen lokalen Server LS eines Installationstyps II, also hier an den Standort 46, sendet.
Aufgrund dieser Gliederung des gesamten Systems 40 in logische (virtuelle oder physikalische Standorte) Standorte 42 bis 50 mit den entsprechenden Installationstypen I bis IV ist eine hohe Verfügbarkeit der jeweils in einem Standort konzentrierten Funktionalitäten erreicht. Ausfälle einzelner Standorte bedrohen daher das System als Ganzes nicht, sondern können vorübergehend tolierbar sein, bis bei Störungszuständen die ursprüngliche Struktur zumindest hilfsweise wieder abgebildet werden kann.
Das vorstehend am Beispiel des Wetterdienst-Systems erläuterte Kommunikationssystem kann auch in einer nahezu unbegrenzten Vielzahl für andere derart verteilte Systeme genutzt werden. Explizit genannt werden hier noch Systeme, die aus den E-Commerce-Bereichen A2A (Administration to Administration) , A2B (Administration to Business) und A2C (Administration to Consumer) stammen können. Liste der verwendeten Bezugszeichen
1 DataBroker: CORBA/ORB
2 Firewall, Dataguard
10 Umsysteme
20 EingriffSysteme
27 Database, Database RDBMS
28 DataManager
29 Portal
30 HilfSysteme
40 Kommunikationsnetzwerk
42 bis 50 Standorte
101 Umsystem
102 Umsystem
103 Umsystem
104 Umsystem
201 EingriffSystem
202 EingriffSystem
301 Notifikationsdienst
302 Workflow Engine
LAN Lokales Netzwerk
LC Lokaler Client
LCM Mobiler lokaler Client
LDB Lokale Datenbank
LS Lokaler Server
RZD Redundanter zentraler Diensteserver
RZDB Redundante zentrale Datenbank
RZS Redundanter zentraler Server
ZD Zentraler Diensteserver
ZDB Zentrale Datenbank
ZS Zentrale Server Liste der verwendeten Akronyme
CORBA Common Object Request Broker Architecture IDL Interface Definition Language OMG Object Management Group ORB Object Request Broker RDBMS Relationales Datenbankmanagmentsystem XML Extensible Markup Language
Literaturliste [1] Common Object Request Broker Architecture: Gore Specification, December 2002, Version 3.0

Claims

Siemens Schweiz AG CH-8047 Zürich
Patentansprüche 1. Netzwerk (40) zur Datenübermittlung zwischen Applikationen (101, 102; 201, 202) mit proprietären Schnittstellen, wobei a) die Applikationen und/oder die ihnen zugeordneten Daten an Standorten (42 bis 50) mit unterschiedlichen Installationstypen (I bis IV) verarbeitbar sind, b) die Applikationen über einen Databroker (1) für die Datenübermittlung koppelbar sind, c) die Datenübermittlung mittels Requests und Responses über den Databroker (1) durchführbar ist, d) die Requests/Responses als XML-Nachrichten ausgebildet sind, e) die verschiedenen Standorte (42 bis 50) mit unterschiedlichen Installationstypen (I bis IV) im Bezug auf ihre Einbindung in das Netzwerk (40) vom Installationstyp (I bis IV) abhängige Kompetenzen im Bezug auf die Speicherung und/oder die Verteilung von Daten für die Applikationen haben.
2. Netzwerk (40) nach Anspruch 1, dadurch gekennzeichnet, dass vier unterschiedliche Installationstypen (I bis IV) vorgesehen sind, wobei a) ein erster Installationstyp (I) einen zentralen Server (ZS) mit zentraler Datenbank (ZDB) , einen lokalen Server (LS) mit einer lokalen Datenbank (LDB) , einen zentralen Diensteserver (ZD) sowie in ein lokales Netzwerk (LAN) eingebundene lokale Clients (LC) umfasst; b) ein zweiter Installationstyp (II) einen lokalen Server (LS) mit einer lokalen Datenbank (LDB), ggfs. beide vorstehend genannten Einheiten in redundanter Ausführung, sowie in ein lokales Netzwerk (LAN) eingebundene Clients (LC) umfasst; c) ein dritter Installationstyp (III) in ein lokales Netzwerk (LAN) eingebundene Clients (LC) umfasst; und d) ein vierter Installationstyp (IV) mindestens einen mobilen Client (LCM) umfasst, wobei die hierarchische Zuordnung wie folgt vorgesehen ist: e) der dritte und der vierte Installationstyp (III bzw. IV) greifen auf den zweiten Installationstypen (II) zu; f) der zweite Installationstyp (II) umfasst ein Datenabbild des ersten Installationstyps (I) , welches der zweite Installationstyp (II) aber nicht berechtigt ist, zu modifizieren; und g) nur im ersten Installationstyp (I) Einträge in die zentrale Datenbank (ZDB) sowie ggfs. weitere redundante zentrale Datenbanken (RZDB) vornehmbar sind.
3. Netzwerk (40) nach Anspruch 2, dadurch gekennzeichnet, dass der Diensteserver (ZD) zentrale Authentisierungs-, einen Naming- und einen Notification-Dienste bereitstellt.
4. Verfahren zur Datenübermittlung zwischen Applikationen (101, 102; 201, 202) mit proprietären Schnittstellen, wobei a) die Applikationen über einen Databroker (1) für die Datenübermittlung gekoppelt sind, b) die Datenübermittlung mittels Requests und Responses über den Databroker (1) erfolgt, c) die Requests/Responses als XML-Nachrichten ausgebildet sind, d) den verschiedenen Standorten (42 bis 50) mit unterschiedlichen Installationstypen (I bis IV) im Bezug auf ihre Einbindung in das Netzwerk (40) vom Installationstyp (I bis IV) abhängige Kompetenzen im Bezug auf die Speicherung und/oder die Verteilung von Daten für die Applikationen zugewiesen werden.
5. Verfahren nach Anspruch 4 , dadurch gekennzeichnet, dass die Standorte (42 bis 50) einem von vier unterschiedlichen
Installationstypen (I bis IV) zugewiesen werden, wobei a) ein erster Installationstyp (I) einen zentralen Server (ZS) mit zentraler Datenbank (ZDB) , einen lokalen Server (LS) mit einer lokalen Datenbank (LDB) , einen zentralen Diensteserver (ZD) sowie in ein lokales Netzwerk (LAN) eingebundene Clients (LC) umfasst; b) ein zweiter Installationstyp (II) einen lokalen Server -(LS) mit einer lokalen Datenbank (LDB), ggfs. beide vorstehend genannten Einheiten in redundanter Ausführung, sowie in ein lokales Netzwerk (LAN) eingebundene Clients (LC) umfasst; c) ein dritter Installationstyp (III) in ein lokales Netzwerk (LAN) eingebundene Clients (LC) umfasst; und d) ein vierter Installationstyp (IV) mindestens einen mobilen Client (LCM) umfasst, - wobei die hierarchische Zuordnung wie folgt vorgesehen ist: e) der dritte und der vierte Installationstyp (III bzw. IV) greifen auf den zweiten Installationstypen (II) zu; f) der zweite Installationstyp' (II) umfasst ein Datenabbild des ersten Installationstyps (I) , welches der zweite Installationstyp (II) aber nicht berechtigt ist, zu modi izieren; und g) nur im ersten Installationstyp (I) Einträge in die zentrale Datenbank (ZDB) sowie ggfs. weitere redundante zentrale Datenbanken (RZDB) vorgenommen werden.
6. Netzwerk nach Anspruch 5, dadurch gekennzeichnet, dass. im Diensteserver (ZD) ein zentraler Authentisierungs-, ein
Naming- und ein Notification-Dienst bereitgestellt werden.
EP05707543A 2004-05-08 2005-02-21 Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen Withdrawn EP1745633A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05707543A EP1745633A1 (de) 2004-05-08 2005-02-21 Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP04010982A EP1594058A1 (de) 2004-05-08 2004-05-08 Netzwerk und Verfahren zur Datenübermittlung zwischen Applikationen mit prorietären Schnittstellen
PCT/EP2005/001762 WO2005109828A1 (de) 2004-05-08 2005-02-21 Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen
EP05707543A EP1745633A1 (de) 2004-05-08 2005-02-21 Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen

Publications (1)

Publication Number Publication Date
EP1745633A1 true EP1745633A1 (de) 2007-01-24

Family

ID=34924916

Family Applications (2)

Application Number Title Priority Date Filing Date
EP04010982A Withdrawn EP1594058A1 (de) 2004-05-08 2004-05-08 Netzwerk und Verfahren zur Datenübermittlung zwischen Applikationen mit prorietären Schnittstellen
EP05707543A Withdrawn EP1745633A1 (de) 2004-05-08 2005-02-21 Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP04010982A Withdrawn EP1594058A1 (de) 2004-05-08 2004-05-08 Netzwerk und Verfahren zur Datenübermittlung zwischen Applikationen mit prorietären Schnittstellen

Country Status (2)

Country Link
EP (2) EP1594058A1 (de)
WO (1) WO2005109828A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10041104C1 (de) * 2000-08-22 2002-03-07 Siemens Ag Einrichtung und Verfahren zur Kommunikation zwischen einer mobilen Datenverarbeitungsvorrichtung und einer stationären Datenverarbeitungsvorrichtung
EP1581867A2 (de) * 2003-01-08 2005-10-05 Siemens Schweiz AG Anordnung und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005109828A1 *

Also Published As

Publication number Publication date
EP1594058A1 (de) 2005-11-09
WO2005109828A1 (de) 2005-11-17

Similar Documents

Publication Publication Date Title
DE69635047T2 (de) Vernetzte server mit kundenspezifischen diensten zum herunterladen von videos
EP0825524B1 (de) Verfahren zur Verwaltung der Benennung von Objekten
DE60308700T2 (de) Dynamische fernkonfiguration eines webservers zur bereitstellung von kapazität auf anfrage
DE69818232T2 (de) Verfahren und system zur verhinderung des herunterladens und ausführens von ausführbaren objekten
DE10036726A1 (de) Skalierbares Multimedia-Dateisystem für Netzergänzungsspeichergeräte
WO2002033802A1 (de) Verfahren zur anzeige des betriebsverhaltens von anlagen
EP1563371A1 (de) Vorrichtung zur entwicklung und/oder konfiguration eines automatisierungssystems
EP1745633A1 (de) Netzwerk und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen
EP1524608B1 (de) Kommunikationssystem zur Verwaltung und Bereitstellung von Daten
EP1195678B1 (de) Verfahren zum Betreiben eines Datenverarbeitungssystems mit Redundanz-Datenverarbeitungseinheit
EP2915304B1 (de) Verfahren und system zum zugreifen auf daten in einem verteilten netzwerksystem
DE10129886A1 (de) Verfahren zum Netzkonfigurationsmanagement und Netzbestandsmanagement eines Netzes und entsprechendes Netzkonfigurationsmanagement- und Netzbestandsmanagementsystem
EP1843929B1 (de) Leitsystem für die steuerung und/oder überwachung von objekten
EP1844396B1 (de) Verfahren zum unterbrechungsfreien software-update
EP1581867A2 (de) Anordnung und verfahren zur datenübermittlung zwischen applikationen mit proprietären schnittstellen
DE19951756B4 (de) Verfahren zur Datenverwaltung sowie Computerprogramm und -system zu dessen Ausführung
EP1610517A1 (de) Netzwerk zur Datenübermittlung zwischen Applikationen mit applikationsspezifischen Anwendungsadaptern
DE10319887A1 (de) Verfahren zum Angleichen eines auf einer Client-Datenverarbeitungseinrichtung angezeigten Datenbestandes an einen auf einer Server-Datenverarbeitungseinrichtung gespeicherten Quelldatenbestand
EP1402421A2 (de) Integriertes dokumentationssystem mit zeitindiziertem relationalem datenbanksystem
DE202022100357U1 (de) Ein System zur Verkehrsabweisung für eine Hochleistungs-Gateway-Plattform mit phasenweiser Deaktivierung von Diensten
EP2452249A1 (de) Verfahren zum kontrollieren eines betriebs eines rechennetzwerks
WO2005081078A1 (de) Verfahren und system zum bereitstellen von einstellwerten für elektrische geräte einer automatisierungsanlage
WO2003017611A1 (de) Kopplungsmittel für eine datenverarbeitungsvorrichtung
WO2003065144A2 (de) Verfahren zum empfang und zur weiterleitung beliebiger client-anfragen in einem client/serversystem
DE10025397A1 (de) Internetaktivitätsprotokollierung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060930

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DE PASCALE, PIERRE

Inventor name: JEANNERET, GAEL

Inventor name: AKERET, FELIX

Inventor name: STUDER, HORST

RIN1 Information on inventor provided before grant (corrected)

Inventor name: AKERET, FELIX

Inventor name: STUDER, HORST

Inventor name: DE PASCALE, PIERRE

Inventor name: JEANNERET, GAEL

RIN1 Information on inventor provided before grant (corrected)

Inventor name: AKERET, FELIX

Inventor name: STUDER, HORST

Inventor name: JEANNERET, GAEL

Inventor name: DE PASCALE, PIERRE

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20070906

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS SCHWEIZ AG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091031