.NET AnwendungsarchitekturVon Schichten zu Verbänden

Ralf Westphal, ralfw@ralfw.de

Freier Autor, Berater, Entwickler und Associate of thinktecture

Bekannte Architekturmodelle heute

Schicht für Schicht

• Architekturen bauen Anwendungen in logischen Schichten (engl. layer) auf

• Logische Schichten können zu physikalischen werden (engl. tier)– sog. „Verteilte Anwendungen“

• Das scheint inzwischen allen plausibel und erinnert an…

OSI Schichten

Probleme mit heutigen Architekturmodellen• Software layers sind etwas anderes als network

protocol layers– Im Netzwerk bleibt die grundsätzliche Funktionalität

je Layer gleich, aber das Abstraktionsniveau steigt– Bei Software ändert sich die Funktion bei u.U. gleicher

Abstraktion

• Es fehlen Aussagen zu physikalischen Einheiten (z.B. Komponente, Host)

• Schwammige Terminologie– Was ist eine Applikation?– Was bedeutet „verteilte Anwendung“?

• Mangelnde Skalierbarkeit– Die Beschreibung von Softwaresystemen wird schnell

unhandlich

Wir brauchen…

• …ein neues Architekturmodell, dass…– leicht verständlich ist– die bisher abgedeckten Fälle enthält– besser skaliert– klare Vorgaben macht– eine klare Terminologie definiert– zu einfacheren Darstellungen größerer

Systeme führt– existierendenen Technologie einen

Platz zuweist– breit anwendbar ist

Software Cells

Software Cell /Software Zelle

United Software Cell Structure /

Software Zellverband

Software Zelle = Applikation

Eigenschaften einer Software Zelle I• Eine Zelle wird gebildet durch Hülle

und Kern– Hülle = Host: Container, in dem Logik

ausgeführt wird•Eine EXE-Assembly•App.Config

– Kern = Core: Zentrale Logik der Anwendung, für den Zweck der Applikation unabdingbar•Besteht aus einer oder mehrer DLL-

Assemblies

Die einfachste Applikation• Host: Console-EXE• Core: eine DLL, die autom. gestartet wird und

ohne Ein/Ausgabe arbeitet

• Eine Applikation besteht immer nur aus genau 1 EXE und 1..n DLLs– Verteilte Anwendungen bestehen daher aus min. 2

Applikationen– Ein SOA Service ist immer auch eine Applikation

Eigenschaften einer Software Zelle II• Adapter und Portale dienen der Kommunikation

mit der Außenwelt– Resource Adapter: Zugriff auf Datenbanken,

Dateisysten, Netzwerkverbindungen• Applikation greift nach außen• Hat einen großen Hub, Impedance Mismatch zwischen

Applikation und Ressource ist groß– Application Adapter: Zugriff auf eine andere

Applikation• Applikation greift nach außen• Hat einen kleinen Hub, aufgerufene Applikation stellt

eine Schnittstelle bereit, die sehr nah am Informationsmodell der aufrufenden ist

– Application Portal: Erlaubt den Zugriff auf die Applikation von außen

• Auf Applikation wird zugegriffen• Stellt anden Applikationen eine Schnittstelle zur

Verfügung– User Portal: Erlaubt den Zugriff auf die Applikation

durch einen Benutzer• Auf Applikation wird zugegriffen

Hosts• Hosts stellen dem Core Infrastruktur zur

Verfügung– Im einfachsten Fall laden sie den Core nur und

starten seine Ausführung

• Existierende Host Technologien– Console EXE– Winforms EXE– NT Service EXE– IE– MS Office Anwendungen: Word, Excel, Outlook

etc.– IIS/ASP.NET– COM+– SQL Server 2005– BizTalk

Applikationsarten I

Einfache Desktop Applikation,z.B. Taschenrechner, Solitair

Desktop Applikation mit Dateisystemzugriff,z.B. Notepad, Photoshop

Desktop Applikation DB-Zugriff, z.B.Lexware Buchhalter

RDBMS dateibasiert bzw. Server ohne SPs

Applikationsarten II

Desktop Applikation, die auf ein serverbasiertes RDBMS zugreift, in dem SPs laufen.

Hos

t: W

info

rms

EXE

Hos

t: S

QL

Serv

er

Applikationsarten III

Entfernte Anwendung, z.B. Web Service

Hos

t: II

S/ASP

.NET

Geschäftsprozess-Anwendung

Hos

t: B

izTa

lk

Applikationsarten IV

Stark verteilte Lösung

Verteilte Anwendungen…

…Anwendungen verteilen

Service Oriented Architecture

Alternative, flexiblere Darstellung

Zellräume• Intrazelluärer Raum

– enthält Kern, Adapter, Portale– wird bestimmt durch Host

• Host stellt Infrastruktur, z.B.– Logging/Tracing– Aktivierung– Transaktionen

• Extrazelluärer Raum– Raum zwischen Applikationen– Verantwortlich für den Nachrichtenaustausch

zwischen Applikationen• TCP/UDP• HTTP• MSMQ

Zellstrukturen - Kern

• Kern kann und soll aus mehreren Komponenten bestehen

• Kern-Komponenten (zunächst) ohne Gewichtung und Reihenfolge

Zellstrukturen – Resource Adapter (RA)• Macht Ressource zugänglich

– Liefert Daten auf Abstraktionsniveau des Kerns aus Ressource an

– High Level RA Layer

• Baut auf einem low level API auf• Enthält ggf. eine vereinheitlichende

