Realisierung einer webbasierten Dienstleistung. Erstellung und Analyse

Inhaltsverzeichnis

Abkurzungsverzeichnis

1 Anlass und Ablauf der Arbeit
1.1 Vorstellung des Unternehmens
1.2 Motivation
1.3 Aufgabe der Diplomarbeit

2 Anforderungen an die webbasierte Dienstleistung
2.1 Anforderungen zur Akzeptanz beim Kunden
2.2 Anforderungen an die Anbindung spezieller Softwareprogramme

3 Grundlagen von Webanwendungen
3.1 Der Begriff Webanwendung
3.2 Client/Server-Modell
3.3 Client/Server-Kommunikation im World Wide Web (WWW)
3.3.1 Webbrowser
3.3.2 Webserver
3.3.3 HypertextTransferProtocol
3.4 Architektur von Webanwendungen
3.5 Serverseitige Webtechnologien
3.6 Clientseitige Webtechnologien
3.7 Integration von Webdiensten

4 Entwicklung des theoretischen Losungskonzeptes
4.1 Die Grobarchitektur
4.1.1 Funktionsweise und Aufgabenverteilung
4.1.2 Erfuällbarkeit der Anforderungen
4.2 Die Feinarchitektur
4.3 Einordnung der Feinarchitektur in die Entwicklung der webbasierten Dienst­leistung

5 Prototypische Implementierung des theoretischen Lösungskonzeptes
5.1 Ausgangszustand
5.1.1 Hardwarekomponenten
5.1.2 Softwarekomponenten
5.2 Implementierung
5.2.1 Bestandteile der Implementierung
5.2.2 Datenflussdiagramm
5.2.3 Konfiguration des Webservers
5.2.4 StatischeWebseiten
5.2.5 Implementierung des Webdienstes
5.2.6 Implementierung des Schedulers und Integration des Funktions­moduls

6 Test der prototypischen Implementierung des theoretischen Losungskonzep­tes
6.1 Zielstellung der Testreihen
6.2 Testaufbau
6.3 Durchfuährung der Testreihen

7 Schlussfolgerungen und Ansatzpunkte zur weiteren Entwicklung

Literaturverzeichnis

Quellenverzeichnis

Tabellenverzeichnis

Abbildungsverzeichnis

Anhang

Autorenreferat

Jaster, Ivo: Erstellung und Analyse eines in Abhängigkeit der Nutzerauslastung ska­lierbaren, theoretischen Konzeptes zur Realisierung einer webbasierten Dienstleistung, Berufsakademie Sachsen, Staatliche Studienakademie Dresden, Studienrichtung Infor­mationstechnik, Diplomarbeit, 2010. 106 Seiten, 31 Literaturquellen , 3 Anhaänge.

Ausgangspunkt fuär diese Diplomarbeit, sind die Anforderungen der Firma CeTaQ an eine webbasierte Dienstleistung, welche die Analyse und Auswertung von Maschinenfaä- higkeitsuntersuchungen (MFU)'s in der Surface Mount Technology (SMT)-Produktion uäber das Internet ermoäglichen soll. Das Hauptziel der Arbeit ist das Entwickeln eines theoretischen Läosungskonzeptes fuär diese webbasierte Dienstleistung auf Grundlage der gegebenen Anforderungen. Dazu wurde die Grobarchitektur einer Webanwendung ent­wickelt. Anschließend ist die Funktionsweise der Webanwendung beschrieben und eine Diskussion uäber die Erfuällbarkeit der Anforderungen durchgefuährt wurden. Die dabei er­mittelten notwendigen Erweiterungen der Grobarchitektur, dienten der Entwicklung der Feinarchitektur. Die Beschreibung der Funktionsweise und die Topologie der Feinarchi­tektur stellen das theoretische Loäsungskonzept der webbasierten Dienstleistung dar. Um die Funktionsweise und die Erfuällung der Anforderungen durch entsprechende Testreihen praktisch nachzuweisen, wurde eine prototypische Implementierung des theoretischen Loäsungskonzeptes vorgenommen.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Anlass und Ablauf der Arbeit

1.1 Vorstellung des Unternehmens

Die Firma CeTaQ GmbH hat ihren Hauptsitz in Radeberg und ist weiterhin in den USA, Frankreich und China vertreten. Sie bietet weltweit Dienstleistungen zur Quali- tatsanalyse und Optimierung von Fertigungsprozessen im Bereich der SMT-Fertigung an. Dazu können Maschinenfahigkeitsuntersungen MFU's zur Beurteilung der folgenden Qualitätsmerkmale durchgeführt werden (vgl. Quelle [7]):

- Positioniergenauigkeit von Bestuckautomaten, Dispensern, Automatic Optical Inspection (AOI)-Systeme, Die- und Wire-Bonder sowie Markierungslaser
- Setzkraftgenauigkeit von Bestuäckautomaten und Die-Bonder
- Druckgenauigkeit von Lotpastendruckern
- Stabilitaät der Temperaturprofile von Reflowoäfen

Um diese MFU's zu realisieren, wurden in Eigenleistung Messsysteme zur Aufnahme der erforderlichen Daten und Software zur statistischen Auswertung entwickelt. Durch die Eigenentwicklungen stellt sich folgende Produktpalette fuär die Messsyteme und Analy­sesoftware dar:

Zur statistischen Analyse von Positioniergenauigkeit, Druckgenauigkeit und der Stabi- litaät der Temperaturprofile wird das Programm CmCstat benutzt. Fuär die statistische Analyse der Setzkraftmessung wurde ein weiteres Programm mit dem Namen CmForce entwickelt. Die Messwertaufnahme zur Ermittlung der Positionier- und Druckgenauig­keit wird durch das Messsystem CmController in Verbindung mit der Software CmCVis realisiert. Um die Daten fuör die Setzkraftgenauigkeit zu ermitteln, steht das Messsystem Force Measurement Board zur Verfuögung. Temperaturprofile von Reflowoöfen koönnen mit dem CeTaQ Shuttle aufgenommen werden.

