Telekommunikationssysteme. 13. Vorlesung: TINA

Transkript

1 WS 1999 / Vorlesung: TINA Prof. Dr. Claudia Linnhoff-Popien M Institut für Informatik Ludwig-Maximilians-Universität, München N TE AM M Prof. Dr. Otto Spaniol Lehrstuhl für Informatik IV RWTH Aachen Unter Mitwirkung von: Christian Ensel (LMU München) Markus Garschhammer (LMU München) Frank Imhoff (RWTH Aachen) Annette Kostelezky (LMU München) Axel Küpper (RWTH Aachen) Jens Meggers (RWTH Aachen) 13-1

2 Historie & Ansatz Vor IN: IN: bei der Einführung neuer Dienste war es notwendig, Programme in allen Vermittlungsknoten zu erweitern. Dienste unabhängig von den Vermittlungsknoten Dazu wurden die dienstspezifischen Informationen aus den Vermittlungssystemen in ein getrenntes Netz von speziellen Rechnern verlagert. Nachteil des IN-Ansatzes: entweder muß ein zentrales IN für das gesamte Telekommunikationsnetz vorhanden sein, oder es müssen verschiedene IN s existieren, die jedoch nicht miteinander kooperieren können. Über die Funktion von IN s hinaus sollen die Dienststeuerung, das Dienstmanagement sowie die Verwaltung dienstspezifischer Informationen von einem Verteilten System durchgeführt werden. Im Gegensatz zum IN werden dabei konventionelle Workstations eingesetzt. Damit: Integration von Tk-technologien und Verteilten Systemen notwendig Ansatz: Telecommunications Information Networking Architecture 13-2

3 Telco-Anforderungen an TINA Abgrenzung von Wettbewerbern Erhöhung der Flexibilität Unabhängigkeit von Herstellern Kürzeste Time-to-market-Zeiten Effizienz im laufenden Betrieb Anpassung an Kundenbedürfnisse rot Airbag Alu-Felge 13-3

4 Was ist TINA? offene, objektorientierte Architektur für verteilte Telekommunikationsanwendungen beschreibt WIE etwas implementiert werden soll, nicht WAS implementiert werden soll durch ein TINA-Konsortium spezifiziert: TINA-C Ziel: Offener Telekommunikations- und Informationsmarkt Dazu: integrierter Ansatz, der Telekommuniations- und Informationstechnologien nutzt mittels - Techniken der Objektorientierung und verteilten Verarbeitung - Schichtenarchitektur - Integration von Kontrolle und Management 13-4

5 TINA ist eine Softwarearchitektur TINA: Softwarearchitektur, bei der einzelne Softwaremodule unabhängig vom Hersteller zu unterschiedlichen Anwendungen kombiniert werden können Damit: - Schnelle Realisierung und Kontrolle der TK-Dienste eines Netzes - Koexistenz verschiedener Anbieter - auf Kundenwünsche angepaßte, maßgeschneiderte Dienste (Tailored Services) Da durch Verschmelzung von Computertechnologie und Telekommunikation Kosten in erster Linie durch die Entwicklung von Software anfallen, sollen mittels TINA Kosten für neue TK-Dienste reduziert werden. Eigenschaften der Softwarearchitektur: Aufsetzen auf bereits bestehenden Ansätzen wie z.b. IN, TMN, WWW,

6 TINA: Anforderungen und Realisierung Anforderungen an ein TINA-System: - Koexistenz vieler Anbieter - unterschiedliche Anforderungen an die verwendete Hardware - Höchstmaß an Skalierbarkeit und Betriebssicherheit - vielfache Verwendung von Ressourcen. Deshalb muß TINA auf der Basis eines Offenen Verteilten Systems realisiert werden. Offenes System: Gesamtheit miteinaner verbundener Endgeräte, deren Kommunikation so festgelegt ist, daß jedes weitere Endgerät - das diese Anforderungen erfüllt - in das System mit aufgenommen werden kann. Verteiltes System: System, das die Möglichkeit bietet, Aufgaben auf mehrere räumlich vereilte Datenendgeräte aufzuteilen 13-6

