Dr. Welf Löwe und Markus Noga1.NET und Hailstorm Neue Standards von Microsoft.NET ist Plattform für Webdienste –Verteilte Server bieten Dienste und Daten –Anwendungen auf beliebigen Plattformen (PC, Game Consolen, PDAs) bauen darauf auf –Bezahlung der Dienste? Hailstorm ist eine Sammlung von Webdiensten (Facility/Service?) –Schwerpunkt: Persönliche Daten –Läuft unter.NET Motivation: –Wachstum des PC-Marktes schwach –Gute Voraussagen für Servermarkt (Nicht Microsoftdominiert) –Microsoft muss 30% Umsatzrendite erreichen Viele Ankündigungen, harte Information schwer zu finden

Dr. Welf Löwe und Markus Noga2.NET als klassische Plattform Besser optimierbare, weniger sichere Java VM Common Language Runtime (CLR) –Common Type System (CTS) (vgl. MOF) mit Untermenge –Common Language Specification (CLS) (vgl. IDL) unterstützt auch zusammengesetzte Werttypen –Microsoft Intermediate Language (MSIL) (vgl. Java VM) Virtuelle Kellermaschine, maschinenunabhängiger Bytecode optional mit Registerallokation optional auch maschinenspezifisch –Managed code and data (optional) Managed code stellt Metadaten zur Verfügung Code wohlgeformt, sicher nach bestimmten Kriterien Speicherbereinigung für Daten –Abschied von Registry - Wiedererfindung von Filesystemen

Dr. Welf Löwe und Markus Noga3 Webdienste in.NET Offene Standards (W3C) als Schnittstelle zum Web Werkzeuge vereinfachen Anbindung an.NET Ebenen laut MicrosoftStandard –DatenformatXML –Nachrichtenformat SOAP –DienstbeschreibungWSDL –Auffindung von Diensten auf Servern? –Auffindung von ServernUDDI Problematische Unterscheidungen –Datenformat – Nachrichtenformat –Ebenen der Auffindung

Dr. Welf Löwe und Markus Noga4 Simple Object Access Protocol (SOAP) XML-basiertes Nachrichtenformat Nachricht ist Umschlag mit Kopf und Körper –Kopf enthält Adressaten und Verarbeitungsinformation –Körper enthält Nutzdaten oder Fehlercodes Wirre Mechanismen zur Typdefinition –Arrays –sonst Rückgriff auf Namensräume (implizit also Schemata) Transport ist transparent, vordefinierte Kanäle –HTTP (mit Rückkanal) –SMTP(Simple Mail Transport Protokoll) –TCP(mit Rückkanal) Problem: Beliebigkeit

Dr. Welf Löwe und Markus Noga5 Web Services Description Language (WSDL) XML-basierte Beschreibungssprache für Webdienste Gegenstand: Mengen von Funktionen –Strukturiertes Programmieren –Keine Objektorientierung - keine Vererbung Modellierung von Parametern –XML Schema oder beliebige andere Beschreibungssprachen –Referenzen (auf Dienste) nicht explizit unterstützt Abbildung auf konkrete Schnittstellen –SOAP –MIME (Multi-Purpose Internet Mail Extensions) für SMTP Probleme: Beliebigkeit, fehlende Objektorientierung

Dr. Welf Löwe und Markus Noga6 Uniform Description, Discovery and Integration (UDDI) Beschreibt Dienste auf auf Geschäftsebene Registrierung ist XML Deskriptor –White Page:Adresse, Erreichbarkeit –Yellow Page:Semantik (basiert auf Standard-Taxonomie) –Green Page:Technische Spezifikation (URL, WSDL, etc.) Logisch zentralisierte, physisch verteilte Datenbank UDDI ist kein Makler oder Marktplatz –Keine geographischen Anfragen –Keine Preisanfragen –Keine Zeitanfragen Also: Wie DNS oder JINI, nur komplexere Felder

Dr. Welf Löwe und Markus Noga7 Hailstorm HailStorm is the user-centric architecture and set of services for.NET that deliver personally relevant information through the Internet to a user, to software running on the user's behalf, or to devices working for the user. Microsoft Kurz: Dienste für persönliche Daten unter.NET Einordnung in CORBA: service oder facility Kern standardisiert durch Microsoft Weitere Definitionen durch Microsoft Open Process

