Einrichtung und Verfahren zur Verteilung und Weiterleitung von Anforderungen zu einer Mehrzahl von Web-Servern in einer industriellen Automatisierungsanordnung

Die Erfindung betrifft eine Einrichtung zur Verteilung und Weiterleitung von Anforderungen gemäß dem Oberbegriff des Pa- tentanspruchs 1, und ein Verfahren zur Verteilung und Weiterleitung von Anforderungen gemäß dem Oberbegriff des Patentanspruchs 11.

In automatisierungstechnischen Einrichtungen und Anordnungen kommunizieren Komponenten und Einrichtungen häufig mittels des TCP/IP-Protokolls und anderer aus dem Internet bekannten Netzwerkprotokollen. Neben dem bloßen Austausch von automatisierungstechnischen Daten, also der Übertragung von Messwerten und Befehlen/Anweisungen, werden diese sog. „Web- Technologien" vielfach auch für die Anbindung von Beobach- tungs- und Bedienstationen, sog. HMI-Interfaces (HMI = Human- Machine-Interface) verwendet. Gerade in diesem Zusammenhang, aber nicht nur in diesem Zusammenhang, sind automatisierungstechnische Einrichtungen oft mit sog. „Web-Servern" ausgerüs- tet, also mit Programmen, welche Daten und Informationen derart bereitstellen, dass sie mit Anforderungen gemäß des HTTP- Protokolls und ähnlicher Protokolle (z.B. HTTPS-Protokoll o.ä.) zugegriffen werden können. Da diese Web-Server prinzipiell durch Installierung einer Software bzw. eines Software- Paketes auf einer Hardware-Plattform errichtet werden, ist es auch möglich, auf ein- und derselben Hardware-Plattform mehrere solcher Web-Server zeitgleich zu betreiben.

Werden auf einem PC oder auf einem Server mehrere Applikatio- nen mit jeweils einem eigenen Web-Server installiert, so führt dies zu dem Problem, dass alle diese Web-Server jeweils einen eigenen TCP/IP-Port benutzen müssen, um für Anforderungen erreichbar zu sein. Problematisch ist dabei, dass es nur einen reservierten „Well-Known-Port" für Web-Server gibt, nämlich den Port mit der Nummer 80. Ein ähnliches Problem tritt auf, wenn diese Web-Server zwar auf unterschiedlichen Maschinen installiert sind, diese jedoch einem Sub-Netz oder privaten Netz mit lokaler Adressierung angehören und von "außen" nicht separat adressierbar sind.

Dieses Problem wird im Stand der Technik beispielsweise da ^¬ durch gelöst, dass mehrere (private oder dynamische) Port ^¬ Nummern für die Adressierung der verschiedenen Web-Server auf einer Maschine verwendet werden. Da diese Portnummern privat, also nicht „well-known" sind, muss ein Anwender (Client) bzw. dessen Web-Browser oder Browser-ähnliche Anwendung über die vom „Standard" abweichende Portnummer informiert werden. Ein weiterer Nachteil ergibt sich daraus, dass solche Ports, die nicht dem Standard entsprechen, zumeist durch übliche Fire ^¬ wall-Einrichtungen und durch übliche Proxy-Server gesperrt oder nicht unterstützt werden, so dass solche Lösungen zu ^¬ meist nur in privaten LANs verwendbar sind.

Eine weitere Möglichkeit, die Adressierung einer Mehrzahl von Web-Servern auf einer „Maschine" zu ermöglichen, besteht im Einsatz von sog. „Transcodern" oder "Reverse Proxies". Dabei wird ein zentraler Web-Server, ein sog. „Portal-Web-Server" eingesetzt, der die von einem Client angeforderten Seiten selbst von den unterlagerten Web-Servern anfordert. Bevor diese Seiten und anderen Informationen zu dem anfordernden Client gesendet werden, werden diese Informationen transco ^¬ diert, d.h., dass alle Verweise (z.B. Hyperlinks) auf den Ur- sprungs-Web-Server (unterlagerter Web-Server) derart umgesetzt werden, dass in den Fällen, in denen der Client später diese Verweise anfordert, die Anforderungen nicht an den un ^¬ terlagerten Web-Server gesendet werden, sondern wiederum an den Portal-Web-Server. Zudem müssen auch bei dieser Technolo- gie die Anforderungen Daten enthalten, anhand derer der Portal-Web-Server entscheiden kann, an welchen der untergelagerten Web-Server die jeweilige Anforderung weitergeleitet werden soll. Nachteile dieser Methode liegen in der hohen Korn- plexität der Transcoder. Beim Einsatz von Technologien wie JavaScript oder Ajax ist die Technologie des „Transcoden" re ^¬ gelmäßig nicht kompatibel, da hierbei der Programmcode je ^¬ weils analysiert werden müsste.