7 12. Vorlesung Grundlagen Verteilter Systeme 13-7

8 Einordnung Verteilter Systeme Historie (ab 1945): wenige Computer, die völlig unabhängig voneinander arbeiten Grosch s Gesetz: Die Rechenleistung einer CPU verhält sich proportional zum Quadrat ihres Preises Mitte 80er Jahre: - Leistungsexplosion bei Mikroprozessoren 4 Tendenzen (schneller, kleiner, billiger) führen zur - schnelle Datennetze zur Verbindung von Rechnern Entwicklung - Softwaretechnik: Prozedur, Modul, Schnittstelle RPC, OO Verteilter Systeme - Abkehr streng hierarchischer Organisationsformen Vorteile der VS: - stetige Anpassung der Größe des Systems - Integrierbarkeit bestehender Lösungen - Autonomie der einzelnen Rechner (indiv. Management) - Flexibilität bei auftretenden Fehlern 13-8

9 send/receive-primitive Idee: Verwaltungsaufwand der 7 OSI-Schichten ist so hoch, daß Verteilte Systeme auf ein eigenes Grundmodell zurückgreifen: Betriebssystem wird als Menge kooperierender Prozesse (=Server) strukturiert, die den Nutzern (=Clients) Dienste bereitstellen Basis: einfaches, verbindungsloses Anfrage/Antwortprotokoll - Client sendet Anfrage an Server und erhält Antwort mittels 2 Systemaufrufen: send send (a, &mp) verschickt Nachricht, die durch mp referenziert wird, an einen Prozeß, der durch a identifiziert wird Anrufer bleibt dabei solange blockiert, bis Nachricht vollständig verschickt receive receive (a, &mp) blockiert den aufrufenden Prozeß, bis eine Nachricht für ihn an einer abzuhörenden Adresse a angekommen ist Die Nachricht wird in den durch mp angegebenen Puffer kopiert 13-9

10 Client/Server-Modell: RPC Datenein- und -ausgabe ist kein Konzept der Systemprogrammierung, wie z.b. Unterprogrammaufrufe, d.h. komfortablere Mechanismen Idee: (Birell/Nelson, 84) Ein Programm soll ein Unterprogramm aufrufen, auch wenn sich dieses auf einem entfernten Rechner befindet Entfernter Prozeduraufruf (Remote Procedure Call,, RPC): 1. Client Server Client- Stub Kern Server- Stub Kern

11 Client/Server-Modell: Dynamisches Binden Ziel: Client soll unabhängig von der Adresse des Servers arbeiten Deshalb: Dynamisches Binden basierend auf formaler Spezifikation des Servers z.b. #include<header.h> specification of file_server, version 3.1; long read (in char name[max_path], out char buf[buf_size], in long bytes, in long position); long write (in char name, in char buf[buf_size], in long bytes, in long position);... end; Der Server nimmt eine Registrierung mittels einer Nachricht beim Binder vor. Der Client-Stub weiß somit, welche Parameter er an den Server senden muß, der Server-Stub weiß, welche Parameter er zurücksenden muß

12 Prinzip der Verteilungsplattformen Prinzip: Trennung von Schnittstelle und Implementierung Anwendung Anwendung Anwendung IDL Verteilungsplattform Betriebssystem Client Code Client Client Stub IDL-Compiler Header Server Stub Server Server Code 13-12

13 12. Vorlesung Wurzeln von TINA 13-13

14 Einflüsse auf die Entwicklung von TINA Intelligent Network Telecommunication Management Network TMN IN IN Open Distributed Processing ODP Information Networking Architecture Telecommunications Information Networking Architecture INA INA TINA INA: 1990 startete Bellcore (amerik. Standardisierungsinstitut) ein Arbeitsprogramm, das die langfristige Weiterentwicklung des IN-Ansatzes zum Ziel hatte 13-14