Dr. Welf Löwe und Markus Noga8 Dienste in Hailstorm myAddress - electronic and geographic address for an identity myProfile - name, nickname, special dates, picture myContacts – electronic relationships/address book myLocation - electronic and geographical location and rendez-vous myNotifications – notification subscription, management and routing myInbox - inbox items like and voice mail myCalendar – time and task management myDocuments – raw document storage myApplicationSettings - application settings myFavoriteWebSites – favorite URLs and other Web identifiers myWallet - receipts, payment instruments and other transaction records myDevices – device settings, capabilities myServices –services provided for an identity myUsage – usage report for above services

Dr. Welf Löwe und Markus Noga9 Die heilige Privatsphäre Hailstorm verwaltet private Daten Sicherheit entscheidet über Akzeptanz Große Kundenstämme als Referenzen –MSN –Hotmail (zugekauft) –Passport (zugekauft?) Beteiligung an Privatsphäre-Initiativen –TRUSTe –Code of fair information practices Kodex: Keine Werbung, kein Mining, keine Weitergabe

Dr. Welf Löwe und Markus Noga10 Motivation für Hailstorm Was Microsoft sagt –Heute:Anwendungen und ihre Daten leben nebeneinander her –Beispiel:Integration Flugbuchungssystem – Terminkalender –Morgen:Verteilung, Vielzahl von Geräten führt ins Chaos –Ausweg:Standardisierung mit Hailstorm persönliche Daten Verwaltung, Zugriffe, Austausch Was Microsoft will –Den Zugang zu Netzdiensten kontrollieren –Offene Standards in.NET sind Feigenblatt –Kontinuierliche Zahlungsströme von Endbenutzern für Verwaltung und Transaktionen Dienstanbietern für Infrastruktur und nötige Zertifikate Entwicklern für Werkzeuge etc.

Dr. Welf Löwe und Markus Noga11 Die üblichen Tricks Wer die Schnittstelle beherrscht, beherrscht das Geschäft: Microsoft will electronically and physically secure data managed by HailStorm to prevent unauthorized access or use. Implementierungen austauschbar –PCs (DOS, Windows) –SEGA Dreamcast (Windows CE, Direct-X) –Webdienste? (.NET, Hailstorm) Nutzung von Marktmacht –Bekannt:Bündelung von Windows 9x und Internet Explorer –Ebenso:Bündelung von Windows XP und Media Player 8 –Variante:Integration von XP- und Hailstorm-Anmeldung Integration in Office, Spiele, Xbox (Spielekonsole), Stinger (SmartPhone),...

Dr. Welf Löwe und Markus Noga12 Komponenten Programmeinheiten mit standardisierter Basiskommunikation –Abstrakt (nur Schnittstelle), generisch oder konkret (mit Implementierung) –Klassen und Module sind Komponenten Entworfen mit standardisierten Verträgen zur Komposition: –Export-Schnittstelle sichert semantische Eigenschaften zu –Import-Schnittstelle definiert Voraussetzungen zur ihrer Garantie Explizit oder Implizit (als Parameter von Konstruktoren oder anderen Methoden) –Keine verstecktes Wissen Komponenten sind wiederverwendbar Komponenten können aus Komponenten zusammengesetzt sein

Dr. Welf Löwe und Markus Noga13 Komposition Instanziieren generischer Komponenten Zusammensetzen von Komponenten laut Verträgen: –Über Funktionen und Daten –Über Kommunikation, Synchronisation und Protokolle –Problem der globalen Lebendigkeit? –Wie erreicht man nichtfunktionale Eigenschaften? Mangelnde Passung erfordert Adaption der Komponenten: –Externe Adaption durch Wrappercode –Interne Adaption: Offenes Einsetzen Invasiver Austausch nicht-funktionaler Aspekte (z.B. Basiskommunikation tauschen, Synchronisation einfügen etc.)

Dr. Welf Löwe und Markus Noga14 Vergleichskriterien Komponenten –Generische Komponenten –Abstrakte Komponenten (Schnittstellen) –Konkrete Komponenten (Implementierungen) –Zusammengesetzte Komponenten –Basiskommunikation Wiederverwendbarkeit Anpassung (extern und intern) von –Funktionen und Daten –Kommunikation, Synchronisation und Protokolle –Problem der globalen Lebendigkeit?

