EP1759509A1 - Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern - Google Patents

Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern

Info

Publication number
EP1759509A1
EP1759509A1 EP04803889A EP04803889A EP1759509A1 EP 1759509 A1 EP1759509 A1 EP 1759509A1 EP 04803889 A EP04803889 A EP 04803889A EP 04803889 A EP04803889 A EP 04803889A EP 1759509 A1 EP1759509 A1 EP 1759509A1
Authority
EP
European Patent Office
Prior art keywords
data
application
applications
network
xml
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
EP04803889A
Other languages
English (en)
French (fr)
Inventor
Gaël JEANNERET
Horst Studer
Felix Akeret
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.)
Atos IT Solutions and Services 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 EP04803889A priority Critical patent/EP1759509A1/de
Publication of EP1759509A1 publication Critical patent/EP1759509A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to a network for data transmission between applications with proprietary interfaces, in which the applications can be coupled via a data broker for data transmission, the data transmission by means of requests and responses via the data broker is feasible and the requests / responses are designed as XML messages.
  • 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 various manufacturers have to be networked in integrated systems.
  • the OMG body has specified the CORBA architecture, which can be used to communicate the various applications, also known as applications.
  • So-called CORBA applications consist of one or more objects which represent an image of one or more real processes - a function and associated data. Each object is assigned a type. There are usually several instances of an object.
  • An e-commerce web application consists of those instances which correspond to the shopping cart of the current users or customers of this web application.
  • For the specification of the architecture CORBA reference is made to document [1].
  • an interface partition is necessary.
  • the applications have interfaces based on CORBA specifications, which are defined in the CORBA IDL (Interface Definition Language) and then translated and implemented in the various implementation languages of the target systems.
  • CORBA IDL Interface Definition Language
  • the invention is therefore an object of the invention to provide a network that allows in particular for the integration of new applications, particularly easy to initialize the later intended function of the application required data traffic and subsequently perform in everyday operation of the network.
  • this object is achieved by a network for data transmission between applications with proprietary interfaces, in which the data broker has an application-specific application adapter for each of the applications coupling to it, wherein each application adapter comprises an XML en / decoding unit, a generic interface and a notification interface ,
  • the generic interface takes over the administration of the application with regard to the required and / or delivered user data in the network.
  • the notification interface ensures that relevant data for this application are made available to other applications embedded in the network or are obtained from the rest of the application.
  • the data required for an application and / or the data supplied by an application can be packed into an XML format and / or extracted from an XML format by means of the XML En / Decoding unit.
  • the XML format is a framework within which any user data from different applications can be transported through the network.
  • a central name management service can be provided, in which the associated application logs on by means of its generic interface.
  • the generic interface can be designed such that it stores the names of the data which are required by this application and / or can be delivered to the central name management service.
  • the notification interface can be used in a targeted manner to subscribe to an application in a central notification service To register data and / or as a supplier of certain data. This also ensures a clean separation between the information to be provided to the name management service and the actual retrieval or provision of data, which in particular simplifies the integration of new applications into the network as well as the modification of the data requirements of existing applications.
  • a data change message can be sent to all the notification interfaces for which the associated application is registered as a subscriber of this data in the central notification service.
  • the notification interface can be configured such that in the case of a data change in an application (possibly also by a data input originating from another application) an update message is sent to the central notification service.
  • the notification interface can be designed such that a demand for certain data currently required by an application can be sent to the central notification service. In this way, an application can independently determine and schedule the data it subscribes to.
  • FIG. 1 shows an overview of the arrangement of different applications exchanging data via a CORBA-based data broker
  • FIG. 2 shows a communication network operating according to the arrangement according to FIG. 1 with a first example for the function of the application adapter
  • FIG. 3 shows a communication network operating according to the arrangement according to FIG. 1 with a second example for the function of the application adapter.
  • FIG. 1 shows an overview of the arrangement of various applications which exchange data via a CORBA-based data broker 1.
  • the data broker is designed as a CORBA / ORB data broker.
  • Reference numeral 10 denotes so-called peripheral systems.
  • the individual applications 101, 102, 103, 104, etc. represent, for example, a weather data evaluation system, a communication system for the acquisition of ground pressure and temperature data, etc.
  • the surrounding systems 10 are the necessary subsystems and thus serve the support of the weather service. System to be fulfilled task.
  • the reference numeral 20 denotes so-called engagement systems.
  • the individual intervention systems 201, 202 stand, for example, for the control of the use of mobile weather stations, such as rising weather balloons, as well as the general control of automatic weather stations. From the application, the aforementioned two engagement 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, and so forth.
  • peripheral systems 10 and intervention systems 20 are not located in one place, but are generally located over a region, e.g. a country, distributed.
  • the data core 1 is subdivided by so-called data guards 2.
  • These dataguards 2 have the function of a firewall. This is to be distinguished from an encryption, which is described below.
  • the data associated with the weather service system is kept in a relational database 27; Access and administration take place via a data manager 28.
  • peripheral systems 10 and the engagement systems 20 usually represent a rather complex network, within which on the one hand the applications 101 to 104, 201, 202 are subject to more or less constant changes and on the other completely new applications or
  • application adapters 50 (FIG. 2) are provided, which on account of their construction make it possible to provide these adaptation functions mentioned above particularly simply and with only little effort.
  • the application adapters 50 all have the same structure, which essentially comprises an XML En / Decoding XML, a generic interface GI and a notification interface NI.
  • the XML En / Decoding XML ensures that the user data required for the application and / or the user data supplied by the application are transported in an XML frame by the Data Broker 1.
  • the function of the generic interface GI and the notification interface NI can best be explained by means of the work flow a) to i).
  • a data bus 1 ' is additionally provided, which is still used, for example, due to an older connection of the applications 102 and 103 to a data exchange of these two applications.
  • the application 202 now experiences, for example, a reprogramming and now requires more specific new data that this application has not previously received.
  • the notification interface NI of the application 202 logs in as an interested party for this data at a notification service NoS arranged in a network service NwS.
  • the application 102 notifies in a step b) a data change over the data bus 1 'to the application 103.
  • the changed data are written in a step c) in a local database of the application 103, that is updated there.
  • the application adapter 50 of the application 103 then takes in a step d) the Updated this data by, for example, by means of database trigger or by monitoring the events on the local database of the application 103 has followed.
  • the updated data now packed in XML format are now sent by the application adapter 50 using its generic interface Gl in a step e) to the generic interface GI of the application adapter 50 of the file manager 28, which in step f) with an update of the central database 27 results.
  • FIG. 3 shows an example of a functional sequence from the point of view of the application 103 with the steps a) to g) in a schematic representation.
  • the application 103 logs in according to step a) using their notification interface NI as an interested party for certain data of the application 202 in the notification service NoS.
  • a transmission of updated data takes place, which in step c) results in an update of the central database 27.
  • the generic interfaces GI are responsible, which provide or receive the data packed in the XML frame.
  • step d) the notification interface NI notifies the updating of this data to the notification service NoS, which in the Step e) ua also informed the application 103 on its notification interface Nl about the data update. Accordingly, the bidirectional arrow in step f) symbolizes the retrieval and delivery of the updated data via the respective generic interfaces GI. Finally, in step f), after the XML decoding has taken place, the data is updated on a local database of the application 103.
  • This example also shows, due to the clear structure of the application adapter 50, in which simple way data can be exchanged within the communication network shown.
  • the simple structure of generic interface so the operational sending and / or In particular, obtaining data and messaging interface, that is, operationally communicating what data is needed or delivered, makes it possible to accomplish the incorporation of new applications in a simple and cost-effective manner.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (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 zur Datenübermittlung zwischen Applikationen (101, 102, 103; 201, 202) mit proprietären Schnittstellen, wobei a) die Applikationen (101, 102, 103, 104; 201, 202) über einen Databroker (1) für die Datenübermittlung koppelbar sind, b) die Datenübermittlung mittels Requests und Responses über den Databroker (1) durchführbar ist, c) die Requests/Responses als XML-Nachrichten ausgebildet sind, dadurch gekennzeichnet, dass der Databroker (1) für jede der an ihm ankoppelnden Applikationen (101, 102, 201, 202) einen applikationsspezifischen Anwendungsadapter (50) aufweist, wobei jeder Anwendungsadapter (50) eine XML En-/Decoding Einheit (XML), ein generisches Interface (GI) und ein Benachrichtigungsinterface (GI) umfasst.