Die genannte Produktpalette wird nicht nur zur Erbringung der Dienstleistungen ge­nutzt, sondern kann auch in kundenspezifischer Form erworben werden. Ein wichti­ges Kriterium fuör den Erfolg des Unternehmens ist die Unabhaöngigkeit der erbrachten Dienstleistungen. Diese ist durch die Eigenstöandigkeit der Firma gewöahrleistet, welche nicht in Abhöangigkeit zu den jeweiligen Maschinenherstellern im SMT-Bereich steht. So­mit koönnen die Dienstleistungen objektiv erbracht und speziell am Kunden ausgerichtet werden.

1.2 Motivation

Der Kunde hat im jetzigen Zustand zwei Moöglichkeiten die MFU an seinen Maschinen durch die Firma CeTaQ zu realisieren. Er kann sich das entsprechende Messsystem mit dazugehoöriger Analysesoftware kaufen und die Messungen selbst durchfuöhren. Ist die Anzahl der durchzufuöhrenden MFU's in einer bestimmten Zeitspanne zu gering, ent­scheidet sich der Kunde aus Kostengruönden meist dafuör, die Messungen durch einen Servicetechniker der Firma CeTaQ in Form einer Dienstleistung zu realisieren. Dieser bringt das benöotigte Messsystem direkt zum Kunden und ist entsprechend ausgebildet um die MFU durchzufuöhren.

Beide Moöglichkeiten besitzen einige Nachteile sowohl fuör den Kunden als auch fuör die Firma CeTaQ. Deshalb soll eine weiteres Angebot in Form einer webbasierten Dienst­leistung bereitgestellt werden. Die spezifischen Nachteile der jetzigen Konzepte und das positive Entgegenwirken durch die Erstellung eines zusaötzlichen webbasierten Konzeptes soll im Folgenden dargestellt werden.

Kauf des Messsystems

Dem Kunden entstehen zusaötzlich zum einmaligen Kauf des Messsystems laufende Kos­ten fuör dessen Instandhaltung. Weiterhin muss er Personal schulen und beschöaftigen, welches die MFU mit dem vorhandenen Messsystem durchfuöhren kann. Fuör die Firma CeTaQ besteht das Problem, dass Updates der Analysesoftware fuör jeden Kunden einzeln zur Verfuögung gestellt werden muössen. Ein weiterer Nachteil ist, dass die Analysesoft­ware einmalig mit einer Lizenz und einem entsprechenden Softwarelevel erworben wird. Die verschiedenen Softwarelevel unterscheiden sich in der Einschröankung der Analysem- moöglichkeiten fuör die Auswertung der Messwerte. Eine zeitabhaöngige Abrechnung oder eine Abrechnung nach der Anzahl der Messungen ist nicht vorgesehen. Dadurch entsteht eine ineffektive Mehrwertbildung, da die Kompetenzen nur einmalig erworben werden muössen, um sie dann unbegrenzt zu nutzen.

Dienstleistung durch Servicetechniker

Waöhrend einer MFU koönnen Probleme an der zu messenden Maschine auftreten, die nur durch Maßnahmen seitens des Maschinenherstellers gelöost werden koönnen. Betraögt die Durchfuöhrung dieser Maßnahmen einen Zeitraum von mehreren Tagen, wird der Servicetechniker der Firma CeTaQ vorerst abgezogen. Eventuelle Messungen, die die Durchfuöhrung der Maßnahmen optimieren wuörden, köonnen nicht vorgenommen werden. Nach Beendigung der Maßnahmen reist der Servicetechniker der Firma CeTaQ erneut zur Vermessung der Maschine an. Die daraus entstehenden mehrmaligen Anfahrtskosten muss der Kunde tragen, wodurch eine unvorhergesehen Kostensteigerung der Dienstleis­tung entsteht.

Webbasierte Dienstleistung

Um den genannten Nachteilen fuör den Kunden und der Firma CeTaQ entgegen zu wirken, soll ein drittes Dienstleistungskonzept angeboten werden. Dieses Konzept sieht vor, dass sich der Kunde fuör die Durchfuöhrung einer MFU ein Messsystem aus einem Messgeröate- pool ausleihen kann. Das gemietete Messsystem ist in der Lage, die noötigen Messwerte mit einer entsprechenden Software aufzunehmen. Die Auswertung der Messwerte wird nicht auf dem Rechner des Kunden durchgefuöhrt, sondern auf einem Serverrechner der Firma CeTaQ, der die Analysesoftware bereitstellt. Die Anreise eines Servictechnikers der Firma CeTaQ ist nicht notwendig. Durch die Benutzung eines Webbrowsers in Ver­bindung mit einem guöltigen Account, bekommt der Kunde Zugriff auf eine browserseitige Benutzeroberflöache. Dadurch wird der Rechner des Kunden zum Clientrechner und kann mit dem Serverrechner kommunizieren. Die Messdaten koönnen nun an die Analysesoft­ware gesendet werden. Als Ergebnis erhaölt der Clientrechner die ausgewerteten Daten und stellt diese im Webrowser fuör den Kunden dar.

Durch die webbasierte Dienstleistung und die Benutzung von Accounts, die der Kunde bei der Firma CeTaQ erwerben kann, wird eine Vielzahl an Moöglichkeiten fuör unter­schiedliche Abrechnungsmodelle eröoffnet. Die Abrechnung der Dienstleistung kann z.B. nach Benutzungszeitraum oder nach Anzahl der Messungen erfolgen.

