Transcript Software aus Komponenten

.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
1
.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 Noga
2
Webdienste in .NET
Offene Standards (W3C) als Schnittstelle zum Web
Werkzeuge vereinfachen Anbindung an .NET
Ebenen laut Microsoft
Standard
–
–
–
–
–
Datenformat
Nachrichtenformat
Dienstbeschreibung
Auffindung von Diensten auf Servern
Auffindung von Servern
XML
SOAP
WSDL
?
UDDI
Problematische Unterscheidungen
– Datenformat – Nachrichtenformat
– Ebenen der Auffindung
Dr. Welf Löwe und Markus Noga
3
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
– SMTP
– TCP
(mit Rückkanal)
(Simple Mail Transport Protokoll)
(mit Rückkanal)
Problem: Beliebigkeit
Dr. Welf Löwe und Markus Noga
4
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 Noga
5
Uniform Description, Discovery and
Integration (UDDI)
Beschreibt Dienste auf auf Geschäftsebene
Registrierung ist XML Deskriptor
– White Page:
– Yellow Page:
– Green Page:
Adresse, Erreichbarkeit
Semantik (basiert auf Standard-Taxonomie)
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 Noga
6
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 Noga
7
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
Dr. Welf Löwe und Markus Noga
8
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 Noga
9
Motivation für Hailstorm
Was Microsoft sagt
–
–
–
–
Heute:
Beispiel:
Morgen:
Ausweg:
Anwendungen und ihre Daten leben nebeneinander her
Integration Flugbuchungssystem – Terminkalender
Verteilung, Vielzahl von Geräten führt ins Chaos
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
10
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
– SEGA Dreamcast
– Webdienste?
(DOS, Windows)
(Windows CE, Direct-X)
(.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
11
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 Noga
12
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 Noga
13
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 Noga
14
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
15
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
16
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
17
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 Noga
18
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
19
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 Noga
20
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
21
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
22
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 Noga
23
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 Noga
24
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 Noga
25
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 Noga
26
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 Noga
27
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 Noga
28
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 Noga
29