Es ist also eine Aufgabe der vorliegenden Erfindung, eine Einrichtung und ein Verfahren anzugeben, womit eine Mehrzahl von Web-Servern, die gemeinsam auf einem Host bzw. in einem Sub-Netzwerk mit lokalen Adressen angeordnet sind, mittels einer gemeinsamen, bekannten Adresse verwendet werden können.

Es ist ein zentraler Gedanke der erfindungsgemäßen Lösung, eine Einrichtung („Dispatcher-Webserver") vorzusehen, welche über ein Netzwerk über einen Well-Known-Port , vorzugsweise den Port mit der Nummer 80, erreicht („adressiert") werden kann. Ein unterlagerter Web-Server, der eine Web-Seite erzeugt, versendet diese mittels der Einrichtung an einen

Client, also an einen externen Computer mit einem WebBrowser. Dabei protokolliert die Einrichtung die URL der Web- Seite und die lokale Adresse des betreffenden sendenden Web- Servers. Sofern seitens des Clients eine weitere Web-Seite mittels eines Elementes, z.B. mittels eines Hyperlinks, ange ^¬ fordert wird, ist diese Anforderung beziehungsweise Anforde ^¬ rungsnachricht an die Einrichtung adressiert. Gemäß RFC 2616 (RFC = Request for Comment) oder gemäß eines anderen Verfah ^¬ rens enthält diese Anforderungsnachricht die URL derjenigen Web-Seite, die Ursprung der Anforderungsmeldung ist. Mittels dieser URL ist es der Einrichtung möglich, die Anforderungsnachricht dem ursprünglichen Web-Server zuzuordnen und an diesen weiterzuleiten.

Die Aufgabe wird insbesondere durch eine Einrichtung gemäß dem Patentanspruch 1 gelöst. Dabei ist eine Einrichtung zur Verteilung und Weiterleitung von Anforderungen zu einer Mehr- zahl von Web-Servern in einer industriellen Automatisierungs- anordnung vorgesehen, wobei die Web-Server mittels zumindest einer lokalen Adresse und vorzugsweise mittels jeweils einer privaten Port-Nummer adressierbar sind. Dabei ist die Einrichtung zur Protokollierung von ersten Informationen über eine erste URL einer von einem ersten der Web-Server erzeugten und an einen Client zu versendenden ersten Web-Seite und zur dazu zugeordneten Protokollierung der ersten lokalen Adresse des ersten der Web-Server eingerichtet, wobei diese erste Web-Seite zumindest ein Element zur Erzeugung einer An- forderungsnachricht zur Anforderung einer zweiten Web-Seite umfasst. Die Anforderungsnachricht umfasst eine Angabe über die erste URL,

wobei die Einrichtung zum Empfang der Anforderungsnachricht und zum Vergleich der Angabe mit den ersten Informationen und für die Ermittlung der ersten lokalen Adresse ausgebildet ist, wobei die Einrichtung weiterhin zur Weiterleitung der Anforderungsnachricht an den der Web-Server mit dieser ersten lokalen Adresse eingerichtet ist. Durch den Einsatz einer solche Einrichtung können auf ein- und derselben Hardware- Plattform oder in einem privaten Sub-Netzwerk mehrere Web- Server integriert werden, wobei alle diese Web-Server über eine einzige, bekannte Adresse, vorzugsweise über eine IP- Adresse mit dem Well-Known-Port (Port 80), erreichbar sind, so dass keine Einschränkungen hinsichtlich der Verwendung von Firewalls, Proxy-Servern etc. bestehen, und wobei anfordernde Web-Browser ihre Anforderungen (Requests) an die bekannte Ad ^¬ resse beziehungsweise den bekannten Well-Known-Port adressie ^¬ ren können. Die Lösung der Aufgabe sieht weiterhin ein Verfahren zur Verteilung und Weiterleitung von Anforderungen zu einer Mehrzahl von Web-Servern in einer industriellen Automatisierungsanordnung gemäß dem Patentanspruch 11 vor, wobei in einem ersten Schritt die Einrichtung eine erste URL einer von einem ersten der Web-Server (WS1, WS2) an einen Client gesendeten Web- Seite und dazu zugeordnet eine Information über eine erste lokale Adresse dieses Web-Servers protokolliert, wobei diese Web-Seite zumindest ein Element zur Erzeugung einer Anforde- rungsnachricht zur Anforderung einer zweiten Web-Seite um- fasst. In einem zweiten Schritt empfängt die Einrichtung eine der Art von dem Client mittels des Elementes erzeugte Anfor ^¬ derungsnachricht, wobei die Anforderungsnachricht eine Angabe über die erste URL umfasst, wonach in einem dritten Schritt die Einrichtung einen Vergleich der mit der Anforderungsnachricht empfangenen ersten URL mit der protokollierten URL vornimmt, wobei die die Einrichtung die dazu zugeordnete erste lokale Adresse aus den protokollierten Daten ermittelt, so dass in einem vierten Schritt die Einrichtung die Anforde- rungsnachricht an denjenigen der Web-Server mit der ersten lokalen Adresse weiterleitet. Mit einem solchen Verfahren lassen sich die Vorteile der erfindungsgemäßen Einrichtung realisieren. Durch den Einsatz eines solchen Verfahrens, bei dem Ketten von einander zugeordneten lokalen Adressen und URLs gebildet werden (so genannte "Referer-Ketten" ) , wird so ^¬ mit eine eindeutige Adressierung auch von solchen Web-Servern ermöglicht, welche auf demselben Host installiert sind, den ^¬ selben Host-Anteil in ihrer URL aufweisen, oder in einem privaten und von "außen" nicht transparent adressierbaren Sub- Netzwerk angeordnet sind.