Es ist nicht mehr notwendig Üpdates an die einzelnen Kunden zu uöbermitteln und diese durchzufuöhren. Die Üpdates werden direkt an der Analysesoftware auf dem Serverrech­ner vorgenommen. Die aktualisierte Analysesoftware steht danach allen Kunden sofort zur Verfuögung.

Sind Maßnahmen durch den Maschinenherstellers notwendig, koönnen diese bei Bedarf durch Messungen optimiert werden. Dauert die Durchfuöhrung der MFÜ laönger als ge­plant, kann der Kunde im Normalfall die Mietzeit erhoöhen. Es entstehen keine finanzi­ellen Zusatzbelastungen, da Anfahrten des Servictechnikers der Firma CeTaQ entfallen. Anhand der Abrechnungsmodelle ist es nun möoglich, die konkrete Mietdauer und die Anzahl der Messungen abzurechnen.

Üm das webbasierte Dienstleistungskonzept zu nutzen, muss der Kunde eine Internet­zugang besitzen und Personal zur Bedienung des Messsystems ausbilden.

1.3 Aufgabe der Diplomarbeit

Die Diplomarbeit befasst sich mit der Erstellung und Analyse eines theoretischen Kon­zeptes zur Realisierung einer webbasierten Dienstleistung. Zu Beginn sind die grundle­genden Anforderungen an die webbasierte Dienstleistung zu benennen. Diese betreffen die Akzeptanz der webbasierten Dienstleistung beim Kunden und die Anbindung an spezielle Softwareprogramme der Firma CeTaQ.

Es ist ein theoretisches Loösungskonzept zu erstellen, welches diesen Anforderungen ge­recht wird. Die hardwareseitige Betrachtung der Server- und Clientrechner sowie Daten­sicherheitskonzepte sind nicht Bestandteil dieser Arbeit. Das entstandene theoretische Loösungskonzept soll anschließend prototypisch implementiert werden. An der prototypi­schen Implementierung sollen verschiedene Tests durchgefuöhrt werden, um die Erfuöllung der Anforderungen zu bewerten.

2 Anforderungen an die webbasierte Dienstleistung

In diesem Kapitel werden die grundlegenden Anforderungen der Firma CeTaQ an das theoretische Löosungskonzept der webbasierten Dienstleistung dargestellt. Diese Anforde­rungen koönnen in zwei Kategorien unterteilt werden. Zum einen sind es Anforderungen, um die grundlegende Akzeptanz beim Kunden zu gewaöhrleisten und zum anderen sind es spezifische Anforderungen der Firma CeTaQ im Bezug auf die Anbindung spezieller Softwareprogramme. Diese sind in den folgenden Abschnitten aufgelistet.

Eine Priorisierung der einzelnen Anforderungen wurde nicht vorgenommen, da alle fuör den Erfolg des Projektes gleichermaßen wichtig sind.

Erst nach Sicherstellung der Erfuöllbarkeit dieser grundlegenden Anforderungen wird von der Firma CeTaQ uöber die Einfuöhrung einer vollstöandigen webbasierten Dienstleistung entschieden.

2.1 Anforderungen zur Akzeptanz beim Kunden

Skalierbarkeit der Nutzerauslastung: Der Server muss in der Lage sein, mehrere An­fragen verschiedener Clients parallel zu verarbeiten. Dabei ist eine Anzahl von 1 bis zu 15 parallel zu verarbeitenden Clients vorgegeben.

Das ist notwendig, um Warteschlangen bei der Verarbeitung der Clientanfragen zu verhindern. Diese wuörden die Performanz und somit die Antwortzeiten bei großen Anfrageaufkommen verschiedener Clients erhöohen. Die Antwortzeit ist dabei die Zeitspanne zwischen dem Absenden einer Anfrage des Clients an den Server bis zum Eintreffen der Antwort des Servers. Weiterhin werden bei einer fehlerhaften Bearbeitung parallel verarbeitete Anfragen nicht beeinflusst, insofern die fehler­hafte Verarbeitung nicht die Stabilität des gesamten Serversystems beeinträchtigt.

Skalierbarkeit der Datenraten: Die Antwortzeiten bei der Kommunikation zwischen

Client und Server duärfen nicht laänger als vier Sekunden in Anspruch nehmen. Um diese einzuhalten, ist eine parallele Verarbeitung der clientseitigen Anfragen not­wendig.

Weiterhin ist das zu uäbertragende Datenvolumen zu beachten. Dem Client koännen unterschiedliche Datennraten zur Uä bertragung der Daten an den Server zur Ver- fuägung stehen. Deshalb muss gewäahrleistet sein, dass auch ein Client mit geringen Uä bertragungsraten die geforderte Antwortzeit einhalten kann.

Verschlusselte Datenubertragung: Die Daten, welche Client und Server austauschen, duärfen nur von diesen beiden im Klartext gelesen werden. Ein Lesen dieser Daten in Klartextform von unberechtigten Dritten muss weitestgehend ausgeschlossen sein. Zusammenfassend ist somit die Authentifizierung der beiden Kommunikationspart­ner untereinander und die Vertraulichkeit beim Datenaustausch zu gewaährleisten.

2.2 Anforderungen an die Anbindung spezieller Softwareprogramme

Anbindung an LabVIEW basierte Softwareprogramme: Der Server soll einen Teil der Datenverarbeitung mit schon bestehenden Laboratory Virtual Instrumentation En­gineering Workbench (LabVIEW)-Programmen durchfuähren. Dazu muässen diese Programme in die Datenverarbeitung des Servers integriert werden. Um die Inte­gration zu realisieren, muässen Schnittstellen entwickelt werden, uäber die der Da­tenaustausch zu den LabVIEW-Programmen erfolgt.