15 Intelligente Netze als Basis für TINA SMP SCEP Betrachten Telefonnetz mit separater Steuerung durch einen IN-Rechner, der Signalisierungsinformationen erhält. SCP IP Das IN ist kein eigenes Netz, sondern ein Konzept, das Netze funktional ergänzt, ihnen Intelligenz zufügt. SS7 SSP Hauptidee: zentralisierte, diensteunabhängige Systemarchitektur X BCP X SCEP - Service Creation Environment Point SMP - Service Management Point SCP - Service Control Point IP - Intelligent Peripheral SS7 - Signaling System No. 7 SSP - Service Switching Point BCP - Basic Call Process 13-15

16 Telecommunications Management Network (TMN) Manager Service Element Managing System OSF Managementoperationen Notifikationen Managementprotokoll QAF Informationsarchitektur: Funktionale Architektur: x q 3 q x f MF Agent f q x NEF TMN WSF Service Zu managende Element Ressourcen Managed System Physikalische Architektur: X Q x QA QA OS OS X/F/Q 3 DCN F WS WS F/Q 3 MD MD TMN DCN Q x Q x NE NE Operations System (OS) Mediation Device (MD) Q Adaptor (QA) Data Communication Network (DCN) Workstation (WS) Network Element (NE) 13-16

17 12. Vorlesung Das Referenzmodell Open Distributed Processing (ODP) 13-17

18 ISO Recommendations X.900: Das ISO-Referenzmodell Open Distributed Processing Reference Model for Open Distributed Processing (RM-ODP) ODP betrachtet alle potentiellen Anwendungen eines verteilten Systems einschließlich Telekommunikationsdiensten, Netz und unterstützenden Umgebungen. Entsprechend der Struktur des ODP-Systems gibt es eine Reihe verschiedener Rollen, die von Beteiligten angenommen werden kann: z.b. der Manager, der den Auftrag vergibt; der Architekt, der das System entwirft; der Programmierer, der es entwirft; der Techniker, der es installiert Jede Person ist an dem selben System interessiert, aber hat relativ gesehen eine andere Sichtweise auf das System. Das ODP-Referenzmodell berücksichtigt diese verschiedenen Interessen durch die Definition von fünf verschiedenen Viewpoints. Jeder dieser Viewpoints liefert eine volle Beschreibung des kompletten Systems, betrachtet dabei aber die verschiedenen Anforderungen und nutzt verschiedene Formen der Beschreibung des Systems

19 Enterprise Viewpoint Enterprise Viewpoint betrachtet die Geschäftsanforderungen eines Systems kann in diesem Sinne als der Blickwinkel des Auftraggebers angesehen werden Fokussiert: - Strukturen eines Systems in einem Unternehmen, - die Organisation, - Managementvorschriften, - die Rolle eines Nutzers bezüglich des ODP-Systems und - die Umgebung, mit der das System in Wechselwirkung steht. Innerhalb dieses Viewpoints wird keine Beschränkung auf ein einzelnes Unternehmen vorgenommen. D.h., das Modell kann auch Randbedingungen und Anforderungen in dem Zusammenspiel einer Reihe von verschiedenen Organisationen beschreiben

20 Information Viewpoint Information Viewpoint hängt - bezüglich des Abstraktionsgrades - eng mit dem Enterprise Viewpoint zusammen, d.h. abstrahiert von einzelnen Komponenten betrachtet die Informationsverarbeitung innerhalb eines offenen, verteilten Systems, ohne die physikalische Verteilung des Systems zu berücksichtigen Informationsmodell beinhaltet: - Informationsquellen - Informationssenken - Speicherstrukturen - Informationsflüsse Aus Informationssicht ist ein System eine formale Struktur, dessen Verhalten vorhersagbar und vollständig durch Aktivitäten, Zustandsübergänge und Attribute definiert ist. Das System wird durch Informationsobjekte und ihre Relationen dargestellt. Änderungen des Systems müssen durch das Modell nachvollziehbar sein

