Upload
ngokiet
View
214
Download
0
Embed Size (px)
Citation preview
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
Dr. Welf Löwe und Markus Noga 2
.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
Dr. Welf Löwe und Markus Noga 3
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
Dr. Welf Löwe und Markus Noga 4
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
Dr. Welf Löwe und Markus Noga 5
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
Dr. Welf Löwe und Markus Noga 6
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
Dr. Welf Löwe und Markus Noga 7
Hailstorm
HailStorm is the user-centric architecture and set ofservices for .NET that deliver personally relevant information through the Internet to a user, to softwarerunning 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 facilityKern standardisiert durch MicrosoftWeitere Definitionen durch Microsoft Open Process �
Dr. Welf Löwe und Markus Noga 8
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
Dr. Welf Löwe und Markus Noga 9
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
Dr. Welf Löwe und Markus Noga 10
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 Noga 11
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 Noga 12
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
Dr. Welf Löwe und Markus Noga 13
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.)
Dr. Welf Löwe und Markus Noga 14
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?
Dr. Welf Löwe und Markus Noga 15
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 Noga 16
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 Noga 17
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 Noga 18
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
Dr. Welf Löwe und Markus Noga 19
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 Noga 20
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 wiederzuverwendenDCOM– Keine Standardisierungen von DCOM Objekten (Klassen)– Industriestandard: Microsoft Anwendungen stark
Dr. Welf Löwe und Markus Noga 21
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 Noga 22
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 Noga 23
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
Dr. Welf Löwe und Markus Noga 24
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
Dr. Welf Löwe und Markus Noga 25
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
Dr. Welf Löwe und Markus Noga 26
Fazit Corba
Die Corba-Schnittstellen sind sehr flexibel, funktionieren und können inder 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
Dr. Welf Löwe und Markus Noga 27
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)
Dr. Welf Löwe und Markus Noga 28
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)
Dr. Welf Löwe und Markus Noga 29
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