3 Grundlagen von Webanwendungen

Fuör die Entwicklung des theoretischen Loösungskonzeptes der webbasierten Dienstleis­tung soll in diesem Kapitel eine grundlegende Uö bersicht der wichtigsten Aspekte einer Webanwendung im Bezug auf die Problemstellung der Anforderungen vorgenommen werden.

Zuerst wird die Frage diskutiert, was ist eine Webanwendung und warum ist sie zur Loö- sung der webbasierten Dienstleistung geeignet. Im weiteren Verlauf des Kapitels sollen die Bestandteile einer Webanwendung und die grundlegenden architektonischen Moöglich- keiten ihres Aufbaues genannt werden. Anschließend folgt eine Auflistung der bekannten client- und serverseitigen Technologien zur Implementierung einer Webanwendung.

3.1 Der Begriff Webanwendung

Um den Begriff Webanwendung zu beschreiben, werden die folgenden zwei Zitate ange- fuöhrt:

Eine Web-Anwendung ist ein Softwaresystem, das auf Spezifikationen des World Wide Web Consortium (W3C) beruht und Web-spezifische Ressourcen wie Inhalte und Dienste bereitstellt, die über eine Benutzerschnittstelle, den Webbrowser, verwendet werden. (Quelle [14], Seite 2)

Eine Webanwendung oder Webapplikation ist ein Computer-Programm, das auf einem Webserver ausgefuührt wird, wobei eine Interaktion mit dem Be­nutzer uüber einen Webbrowser erfolgen kann. Hierzu sind der Computer des

Benutzers (Client) und der des Dienstanbieters (Server) uber ein Netzwerk wie das Internet oder über ein Intranet miteinander verbunden, so dass die raumliche Entfernung zwischen Client und Server unerheblich ist.

(Quelle [28])

Den Zitaten ist zu entnehmen, dass eine Webanwendung ein Softwaresystem ist, wel­ches webspezifische Dienste und Inhalte uöber den Webserver eines Servers bereit stellt. Diese koönnen von den Clients uöber einen Webbrowser genutzt werden. Die Kommuni­kation zwischen Server und Client wird uöber ein Netzwerk wie z.B. dem Internet her­gestellt. Dieses Softwaresystem beruht auf den Spezifikationen des World Wide Web Consortium (W3C). Das ist eine Organisation, welche die Technologien des WWW stan­dardisiert. Diese Technologien werden zum Teil auch bei der Realisierung von Webanwen­dungen benoötigt . Durch das W3C standardisierte Technologien sind z.B. Hypertext Mar­kup Language (HTML), Extensible Hypertext Markup Language (XHTML), Extensible Markup Language (XML), Cascading Style Sheets (CSS) und Portable Network Graphics (PNG), um nur einige der bekanntesten Vertreter zu nennen (vgl. Quelle [26]). Weitere Empfehlungen und Arbeitsentwuörfe sind auf der Webseite des W3C unter http://www.w3.org/TR/ (Quelle [26]) zu finden.

Eine Webanwendung ist fuör die webbasierte Dienstleistung geeignet, weil sie genau die Aufgaben erfuöllen muss, die in der Begriffserklaörung zum Tragen kommen. Die Aufga­ben bestehen darin, global Dienste und Inhalte zur Verfuögung zu stellen. Diese sollen zentral verwaltet und jedem Kunden uöber eine Schnittstelle zugaönglich sein. Mit dem Internet ist ein Netzwerk gegeben, das dem Kunden weitestgehend global den Zugang zur Dienstleistung ermoöglicht. Durch die Nutzung eines Webbrowsers, der mit Hilfe des WWW Daten mit dem Webserver austauschen kann, steht weiterhin eine Benutzer­schnittstelle zur Verfuögung. Die grundlegenden Eigenschaften der Webanwendung sind somit zielfuöhrend fuör die Loösung der Problemstellung.

3.2 Client/Server-Modell

Den Webanwendungen liegt das Client/Server-Modell zugrunde. Hierbei bildet die Client/Server-Kommunikation das Ruöckrad zwischen dem Kunden (Client) und der ei­gentlichen Anwendung (Server) (vgl. Quelle [14], Seite 135).

Grundsaötzlich kann das Modell in folgende drei Bestandteile zerlegt werden (vgl. Quel­le [1]):

- ein oder mehrere Clients
- ein Server
- ein Kommunikationsdienst

Die Begriffe Client und Server bezeichnen dabei in welcher Beziehung die beiden zu­einander stehen. Der Client ist derjenige, der Anfragen an den Server stellt. Der Server wiederum verarbeitet die Anfragen und sendet die entsprechende Antwort an den Client zuruöck. Ein Kommunikationsdienst verbindet die beiden miteinander.

In Abbildung 3.1 ist das Prinzip des Client/Server-Modells dargestellt. Dabei wird er­sichtlich, dass ein Rechner sowohl Client als auch Server sein kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Client/Server-Modell (Quelle [1], Seite 8)

Das ist der Fall, wenn er z.B. Anfragen eines Client als Server annimmt und diese als Client an einen anderen Server zur Bearbeitung delegiert. Es ist weiterhin moöglich, dass der Client und der Server auf einem Rechner laufen und nicht durch ein Netzwerk ver­bunden sind. Das macht deutlich, dass es sich nicht um eine Hardware- sondern um eine Softwarearchitektur handelt (vgl. Quelle [1], Seite 8). Fuör eine Webanwendung die ein verteiltes System in einem Netzwerk darstellt, wird im weiteren Verlauf der Arbeit davon ausgegangen, dass Client und Server auf unterchiedliche Rechner verteilt sind.