Description

Netzwerk zur Datenübermittlung zwischen Applikationen mit applikationsspezifischen Anwendungsadaptern
Die vorliegende Erfindung betrifft ein Netzwerk zur Datenübermittlung zwischen Applikationen mit proprietären Schnittstellen, bei dem die Applikationen über einen Databroker für die Datenübermittlung koppelbar sind, die Datenübermittlung mittels Requests und Responses über den Databroker durchführbar ist und die Requests/Responses als XML-Nachrichten ausgebildet sind.
Die vorliegende Erfindung ist auf dem Gebiet der Informa- tions- und Kommunikationstechnologie 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 Objek¬ ten, 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 ent¬ sprechen. 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 Schnittsteilenderinition notwendig. Die Appli¬ kationen 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 Archi¬ tektur einen Datenaustausch zwischen verschiedenen Daten¬ quellen 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.
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.
Nachteilig ist jedoch in diesem Umfeld, dass die Organisation des Datenaustausches besonders im Fall der Integration neuer Applikationen aufwendig ist, weil im besonderen dem zentralen Datenserver und der neuen Schnittstelle zu dieser Applikation ein hoher integrativer Aufwand zufällt.
Der Erfindung liegt daher die Aufgabe zugrunde, ein Netzwerk anzugeben, das es im besonderen zur Integration neuer Applikationen ermöglicht, den für die spätere bestimmungsgemässe Funktion der Applikation erforderlichen Datenverkehr besonders einfach zu initialisieren und nachfolgend im Alltagsbetrieb des Netzwerkes durchführen zu können.
Diese Aufgabe wird erfindungsgemäss durch ein Netzwerk zur Datenübermittlung zwischen Applikationen mit proprietären Schnittstellen gelöst, bei dem der Databroker für jede der an ihm ankoppelnden Applikationen einen applikationsspezifischen Anwendungsadapter aufweist, wobei jeder Anwendungsadapter eine XML En-/Decoding Einheit, ein generisches Interface und ein Benachrichtigungsinterface umfasst.
Auf diese Weise besteht für alle Applikationen ein vom Grundtyp her immer gleicher Anwendungsadapter zur Verfügung, der mit seiner XML En-/Decoding Einheit den Verkehr der Nutzdaten vollkommen unabhängig von der Art und dem Umfang der Nutzdaten gewährleistet. Davon getrennt übernimmt das generische Interface die Verwaltung der Applikation hinsichtlich der benötigten und/oder gelieferten Nutzdaten im Netzwerk. Weiter stellt das Benachrichtigungsinterface sicher, dass für andere im Netzwerk eingebundene Applikationen relevante Daten dieser Applikation entsprechend zur Verfügung gestellt werden bzw. von den übrigen Applikation erhalten werden.
In zweckmässiger Ausgestaltung der Erfindung können daher mittels der XML En-/Decoding Einheit die für eine Applikation erforderlichen Daten und/oder die von einer Applikation gelieferten Daten in ein XML Format verpackt werden und/oder aus einem XML Format entpackt werden. Auf diese Weise stellt das XML Format einen Rahmen dar, innerhalb dessen beliebige Nutzdaten von verschiedenen Applikation durch das Netzwerk transportiert werden können.
Damit bereits im Netzwerk eingebundene Applikation überhaupt Kenntnis davon haben, welche Applikationen tatsächlich eingebunden sind oder welche Applikation neu hinzugekommen ist, kann ein zentraler Namensverwaltungsdienst vorgesehen sein, bei dem sich die zugehörige Applikation mittels ihres generischen Interfaces anmeldet. Weiter kann das generische Interface so ausgestaltet sein, dass es bei dem zentralen Namensverwaltungsdienst die Namen der Daten hinterlegt, die von dieser Applikation benötigt werden und/oder geliefert werden können.
Um den Datenaustausch nun effektiv gestalten zu können und um es auch neu hinzugekommenen Applikationen zu ermöglichen, auf Daten bereits bestehender Applikationen zuzugreifen oder diese mit Daten zu versorgen, kann ganz gezielt das Benachrichtigungsinterface genutzt werden, um eine Applikation bei einem zentralen Benachrichtigungsdienst als Abonnent von bestimmten Daten und/oder als Lieferant von bestimmten Daten registrieren zu lassen. Damit wird auch eine saubere Trennung vollzogen zwischen der dem Namenverwaltungsdienst zur Verfügung zu stellenden Information und dem eigentlichen Abrufen oder Zurverfügungstellen von Daten, was insbesondere auch die Einbindung neuer Applikationen in das Netzwerk wie auch die Modifikation des Datenbedarfs bestehender Applikationen vereinfacht.
Um im besonderen die Applikationen, die Abonnenten von bestimmten Daten sind, möglichst schnell mit den für sie erforderlichen aktuellen Daten bedienen zu können, kann mittels des zentralen Benachrichtigungsdienstes im Falle einer Datenänderung eine Datenänderungsmeldung an alle die Benachrichtigungsinterfaces versendet werden, für die die zugehörige Applikation als Abonnent dieser Daten im zentralen Benachrichtigungsdienst registriert ist. Entsprechend kann in der anderen Richtung das Benachrichtigungsinterface so ausgestaltet sein, dass im Falle einer Datenänderung in einer Applikation (ggfs. auch durch einen von einer anderen Applikation stammenden Dateninput) eine Update-Meldung an den zentralen Benachrichtigungsdienst versendet werden. Weiter kann das Benachrichtigungsinterface so gestaltet sein, dass eine Nachfrage nach bestimmten aktuell von einer Applikation benötigten Daten an den zentralen Benachrichtigungsdienst gesendet werden kann. Auf diese Weise kann eine Applikation auch selbständig die von ihr abonnierten Daten bestimmen und disponieren.
Weitere vorteilhafte Ausgestaltungen der Erfindung sind den übrigen Unteransprüche zu entnehmen.
Die Erfindung wird nachfolgend anhand einer Zeichnung bei¬ spielsweise näher erläutert. Dabei zeigen:
Figur 1 Übersicht der Anordnung von verschiedenen Applikation, die über einen auf CORBA basierenden Databroker Daten austauschen;
Figur 2 ein gemäss der Anordnung nach Figur 1 arbeitendes Kommunikationsnetzwerk mit einem ersten Beispiel zur Funktion der Anwendungsadapter; und
Figur 3 ein gemäss der Anordnung nach Figur 1 arbeitendes Kommunikationsnetzwerk mit einem zweiten Beispiel zur Funktion der Anwendungsadapter.
Das nachfolgende Ausführungsbeispiel betrifft ein integrier¬ tes 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 Anwendungen 101, 102, 103, 104 usw. stehen beispielsweise für ein Wetterdatenbewertungssystem, für ein KommunikationsSystem zur Erfassung von Bodenluftdruck- und -temperaturdaten, usw. Die Umsysteme 10 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 Notifika¬ tionsdienst 301, eine Workflow Engine 302, einen Namensdienst usw.
Umsysteme 10 und EingriffSysteme 20 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 10 und die Eingriffssysteme 20 in der Regel ein eher komplexes Netzwerk darstellen, innerhalb dessen einerseits die Anwendungen 101 bis 104, 201, 202 mehr oder weniger ständigen Veränderungen unterworfen sind und andererseits komplett neue Anwendungen hinzutreten oder bestehende Anwendungen ausscheiden, sind im vorliegenden Ausführungsbeispiel Anwendungsadapter 50 (Fig. 2) vorgesehen, die es aufgrund ihres Aufbaus ermöglichen, diese voranstehend genannten Anpassungsfunktionen besonders einfach und mit nur geringem Aufwand zu bieten.
Mit Bezug auf Figur 2 ist in dem Kommunikationsnetzwerk nach Figur 1 ein diesbezüglicher Arbeitsfluss der Anwendungsadapter 50 mit den Schritten a) bis i) gezeigt. Die Anwendungsadapter 50 haben alle den gleichen Aufbau, der im wesentlichen ein XML-En-/Decoding XML, ein generisches Interface GI und ein Benachrichtigungsinterface NI umfasst. Das XML En-/Decoding XML sorgt dabei dafür, dass die für die Anwendung erforderlichen Nutzdaten und/oder die von der Anwendung gelieferten Nutzdaten in einem XML Rahmen durch den Data Broker 1 transportiert werden. Die Funktion des generischen Interfaces GI und des Benachrichtigungsinterfaces NI sind am besten anhand des Arbeitflusses a) bis i) erläuterbar.
In diesem Ausführungsbeispiel wird zusätzlich ein Datenbus 1' vorgesehen, der beispielsweise aufgrund einer älteren Verknüpfung der Anwendungen 102 und 103 noch zu einem Datenaustausch dieser beiden Anwendungen genutzt wird. Die Anwendung 202 erfährt nun beispielsweise eine Umprogrammierung und benötigt nun mehr bestimmte neue Daten, die diese Anwendung vorher noch nicht erhalten hat. Für diesen ersten Schritt a) meldet sich daher das Benachrichtigungsinterface NI der Anwendung 202 als Interessent für diese Daten bei einem in einem Netzwerkservice NwS angeordneten Benachrichtigungsdienst NoS an. Irgendwann später meldet die Anwendung 102 in einem Schritt b) eine Datenänderung über den Datenbus 1' an die Anwendung 103. Die geänderten Daten werden in einem Schritt c) in eine lokale Datenbank der Anwendung 103 geschrieben, also dort aktualisiert. Der Anwendungsadapter 50 der Anwendung 103 nimmt daraufhin in einem Schritt d) die Aktualisierung dieser Daten wahr, indem er beispielsweise mittels Datenbank-Trigger oder durch Monitoring das Geschehen auf der lokalen Datenbank der Anwendung 103 verfolgt hat.
Die nun im XML Format verpackten aktualisierten Daten werden nun vom Anwendungsadapter 50 mit Hilfe seines generischen Interfaces Gl in einem Schritt e) an das generische Interface GI des Anwendungsadapters 50 des Datei-Managers 28 gesendet, was im Schritt f) mit einer Aktualisierung der zentralen Datenbank 27 resultiert. Der Datei-Manager 27 sendet in Antwort auf die erfolgte Aktualisierung mittels seines Benachrichtigungsinterfaces NI im Schritt g) eine Benachrichtigung an den Benachrichtigungsdienst NoS, dass bestimmte Daten nun in aktualisierten Form in der zentralen Datenbank 27 vorliegen. Aufgrund ihrer Anmeldung im Schritt a) erhält nun die Anwendung 202 von dem Benachrichtigungsdienst NoS im Schritt g) eine diesbezügliche Aktualisierungsmeldung am Benachrichtigungsinterface NI.
Selbstverständlich erhalten auch alle übrigen Anwendungen, die sich beim Benachrichtigungsdienst NoS für diese Daten angemeldet haben, einen entsprechenden Hinweis. Mit einem bidirektionalen Pfeil zwischen den generischen Interfaces GI der Anwendung 202 und dem Datei-Manager 28 werden in einem Schritt i) nun die aktualisierten Daten aus der zentralen Datenbank 27 abgerufen und an die Anwendung 202 übermittelt. Dabei sorgt das Decoding im XML En-/Decoding XML dafür, dass die in einem XML Rahmen transportierten Daten nun in der für die Anwendung 202 erforderlichen Form zur Verfügung stehen.
Für die weitere Betrachtung des Ausführungsbeispiels nach der Figur 2 wird jetzt angenommen, dass die Anwendung 102 modernisiert und stärker an den Data Broker 1 angebunden wird. Es ist diesbezüglich nur der Anwendungsadapter 50 der Anwendung 102 zu modifizieren, die sich mittels des generischen Interfaces GI bei dem Namensdienst NaS anmeldet und dort mitteilt, welche Daten die Anwendung 102 nun direkt liefert. Entsprechend wird das generische Interface GI diesbezügliche aktualisierte Daten direkt an das generische Interface GI des Datei-Managers 28 senden. Die darauffolgende weitere Benachrichtigung und der Datenaustausch läuft dann wie bereits beschrieben mit den Schritten g) , h) und i) ab.
Figur 3 zeigt einen beispielhaften Funktionsablauf nun aus der Sicht der Anwendung 103 mit den Schritten a) bis g) in schematischer Darstellung. Die Anwendung 103 meldet sich gemäss Schritt a) mit Hilfe ihres Benachrichtigungsinterface NI als Interessent für bestimmte Daten der Anwendung 202 bei dem Benachrichtigungsdienst NoS an. Auch findet zu einem späteren von der Anmeldung unabhängigen Zeitpunkt im Schritt b) eine Sendung von aktualisierten Daten statt, die im Schritt c) zu einer Aktualisierung der zentralen Datenbank 27 führt. Für diesen Datenaustausch sind wiederum ausschliesslich die generischen Interfaces GI zuständig, die die im XML Rahmen verpackten Daten bereitstellen bzw. erhalten. Das Encoding und das Decoding dieser XML Rahmen erfolgt wie gehabt im XML En-/Decoding XML der jeweiligen Anwendungsadapter 50 von Anwendung 202 und Datei-Manager 28. Im Schritt d) meldet das Benachrichtigungsinterface NI die Aktualisierung dieser Daten an den Benachrichtigungsdienst NoS, der im Schritt e) u.a. auch die Anwendung 103 an ihrem Benachrichtigungsinterface Nl über die Datenaktualisierung informiert. Entsprechend symbolisiert der bidirektionale Pfeil im Schritt f) den Abruf und die Lieferung der aktualisierten Daten über die jeweiligen generischen Interfaces GI. Abschliessend erfolgt im Schritt f) nach erfolgtem XML Decoding die Aktualisierung der Daten auf einer lokalen Datenbank der Anwendung 103.
Auch diese Beispiel zeigt aufgrund der klaren Struktur des Anwendungsadapters 50, in welch einfacher Weise Daten innerhalb des gezeigten Kommunikationsnetzwerkes ausgetauscht werden können. Besonders die einfache Struktur von generischen Interface, also dem operativen Senden und/oder Erhalten von Daten, und Benachrichtigungsinterface, also dem operativen Mitteilen, welche Daten benötigt oder geliefert werden, macht es im besonderen möglich, die Einbindung von neuen Anwendungen in einfacher und vom Aufwand her vertretbarer Weise zu bewerkstelligen.
Im Rahmen der vorliegenden Erfindung sind daher natürlich eine nahezu unbegrenzte Anzahl von Änderungen und Modifikation möglich. Besonders zu erwähnen ist u.a. auch noch die Möglichkeit, dass sich die Anwendungen auch direkt unter Umgehung der zentralen Datenbank 27 bei anderen Anwendungen mit Daten versorgen können. Diese diesbezüglichen Abläufe werden im wesentlichen vom Namensservice NaS administriert bzw. durch aktive Anmeldung beim Benachrichtigungsdienst initiiert.
Liste der verwendeten Akronyme
CORBA Common Object Reguest 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: Core Specification, December 2002, Version 3.0