Vorteilhafte Ausgestaltungen der erfindungsgemäßen Einrichtung sind in den abhängigen Patentansprüchen angegeben. Die dabei beschriebenen Merkmale und Vorteile gelten sinngemäß auch für das erfindungsgemäße Verfahren.

Vorteilhaft wird die Angabe über die erste URL konform zu ei ^¬ nem Verfahren gemäß RFC 2616 übermittelt, so dass seitens ei ^¬ nes Web-Browsers des Clients beziehungsweise dessen Computers keine zusätzliche Software oder Plug-ins erforderlich sind. Die Verfahren gemäß RFC 2616 werden im Stand der Technik vor allem dazu verwendet, um bei der Verwendung von Werbe-Bannern diejenige Web-Seite zu identifizieren, auf der dieser Werbe- Banner angeordnet war, so dass dem Betreiber dieser Web-Seite eine Provision zuerkannt werden kann. Daher werden die Verfahren gemäß RFC 2616 von nahezu allen gebräuchlichen Web- Browsern unterstützt.

Vorzugsweise leitet die Einrichtung die Anforderungsmeldungen unverändert an den entsprechend identifizierten der Web- Server weiter, wodurch mögliche Fehler und Aufwand einer Transcodierung vermieden werden können; der Inhalt der Anfor- derungen und Meldungen braucht also nicht geändert werden.

Vorteilhaft werden zur Adressierung der Web-Server IP-Port- Nummern von privaten oder dynamischen Ports verwendet, wodurch sichergestellt ist, dass keine anderweitig genutzten Well-Known-Ports blockiert werden. In einer vorteilhaften