21 Computational Viewpoint Computational Viewpoint realisiert funktionale Zerlegung des Systems beschäftigt sich mit der Beschreibung der Systemkomponenten und ihrer Wechselwirkung unabhängig von einem spezifischen Betriebs- oder Kommunikationssystem spezifiziert ggf. Algorithmen und Datenstrukturen, die zur Charakterisierung der Funktionalität des Verteilten Systems notwendig sind Die Darstellung im Computational Viewpoint ist objektorientiert. In diesem Sinne werden von den Objekten anwendungsspezifische Funktionen zur Verfügung gestellt. Diese Funktionen können durch eine Infrastruktur unterstützt werden, die Verteilungstransparenz zur Verfügung stellt. Basis bilden zeitgemäße Konzepte wie RPC, Threads,

22 Engineering Viewpoint Engineering Viewpoint beschäftigt sich mit Verteilungsmechanismen und stellt die verschiedenen Arten von Transparenz bereit, die in dem offenen, verteilten System gefordert werden betrachtet neben der Verteilung auch die Konfiguration, die Leistungsfähigkeit und die Infrastruktur des Systems Im Engineering Viewpoint wird ein System angesehen als eine Sammlung von - Systemdiensten, - Kommunikationskomponenten und - Mechanismen, die eine Verteilung von Programmen und Daten ermöglichen. Dabei wird auch das Management der physikalischen Verteilung einbezogen. Zu diesem Zweck müssen Schnittstellenreferenzen im Namensraum einer Managementdomäne eindeutig sein

23 Technology Viewpoint Technology Viewpoint befaßt sich mit Hard- und Softwarekomponenten sowie Ein- und Ausgabegeräten, Betriebssystemen, Speicher betrachtet diese Komponenten eines Systems als auch deren Verbindungen bis ins Detail Aus Sicht der Informatik ist diese Sichtweise von geringerer Bedeutung: Diese Komponenten sollen in der Informatik nicht entwickelt werden, sondern nur zusammengesetzt und programmiert werden. Analog: Im Kontext von TINA kommt dem Technology Viewpoint - als einzigem Viewpoint - auch keine Bedeutung zu

24 Der Dienst Dienst: Funktionalität, die von einem Objekt an einer Schnittstelle eines Objekts angeboten wird Dienst ist Instanziierung eines Diensttyps - Dienste ein und desselben Diensttyps besitzen die gleiche Funktionalität, können jedoch in einigen rechnerund verhaltensunabhängigen Aspekten voneinander abweichen. Diese Aspekte werden Diensteigenschaften genannt und durch Name-Wert- Paare charakterisiert. Diensttypen bestehen aus einem Schnittstellentyp und beliebig vielen Diensteigenschaftstypen. Wird ein Dienst angeboten (exportiert), so ist dies ein Dienstangebot. Es beschreibt einen Dienst, der anderen Objekten an einer Schnittstelle zur Verfügung gestellt wird. Seine Diensteigenschaften können statisch oder dynamisch sein

25 Beispiel: Diensttyp/Dienst/Dienstangebot Diensttyp: Input: C, C++, PASCAL, FORTRAN, MODULA 3,... Output: 68040_Code, Power_PC_Code,... Loc: String Id: String Cost: Integer Dienst Input = C Input = C++ Output = 68040_Code Output = Power_PC_Code Location = 0.52 Location = Serverraum Cost = 0.01 Cost = 0.01 Date: String Date: String Access: every., assi, prof Access: every., assi, prof Dienstangebot Date = Date = Access = everyone Access = assi 13-25

26 Dienstvermittlung: Der Trading Service Anbieten eines Dienstes 1. Trader 2. Anfragen mittels search oder select 3. Angebot Exporter (Server) Importer (Client) 4. Beachte: statische/dynamische Diensteigenschaften (mittels Caching/Polling aktualisieren) Annahme des Angebots/ Erbringen des Dienstes 13-26

27 12. Vorlesung Information Networking Architecture (INA) 13-27

