Liberalisierung, Privatisierung, und Deregulierung
Inter process communication:
Das Distributed Computing Enviroment ist ein einheitlicher Standard der Open Group für eine RPC basierte Umgebung und ein dazugrhörige API. Sie bietet natürlich RPCs, Threads, einen Distributed Time Service, einen Cell Directoy Service, einen Security Service, und einen Distributed Files Service.
Passing - direkte (meist synchrone) Kommunikation zwischen zwei Applikationen.
Queuing - indirekte Kommunikation bei die Nachricht gespeichert wird, bis zie zugestellt werden kann oder abgeholt wird (asynchron, aber immer noch nur zwei Applikationen).
Public & Subscribe - eine Applikation veröffentlicht eine Nachricht und die Applikationen die sich für diesen Kanal subscribed haben werden darüber informiert, dass eine neue Nachricht vorliegt und können diese dann lesen.
Atomicy - jede Transaktion ist eine Einheit, die entweder ganz oder gar nicht ausgeführt wird.
Consistency - Übergang nur von einem konsistenten Zustand in einen anderen konsistenten Zustand.
Isolation - Transaktionen sind untereinander unabhängig, d.h. sie beeinflussen sich nicht gegenseitig.
Durability - einmal ausgeführte Transaktionen sind/werden dauerhaft gespeichert.
Bei einem one-way request wird eine Information nur in eine Richtung geschikct ohne dass auf eine Antwort gewartet wird. (Von daher nicht wirklich ein Request im Sinne von Frage, sonder eher ein one-way information.) Sinnvoll einsetzen lässt sich ein one-way request, wenn es z.B. darum geht über einen Status-Wechsel zu informieren.
Die Object Management Group ist eine Non-Profit Interssensvereinigung mit mehr als 800 Mitgliedern, die Schnittstellen vereinbart um im Bereich verteilter, objektorientierter Appilkation interoperabilität zu garantieren.
Die OMG möchte eine Architektur für verteilte, objektorientierte Applikationen entwickeln, die folgendes garatiert:
Da es nie einen Konsenz in Bezug auf Hardwareplattform, Betriebssystem, Netzwerprotokoll oder Applikationsformate geben wird, versucht man nur die Interoperabilität zwischen den einzelnen Teilen zu gewährleisten. Und dies erreicht man am einfachten, indem man klar definierte Schnittstellen (Interfaces) vor gibt, an die sich alle zu halten haben.
encapsulation - Objekte sollten gegeinander gekappselt sein.
abstraction - man sollte verschiedene Abstraktionsebenen verwirklichen können.
inheritance - Vererbung = Wiederverwendung von Code.
dynamic binding - Bindungen sollten erst zur Laufzeit ausgelöst werden müssen.
polymorphism - ein Objekt sollte mit verschiedenen Schnittstellen ``mehrfach'' auftreten können.
Object Managemnt Architecture (OMA) - stellt die Basis für alle OMG Standardisierungen dar. In ihr werden die Zusammenhänge zwischen Services, Facilities und ORB her-/dargestellt.
Object Services Architecture (OSA) - das Framework für die Services die von Ojekten in Anspruch genommen werden wie Naming, Creation, etc. Unabhängigkeit und Modularität der Services, Minimierung doppelter Funktionalitäten, Encapsulation (no hidden Interfaces)...
Common Object Request Broker Architecture (CORBA) - der eigentliche ORB der das Runtime-Enviroment zur Verfügung stellt, und die Kommunikation zwischen den Obekten ermöglicht.
CORBA Facilities Architecture (CFA) - bei den Facilities gibt es die horizontalen Facilitites, die von fast allen Applikationen in Anspruch genommen werden, wie User Interface, Task Management, System Management und Information Management. Die vertikalen Facilities umfassen Standards für bestimmte Applikationsgruppen wie z.B. CIM.
Request and result delivery -
Object / process activation -
Request dispatching -
Security mechanisms -
Exception handling -
Mapping of object models -
Lifecycle - instanzieren und löschen von Objekten
Naming - Vergabe und mapping eindeutiger Namen
Event Notifaction - Signalisierung eingetretener Ereignisse
Time - ORB-weite eindeutige Zeit mit Standardabweichung
Security - Kontrolle von Zugriffsrechten und Identitäten
Der Stub ist die clientseitige, programmiersprachenabhängige Repräsentation der Schnittstellen der Server-Objekte.
Interface Repository - eine Datenbank der zur Verfügung stehenden Interfaces in IDL
Implementation Repositiory - eine Datenbank in der festgehalten wird, wo und wie bestimmte Objekte aufgerufen werden können, und welche Regeln dabei eingehalten werden müssen.
Client Stub - Repräsentation der Schnittstelle eines Server-Objektes
Dynamic Invocation Interface - dient dem dynamischen konstruieren einer Schnittstelle zu einem Objekt
ORB Interface - die Schnittstelle zu der kleinen Menge an Operationen die ein ORB selber anbieten muss.
Object Adapter - Generierung und Interpretation von Object Referenzen, Methodenaufrufe, Beachtung der Sicherheit, Objekt und Implementierungs Aktivierung und Deaktivierung, Mapping von Referenzen auf Implemtierungen, Registrierung von Implemetierungen
Implementation Skeleton - die Schnittstelle über die ein Objekt seine Requests bekommt
Dynamic Server Interfac -
Im Interface Repsoitory befinden sich die Schnittstellen aller zur Verfügung stehenden Objekte in IDL. Das Implementation Repository enthält hingegen Beschreibung wie und wo Implementierungen von Objekten zu instanzieren und aufzurufen sind.
Er stellt die Schnitstelle zwischen Objekte Instanzen und dem ORB da, und bietet den Objekten die Dienste des ORB an. Aus Sicht des ORB bietet er folgendes an: Generierung und Interpretation von Object Referenzen, Methodenaufrufe, Beachtung der Sicherheit, Objekt und Implementierungs Aktivierung und Deaktivierung, Mapping von Referenzen auf Implemtierungen, Registrierung von Implemetierungen
Ein Beispiel könnte ein Debugger sein, der bei seiner Kompilierung nur einen generischen Aufruf an das DII eingebaut bekommt. Zur Laufzeit wird dieses dann dazu genutzt die zu debuggenden Objekte aufzurfen, ohne das dieses oder ihre Schnittstellen vorher bekannt waren.
Es handelt sich dabei um ein generisches Objekt welches das Dynamic Skeleton Interface (DSI) an die Dynamic Implemetation Routine (DRI) übergibt, welches dann mit der Referenz auf das zu benutzende Objekt den Request ausführt.
Die Idee des Portable Object Adapters (POA) besteht darin, eine Objekt-Instanz möglichst häufig und transparent zu benutzen. D.h. mit Hilfe des POA kann eine Instanz mehrere Schnittstellen und mehrere Refenrezen repräsentieren. z.B. um über die Laufzeit des Servers hinweg noch die gleiche Referenz darstellen zu können, und um portable für verschieden ORB Implemtierungen zu sein.
Mit dem POA werden sozusagen einige Aufgaben des OA in die Hände des Objektes selber trandferiert, um größere Flexibilität zu erreichen.
POA - ist eine identifizierbare Entität innerhalb des Servers. Jeder POA stellt einen Namespace für seine Objets IDs zur Verfügung.
Adaptor Activator - ein mit einem POA assoziertes Programm das für nachladen von Child-POA sorgt.
POA Manager - verwaltet einen oder mehrere POAs indem er sie kapselt. Er kann request queuen oder verwerfen, und POA deaktivieren.
Object ID - eindeutige Referenz innerhalb eines POA auf die geladenen Servants.
Servant - sind die eigentliche Implementierung, die die Requests bearbeiten und beantworten. Sie werden von den POAs geladen und mit Requests versorgt.
Servant Manager - eine extra Implementierung, die vom POA dazu benutzt wird Servants zu laden, aktivieren und deaktivieren.
Die Interface Definition Language dient der Programmiersprachenunabhängigen Definition von Schnittstellen, die dann mit Hilfe von speziellen IDL-Compiler in die eigentlichen Schnitstellenbeschreibung in der jeweilgen Programmiersprache umgewandelt werden. Weil die Sprache unabhänging von Programmiersprachen, Hardware-Plattformen etc. ist, ermöglicht sie die Interoperabilität.
IDL konkret können ???????????????????????????????
Es ist ein zum Internet inter-ORB Protocol (IIOP) optionales Protkoll, das den jweiligen Gebenheiten des Enviroment angepasst sein kann, mit dem sich zwei ORBs unterhalten können.
Wenn die Protokolle zur Inter-ORB Kommunikation nicht direkt im ORB implementiert sind, sondern ein externes Porgramm aufgerufen wird, um die Daten zum anderen ORB zu transportieren spricht man Half-Bridges oder request-level bridging. IIOP-Half-Bridge heisst dann nur, dass die Half-Bridge das IIOP Protokoll zur Kommunikation benutzt.
Zielgruppe:
DCOM und RMI sind binär-compatibel, bei CORBA ist nur der Sourcecode portabel.
Mit RMI schon, denn es macht das verteilte Computing transparent und Plattformunabhängig.
Ein Inproc-Server ist ein DCOM Server der aus einer DLL in den Adressraum des Client geladen wird.
Wenn ein Client eine Request an ein Objekt absetzt, prüft der SCM ob schon sein Server läuft der dieses Objekt geladen hat. Falls nicht wird der zuständige Server lokalisiert und über dessen SCM gestartet. Der SCM sorgt auch für das Laden der Client und Server Stubs, und baut schliesslich eine RPC-Channel auf den die beiden Applikationen dann nutzen können.
DCOM ist ein Produkt, CORBA ist ein Standard bzw. eine Spezifikation.
DCOM ist binary kompatibel, wärend es bei CORBA vom eingesetzten Produkt und vom IIOP Support des Produktes abhängt ob verschiedene Binaries zusammen arbeiten können.
DCOM erlaubt Vererbung nur bei Interfaces, Code darf überhaupt nicht vererbt werden. CORBA hingegen erlabt sogar mehrfache Vererbung.
DCOM ist bei Windows NT mit dabei, wärend man für CORBA Entwickler- oder zumindest Runtime-Lizenzen benötigt.
Für DCOM muss man die Interfaces nicht in (der MS eigenen) IDL beschreiben, auch wenn es meistens gemacht wird, bei CORBA ist es hingegen Pflicht.
Late binding ist bei DCOM Standard, wärend bei CORBA meistens die Interfaces mittels IDL beschrieben werden, weil das Programmieren für DII zu schwierig ist.
Ein intelligenter Agent verhält sich intelligent (pro-activ), dies beinhaltet planen, lernen, und schlussfolgern. Mobilität ist für intelleginte Agenten kein primäres Attribut. Für mobile Agenten hingegen ist Mobilität das wichtigste Attribut, denn sie bewegen sich von einem Knoten zu nächsten.
Bei der Remote Execution werden Code und Daten zum Zielsystem transferiert, und dort gestartet und ausgeführt. Was danach mit dem Agenten passiert hängt von der Aufgabe ab: Terminierung oder Rückkehr.
Bei der Migration wird der Agent lokal gestartet und wärend seiner Laufzeit transferiert er sich zum Zielsystem. Zusätzlich zu Code und Daten wird hierbei auch der Ausführungszustand des Agenten transferiert. Der Agent entscheidet dann wann und wohin er als nächstes mirgrieren möchte: Rückkehr oder weiter migrieren.
Vorteile:
Die Integration von Agenten-Systemen und Distributed Object Computing (DOC) scheint sinnvoll zu sein. So könnten die Agenten die Services der etablierten DOCs nutzen, und die DOCs würde von der Intelligenz und der Mobilität der Agenten profitieren. Eine mögliche Lösung wäre der Betrieb der Agenten auf den DOCs, aber eigentlich sollte eine einheitliche Midlleware Plattform für beides angestrebt werden.
Agenten haben oft Reisetagebücher (itineraries) in denen festegehalten ist, wohin sie gehen sollen.
Stationary Agents bieten Services ihrer Agency an und migrieren daher nicht. Mobile Agenten hingegen sind nicht an eine Agency gebunden und können von einem System ins andere migieren.
Region(Agency(Place(Agent)))
Ein Agent ist ein Stück autonome Software, der sich in einem Place befindet. Places sind eine logische Gruppierung, die einem gemeinsamen Zweck dienen (z.B. communication place, trading place, etc.). Die Places wiederrum befinden sich in Agencys, die jewils ein einheitliches Runtime Enviroment bieten. Dieses Agency können sich wiederum zu einer Region zusammenschliessen, wenn sie z.B. einem einheitlichen Zweck dienen (z.B. einheitlich Sicherheitspolitik). Ausserdem sind Regions location transparent, d.h. innerhalb einer Region kennen sich alle Agents.
Um die Zusammenarbeit mit anderen Agenten-Plattformen zu ermöglichen wurde spezielle Interaces und Wrapper in Grasshopper implementiert, um sie MASIF conform zu bekommen. Ausserdem ist Grasshopper die erste MASIF Referenz-Plattform.
Das die Agentensysteme sich nach möglichkeit nicht nur in einem Protokoll verständigen können, sonder nach Möglichkeit so viel wie möglich der folgende Protokolle beherrschen: RMI, plain sockets, CORBA IIOP, MASIF IIOP, RMI/SSL und socket/SSL.
Mobile Agent System Interoperability Facility (MASIF), Foundation for Integellient Physical Agents (FIPA)
Agent management, Agent tracking, Agent transfer, Naming of agents nad agent systems, Agent system type and location syntax, integration of common CORBA services.
Interoperabilität von Agenten Plattformen ermöglichen, gemeinsame Themen zur Standardisierung finden, Integration von RPC Beispielen und MA Technologie, profitieren aus bestehenden Standards (CORBA)
Aglets Workbench (IBM), MOA (The Open Group), Grasshopper (IKV++)
Agent-Agent Kommunikation, einfache Agenten Plattform Services, und Agenten-Interaktion mit nicht Agenten-Software Resourcen.
Es existieren viel heterogene Agenten. Agenten sollen über Nachrichtenaustausch miteinander interargieren können. Agenten sollen sich bei einem Domain Server registrieren können, und diesen dazu nutzen können ihre eigenen Services anbieten zu können und zur Verfügung stehen Resourcen heraus zu finden. Agenten sollen Nicht-Agenten-Software kapseln können, um diese als Agenten Service anzubieten.
Einen persönlichen Reiseagenten, einen persönlichen Assistenten, audio-visuelles Entertainment und Broadcasting, und Netzwerk Management und Bereitstellung.
Die Agent Society ist eine Vereinigung, die dem Austausch von Wissen über Agenten, dem Promoten von Agenten, und dem Vorantreiben der Forschung im Bereich Agenten verschrieben hat.
Aktive Objekte sind Personen (bzw. Objekte die autonom agieren), wärend passive Objekte nur durch aktive Objekte verändert werden können. Oder anders ausgedrückt: aktive Objekte können ihren Status selber verändern, wärend passive Objekte nur von aussen verändernt werden.
Rollen sind Postitionen die von Objekten eingenommen werden können, und die durch die mit den Rollen verbundenen Regeln (Policies) bestimmte Regeln oder Möglichkeiten auferlegt bekommen.
Das Operational Interface ist nur eine einfache RPC Schnittstelle, an der eine Funktion aufgerufen wird, und das Ergebniss geliefert wird. Beim Streaming Interface hingegen, besteht ein kontinuierlicher Datenfluss zwischen Produzent und Konsument.
Sie stellen die Objekte aus dem Computational Viewpoint dar, und implementieren bereits Teile der Funktion der Objekte.
Infrastructure objects repräsentieren normalerweise keine Computational Objects, sondern implementieren einen Teil der Infrastuktur z.B. Netzwerkprotokolle.
Channels verbinden engineering Objekte miteinander, und ermöglichen deren Kommunikation. Sie repräsentieren computational binding objects (complex computational object). Sie bestehen aus client und server stub, einem Bindemittel (binders), und einem protocol Objekt.
Node(Nucleus(x Capsule(x Cluster(x Basic Engineering Object))))
Ein Node ist ein Computer System. Dieser Node hat ein Nucleus object, welches dem Betriebssystem entspricht. Ein Nucleus kann mehrere Capsule Objekte unterstützen. Die Capsule beinhalten ein Capsule Manager Objekt, kann aber mehrere Cluster Objects beinhalten. Für jedes Cluster Object gibt es ein Cluster Manager Object, und die Cluster Objects dienen als Behälter für die Basic Engineering Objects. Innhalb eines Clusters können die Basic Objects mit lokalen Mitteln kommunizieren, wärend für die Kommunikation zwischen Clustern über die oben erklärten Channels abläuft.
ODP Functions stellen Services bereit um die Computational und Engineering Objekte zu unterstützen. Vorgegeben sind die Klassen: Repository functions, Co-ordination functions, Management functions und Security functions.
Transparencies dienen der Vereinfachung, indem sie die Komplexität kapseln, und den Aufwand vom Application Developer zum Infrastructure developer verschieben.
Access, Location, Relocation, Migration, Persistence, Failure, Replication, Transaction
Die Service Architekture unterscheidet zwischen prescriptive und descriptive Material.
Die descriptive Spezifikation enthält die Service componenten specification (SCS), die prescriptive hingegen die Reference points (RP) inklusive des Buisness modells.
Richtig aber unrelevant.
Ein Referenzpunkt ist eine definierte Schnittstelle zwischen Objekten oder Rollen.
An RPs werden auch Abhängigkeiten von anderen Komponenten und auch die Semantik der zu übertragenden Daten definiert.
Es handelt sich bei Computational Objects um verteilbare Objekte.
Distributed computing und objektorientierte Analyse und Design Techniken.
Computing Architecture, Service Architecture, Network Architecture
Ja, kann er.
Operational Objects = Computational Objects ???????????????????????
Wegen der möglichen Komposition von Objekten und weil unterschiedliche User auf die Objekte zugreifen.
Object Definition Language (ODL) a superset of IDL.
Der Retailer kauft Service vom Provider ein und verkauft sie weiter an den Consumer.
Management ist ein integraler Bestandteil der als Service angeboten/ausgeführt wird.
user mobilty - der User bewegt sich und benutzt Terminal an verschieden Orten
terminal mobility - das Terminal kann sich bewegen (Handy)
session mobility - eine gestartete Session bewegt sich z.B. vom Telefon zum PC
apllication mobility - Stefan unbekannt :-)
VERMUTUNG (richtig s.o.): terminal mobility bedeutet, dass ein Endgeräte physisch bewegt werden kann, und von mehreren Nutzern in Anspruch genommen werden kann. personla mobility bedeutet, dass der User nicht an einen Ort, oder ein Endgerät gebunden ist, sondern die Services als vielen verschiedenen Orten und Endgeräten nutzen kann.
Access Session: Zugriff auf Dienste, die vom Provider angeboten werden
User/Provider Service Session: Unterstützung der Nutzung von Diensten
Communication Session: das direkte Verwenden von Diensten
Ja.
Er spielt ein sehr wichtige Schlüsselrolle, als der Anlaufpunkt für den Consumer um die Services zu benutzen, zu personalisieren, und um die Mobilität zu unterstützen.
This document was generated using the LaTeX2HTML translator Version 2002-2 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir27104JuxJjj/lyx_tmpbuf1/Dienstplattformen_Zusammenfassung.tex
The translation was initiated by Nils Ohlmeier on 2003-07-22