.NET und Hailstorm

.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

.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

Webdienste in .NET • Offene Standards (W3C) als Schnittstelle zum Web • Werkzeuge vereinfachen Anbindung an .NET • Ebenen laut Microsoft Standard • Datenformat XML • Nachrichtenformat SOAP • Dienstbeschreibung WSDL • Auffindung von Diensten auf Servern ? • Auffindung von Servern UDDI • Problematische Unterscheidungen • Datenformat – Nachrichtenformat • Ebenen der Auffindung

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

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

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

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 

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 e-mail 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

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

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.

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), ...

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

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.)

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?

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

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)

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

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

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

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

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

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

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

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

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

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

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)

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)

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

.NET und Hailstorm