28 Information Networking Architecture (INA) Information Network: ein Telekommunikationssystem, das zu jedem Zeitpunkt, an jedem Ort, in jeder Menge und jeder Form Zugang zu Informationen bietet und das Management von Informationen ermöglicht. Information Networking Architecture (INA): Konzepte für die Entwicklung und Bereitstellung von Telekommunikations- Anwendungssoftware Basiert auf: Verteilter Verarbeitung und Objektorientierung INA-Anwendungen werden von einer Distributed Processing Environment (DPE) unterstützt. Entwicklung: INA Issue INA Issue 2 ab 1993: Weiterführung der Arbeiten als TINA 13-28

29 INA - Prinzip INA-Prinzip: Unterteilung von Funktionalitäten des Netzes in - Service Segments, die den Nutzern Netzdienste bereitstellen - Delivery Segments, die eine Vermittlung und Übertragung von Informationen entsprechend der zugrundeliegenden Ausrüstung durchführen Dieses Prinzip entspricht dem Grundprinzip Intelligenter Agenten: Dienstkontrolllogik und -daten werden von Vermittlungs- und Transportfunktionen logisch getrennt. INA verallgemeinert diese Prinzip dahingehend, daß der Kunde eine Netzkontrolle vornehmen kann und damit Managementfunktionen einbezogen werden. Die Interaktion zwischen den Segmenten basiert auf dem Manager/Agenten- Prinzip sowie dem Managed Object Model der OSI - d.h. hier Einfluß seitens TMN. Beachte: während diese Prinzipien heute vorwiegend für Managementzwecke angewandt werden, wurden damit bei INA auch Anrufe verarbeitet

30 INA Building Blocks INA Building Blocks sind ein grundlegendes Architekturkonzept von INA: dabei handelt es sich um Softwareeinheiten, in die Service Segment und Delivery Segment strukturiert werden Building Blocks werden als separate Einheiten konstruiert, installiert und gewartet und interagieren über Invocations auf den Operationen ihrer Schnittstellen gemäß dem Client/Server-Prinzip Building Blocks müssen sowohl die Funktionalität des Service Segments als auch des Delivery Segments unterstützen. ABER: Service Segment Building Blocks unterstützen nur Service Segment Funktionen, Delivery Segment Building Blocks unterstützen nur Building Block Funktionen. Objekt Building Block Interaktion über Verträge Objekt Building Block 13-30

31 INA-Architektur Service Segment Service Management Network Resource Management Delivery Segment Distributed Processing Environment (DPE) Native Communications and Computing Environment (NCCE) Information Networking Architecture 13-31

32 Network Management und Service Management Network Management: betrachtet primär das Netz; von Interesse sind dabei die Übertragungsund Vermittlungskomponenten Fokus liegt auf der Realisierung von Informations- und Kommunikationsdiensten - geht von einer einheitlichen Ressourcensicht durch viele Netzressourcen aus, verbirgt die Komplexität der Ressourcen vor dem Entwickler Service Management: hat zum Ziel, Nutzerdienste geeignet bereitzustellen, verbirgt dabei die Komplexität der Dienstkonfiguration, des Monitorings, der Verwaltung und der Evolution von Diensten 13-32

33 13. Vorlesung TINA-Architektur 13-33

34 TINA Overall Architecture Overall Architecture 2 1 Service Architecture Network Architecture Management Architecture Computing Architecture - definiert eine Menge von Prinzipien, um Dienste anzubieten - basiert auf dem Session Concept - definiert ein generisches, technologieunabhängiges Modell - befaßt sich mit den Ressourcen im Netz - definiert Konzepte insbesondere für Konfigurations- u. Fehlermanagement - definiert Modellierungskonzepte - spezifiziert DPE, d.h. Umgebung, die Anwendungen unterstützt 13-34

35 13. Vorlesung TINA Computing Architecture 13-35