3.3 Client/Server-Kommunikation im WWW

Wie im vorhergehenden Abschnitt angesprochen, spielt die Client/Server-Kommunikati- on im Rahmen der Webanwendungen eine wichtige Rolle. Diese Kommunikation wird im WWW wie folgt realisert. Der Webbrowser (Client) stellt eine Anfrage an den Webserver (Server). Die Anfrage ruft eine Antwort des Webserver hervor. Diese wird vom Webser­ver an den Webbrowser zuruöckgesendet . Um zu regeln wie ein Webbrowser eine An­frage stellt, welche Antworten ein Webserver liefern kann und in welcher Form, gibt es entsprechende Protokolle. Eine zentrale Rolle spielt hierbei das Hypertext Transfer Protocol (HTTP) (vgl. Quelle [14], Seite 135). Im Folgenden sollen die genannten Begriffe Webserver, Webbrowser und HTTP-Protokoll als weitere Spezialisierung der Grundbe­standteile des im Abschnitt 3.2 vorgestellten Client/Server-Modells in Hinblick auf eine Webanwendung genauer betrachtet werden.

3.3.1 Webbrowser

Der Webbrowser stellt die Benutzeroberflöache einer Webanwendung dar. Er ist somit eine Schnittstelle fuör den Menschen, um mit dem WWW zu kommunizieren. Dies ge­schieht mit der Bedienung des HTTP-Protokolls im Webbrowser durch den Menschen. Das betrifft zum einen das Senden von HTTP-Anfragen an einen Webserver und zum an­deren das Verarbeiten und Darstellen der Antworten eines Webservers. Die Darstellung erfolgt durch die Nutzung einer Auszeichnungssprache. Die bekanntesten sind HTML und die erweiterte Variante XHTML. Die Aufgaben eines Webbrowsers beschraönken sich nicht nur auf die grundlegende Arbeit mit dem HTTP-Protokoll. Der heutige Funk­tionsumfang laösst die Nutzung einer Vielzahl von Internetdiensten zu. Weiterhin be­sitzen moderne Webbrowser meist eine Java Virtual Machine (JVM) zur Ausfuöhrung von Java-Applets, Interpreter fuör Scriptsprachen und Sicherheitsfunktionen wie Secure Sockets Layer (SSL)/Transport Layer Security (TLS), auf deren Basis eine verschluössel- te und authentifizierte Kommunikation zwischen Webserver und Webbrowser uöber das HTTP-Protokoll möoglich ist.

Heutzutage wird eine Vielzahl von Webbrowsern unterschiedlicher Anbieter genutzt. Ei­ne kurze Auflistung der aktuell bekanntesten soll an dieser Stelle folgen:

- Internet Explorer
- Firefox
- Chrome
- Safari
- Opera

Die Webbrowser werden im unterschiedlichen Maße benutzt. Zur Erfassung des Markt­anteils gibt es viele Statistiken, die teilweise stark voneinander abweichen. Um zumindest ansatzweise die Bedeutung der jeweiligen Webbrowser zu skizzieren, soll die Abbildung 3.2 genutzt werden, welche der Quelle [29] entnommen ist und sich auf Messdaten der Webseite www.w3schools.com (Quelle [6]) bezieht.

Ein Problem bei der Entwicklung von Webanwendungen besteht darin, dass man nicht davon ausgehen kann, dass die Darstellung göangiger Technologien wie XHTML und CSS aufjedem Webbrowser uöbereinstimmt. Das bedeutet, die Darstellung der Webanwendung im Webbrowser kann zwischen verschiedenen Webbrowsertypen unterschiedlich oder feh­lerhaft sein. Die Ursache liegt in der teilweise unzureichenden Umsetzung der Vorgaben des W3C im Bezug auf die Webtechnologien im jeweiligen Webbrowser (vgl. Quelle [27], Seite 68ff.). Um dem Problem entgegenzuwirken, ist es notwendig die Oberflaöchen der Webanwendungen mit den unterschiedlichen Webbrowsertypen zu testen und wenn noötig, entsprechende Maßnahmen zu ergreifen. Zur Auswahl der zu testenden Webbrow­sertypen kann die Abbildung 3.2 herangezogen werden. Es ist offensichtlich das Internet Explorer und Firefox die groößten Marktanteile besitzen. Generell ist es notwendig, die­se beiden Webbrowsertypen zu testen. Es ist auch zu empfehlen die anderen Typen in die Tests einzubeziehen, da einer oder mehrere dieser Webbrowsertypen zukuönftig eine wichtigere Rolle spielen köonnten.

Nicht betrachtet wurden die unterschiedlichen Versionen der Webbrowser und ihre Ver­breitung. Diese sollten bei der Erstellung der Tests ebenfalls beruöcksichtigt werden. Sta­tistiken, welche die Relevanz der einzelnen Versionen darstellen, sind im Internet zu finden. Dabei ist ebenfalls auf die ungewisse Aussagekraft der jeweiligen Statistiken hin- zuweisen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: Marktanteile der Webbrowser ab Januar 2002 (Quelle [29])

3.3.2 Webserver

Die Aufgabe des Webservers besteht darin, Anfragen der Clients zu beantworten indem entsprechende Daten verarbeitet und die angeforderten Dokumente zurück gesendet wer­den. Hierbei ist nochmals die Bedeutung des HTTP-Protokolls zur Nutzung des WWW herauszustellen. Das Transmission Control Protocol (TCP)-Port 80 ist als Standardport zur Nutzung des HTTP-Protokolls fuör Webserver festgelegt. Dementsprechend belegt der Webserver dieses Port und bearbeitet die eingehenden und ausgehenden im HTTP- Protokoll formulierten Anfragen. Als alternatives Port zur Nutung des HTTP-Protokolls kann Port 8080 genutzt werden. Üm mittels SSL/TLS-Protokoll eine verschluösselte und authentifizierte HTTP-Kommunikation mit dem Webbrowser des Clients herzustellen, ist Port 443 standardmaößig festgelegt.