Dr. Welf Löwe und Markus Noga15 Generische Komponenten - Spezifikationen Corba –Schnittstellen werden aus IDL generiert –Kein ähnliches Konzept für Implementierungen EJB –Deployment entsprechend Descriptor Generierung von Stubs und Skeletons wie bei IDL, Anpassungen an Container, Einweben von Persistenz, Transaktion,... DCOM –Schnittstellenklassen und Proxies werden aus MIDL generiert –Kein ähnliches Konzept für Implementierungen

Dr. Welf Löwe und Markus Noga16 Abstrakte Komponenten - Schnittstellen Corba –Schnittstellen werden aus IDL generiert –Stub und Skeleton –Mehrfachvererbung EJB –Generierung bei Deployment, –Mehrfachvererbung DCOM –Schnittstellen werden aus MIDL generiert –Schnittstellenobjekte –Mehrfachvererbung –Unveränderliche Schnittstellen (immer und überall)

Dr. Welf Löwe und Markus Noga17 Konkrete Komponenten - Implementierungen Corba –Mit Transaktionskonzept / Persistenzkonzept –Sprach- / Plattformunabhängig –Vererbungskonzept der jeweiligen Sprache EJB –Mit Transaktionskonzept / Persistenzkonzept –Java / Plattformunabhängig –Einfachvererbung DCOM –Mit Transaktionskonzept / Persistenzkonzept –Sprachunabhängig (aber de facto MS C-Compilerabhängig) / Plattformunabhängig (aber de facto Windows) –Vererbungskonzept der jeweiligen Sprache

Dr. Welf Löwe und Markus Noga18 Zusammengesetzte Komponenten Corba –Aufruf über ORB –Aggregation über Entwurfsmuster Fassade (auch dynamisch) seit Corba 3.0 EJB –Aufruf über Container –Java Sprachkonzepte zur Delegation DCOM –Aufruf über (D)COM Bibliothek und Proxies –Delegation in Komponenten über Wrapper –Aggregation von Klassen über Entwurfsmuster Fassade (nur statisch) –Aggregation von Schnittstellen

Dr. Welf Löwe und Markus Noga19 Basiskommunikation Corba –Erzeugung und Fernaufruf über ORB (Object Request Broker) –Zentrale Vermittlung über ORB –Fernaufruf GIOP/IIOP (General/Internet Inter ORB Protokoll) EJB –Erzeugung und RMI (Remote Message Invocation) über Container –Anbindung an Corba –Zentrale Vermittlung über Container –Migration von Javacode DCOM –Erzeugung (Fabrik) über lokale Bibliotheksdienste –Objekterzeugung ist Fabrikmethodenaufruf –Objektorientierter Fernaufruf basierend auf DCE über Stellvertreter (proxies) –Dezentrale Vermittlung

Dr. Welf Löwe und Markus Noga20 Wiederverwendung Corba –Vordefinierte Facilities und Services –Vertical Facilities (Fachkomponenten) schwach EJB –Keine Standardisierungen von Beans –AWT und Swing (JavaBeans) meistverwendete Java Bibliothek –Industriestandards: SanFrancisco gescheitert, Fiscus-Projekt? –Derzeit wird eher die Architektur wiederverwendet, um firmenintern Komponenten wiederzuverwenden DCOM –Keine Standardisierungen von DCOM Objekten (Klassen) –Industriestandard: Microsoft Anwendungen stark

Dr. Welf Löwe und Markus Noga21 Generierung aus Spezifikationen Corba –Stub-Skeleton Generierung aus IDL EJB –Klare Trennung von Entwicklung und Einpassung (Deployment) –Unterschiedliche Rollen im Entwurf –Ausbaufähiges Konzept zur Entwicklung von Komponentensystemen durch Trennung von Entwurfsentscheidungen aus Komponentensicht (Implementierungsdetails) Entwurfsentscheidungen aus Kontextsicht (Transaktion, Persistenz, aber auch verteilte Protokolle zur Diensterfüllung) DCOM –Schnittstellen-Proxies Generierung aus MIDL