36 TINA Computing Architecture: Konzept der TINA Computing Architecture - definiert eine Menge von Konzepten und Prinzipien für den Entwurf und die Konstruktion von verteilter Software - definiert außerdem eine Softwareunterstützungsumgebung, die auf den Prinzipien der Objektorientierung basiert - basiert auf dem Referenzmodell für Open Distributed Processing (ODP) - lehnt sich dabei an die ODP-Viewpoints an: Enterprise, Information, Computational, Engineering, Technology denen in TINA eine unterschiedliche Bedeutung zukommt - ist damit die Grundlage für die anderen drei Architekturen: die Service Architecture, die Network Architecture und die Management Architecture 13-36

37 Die vier TINA-Viewpoints Business Viewpoint Information Viewpoint Rahmenwerk und Anforderungen Realisierung TINA System Bedeutung Verteilung Computational Viewpoint Engineering Viewpoint 13-37

38 Business Modelling Anforderung: Anwendung soll aus Teilen zusammengesetzt werden (schnell, billig, flexibel) Die Objekttechnologie ist eine gute Basis für solche Teile : - Teile können miteinander kommunizieren - Teile können verteilt werden, verwaltet, konfiguriert - verteilte Objekttechnologie existiert in verschiedenen Architekturen (CORBA, Java, DCOM,...) Zur Spezifikation von Anforderungen an ein System werden Konzepte, Regeln und Strukturen aus Unternehmenssicht festgelegt. Insbesondere erfolgt eine Beschreibung - der Rollen, die von dem System eingenommen werden, - der Aktivitäten des Systems und - der Strategien einschließlich Relationen zur Umgebung

39 Beispiel: Business Model für TINA Service Architecture Bestandteile der TINA Service Architecture Nutzer von Diensten, die im TINA- System angeboten werden Consumer Bkr Ret Management des Netzes, d.h. Unterstützung von Verbindungen, die der Nutzer benötigt Stellt Interessenten Informationen zur Verfügung, um Partner und Dienste zu finden Bkr Broker Retailer Connectivity Provider Bkr 3Pty Ermöglicht Zugang zu einzelnen Diensten, die ggf. von dritten Anbietern bereitgestellt werden (Einzelhändler) 3pty Service Provider Stellt Dienste bereit, hat dabei i.d.r. keinen Vertrag mit Kunden (Großhändler) Jede Business Role (Consumer, Retailer,...) wird von einem eigenen Business Administrative Domain ausgeführt

40 Referenzpunkte Im TINA Business Model wird eine Menge von Referenzpunkten definiert. - Referenzpunkte dienen einer klaren Trennung von Rollen - Sie ermöglichen eine transparente Einordnung im Markt, ins. Flexibilität - Konformität bzgl. dieser Referenzpunkte ermöglicht Interoperabilität zwischen TINA-Komponenten und -Produkten Da jede Business Role von eigenem Business Administrative Domain ausgeführt wird, können Beziehungen zw. zwei Rollen 1:1 auf Referenzpunkte zwischen Domainen abgebildet werden. Alle Referenzpunkte können in zwei Teile gesplittet werden: Access Part - realisiert Wechselwirkungen zw. Business Administrative Domains Usage Part - stellt Funktionalität für Dienst und sein Management bereit Beispiel: Retailer Reference Point (Ret-RP) Access Part - Initiierung des Dialogs zwischen den BAD s - Identifizierung, Aufbau einer sicheren Verbindung,... Usage Part - Kontrolle und Management der Session 13-40

41 Bsp. Multiprovider Szenario Betrachten Retailer - RP und 3rd Party Provider - RP : Customers Ret Retailers 3Pty Beispiele für Dienste, die von verschiedenen Anbietern bereitgestellt werden Video-On-Demand Whiteboard Video Conferencing Andere Dienste 13-41