Da ein oder mehrere Clients von der Bearbeitung des Webservers abhaöngig sind, ist die Leistungsföahigkeit und Zuverlöassigkeit eines Webservers von zentraler Bedeutung und beeinflusst somit die Qualitaöt einer Webanwendung. Webserver sind nicht nur in der Lage statische Dokumente auf Anfrage zu uöbermitteln, sondern auch dynamische Doku­mente anhand der empfangenen Daten zu erstellen.

Einer der bekanntesten Webserver ist der Apache HTTP Server der Apache Softwa­re Foundation. Die Dienstplattform Internet Information Services (IIS) von Microsoft, welche auch das HTTP-Protokoll unterstuötzt, kann ebenfalls als Webserver eingesetzt werden. Diese ist aber im Gegensatz zum Apache HTTP Server an ein Microsoft Be­triebssystem gebunden.

Es gibt noch weitere Webserver. Im Hinblick auf die im Kapitel 2 gestellte Anforderung, zur Anbindung an LabVIEW basierte Softwareprogramme, soll hier auf die Existenz eines LabVIEW-Webservers in der LabVIEW-Entwicklungsumgebung hingewiesen werden.

3.3.3 Hypertext Transfer Protocol

Das HTTP-Protokoll wurde 1989 von Tim Berners-Lee in der Version 0.9 vorgestellt (vgl. Quelle [27], Seite 12). Es stellt zusammen mit HTML und Üniform Resource Locator (ÜRL) die Grundlage des Internetdienstes WWW dar. Das Zusammenwirken dieser Technologien soll im Folgenden indirekten Zitat dargestellt werden:

Hypermedia-Dokumente werden mittels HTML beschrieben. Ihr Lagerort (auf einem Webserver) wird durch eine URL benannt und sie werden mittels HTTP vom Webserver zum Webclient bzw. Webbrowser übertragen. Durch die Links bilden Hypermedia-Dokumente ein weltweites Geflecht auf das sich die Bezeichnung WWW bezieht.

- URL: Wie man ein Dokument adressiert.
- HTML: Wie man ein Dokument beschreibt.
- HTTP : Wie man ein Dokument transferiert.

(vgl. Quelle [21], Seite 424)

Die Aufgabe des HTTP-Protokolls kann somit allgemein als Regelung des Informations­austausches zwischen dem Webbrowser und dem Webserver zusammengefasst werden. Dabei werden durch das Protokoll Anfragen von Webbrowser an den Webserver und Antworten in die Gegenrichtung realisiert. Sowohl die Auszeichnungssprachen als auch das HTTP-Protokoll haben sich im Laufe der Zeit weiterentwickelt. Das HTTP-Protokoll liegt momentan in der Version 1.1 vor (vgl. Quelle [15]).

Netzwerkprotokolle und deren hierarchischen Abhöangigkeiten zueinander werden im stan­dardisierten International Organization for Standardization (ISO)/Open Systems Inter­connection (OSI)-Referenzmodell dargestellt. In diesem Referenzmodell wird das Proto­koll der Anwendungsschicht zugeordnet. Es setzt somit auf andere Protokolle der nie­deren Schichten auf. Hierzu zaöhlt das verbindungsorientierte, paketvermittelnde TCP der Transportschicht , welches die Korrektheit der Datenuöbertragung uöberpruöft und so­mit fuör einen zuverlöassigen Transport der Informationen zwischen Client und Server ge­nutzt wird. Dieses setzt wiederum auf das Internet Protocol (IP) der Vermittlungsschicht auf, das der Adressierung und dem Verbindungsaufbau im Internet dient. Um eine ver- schluösselte und authentifizierte Kommunikation mit dem HTTP-Protokoll herzustellen, kann zusaötzlich das SSL/TLS-Protokoll der Darstellungsschicht genutzt werden. Die­ses stellt ein hybrides Verschluösslungsprotokoll dar und dient dem verschluösselten und authentifizierten Informationsaustausch im Internet. Wird auf diese Weise eine siche­re Verbindung hergestellt, bezeichnet man das HTTP-Protokoll als Hypertext Transfer Protocol Secure (HTTPS)-Protokoll. Die genannten Protokolle der jeweiligen Schichten des ISO/OSI-Referenzmodells sind zusammengefasst in Abbildung 3.3 dargestellt. Um diese und deren hierarchischen Zusammenhang herauszustellen, wurden keine weiteren Protokolle oder Technologien in die Abbildung des Referenzmodells eingebracht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Die Protokolle HTTP und HTTPS im ISO/OSI-Referenzmodel

Nachdem eine Einordnung des Protokolls erfolgte, sollen nun dessen wichtigste Eigen­schaften und der grundlegende Funktionsumfang stichpunktartig zusammengefasst wer­den.

Eigenschaften:

- HTTP ist ein Protokoll der Anwendungsschicht und setzt auf TCP auf (vgl. Quelle [21], Seite 426).
- Die aktuelle Version ist HTTP 1.1, welche im Requests for Comments (RFC)2616 (Quelle [12]) dokumentiert ist.
- In Verbindung mit dem SSL/TLS-Protokoll kann eine verschluösselte und au­thentifizierte HTTP-Verbindung aufgebaut werden.
- HTTP ist ein zustandsloses Protokoll, d.h der Webserver betrachtet jede An­frage unabhaöngig von vorhergehenden Anfragen (vgl. Quelle [21], Seite 426).
- Eine bidirektionale Uöbertragung ist möoglich (vgl. Quelle [21], Seite 426).