Claims

Patentansprüche
1. Netzwerk zur Datenübermittlung zwischen Applikationen (101, 102, 103, 104; 201, 202) mit proprietären Schnittstellen, wobei a) die Applikationen (101, 102, 103, 104; 201, 202)über einen Databroker (1) für die Datenübermittlung koppelbar sind, b) die Datenübermittlung mittels Requests und Responses über den Databroker (1) durchführbar ist, c) die Requests/Responses als XML-Nachrichten ausgebildet sind, dadurch gekennzeichnet, dass der Databroker (1) für jede der an ihm ankoppelnden Applikationen (101, 102, 201, 202) einen applikationsspezifischen Anwendungsadapter (50) aufweist, wobei jeder Anwendungsadapter (50) eine XML En-/Decoding Einheit (XML) , ein generisches Interface (GI) und ein Benachrichtigungsinterface (GI) umfasst.
2. Netzwerk (40) nach Anspruch 1, dadurch gekennzeichnet, dass mittels der XML En-/Decoding Einheit (XML) die für eine Applikation (101, 102, 103, 104; 201, 202) erforderlichen Daten und/oder die von einer Applikation (101, 102, 103, 104; 201, 202) gelieferten Daten in ein XML Format verpackbar und/oder aus einem XML Format entpackbar sind.
3. Netzwerk (40) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass mittels des generischen Interfaces (GI) bei einem zentralen Namensverwaltungsdienst (NaS) die zugehörige Applikation (101, 102, 103, 104; 201, 202) anmeldbar ist.
4. Netzwerk (40) nach Anspruch 3, dadurch gekennzeichnet, dass mittels des generischen Interfaces (GI) bei einem zentralen Namensverwaltungsdienst (NaS) die Namen der Daten hinterlegbar sind, die von dieser Applikation (101, 102, 103, 104; 201, 202) benötigt und/oder geliefert werden.
5. Netzwerk (40) nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass mittels des Benachrichtigungsinterfaces (NI) eine Applikation (101, 102, 103, 104; 201, 202) bei einem zentralen Benachrichtigungsdienst (NoS) als Abonnent von bestimmten Daten und/oder als Lieferant von bestimmten Daten registrierbar ist.
6. Netzwerk (40) nach Anspruch 5, dadurch gekennzeichnet, dass mittels des zentralen Benachrichtigungsdienstes (NoS) im Falle einer Datenänderung eine Datenänderungsmeldung an alle die Benachrichtigungsinterfaces (NI) versendbar ist, für die die zugehörige Applikation (101, 102, 103, 104; 201, 202) als Abonnent dieser Daten im zentralen Benachrichtigungsdienst (NoS) registriert ist.
7. Netzwerk (40) nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass mittels des Benachrichtigungsinterface (NI) im Falle einer Datenänderung in einer Applikation (101, 102, 103, 104; 201, 202) eine Update-MeIdüng an den zentralen Benachrichtigungsdienst (NoS) versendbar ist.
8. Netzwerk (40) nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, dass eine Applikation (101, 102, 103, 104; 201, 202) mittels des Benachrichtigungsinterfaces (NI) eine Nachfrage nach bestimmten aktuell von der Applikation (101, 102, 103, 104; 201, 202) benötigten Daten an den zentralen Benachrichtigungsdienst (NoS) sendet.
EP04803889A 2004-06-24 2004-12-15 Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern Withdrawn EP1759509A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04803889A EP1759509A1 (de) 2004-06-24 2004-12-15 Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP04014808A EP1610517A1 (de) 2004-06-24 2004-06-24 Netzwerk zur Datenübermittlung zwischen Applikationen mit applikationsspezifischen Anwendungsadaptern
PCT/EP2004/014269 WO2006000250A1 (de) 2004-06-24 2004-12-15 Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern
EP04803889A EP1759509A1 (de) 2004-06-24 2004-12-15 Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern

Publications (1)

Publication Number Publication Date
EP1759509A1 true EP1759509A1 (de) 2007-03-07

Family

ID=34925476

Family Applications (2)

Application Number Title Priority Date Filing Date
EP04014808A Withdrawn EP1610517A1 (de) 2004-06-24 2004-06-24 Netzwerk zur Datenübermittlung zwischen Applikationen mit applikationsspezifischen Anwendungsadaptern
EP04803889A Withdrawn EP1759509A1 (de) 2004-06-24 2004-12-15 Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP04014808A Withdrawn EP1610517A1 (de) 2004-06-24 2004-06-24 Netzwerk zur Datenübermittlung zwischen Applikationen mit applikationsspezifischen Anwendungsadaptern

Country Status (2)

Country Link
EP (2) EP1610517A1 (de)
WO (1) WO2006000250A1 (de)

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
EP1610517A1 (de) 2005-12-28
WO2006000250A1 (de) 2006-01-05

Similar Documents

Publication Publication Date Title
DE60008555T2 (de) Verfahren und vorrichtung zur effizienten übertragung von daten einer interaktiven anwendung zwischen klienten und server mit hilfe einer markup-sprache
DE69624579T2 (de) System und verfahren für eine verteilte objektverwaltungsumgebung an mehreren orten
DE60308700T2 (de) Dynamische fernkonfiguration eines webservers zur bereitstellung von kapazität auf anfrage
DE60122691T2 (de) Verfahren und vorrichtung zum verteilten cachen
DE60306932T2 (de) Schnelle Datenbankreplikation
DE60133384T2 (de) GEZIELTE NACHRICHTEN FüR EIN ENDBENUTZERGERÄT, DAS MIT EINEM DIENSTKNOTEN IN EINEM KOMMUNIKATIONSNETZ VERBUNDEN IST
EP3523927A1 (de) Konzept zum steuern einer nachrichtenübermittlung zwischen kommunikationsteilnehmern eines automatisierungssystems
DE19822553A1 (de) Netzelement mit einer Steuerungseinrichtung und Steuerungsverfahren
WO2003094046A2 (de) Verzeichnisdienst in einem automatisierungssystem
DE10332360A1 (de) Verfahren und System zur Ereignisübertragung
DE69630316T2 (de) Verfahren und einrichtung zur laufzeit verbindungsherstellung zwischen kunden und anbietern in einem verteilten netzwerk
EP1484882A1 (de) Verfahren zum Überwachen von Teilnehmerdiensten in einem Telekommunikationsnetz
EP1759509A1 (de) Netzwerk zur datenübermittlung zwischen applikationen mit applikationsspezifischen anwendungsadaptern
EP1524608B1 (de) Kommunikationssystem zur Verwaltung und Bereitstellung von Daten
EP1437655A2 (de) Rechner- und/oder Software-Architektur unter Verwendung von Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik
WO1999044163A1 (de) Verfahren und einrichtung zur publikation von nachrichten, werbebotschaften und dergleichen darstellenden daten
DE10129886A1 (de) Verfahren zum Netzkonfigurationsmanagement und Netzbestandsmanagement eines Netzes und entsprechendes Netzkonfigurationsmanagement- und Netzbestandsmanagementsystem
EP1158747A2 (de) Verfahren zum Übertragen von Daten
DE10152874B4 (de) Kommunikationsanordnung und Verfahren zum Datenaustausch mit Adressierungsservice
EP1139243A1 (de) Abrechnungs- und Kundenverwaltungssystem
EP1844396B1 (de) Verfahren zum unterbrechungsfreien software-update
WO2005011303A1 (de) Individuelle dienstanbieterspezifische aktualisierung oder neugestaltung von ansage- und dialogdiensten
WO2000057299A2 (de) Verfahren und anordnung zur installation und verfahren und anordnung zur installation und zum betreiben eines von einem nutzerrechner angeforderten dienstes
EP1098486B1 (de) Caching-Verfahren und Cachesystem
EP2017753B1 (de) Verfahren zur steuerung von datenbankübergreifenden routinen

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: 20061116

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

17Q First examination report despatched

Effective date: 20070320

RIN1 Information on inventor provided before grant (corrected)

Inventor name: AKERET, FELIX

Inventor name: STUDER, HORST

Inventor name: JEANNERET, GAEL

RIN1 Information on inventor provided before grant (corrected)

Inventor name: STUDER, HORST

Inventor name: AKERET, FELIX

Inventor name: JEANNERET, GAEL

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS SCHWEIZ AG

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

Owner name: SIEMENS IT SOLUTIONS AND SERVICES AG

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

Owner name: ATOS IT SOLUTIONS AND SERVICES 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: 20150728