42 Information Modelling TIINA - Information Modelling: betrachtet die Informationen, die ein Dienst oder eine Dienstkomponente benötigt Diese Informationen werden in sogenannten Information Objects gesammelt, in ihren wechselseitigen Beziehungen, ihren Constraints und Regeln, die ihr Verhalten bestimmen. Als Beschreibungssprache wurde eine sogenannte Quasi-Guidelines for the Definition of Managed Objects/General Relationship Model (Quasi-GDMO/GRM) Notation eingeführt. Zusätzlich wurde die Object Management Technique (OMT) für eine graphische Beschreibung angepaßt

43 Computational Modelling TINA-Computational Modelling: beschreibt eine Anwendung als Menge interagierender Computational Objects (CO s) Computational Objects sind dabei programmierbare, gekapselte Einheiten, die miteinander interagieren, indem sie Informationen von einer Schnittstelle an die eines anderen Objekts senden. Ein Objekt kann dabei auch mehrere Schnittstellen desselben Typs oder unterschiedlicher Typen besitzen. Generell unterscheidet man zwei Arten von Schnittstellen: CO A CO B CO A CO B Client Server Quelle Erzeuger Senke Verbraucher Operational Interface Stream Interface 13-43

44 Computational Objects Operational Interface Object 3 Object 1 Stream Interface Object 2 Computational Objects Objekt mit Schnittstellen verschiedener Typen Object Komposition Dekomposition Object Object Object Object 13-44

45 Object Definition Language (ODL) Computational Objects werden in TINA in einer Object Definition Language spezifiziert, die eine Erweiterung der Interface Definition Language (IDL) ist, die von der Object Management Group (OMG) entwickelt wurde. Prinzip: Object Template der ODL Object 1 Interface Service Attributes Behaviour Description Object n Interface Service Attributes Behaviour Description Client Code Von der IDL zur Implementierung Client Stub IDL IDL-Compiler Header Server Stub Server Code Client Server 13-45

46 Engineering Modelling TINA - Engineering Modelling: definieren eine abstrakte TINA-C Maschine, d.h. das Modell der TINA - DPE (TINA - Distribued Processing Environment) Die DPE stellt die notwendige Plattform für Computational Objects bereit, über die diese Objekte miteinander interagieren können ohne zu wissen, auf welchen Computer oder Netzknoten diese Objekte sich befinden. Aus Sicht eines Anwendungsentwicklers kann die DPE als eine homogene Infrastruktur angesehen werden, welche die Komplexität und Heterogenität des darunterliegenden Netzes verbirgt. In der Praxis besteht die DPE aus kernels, die über den verschiedenen heterogenen Computerumgebungen - den sogennanten Native Computing and Communication Environments (NCCE s) - implementiert werden

47 Die Rolle der DPE im Engineering Modelling Die DPE Kernels werden durch zusätzliche generische Softwarekomponenten - die DPE Services - erweitert. Interagierende Dienstkomponenten Distributed Processing Environment (DPE) NCCE NCCE NCCE HW HW HW DPE Services realisieren Verteilung, Sicherheit, Quality of Service,... In diesem Sinne stellt die DPE die Abstraktion der Verteilung von Netzknoten und damit eine gemeinsame Basis für eine verteilte Realisierung von TINA Diensten bereit. Für die Implementierung einer TINA DPE wird eine geeignete Verteilungsplattform benötigt

48 Kooperation Verteilter Objekte DCOM CORBA Java-RMI Integrationstechnologien Programmiertechnologie Objektkommunikation basierend auf Objektmodell - Kapselung - Wiederverwendbarkeit Java-zu-Java- Kommunikation auf Objektebene reine Windows- Umgebungen Praxiseinsatz skalierbar, getestet Lösung für heterogene Umgebungen mit verschiedenen Programmiersprachen, verschiedenen Betriebssystemen reine Java- Umgebungen 13-48

49 Realisierung der DPE TINA- Anwendungen (Application Objects) Verteilungsplattform Distributed Processing Environment (DPE) - CORBA AIX Solaris Win. NT Native Computing and Communication Environment (NCCE) IBM SUN DEC Hardware Ressourcen 13-49

50 13. Vorlesung TINA Service Architecture 13-50