Funktionsbereich:

- Anfrage-Methoden ermoöglichen dem Client mehrere Varianten von Anfragen an den Webserver zu stellen. Diese koönnen serverseitige Operationen beschrei­ben, wie z.B. das Hochladen einer Datei oder das Senden eines Dokuments.
- Die Cache-Steuerung kann dazu genutzt werden, um festzulegen, ob Inhalte in einem Cache gespeichert werden und welche Clients darauf zugreifen duörfen.
- HTTP-Statuscodes geben den Webserver die Moöglichkeit den Client das Er­gebnis seiner Anfrage mitzuteilen. Ist eine URL unguöltig, wird das z.B. mit dem Statuscode 404 gekenzeichnet.
- HTTP-Authentifizierung realisiert das Schuötzen von Daten durch Benutzer­name und Passwort vor unberechtigten Clientzugriffen.

Fuör weiterfuöhrende Informationen zu den genannten Funktionsbereichen wird auf den RFC2616 verwiesen.

Wie in den Eigenschaften des HTTP-Protokolls erwöahnt, ist es ein zustandsloses Pro­tokoll. Bei der Benutzung von interaktiven Webanwendungen stellt das ein Problem dar. Auf einer Webseite koönnen Einstellungen uöber den Webbrowser des Clients vorge­nommen werden. Das kann z.B. die Sprache in der die Webseite praösentiert werden soll oder das Speichern von Artikeln in einem Warenkorb eines Online-Shops betreffen. Oh­ne die Moöglichkeit das zusammengehöorige HTTP-Anfragen zwischen Client und Server uöber einen bestimmten Zeitraum definiert werden köonnen, kann der Inhalt des Waren­korbs oder die eingestellte Sprache nicht den einzelnen HTTP-Anfragen und somit den jeweiligen Clients zugeordnet werden. Die Einstellungen gehen somit verloren. Um die zeitabhaöngige Zuordnung der Anfragen zwischen Client und Server zu realisieren, gibt es sogenannte Sessions. Dazu bekommt der Client bei der Beantwortung der ersten HTTP- Anfrage eine Session-ID vom Server zugesendet. Der Client uöbertraögt diese Session-ID bei den folgenden HTTP-Anfragen zum Server. Somit kann serverseitig die Zuordnung des Clients zur Session vorgenommen werden. Um die Session-ID zu uöbertragen, gibt es mehrere Möglichkeiten. Zum einen kann der Server im Header der HTTP-Antwort einen von ihm erzeugten Cookie, welcher unter anderm die Session-ID beinhaltet, an den Client übertragen. Der Client speichert das Cookie in Form einer Textdatei mit den Serverdaten wie der Session-ID auf dem Rechner. Der Client übertragt von jetzt an das Cookie und somit die Session-ID bei jeder Anfrage mit zum Server. Auf Grund der Information ist es dem Server nun moglich, die Clients einer bestimmten Session zu zuordenen. Eine andere Moglichkeit ist das URL-Rewriting. Dabei werden die relevan­ten Daten einer Session nicht mit einem Cookie sondern durch Paramter in der URL ubertragen.

Die in Abschnitt 1.2 beschriebene webbasierte Dienstleistung beinhaltet Interaktionen mit dem Kunden. Es muss gewahrleistet sein, dass die Auswertung der gesendeten Mess­werte des Kunden an den Server der Firma CeTaQ, auch an diesen Kunden zuruckge­sendet werden. Deshalb ist das Problem der Zustandslosigkeit des HTTP-Protokolls bei der Entwicklung des Losungskonzeptes fur die webbasierte Dienstleistung zu beriicksich- tigen.

3.4 Architektur von Webanwendungen

Eine Webanwendung kann in verschiedene Schichten eingeteilt werden. Jeder Schicht wird ein bestimmter Aufgabenbereich zugeordnet. Fur Webanwendungen sind dafur min­destens drei Schichten notwendig (vgl. Quelle [27], Seite 57). Die Schichten und deren Aufgaben sind im Folgenden dargestellt:

Darstellungsschicht: Diese Schicht dient als Benutzerschnittstelle und hat die Aufgabe den Dialog mit dem Kunden und somit die Interaktion mit der Anwendung zu ermöglichen.

Verarbeitungsschicht: Diese Schicht stellt die eigentliche serverseitige Verarbeitungslo­gik dar und beinhaltet somit die Anwendungen, die vom Kunden genutzt werden.

Datenhaltungsschicht: In dieser Schicht werden die fuör die Anwendung benöotigten Da- ten gesichert und bei Bedarf wieder bereitgestellt.

Die Schichten können auf drei autonome Teilsysteme verteilt werden. Wobei z.B. die Darstellungsschicht von dem Webbrowser eines Clients, die Verarbeitungsschicht von einem Webserver und die Datenhaltung von einem Datenbankserver uöbernommen wer­den. Diese Aufteilung der Schichten nennt man 3-tier Architektur. Bei einer 2-tier Ar­chitektur kann die Verarbeitungs- und Datenhaltungsschicht einem Server zugeordnet werden. Repröasentiert der Server nun Verarbeitungs- und Datenhaltungsschicht nennt man den Client, welcher durch den Webbrowser der Darstellungsschicht zugeordnet ist, einen Thin-Client. Beinhaltet der Client jedoch Darstellungs- und Verarbeitungsschicht spricht man von einem Fat-Client. Anzumerken ist, dass die einzelnen Schichten eine weitere Unterstruktur besitzen köonnen und die Anzahl der Schichten zur weiteren Glie­derung der Webanwendung beliebig gewaöhlt werden kann.

3.5 Serverseitige Webtechnologien

