184158/2005 01 17
Aus WinfWiki
IT/IS VU 184158 Internet Applikationen - Angabe vom 17.01.2005
Schriftliche Prüfung, 8 Seiten, 50 Punkte, 45 Minuten, keine Unterlagen.
1. Welche 4 Industrien sind in den Bereich Multimedia involviert + jeweils kurze Beschreibung?
Computer
TV und Broadcasting
Telecom
Printmedien
2. Jeweils 2 Beispielanwendungen für Personal-/Group-/Enterprise-Multimedia-Anwendungen
Personal Multimedia Systems:
- Kiosk Systeme
- Video-on-demand
- Musik-on-Demand
- Interaktive-TV
Group Multimedia Systems:
- Point-to-Poin conferencing
- Multipoint conferencing
- Concurrent engineering
Corporate Multimedia Systems:
- Multimedia training system to the desktop
- Advanced computer-telephony integration
- Multimedia Information Services (WWW)
3. Jeweils 3 Beispielsysteme für same time/different place, same time/same place, different time/same place und different time/different place
4. CORBA vs. Web Services: Coupling, Data Model, Parameter Passing, call types(?), communication mode
5. Die 4 möglichen workflow interoperability Szenarien graphisch darstellen
Die WfMC will Interoperabilität zwischen Workflow-Management-Systemen erreichen, ohne dabei die Leistungsfähigkeit der Produkte einzuschränken. Deshalb wurden verschiedene Interoperabilitätsszenarien entworfen. Dabei ist zu erwarten, daß die Produkte zunächst nur die relativ einfachen Szenarios unterstützen, in denen einzelne Teile von Prozessen zwischen verschiedenen Systemen übertragen werden. Ein engeres Zusammenwirken mehrerer Workflow-Engines hingegen erfordert unter anderem die gemeinsame Benutzung derselben Prozeßdefinitionen und Workflowkontrolldaten.
Szenario 1: Connected Discrete
In diesem Szenario ist es möglich, das zwischen den beteiligten Systemen eine einzelne Instanz übertragen wird, die in der neuen Umgebung unabhängig von der alten Umgebung ausgeführt wird. Die Prozesse sind nur an einem bestimmten Punkt miteinander verbunden. Deshalb wird dieses Szenario von der WfMC als Connected Discrete oder Chained bezeichnet.
Szenario 2: Hierarchical
Auf dieser Stufe wird die Ausführung von Subprozessen in anderen Workflow- Engines möglich. Zwischen den Prozessen besteht eine hierarchische Beziehung: Prozeß B ist ein Subprozeß von Prozeß A. Das Szenario trägt deshalb die Bezeichnung Hierarchical oder Nested Subprocesses. In Abbildung 12 enthält Prozeß A eine Aktivität, die die Ausführung des Subprozesses B in einer anderen Workflow-Engine bewirkt.
Szenario 3: Connected Indiscrete
In diesem Szenario bestehen Prozesse aus Aktivitäten, die in verschiedenen Workflow-Engines ausgeführt werden. Die Interaktionen zwischen den Workflow-Engines erfordern keine besonderen Handlungen durch Administratoren oder Nutzer. Sie erfolgen vielmehr über eine Schnittstelle, die von beiden Workflow-Engines unterstützt werden muß. Die WfMC bezeichnet diese Form der systemübergreifenden Ausführung von Prozessen als Connected Indiscrete oder Peer-to-Peer-Model. Abbildung 13 zeigt einen Prozeß C, dessen Aktivitäten in verschiedenen Umgebungen ausgeführt werden.
Szenario 4: Parallel Synchronized
In diesem Szenario werden in verschiedenen Systemen parallel ablaufende Prozesse miteinander synchronisiert. Deshalb wird es als Parallel Synchronized bezeichnet. Es erfordert einen Event-Mechanismus, der von verschiedenen Workflow-Engines genutzt werden kann. Dieses Szenario wird von den derzeitigen Aktivitäten der WfMC nicht erfaßt.
6. Was sind Web Services, und wie unterscheiden sie sich von Web Applikationen (die mit Scriptsprachen/Servlets implementiert wurden)
Die SOA besagt, dass Web- Services beschrieben, veröffentlicht (published), gefunden (discovered) und dynamisch aufgerufen (invoked) werden können. Ein Web-Service bietet eine Schnittstelle auf Softwareoperationen über ein Netzwerk (z.B. Internet), das mittels Nachrichten-basiertem XML-Datentransfer aufrufbar ist (z.B. SOAP, WSDL), an. Ein weiteres Merkmal von einem Web Service ist, dass es in sich abgeschlossen bzw. unabhängig ist (self-contained). Ein Web-Service muss nicht notwendigerweise Komponenten-basiert sein. Ganz im Gegenteil, es ist auch möglich, "alte" Mainframe-Applikationen als ein Web- Service zu verpacken. Das Marktsegment für Web-Services sind der EAI- und B2B. Ein Webservice ist ein Dienst, der mit Hilfe von XML auf der Basis von Internet-Netzwerkprotokollen erbracht wird. Web Services sind nicht für menschliche Benutzer gedacht, sondern für Softwaresysteme, die automatisiert Daten austauschen und/oder Funktionen auf entfernten Rechnern aufrufen. Client-Programme senden im Allgemeinen Anfragen an einen Web Service und dieser antwortet mit der gewünschten Information. Von vielen Seiten wird daher behauptet, dass Webservices für Rechner das sind, was Webseiten für den Menschen sind. Auch wenn das nur ein Teil der Möglichkeiten der Webservices beschreibt, ist diese Aussage durchaus treffend. Erreichbar sind Webservices über ein eindeutiges URI. Webservices bilden die drei wichtigsten Teile der Zusammenarbeit zwischen Client und Server ab: Das Zusammenfinden, Binden und den Datenaustausch. Web Service stellen die einfache Möglichkeit heterogene Systeme miteinander zu verbinden. Die Einführung von Web Services bietet folgende Vorteile:
- Lose Kopplung unterschiedlicher Systeme
- Integration von Legasy Systemen
- Einfache Implementierung
- Standardisierung
Durch die Verwendung von bereits bestehenden und weit verbreiteten Internet-Standards (HTTP, XML etc.) entsteht eine offene und sehr flexible Architektur, die unabhängig von den verwendeten Plattformen, Programmiersprachen und Protokollen ist. Web Services stellen neue Ansätze im Rahmen von EAI (Enterprise Application Integration) und Grid-Computing dar. Das geplante Haupteinsatzgebiet liegt im Business-to-Business-Bereich (B2B). Geschäftsprozesse sollen problemlos über Unternehmensgrenzen hinweg abgewickelt werden.
7. Welche Aufgaben hat ein Applikationsserver (Middleware)
Middleware organisiert den Transport komplexer Daten (Messaging), vermittelt Funktionsaufrufe zwischen den Komponenten (Remote Procedure Calls), stellt die Transaktionssicherheit über ansonsten unabhängige Teilsysteme her (Funktion als Transaktions-Monitor) etc. Middleware-Software ist als Standardsoftware von mehreren Herstellern verfügbar. Technisch stellt sie Software-Schnittstellen und/oder Dienste bereit. Eine Softwarekomponente A, die die Middleware-Schicht benutzen möchte, um mit einer Softwarekomponente B zu kommunizieren, kann diese Schnittstellen benutzen. Die entsprechenden Aufrufe werden von der Middleware-Softwarekomponente über ein Netzwerk weitergereicht (dabei werden in der Regel gebräuchliche Netzwerk-Standardprotokolle (fast immer TCP/IP, darauf aufbauend meist HTTP, darauf aufbauend u.a. SOAP, Web Services verwendet). Auf der Empfängerseite setzt die Middleware die Anforderung in einen Funktionsaufruf an die Software B um. Gegebenenfalls leitet sie die "Antwort" der Komponente B an Komponente A auf demselben Weg zurück.
8. Nachrichtenmuster (message patterns)-Skizzen und Beschreibung
Web-Services bzw. die Service-orientierte Architektur unterstützen generell vier Nachrichtenmuster (message patterns), von denen zurzeit zwei auch tatsächlich von den Produkten unterstützt werden. Diese Muster beschreiben die Reihenfolge der Nachrichten zwischen Requestor und Provider. Das Request-Response-Muster sendet eine Nachricht (Request) von Punkt A nach Punkt B (siehe Abb. unten, ersterTeil Pfad 1). In weiterer Folge sendet Punkt B die Antwort (Response) an Punkt A (siehe Pfad 2).
Request-Response- und One-Way-Nachrichten-Muster
One-Way-Muster Bei diesem Muster wird eine Nachricht lediglich von Punkt A zu Punkt B geschickt, ohne eine Antwort zu erwarten. Request-Response und Solicit Response
Im ersten Fall sendet der Requestor eine Nachricht an den Provider und erbittet eine Nachricht von diesem. Der Provider "weiß", dass der Requestor auf eine Antwort wartet. Im zweiten Fall erwartet der Provider, dass der Requestor eine Antwort liefert.
Im Oneway- Nachrichtenmuster sendet der Requestor eine Nachricht zum Provider. Der Provider empfängt die Nachricht, antwortet jedoch nicht. Im Falle des Notifikationsmusters sendet der Provider eine Nachricht zum Requestor. Der Requestor empfängt die Nachricht, antwortet jedoch nicht.
Zusammenfassend kann man sagen, dass ein Web-Service-Interface eine Sammlung von Operationen, die aus den oben dargestellten Nachrichtenmustern besteht,ist.
9. Problembereiche bei der Composition von Web Services
- Representation of an abstract Web Process
- Representing/specifying the abstract process in a proper form
- Discovery and Interoperability of Services
- Need to manually or automatically search for appropriate services - The discovered services should interoperate
- Efficiency of a Composed Web Process
- Need to compose processes which are efficient in terms of performance
- Process Execution
- Adopting a suitable technique for executing the composed concrete process
- Process Monitoring
- Using a monitoring technique for run time analysis of the Web process execution
10. BPEL4WS - welche Problembereiche, Aufgabenbereiche, andere Standards
Durch Web Services ist es möglich, online Dienste anzubieten und aufzurufen. Die Möglichkeiten eines einzelnen Services sind jedoch beschränkt, so dass man mehrere Web Services miteinander kombinieren möchte. Grundsätzlich ist BPEL4WS eine Sprache, mit der man eine solche Komposition von einzelnen Web Services zu einem Business Prozess implementieren kann. Im BPEL4WS Kontext wird so eine Komposition Prozess genannt. Das Interface eines solchen Prozesses ist eine Kollektion von WSDL portTypes. Der Prozess präsentiert sich im Web also wie jeder andere Web Service auch. Der Prozess kommuniziert mit anderen Web Services ebenfalls über WSDL port-Types.
Mit der Einführung von Web Services wurden Terme wie "web services compostion" und "web services flow" benutzt um die Komposition eines Web Services in einem Prozess-Fluss zu beschreiben. Jüngst werden auch die Begriffe Orchestration und Choreography hierzu benutzt. Orchestration beschreibt wie Web Services miteinander interagieren können. Darin enthalten ist auch die Business Logik und die Ausführreihenfolge der Interaktionen. Orchestration bezieht sich auf einen ausführbaren Business Process, welcher sowohl mit internen, als auch mit externen Web Services interagieren kann. Der Prozess wird immer aus der Perspektive einer der involvierten Parteien koordiniert. Das Ergebnis einer Orchestration ist ein ausführbares Dokument. Choreography verfolgt die Sequenz der Nachrichten, welche zwischen verschiedenen Parteien ausgetauscht werden. Typischerweise wird Choreography mit dem öffentlichen Nachrichtenaustausch zwischen den involvierten Web Services assoziiert. Choreography ist von gemeinschaftlicher Natur, jede involvierte Partei beschreibt welchen Part sie in der Interaktion spielt. Das Ergebnis einer Choreography ist ein beschreibendes, nicht ausführbares Protokoll. In BPEL4WS ist sowohl möglich einen ausführbaren Business Prozess zu implementieren, als auch einen nicht ausführbaren, abstrakten Prozess zu beschreiben. BPEL4WS unterstützt demnach beide Konzepte, Orchestration und Choreography.
11. 3 Transaktionstypen aus WS-T
Synchronous Transactions
Adaptable application serves as connector accessing application systems
- Transaction is completed in real-time
- Data returned to requestor immediately
Point-to-Point Messaging
- Queue serves as destination for messages produced
- Message sent to single destination and consumed bysingle receiver
- Consumption of a message (with commit if transactional) causes it to be removed from the queue
Publish/Subscribe Messaging
Topic serves as destination for messages produced
- Message sent to broker, who then distributes to interested parties (subscribers)
- Consumption of a message does not cause it to be removed from the topic
12. Language/Action - Theorie von Winograd und Flores erklären und ein Beispiel für Implemntierung dieser (Software)
- Koordination der Aktivitäten durch Sprache
- Lokutionäre Akte: "er sagt etwas"
- Illokutionäre Akte: "indem er etwas sagt" vollzieht er einen Handlungsakt
- Perlokutionäre Akte: "dadurch, dass er etwas sagt, bewirkt er etwas in der Welt"
- Coordinator System wurde entwickelt
- Action Technologies Workflow basiert darauf
- Kritik: Zwang einen Sprachakt zu identifizieren
