Dr. Welf Löwe und Markus Noga1.NET und Hailstorm Neue Standards von Microsoft.NET ist Plattform...

Dr. Welf Löwe und Markus Noga 1

.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 VMCommon 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 WebWerkzeuge vereinfachen Anbindung an .NETEbenen 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 NachrichtenformatNachricht 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 WebdiensteGegenstand: 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 DatenbankUDDI 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 .NETEinordnung in CORBA: service oder facility Kern standardisiert durch MicrosoftWeitere Definitionen durch Microsoft Open Process


Dienste in Hailstorm

myAddress - electronic and geographic address for an identitymyProfile - name, nickname, special dates, picturemyContacts – electronic relationships/address bookmyLocation - electronic and geographical location and rendez-vousmyNotifications – notification subscription, management and routingmyInbox - inbox items like e-mail and voice mailmyCalendar – time and task managementmyDocuments – raw document storagemyApplicationSettings - application settingsmyFavoriteWebSites – favorite URLs and other Web identifiersmyWallet - receipts, payment instruments and other transaction recordsmyDevices – device settings, capabilitiesmyServices –services provided for an identitymyUsage – usage report for above services


Die heilige Privatsphäre

Hailstorm verwaltet private DatenSicherheit entscheidet über AkzeptanzGroß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 WissenKomponenten sind wiederverwendbarKomponenten können aus Komponenten zusammengesetzt sein


Komposition

Instanziieren generischer KomponentenZusammensetzen 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

WiederverwendbarkeitAnpassung (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.0EJB– 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 umzusetzenAnpassung der Metadaten (Datenbeschreibungen) und nicht der Daten selber


Weitere Anpassungen EJB Deployment

Komposition entsprechend Bean DescriptorEinweben von Aspekte aus Bean Descriptor– Persistenz– Transaktionsverwaltung

Interne Adaption dieser AspekteHier weitere (automatische) Anpassungen denkbar– Forschungsgegenstand– Architektur vorhanden


Fehlende Anpassungen

Daten, Funktionen, Kommunikation werden explizit und extern angepasstSynchronisation 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 PraxisCorba 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 schiebenJava 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 werdenStandard in Firmenhand Sun Microsystems - kann die gleichen Probleme bereiten wie bei MicrosoftJava/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 MarktDie Dokumentation ist gutDeployment 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 ProxiesKein offener Standard - bei bekannter Firmenpolitik von Microsoft besonders kritischAnstelle 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

Dr. Welf Löwe und Markus Noga1.NET und Hailstorm Neue Standards von Microsoft.NET ist Plattform...

Documents

Transcript of Dr. Welf Löwe und Markus Noga1.NET und Hailstorm Neue Standards von Microsoft.NET ist Plattform...