Fuör die serverseitige Implementation einer Webanwendung gibt es unterschiedliche Tech­nologien. Im Hinblick auf die Entwicklung des theoretischen Löosungskonzeptes der web­basierten Dienstleistung und dessen anschließende prototypische Implementation, sollen diese kurz angesprochen werden. Die Technologien haben vorwiegend die Aufgabe, An­fragen eines Clients auf der Serverseite entsprechend zu verarbeiten. Als Ergebnis die­ser Verarbeitung steht meist eine dynamisch erzeugte Webseite, welche auf einer Aus­zeichnungssprache wie HTML oder XHTML basiert. Diese Seite wird dem jeweiligen Webbrowser als Antwort seiner Anfrage zuruöckgesendet. Das Spektrum der eingesetzten Techniken ist sehr groß. Es soll eine kurze stichpunktartige Auflistung einiger möoglicher Technologien folgen. Die speziellen Funktionsweisen und Anwendungsmoöglichkeiten der Technologien sind in entsprechender Literatur, wie Quelle [3], [14] und [27] zu finden.

- Common Gateway Interface (CGI)/FastCGI
-Servlets
- Active Server Pages (ASP).net
- Server Side Includes (SSI)
- Java Server Pages (JSP)
- Server-Side Scripting mit PHP, Perl, Pyton, Ruby u.a.

3.6 Clientseitige Webtechnologien

Um die Möglichkeiten der clientseitigen Webtechnologien bei der Entwicklung und pro­totypischen Implementation des Lösungskonzeptes der webasierten Dienstleistung ein­zubeziehen, sollen diese kurz vorgestellt werden. Das Aufgabengebiet der clientseitigen Webtechnologien umfasst die Darstellung der Daten im Webbrowser des Clients und die direkte Interaktion mit dem Kunden. Dabei köonnen auch eingegebene Daten des Kunden vor der Absendung an den Server kontrolliert werden. Durch eine asynchrone Kommuni­kation des Clients mit den Serverdiensten ist die Erzeugung eines desktopaöhnliches Ver­haltens im Webbrowser moöglich. Die Integration von Programmen im Webbrowser ist ebenfalls Bestandteil dieser Technologien. Wie in Abschnitt 3.5 folgt eine stichpunktarti­ge Notation einiger moöglichen Technologien und ein Verweis auf entsprechende Literatur wie Quelle [3], [14] und [27], zur genaueren Darstellung der Anwendungsmoöglichkeiten und Funktionen.

- Auszeichnungssprachen zur Darstellung der Daten z.B. mit XHTML und CSS
- JavaScript als Client-Programmiersprache
- Java-Applet
- Asynchronous JavaScript and XML (Ajax) fuör eine desktopaöhnliches verhalten
- Plug-ins zur Integration von Programmen im Webbrowser

3.7 Integration von Webdiensten

Ein Thema, das hinsichtlich der Erbringung von Diensten im WWW eine Rolle spielt, sind Webdienste. Diese sind laut W3C unter anderem als Unterstützung zur Zusam­menarbeit zwischen verschiedenen Anwendungsprogrammen, die auf unterschiedlichen Plattformen und/oder Frameworks betrieben werden, vorgesehen (vgl. Quelle [30]). Es gibt unterschiedliche Beschreibungen von Webdiensten, welche diese unter verschiedenen Aspekten betrachten. Folgendes Merkmal wird jedoch von den meisten Definitionen her­ausgestellt. Webdienste sind nicht auf eine Mensch-Maschine-Kommunikation, sondern auf eine Maschine-Maschine-Kommunikation ausgelegt. Der Mensch kann zwar Initia­tor der Kommunikation sein, aber er nutzt den Webdienst nur indirekt und wird durch eine Software oder Hardware, die Nachrichten empfangen und senden kann, vertreten (vgl. Quelle [8], Seite 26). Das bedeutet, ein Client-Programm sendet eine Anfrage an den Webservice und bekommt die gewunschte Information als Antwort. Es wird daher gelegentlich behauptet, dass Webdienste für den Rechner das sind, was Webseiten für den Menschen sind (vgl. Quelle [30]). Hierin besteht auch eine Abgrenzung zur Weban­wendung, da diese eine Benutzerschnittstelle zur Eingabe und Ausgabe von Informatio­nen fur den Menschen zur Verfugung stellt. Diese Informationen können auch zu einem Webdienst gesendet oder von einem empfangen werden. Somit konnen Webdienste von Webanwendungen benutzt werden, um Dienste fur diese bereit zu stellen. Anwendungen die in unterschiedlichen Programmiersprachen implementiert wurden, konnen uber einen Webdienst miteinander kommunizieren. Deshalb könnte im Hinblick auf die Anforderung aus Kapitel 2, zur Anbindung an LabVIEWbasierte Softwareprogramme, diese Technik bei der Entwicklung des theoretischen Löosungskonzeptes der webbasierten Dienstleistung von Nutzen sein. Es gibt verschiedene Moöglichkeiten Webdienste zu implementieren und zu nutzen. Diese köonnen in entsprechender Literatur wie Quelle [8] nachgelesen werden. Abschließend soll eine kurze Einordnung des vorliegenden Kapitels in die Gesamtarbeit erfolgen. Das Kapitel befasste sich mit den grundlegenden Aspekten des Aufbaus und der Bestandteile einer Webanwendung. Hierbei wurde nicht das komplette Spektrum der Themen, welche eine Webanwendung umfassen, aufgezeigt. Es stellt vielmehr eine grundlegende Betrachtung dar, um einen Überblick hinsichtlich der Entwicklung eines theoretischen Lösungskonzeptes im Kontext der Aufgabenstellung dieser Arbeit zu er­möglichen.

[...]