Dr. Welf Löwe und Markus Noga22 Anpassungen (Corba, EJB, DCOM) Aspekttrennung schafft Voraussetzungen –Trennung von Schnittstellen und Implementierungen –Mehrere Schnittstellen pro Komponente –Trennung von Persistenz-, Transaktions-, Verteilungsaspekt Reflektion erlaubt das Erkennen der Notwendigkeit Brücken zur Anpassungen der Kommunikation zwischen den Welten –EJB – Corba –Java – DCOM –Corba - DCOM Konzepte zur Anpassung –Explizites Adaptieren und Delegieren –IDL Generatoren erzeugen Code für Sprach- und Verteilungsanpassungen –siehe Konzepte zur Komposition

Dr. Welf Löwe und Markus Noga23 Weitere Anpassungen mit Corba MOF Meta Object Facility (MOF) –Beschreibung mit gleicher Sprache –zur Anpassung verschiedener Typsysteme (z.B. IDL und UML) XMI, um automatisch Stromformate von Werkzeugen ineinander umzusetzen Anpassung der Metadaten (Datenbeschreibungen) und nicht der Daten selber

Dr. Welf Löwe und Markus Noga24 Weitere Anpassungen EJB Deployment Komposition entsprechend Bean Descriptor Einweben von Aspekte aus Bean Descriptor –Persistenz –Transaktionsverwaltung Interne Adaption dieser Aspekte Hier weitere (automatische) Anpassungen denkbar –Forschungsgegenstand –Architektur vorhanden

Dr. Welf Löwe und Markus Noga25 Fehlende Anpassungen Daten, Funktionen, Kommunikation werden explizit und extern angepasst Synchronisation und Protokollanpassungen entsprechen Anpassungen von Transaktionen und Sessions (siehe vorige Folien) Keine Konzepte zur globalen Lebendigkeit –Lockingkonzepte unter Komposition –Lebendigkeitstests

Dr. Welf Löwe und Markus Noga26 Fazit Corba Die Corba-Schnittstellen sind sehr flexibel, funktionieren und können in der Praxis eingesetzt werden - aber auch komplex und umfangreich, vielleicht zu flexibel für die Praxis Corba ist ein offener Standard. Geht über den Verdrahtungsstandard hinaus normiert (facilites, services) MOF/XMI zur Integration von Typsystemen von Programmiersprachen, Entwurfs- und Entwicklungssystemen, Datenbankschemats etc. Freie ORBs in Linux könnten Corba schieben Java für neue Software, Corba für gemischte Alt-Neu-Systeme

Dr. Welf Löwe und Markus Noga27 Fazit EJB Die Java-Schnittstellen sehr flexibel, funktionieren und können in der Praxis eingesetzt werden Standard in Firmenhand Sun Microsystems - kann die gleichen Probleme bereiten wie bei Microsoft Java/Beans/EJB wird die Basis für Geschäftsobjekte Die Definition von Beans und EJB als Standardkomponenten erhöht den Grad der Modularisierung und Widerverwendung, bislang aber noch keine Komponenten von der Stange am Markt Die Dokumentation ist gut Deployment in EJB gehen weiter als andere Konzepte, da Anpassungen generiert werden (das kann Corba/DCOM nur für Verteilung)

Dr. Welf Löwe und Markus Noga28 Fazit DCOM Vorwiegend Verdrahtungsstandard Dezentrale Kommunikationsvermittlung über Proxies Kein offener Standard - bei bekannter Firmenpolitik von Microsoft besonders kritisch Anstelle der der Facilities und Services Microsoft Anwendungen –Office ist Quasistandard (Formate von allen Konkurrenten unterstützt) –Weitere Verbreitung als Corba –Schnittstellen / Formate können durch Microsoft geändert werden Windows als Plattform vorausgesetzt (auch wenn EntireX von Software AG auf Linux existiert)

Dr. Welf Löwe und Markus Noga29 Fazit kommerzielle Komponentensysteme + Komponenten- und Verdrahtungsstandard + Transparenz bzgl. Verteilung, Sprache, Plattform, Persistenz + Transaktionskonzepte + Vordefinierte Dienste, Komponenten, Anwendungen -Komplex, hoher Einarbeitungsaufwand -Flexibilität führt zur hoher Komplexität auch im Produktionscode (Laufzeitprobleme) -Objektorientierte Entwurfskonzepte nicht auf Komponentenebene umgesetzt -Kaum Unterstützung für Anpassungen der Komponenten