Schicht zur Ansteuerung verschiedener APIs

• Low Level RA Layer

Zellstrukturen – Application Adapter (AA)• Macht andere Applikationen

zugänglich– Daten werden auf hohem

Abstraktionsniveau erwartet– High Level AA Layer

• Kapselt ggf. Proxy der anderen Applikation– Verbirgt Details des

Applikationszugriffs

Zellstrukturen – Application Portal• Macht Applikation für Zugriff von außen

zugänglich– Abstraktionsniveau abhängig von

Anwendungsart und Kommunikationsmedium

• Strukturierung vonAbstraktionsniveau undAnwendungsartabhängig

Zellstrukturen – User Portal• Birektionale Kommunikation mit einem

Anwender– Präsentation des Kern-Zustands– Erfassung von Daten zur Steuerung des

Kerns

• Typischerweise Organisiertnach dem MVC Pattern

Nichts Neues unter der Sonne• Bei Software geht es immer noch um EVA und

I/O– Eingabe/Input: Adapter/Portal– Ausgabe/Output: Adapter/Portal– Verarbeitung/Processing: Core

Fast wieder OSI

Membranen• Strukturen erhalten

Unabhängigkeit durch Umhüllung mit einer Membran– Membranen isolieren „Innereien“

(Implementation) voneinander•Entkopplung

– Interfaces definieren die „Durchlässigkeit“ von Membranen•Exozytose: Information fließt aus einer

Applikation aus•Endozytose: Information fließt in eine

Applikation ein

– Membranen schließen wiederverwendbare Strukturen ein

Interzelluäre Membran

Intrazelluläre Membranen

Intranukleare Membranen• Kerne haben Strukturen

– Komponenten

• Strukturen im Kern sollten wiederum durch Membranen voneinander getrennt sein

Contract First Design

• Membranen sind vor und unabhängig von der Implementation von Strukturen zu planen– Komponenten referenzieren keine

Komponenten zur Designzeit, sondern Interfaces

– Interfaces definieren…•Operationen•Daten(strukturen)

– Komponenten implementieren Interfaces

Implikationen• Komponentennutzung

– Komponenten (bzw. Klassen aus Komponenten) können nicht mehr direkt instanziert werden

• Lösung: Microkernel lokalisiert und instanziert Komponenten

• Projektorganisation– Projekte referenzieren (nur noch) Interface-

Assemblies– Komponenten werden in separaten

Projektmappen entwickelt• Verhindert die Umgehung von Interfaces

Beispielanwendung

• Ermittlung einer Zahlenreihe– Benutzer wählt aus einer Liste von

Algorithmen zur Zahlenreihenbestimmung aus

– Benutzer gibt einen Maximalwert vor– Benutzer startet

Zahlenreihenberechnung– Anzeige der Ermittelten Zahlen– Benutzer kann die Zahlenreihe

speichern

Beispielarchitektur

The Big Picture• 10n – Eine Reise durch das

Software-Universum

Fazit• Existierende Architekturmodelle haben

Nachteile– Unvollständige Beschreibungen– Umständliche Beschreibungen– Unpräzise Beschreibungen

• Software Cells bieten einen frischen Blick auf Softwarearchitektur– Enthalten bisherige Konzepte

• Schichtenmodell• Onion• Mehrschichtige Anwendungen• SOA

– Machen klare Aussagen und geben Empfehlungen– Sind einfach zu verstehen und lernen– Können große und kleine Systeme ohne

Notationswechsel darstellen

Referenzen• Ralf Westphal, Software Cells – An Introduction,

http://weblogs.asp.net/ralfw/category/9899.aspx • Microsoft, Application Architecture for .NET,

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp

• Clemens Vasters, Ralf discovers the onion and resource access and I say „Duplex“, http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=2892db4d-e9d7-4fd0-ac62-5dc1b68e24f5

• Microkernel Ansätze– Castle Project, http://www.castleproject.org/castle/show/HomePage– Spring.NET, http://www.springframework.net/– Picocontainer, http://www.picocontainer.org– StructureMap, http://sourceforge.net/projects/structuremap

Über den Referenten• Ralf Westphal (www.ralfw.de) ist freier

Softwaretechnologievermittler. Er arbeitet als Fachautor, Coach/Berater, Softwareentwickler und Sprecher auf Entwickler-Events im In- und Ausland wie dem Microsoft Technical Summit, Microsoft DevDays, ADC, BASTA!, COMDEX oder SD West. Der Schwerpunkt seiner Arbeit liegt bei der Vermittlung und Anwendung moderner Softwaretechnologien und -konzepte im Zusammenhang mit dem .NET Framework.

• Darüber hinaus ist Ralf Westphal einer der unabhängigen deutschen Microsoft Regional Directors, Produzent von .NET TV (www.dotnettv.de), Associate der ersten Stunde bei thinktecture (www.thinktecture.com) und zusammen mit Christian Weyer einer der .NET Twins (www.dotnettwins.de).

•Email: ralfw@ralfw.de

www.thinktecture.com

Publikationen

.NET kompakt, Spektrum Akademischer Verlag 2002, ISBN 3827411858

Bücher

ADO.NET Datenbankprogrammierung, Addison-Wesley 2002, ISBN 3827319978

Jetzt lerne ich ADO.NET, Markt+Technik, 2003, ISBN 3827262291(zusammen mit Christian Weyer)

In Fachzeitschriften

Video

www.dotnettv.de tv.dotnetpro.de