Ausgestaltung sind einige oder alle der Web-Server auf einer gemeinsamen Hardware-Plattform installiert. Dadurch wird beispielsweise vermieden, dass dem Netzwerk-Interface dieser Hardware-Plattform („Maschine") eine Mehrzahl von IP-Adressen (nämlich für jeden der Web-Server eine) zugewiesen werden muss. Außerdem sind die Web-Server vorteilhaft über die „lo- calhost"-Adresse (IP-Adresse 127.0.0.1) adressierbar; dies gilt insbesondere für eine vorteilhafte Ausgestaltung der Er ^¬ findung, in der die Einrichtung auf einer gemeinsamen Hard- ware-Plattform mit einigen oder allen der Web-Server installiert ist. Dadurch kann der Datenverkehr zwischen der Einrichtung und den Web-Servern intern in der „Maschine" abgewickelt werden, ohne Ressourcen des Netzwerkes zu beanspruchen. Weiterhin kann dadurch die Sicherheit erhöht werden ("Securi- ty Aspekt") _/ da die einzelnen Web-Server nicht direkt aus dem Netzwerk erreichbar sein müssen.

Für den Vergleich der mit der Anforderungsnachricht übermit ^¬ teltem URL der Web-Seite, auf der das Element angeordnet war, mit den protokollierten Daten ist es von Vorteil, wenn in der Einrichtung beim Versenden dieser Quell-Web-Seite nicht die erste lokale Adresse beziehungsweise erste URL selbst proto ^¬ kolliert wird, sondern ein Hash-Wert über einen signifikanten Teil dieser ersten lokalen Adresse oder URL. Wenn bei der in der Anforderungsnachricht übermittelten lokalen Adresse oder URL ebenfalls ein Hash-Wert mittels desselben Algorithmus ge ^¬ neriert wird, können diese beiden Hash-Werte leicht vergli- chen werden. Dies führt zu einer beschleunigten Durchführung des Vergleichs.

Vorteilhaft wird als der Well-Known-Port der IP-Port mit der Nummer 80 verwendet, weil dies derjenige Well-Known-Port ist, an den Clients (z.B. Web-Browser) üblicher Weise Ihre Anforderungen („Requests") adressieren. Für das HTTPS-Protokoll wird analog dazu vorteilhaft der Well-Known-Port mit der Num ^¬ mer 443 verwendet. Es ist ein weiterer vorteilhafter Gedanke der Erfindung, dass bei eingehenden Erst-Anforderungsnachrichten, zu denen also keine Informationen in der Einrichtung protokolliert sind, diese an Anforderungsnachrichten an alle unterlagerten Web- Server weitergeleitet werden, so dass in den Fällen, in denen nur einer dieser unterlagerten Web-Server antwortet, die Zuordnung entsprechend protokolliert werden kann. Alternativ ist es auch möglich, bei solchen Erst-Anforderungsnachrichten einer Portal-Web-Seite zu generieren, die eine manuelle Aus ^¬ wahl ermöglicht. Die dazu notwendigen, auf der Portal-Web- Seite anzuzeigenden Informationen über die von dem jeweiligen Web-Server angebotenen Funktionalitäten können vorteilhaft direkt bei diesem jeweiligen Web-Server abgerufen und für den Aufbau der Portal-Web-Seite verwendet werden. In einer vorteilhaften Ausgestaltung kann in einer Initialisierungsphase die Einrichtung die unterlagerten Web-Server durch eine Suche auffinden, vorzugsweise durch einfache

"Portscans" auf dem "localhost", zumindest in den Fällen, in denen die Einrichtung und die unterlagerten Web-Server auf ein- und derselben Hardware-Plattform installiert sind.

In einer weiteren vorteilhaften Ausgestaltung haben die protokollierten Informationen nur eine begrenzte Gültigkeitsdau- er, damit zwischenzeitliche Veränderungen in der Adressierung abgefangen werden können.

Ausführungsbeispiele der erfindungsgemäßen Einrichtung werden nachfolgend anhand der Zeichnung erläutert. Sie dienen gleichzeitig der Erläuterung eines erfindungsgemäßen Verfahrens .

Dabei zeigt die einzige Figur in schematischer Darstellung eine an einem Netzwerk angeschlossene Hardware-Plattform mit der Einrichtung und zwei „unterlagerten" Web-Servern.

In der Figur ist schematisch eine Hardware-Plattform PPC ("Portal-PC") dargestellt, die im vorliegenden Ausführungs- beispiel eine automatisierungstechnische Komponente mit meh ^¬ reren Funktionen ist, von denen jede einen eigenen lokalen Web-Server WS1, WS2 aufweist. Die Hardware-Plattform PPC ist mittels eines nicht dargestellten Netzwerks mit einem Client CL verbunden, der u.a. mit einem gebräuchlichen Web-Browser ausgestattet ist. Die Web-Server WS1, WS2 haben für die auto ^¬ matisierungstechnische Anordnung, die hier betrachtet wird, unterschiedliche Funktionen, so dass eine zufällige, zykli ^¬ sche oder wechselweise Zuordnung von Anforderungsmeldungen des Clients CL oder anderer Clients im Sinne eines "Load- Balancing" nicht zielführend ist, sondern eine feste Zuord ^¬ nung von Sitzungen ("sessions") zu den einzelnen Web-Servern WS1, WS2 erforderlich ist.

Beim Einschalten oder "Hochfahren" der Einrichtung DISP un- tersucht diese die Hardware-Plattform PPC nach unterlagerten Web-Servern und findet dabei die Web-Server WS1, WS2 auf. De ^¬ ren lokale Adressen, insbesondere die privaten IP- Portnummern, werden dabei registriert. Im Folgenden wird anhand der Figur der Fall geschildert, in dem ein Browser des Clients CL gestartet wird und eine URL der Einrichtung DISP eingegeben wird, also ohne dass zuvor bereits eine Web-Seite mittels des Browsers angezeigt wurde, auf der ein Hyperlink zu der Einrichtung DISP vorhanden ist. Die Einrichtung DISP wird dabei wie ein Web-Server adres ^¬ siert . Die entsprechende Anforderungsnachricht, die von dem Client CL zu der Einrichtung DISP versendet wird, ist also keine "weiterführende" Anforderung und umfasst daher keinen "Hea ^¬ der" gemäß RFC 2616. Dies bedeutet, dass die Einrichtung DISP diese Anforderungsnachricht keinem der unterlagerten Web- Server WSl, WS2 zuzuordnen vermag. Daher generiert die Einrichtung DISP eine Portal-Welt-Seite, die eine Auswahl zwi ^¬ schen den unterlagerten Web-Servern WSl, WS2 möglich macht. Dazu werden Beschreibungen der unterlagerten Web-Server WSl, WS2 von diesen abgerufen und für den Aufbau der Portal-Web- Seite verwendet. Diese Portal-Web-Seite wird zu dem Client CL übertragen und dort mittels des Browsers dargestellt.

Eine entsprechende Auswahl eines Benutzers des Clients CL führt dazu, dass eine neue Anforderungsnachricht erstellt wird, die den ausgewählten der Web-Server WSl, WS2 identifiziert und die zu der Einrichtung DISP übertragen und dort ausgewertet wird. Dadurch kann die zuvor übermittelte erste Anforderungsnachricht einem ersten der Web-Server WSl, WS2 zugeordnet und diesem zugeleitet werden.

Als Antwort auf diese Anforderungsnachricht erzeugt der betreffende der Web-Server WSl, WS2 eine neue Web-Seite, die mittels der Einrichtung DISP an den Client CL übermittelt wird. Dabei protokolliert die Einrichtung DISP mittels eines Verfahrensschritts S-URL (Speichern URL) in einer Datenbank

DB sowohl die lokale Adresse (beispielsweise die lokale, pri ^¬ vate IP-Portnummer) des betreffenden der Web-Server WSl, WS2, und eine Information über die URL der soeben übermittelte Web-Seite. Diese Information ist hier ein Hash-Wert, der aus der URL erzeugt wird und für diese eindeutig ist. Sowohl die protokollierte Adresse des Web-Server WSl, WS2 als auch der Hash-Wert über die URL werden einander zugeordnet gespei ^¬ chert, bilden also ein Werte-Paar. Die übermittelte Web-Seite umfasst regelmäßig eine Anzahl von Elementen, vorzugsweise Hyperlinks, die jeweils mit weiteren Web-Seiten assoziiert sind, die im zuvor verwendeten der Web- Server WS1, WS2 entweder bereits hinterlegt sind, oder aber von diesem erzeugt werden können. Eine Aktivierung eines solchen Elementes beziehungsweise Hyperlinks führt seitens des Clients CL zur Generierung einer neuen Anforderungsnachricht, die an die Einrichtung DISP übermittelt wird. Gemäß RFC 2616 ist ein so genannter "Referer" Bestandteil dieser Anforderungsnachricht, das heißt, dass mit der Anforderungsnachricht nicht nur eine Information über die gewünschte, also mit dem Element verknüpfte URL enthalten ist, sondern auch diejenige URL, deren zugeordnete Web-Seite dasjenige Element umfasst, welches von einem Benutzer des Clients CL aktiviert bezie ^¬ hungsweise angeklickt wurde. Die Einrichtung DISP erzeugt über diesen Referer, also über diese Quell-URL, ebenfalls einen Hash-Wert und sucht diesen in einem Verfahrensschritt LR (Look-up Referer) mit den Einträgen der Datenbank DB. Dabei findet die Einrichtung DISP die zugeordnete lokale Adresse beziehungsweise lokale IP-Portnummer desjenigen der unterla ^¬ gerten Web-Server WS1, WS2, von dem die ursprüngliche Web- Seite stammt. An diesen Web-Server WS1, WS2 wird die Anforde ^¬ rungsnachricht weitergeleitet, wodurch das Adressierungsprob- lern der unterlagerten Web-Server gelöst ist.

Als Absenderadresse, Host-Anteil der URLs, die mit den Ele ^¬ menten verknüpft sind, wird von den Web-Servern WS1, WS2 vorteilhaft die Adresse und die Well-known-Portnummer der Ein- richtung DISP verwendet, so dass die Rückantworten (Anforde ^¬ rungsnachrichten) automatisch der Einrichtung DISP zugeleitet werden. In einer alternativen Ausführungsform kann ein Netzwerk-Interface der Hardware-Plattform PPC derart eingerichtet sein, dass automatisch alle Anforderungsnachrichten, die ein- gehen, ausschließlich an die Einrichtung DISP geleitet werden .