51 Das Session Concept Session (Sitzung): Temporäre Beziehung zwischen einer Menge von Objekten zwecks kollektiver Ausführung von Aktivitäten ( session soll das traditionelle Konzept des call s ersetzen und damit auch komplexe Multimedia-TK-Dienste ermöglichen) Eine Session hat einen Zustand, der sich während des Bestehens dieser Session ändern kann. Es werden 3 grundlegende Arten von Sessions unterschieden - gemäß Splittung der Referenzpunkte in Access und Usage Part, wobei letzterer noch verfeinert wird: Access Session Service Session Access Session Communication Session 13-51

52 Access Session - stellt einem Nutzer einen Kontext bereit, um einen TINA Dienst zu nutzen, der von einem Provider angeboten wird - schafft eine sichere, abrechenbare, managebare Beziehung zwischen dem Nutzer und Provider im TINA-System Eine Access Session (AS) entsteht, wenn zwei Domain Access Sessions (D_AS) ein Binding eingehen. Die AS kann dann von jedem Domain terminiert werden. Domain 1 (Consumer) Domain 2 (Retailer) Domain 3 (3rd Party) Domain Access Session Domain Access Session Domain Access Session Domain Access Session Access Session Access Session 13-52

53 Service Session Aus einer Access Session können eine oder mehrere Service Sessions aufgerufen werden - die Service Session ist dann (nur) solange aktiv, wie die Access Session. Die Service Session unterteilt sich dann noch einmal in Usage Service Session und Provider Service Session: Domain 1 Domain 2 Domain 3 Usage Service Session D1-USS D2-USS Service Session Provider Service Session Usage Service Session D2-USS D3-USS Provider Service Session: repräsentiert grundlegende Dienstlogik und -kontrolle für die Domains, die am Dienst beteiligt sind Usage Service Session: repräsentiert andere Domains in der Service Session 13-53

54 Communication Session Die Communication Session kann mehrere Verbindungen mit mehreren Endpunkten zur Multimedia-Übertragung handhaben. Aber: Zu jedem Zeitpunkt kann nur eine Service Session einer Communication Session zugeordnet sein. Sie kann mit dem Connectivity Provider interagieren, um Interaktionen für die Service Session bereitzustellen. Generell gilt: eine Service Session kann ohne eine entsprechende Access Session nicht existieren eine Access Session kann mehrere Service Sessions umgeben eine Communication Session kann nicht ohne eine Service Session existieren eine Communication Session kann durch lediglich eine einzelne Service Session kontrolliert werden, um Konflikte zu vermeiden 13-54

55 Beispiel: Abhängigkeiten zw. verschiedenen Sessions User Mickey User Minnie Provider X start end Access Session 1 start end Access Session 2 start end invite SS 2 start end start join end Service Session (SS) 1 Service Session 3 start end start end Provider Y start end Comm. Session (CS) 1 CS 2 CS 4 start end CS 3 time 13-55

56 Bsp. Session Concept zw. Consumer, Retailer u. 3rd Party Domain 1 (Consumer) Domain 2 (Retailer) Domain 3 (3rd Party) Domain 1 Access Session Domain 2 Access Session Domain 2 Access Session Domain 3 Access Session Access Session Access Session Service Session D1-USS D2-USS D2-USS D3-USS Usage Service Session Provider Service Session Usage Service Session Communication Session 13-56

57 TINA Service Components: Aufbau einer Sitzung Service Componets sind eine Kombination von Computational Objects und Computational Object Groups. Computational Objects sind dabei eine Verteilungseinheit über einem DPE-Knoten. as-uap IA 1 PA 1 UA 1 SF ss-uap USM SSM 13-57

58 Aktive TINA Working Groups TINA-Anwendungen Dienstmanagement TINA - IN Virtual Home Environment Service Architecture Reference Points Electronic Commerce Compliance and Testing Framework DPE Architecture IP Control and Management Security SIG TINA geht generell von Spezifikationen zur Entwicklung von Produkten über