Internet-Economics 4

Burkhard Stiller, Jan Gerke, Hasan, David Hausheer, Pascal Kurtansky, Institut Für Technische Informatik Und Kommunikationsnetze Zürich
2002
WICHTIGE BEGRIFFE UND ABKÜRZUNGEN -"Funktion" Ein Web Service an sich bietet eine eng definierte Funktionalität. Es sind also kleine Applikationen, die eine einzige Funktion ausführen. Ein Service kann seine Input-und Output-Parameter selber beschreiben, also die Art und Weise, wie er aufgerufen wird und welches Resultat zu erwarten ist. -"Von Programmen angesprochen" Im Gegensatz zu Web-Seiten und Desktop-Applikationen sind die Web Services nicht für direkte User-Interaktion entworfen und
more » ... in der Regel auch keine graphische Benutzeroberfläche. Sie funktionieren auf Code-Level und werden durch andere Applikationen oder Services aufgerufen und tauschen mit ihnen Daten aus. Web Services werden in Software eingebunden, und diese Software stellt ggf. dann die notwendige Interaktivität zur Verfügung. -"Verteilung über das Internet" Web Services werden übers Internet verteilt, d.h. sie basieren auf altbekannten Internetstandards und -protokollen wie HTTP oder SMTP. Dadurch, dass Web Services auf diesen Protokollen "Huckepack" fahren ("Piggybacking"), können sie bestehende Infrastrukturen mitbenutzen und sollten grundsätzlich auch mit Firewalls klarkommen. Web Services vs. andere Technologien Web Services haben einige Ideen von Informatikkonzepten wie verteilte Datenverarbeitung, ASP und Enterprise Application Integration (EAI) übernommen (Bei EAI werden bestehende, grosse Applikationen einer Unternehmung zum Beispiel mit Middleware-Lösungen in eine Gesamtapplikation integriert). Web Services lassen sich jedoch klar von diesen drei obengenannten Modellen abgrenzen. [1] Beim Konzept der Verteilten Datenverarbeitung wird der Datenaustausch mit Remote Procedure Calls (RPC) bewerkstelligt. Dafür werden unterschiedliche RPC-Produkte eingesetzt, die wiederum auf verschiedenen Komponentenmodellen wie COM, CORBA oder Java RMI aufgebaut sind. Ohne spezielle Lösungen wie Softwarebrücken sind diese Technologien untereinander inkompatibel. Da Web Services auf Internetstandards wie HTTP, XML und HTML basieren, wird eine Zusammenarbeit einfacher. [12] EAI-Lösungen sind insofern mit Web Services verwandt, dass sie beide einen "integrativen" Charakter haben. Jedoch fassen EAI-Lösungen bestehende, grosse Applikationen unter einem gemeinsamen Dach zusammen, während man bei Web Services modulare, kleine Funktionen ad hoc für eine Aufgabe zusammenfügt. Bei einer EAI-Lösung müssen feste Verbindungen zwischen den Bestandteilen spezifiziert werden, während Web Service Komponenten unzählige und vielfältige Verbindungen anbieten. Zudem lassen sich Web Services nach und nach einführen, bei EAI-Lösungen hingegen gibt es nur das "alles oder nichts"-Prinzip. Die Gemeinsamkeit von Web Services und ASP ist, dass beide Konzepte Software als Dienstleistung betrachten. Jedoch werden bei ASP ganze Applikationen von einem zentralen Host zur Verfügung gestellt, bei Web Services dagegen nur kleine Softwarestücke, die zudem weit verstreut sind. Auch lässt sich eine ASP-Lösung nicht so einfach und flexibel erweitern wie Web Services. 4.2 Microsoft .NET, SunONE Das Ziel von Microsoft .NET und SunONE ist es, verschiedene Endgeräte wie Mobiltelefone, PDAs und PCs mit Hilfe von Web Services zu vernetzen. Informationen, die auf einem Gerät zur Verfügung stehen, etwa Adressbücher oder Termindaten, sollen auch auf dem anderen einseh-und manipulierbar sein [16][17][19][20]. Das Internet spielt dabei als gemeinsames Kommunikationsmittel die tragende Rolle. SunONE setzt dabei vollumfänglich auf die Programmiersprache JAVA. Microsoft hingegen entwickelte die neue Sprache C#, wobei aber andere Sprachen leicht eingebunden werden können und auch unterstützt werden. Die Entscheidung, ob ein Entwickler künftig zu Microsoft .NET oder zu Java greifen wird, lässt sich durch einen puren Feature-Vergleich kaum entscheiden. Dazu sind die abgedeckten Aufgabenbereiche, die verwendeten Technologien und die Lösungsansätze zu ähnlich. Deshalb soll im folgenden nur näher auf .NET eingegangen werden. Bei .NET handelt es sich nicht um ein geschlossenes, proprietäres System, sondern benutzt öffentliche Standards aus dem Web Services Technology Stack: HTTP als Transportprotokoll, SOAP und XML zum Aufruf und zum "Verpacken" der Daten, WSDL für die Beschreibung und Spezifikation von Web Services sowie UDDI für die Registratur derselben. Ein Entwickler kann bei .NET in eine (fast) beliebigen Programmiersprache programmieren. Der zugehörige Compiler (es braucht für jede Sprache einen) übersetzt dies in eine Intermediate Language ([MS]IL). Diese kann dann auf einem beliebigen Endgerät mit einem Just-In-Time-Compiler in ausführbaren Code übersetzt werden. .NET bietet Werkzeuge und Mechanismen an, mit denen sich Web Services integrieren lassen können. Bei Office XP gibt es bereits einen Zusatzt, mit dem man von VBA-Applikationen aus Web Services aufrufen kann. Damit könnte man zum Beispiel aktuelle Börsendaten relativ einfach in Excel einlesen. Ein anderes Anwendungsgebiet könnte der Online-Zugang fürs Internetbanking sein, den man mit Web Services vereinheitlichen könnte. Allerdings gibt es derzeit auch bei .NET keine Standardweg, wie die Zugriffsrechte für die Inanspruchnahme von Web Services geregelt sind und ob, wie und wer eventuell eine Abrechnung erledigt. Auch eine branchenweit gültige Konvention, wie es mit der Sicherheit bei Aufrufen von Web Services steht, fehlt noch. Ein weiteres Problem ist die zentralistische Struktur von .NET: Die Identifikation erfolgt über den Anmeldedienst Passport von Microsoft. Dieser und auch andere Servicekomponenten sammeln spezifische Userdaten (bis hin zur Kreditkartennummer), welche dann auf den Servern von Microsoft gespeichert werden. 5 Probleme 5.1 Sicherheit Wie bei allen Internetbasierten Anwendungen ist die Sicherheit auch bei Web Services ein grosses Thema. Da der Anwender eine Applikation aus verschiedenen Service-Komponenten zusammenstellt, muss er die Gewissheit haben, dass er diesen Komponenten "vertrauen" kann, d.h. dass sie auch wirklich die beschriebene Funktionalität bieten und nicht irgendwelche unerwünschte Nebeneffekte auslösen. Deshalb braucht es eine sogenannte "Trusted Third 6 Schlussfolgerungen Die mehr oder weniger offenen Fragen und Probleme bezüglich Sicherheit, Abrechnung, QoS, Verfügbarkeit einer Komponente müssen gelöst werden, damit sich das Konzept der Web Services durchsetzen kann. Es müssen standardisierte Techniken gefunden und weiterentwickelt werden, damit etwas Ordnung in das noch vorherrschende Chaos gebracht wird und bestehende Unsicherheiten beseitigt werden können. Wir haben jedoch versucht aufzu-12 zeigen, welche Mächtigkeit dadurch bezüglich Dynamik und Einfachheit zur Generierung neuer Applikationen entstehen könnte. Von Web Services können sicherlich viele moderne Anwendungsgebiete, insbesondere im Bereich Mobile und Ubiquitous Computing, profitieren. Auch die Tatsache, dass Microsoft und Sun mit .NET und SunONE grosse Anstrengungen in Richtung Web Services unternehmen, lässt erkennen, dass diese in naher Zukunft stark in den Informatikalltag einfliessen werden. Vielleicht werden Web Services sogar zum nächsten Programmierparadigma.
doi:10.3929/ethz-a-004446275 fatcat:wi7y7aytzje4llidly62xm2asm