Design und Realisierung komplexer Systeme mit .NET-Technologie

1
Design und Realisierung komplexer Systeme mit
.NET-Technologie
Dr. Harald Haller Wuppertal, 14. April 2005
A Company of
2
Agenda
Agenda

• Kurzvorstellung sdm

3
sdm AG software design management
Kurzvorstellung sdm
Geschäftsfelder

• Entwicklung und Integration maß-geschneiderter
  Informationssysteme für unternehmenskritische
  Prozesse
• IT-Beratung mit Umsetzungskompetenz

Hamburg
Berlin
Düsseldorf
Köln/Bonn
Wroclaw
Frankfurt
Kunden
Stuttgart

• Namhafte Unternehmen und Organisa-tionen, die
  durch Einsatz individueller Lösungen
  Wettbewerbsvorteile erlangen

München
www.sdm.de
Zürich
Eckdaten 2004

• Mitarbeiter 950
• Umsatz 125 Mio.

Kernkompetenz

• Software-Engineering und IT-Architektur
• Projekt- und Qualitätsmanagement
• Prozessgestaltung und -optimierung

Aktionär
Forschung
4
Agenda
Agenda

• Projektvorstellung

5
Im Projekt MIRA wurde in .NET ein Pflegesystem
für ein Risikobewertungssystem der Münchener Rück
entwickelt
Projektvorstellung
Projektname MIRA
Münchener Rück Weltweit führende
Rückversicherung, 6.000 Kunden (Erstversicherer)
in 150 Ländern
Kunde
Munich Re Internet Risk Assessor Risikobewertungss
ystem für personenbezogene Versicherungen Weltweit
in verschiedenen Markt- und Sprachversionen
MIRA
09/01 03/03 (Stufe 1)
Team
Bis zu 15 Mitarbeiter
Zeitraum
Neues internationales Pflegesystem für MIRA
mit - Dokumentenmanagement - Workflow-Unterstütz
ung - MS-Office-Integration
Projekt
ca. 100 Nutzer, generische und konfigurierbare
Dialoge ca. 90 DB-Tabellen mit ca. 600
Attributen ca. 1.200 Programmklassen (C)
Mengengerüst
6
MIRA (Munich Re Internet Risk Assessor) ist ein
weltweit im Einsatz befindliches
Risikobewertungssystem
Projektvorstellung
Auskunftssystemfür Erstversicherer
Pflege der Wissensbasis durchMitarbeiter der MR
Webbrowser
.NET Client
MS Office
Remoting
Internet
Webserver
.NET Server
JDBC
ADO.NET
Wissensbasis
Oracle
7
Das Kernsystem für die Immobilienfonds-gesellscha
ft Real I.S. AG gewann den Microsoft .NET
Solutions Award 2004
Projektvorstellung
Kunde

• 100-ige Tochter der Bayerischen Landesbank
• Fondsinitiator für private und institutionelle
  Anleger mit den Themen Immobilien, Schiffe,
  Medien, Flugzeuge u. a.
• Immobilienentwicklung/-management

Projekt LEONARDO

• CRM-System für die gesamte Wertschöpfungskette
  geschlossener Fonds Von Akquise über Vertrieb
  bis hin zur Betreuung der Zeichner und Verwaltung
  der Beteiligungen
• Anwender Mitarbeiter der Real I.S.,
  Vertriebspartner
• Zeitraum Seit 05/2001, produktiv seit 09/2002
• Aufwand 20 Bearbeiterjahre
• Technologie Microsoft .NET, C, Webservices

Preis LEONARDO

• Mit LEONARDO wurde auf Basis der .NET Plattform
  eine innovative Unternehmenslösung entwickelt und
  integriert.
• Jury Microsoft Deutschland, TU München, Vodafone
  D2, Gesellschaft für Strategie und Ergebnisse
  und Intel
• 140 Bewerbungen für den Preis

8
Agenda
Agenda

• Unsere Erfahrungen im Design mit .NET

9
Unsere Erfahrungen im Design mit .NET
Windows Forms
Technische Architektur
Tools
Dialog
Portal
View
Basis
Model
Controller
Transformation
Kommunikation
Aus Zeitgründen im Folgenden nur Betrachtung der
Kommunikation und der Datenbankzugriffsschicht
Server
Remoting
ASP.NET
ASP.NET
ASP.NET
Kommunikator
Webservice
Web Client
COM
XMLKonfigu- ration
Security
AWK
DB Zugriff
DB-Server
DBMS
ADO.NET
10
.NET unterstützt moderne Architekturen für
Zugriffsschichten
Unsere Erfahrungen im Design mit .NET
Wahl des DB-Treiber beeinflußt Performanz
11
Eine zentrale Frage für die Architektur ist die
Art des Datenbankzugriffes
Unsere Erfahrungen im Design mit .NET
ADO.NET bietet zwei Alternativen für den
Datenbankzugriff
DataReader eigene Objekte
DataSet

• schlanker
• effizienter
• sehr gute Antwortzeiten

• umfangreiche FunktionalitätHauptspeicher-Datenba
  nkmit Replikation

Vorteile

• höherer Programmieraufwand in der Zugriffsschicht

• Overhead bei - Instanziierung -
  Speicherbedarf - Serialisierung

Nachteile

• großen Datenmengen
• Loading on Demand
• Client-Server-Kommunikation
• kritischer Performanz

• Funktionalität wird verwendet
• Stand-alone Anwendungen
• Web Clients
• Web Services

verwenden bei (Richtlinien)
12
Die Verwendung von DataSets bei der
Client-Server-Kommunikation kann zu
Performanz-Problemen führen
Unsere Erfahrungen im Design mit .NET

• Ein Beispiel
• Es sollen folgende Daten transportiert werden
• Datenhaltung in Datencontainer/Transportobjekt
  (TO)
• DataSet mit einer Tabelle
• TO (Objects)Ablage in Hashtable Schlüssel ist
  Zeilennummer, Inhalt ist Objekt mit genau einer
  Zeile
• TO (2-dim. Array)Ablage der Daten in einer
  String-Matrix (String)

Performance bei der Kommunikation ein Beispiel
No. 3
No. 2
No. 1
Area
Capital
Country
634,52
3575
8234
Europe
Berlin
Germany
265,34
243
2345
Asia
Bejing
China
...
...
...
...
...
...
13
Die Zeiten für die Serialisierung variieren stark
in Abhängigkeit von der Struktur der
Transportobjekte
Unsere Erfahrungen im Design mit .NET
Serialisierung (Remoting)
14
... auch die Netzlast variiert stark
Unsere Erfahrungen im Design mit .NET
Netzlast (Remoting)
15
Bei der Deserialisierung hängt die Performance
ebenfalls stark von der Struktur der
Transportobjekte ab
Unsere Erfahrungen im Design mit .NET
Deserialisierung (Remoting)
16
Die Art der Kommunikation hat einen
entscheidenden Einfluss auf die Performanz
Unsere Erfahrungen im Design mit .NET
Netzlast bei verschiedenen Kommunikationsvarianten
Netzlast bei verschiedenen Kommunikationskanälen
Basierend auf Senden und Empfangen eines Array
von 1000 zufälligen Strings
17
Die Art der Kommunikation hat einen gravierenden
Einfluss auf die Performanz verteilter Anwendungen
Unsere Erfahrungen im Design mit .NET

• Wenn es um die Netzlast geht
• sind Kompressionsverfahren sehr effektiv
• sind die Kommunikationskanäle eher zweitrangig,
  falls Kompressionsverfahren eingesetzt werden
  können
• Wenn es um die Rechenleistung geht
• sind IIOP und Remoting über tcp am effizientesten
• bedeuten Kompressionsverfahren einen deutlichen
  Zeitaufschlag
• Wenn es um die Gesamtperformance geht
• zeigt sich in realen Projekten, dass die
  Rechenleistung eine untergeordnete Rolle spielt,
  sobald am Server weitere entfernte Aufrufe
  stattfinden, insbesondere Datenbankzugriffe (!)

18
Damit die Kommunikation kein Performanz-Killer
wird,sind einige Aspekte zu beachten
Unsere Erfahrungen im Design mit .NET

• Keine komplexen Strukturen transportieren
  (DataSet mit verlinkten Tabellen noch teurer
  als Transportobjekt mit Strukturen)
• Binäre Serialisierung ist schneller als
  XML/SOAP-Variante via HTTP-Channel
• In Projektbeispielen XML/SOAP-Serialisierung
  ca. 3-fache Kommunikationszeiten (Extremwerte
  Faktor 10)
• Varianten für den Datenaustausch testen und
  individuell entscheiden

19
Agenda
Agenda

• Installation und Betrieb der .NET-Anwendungen

20
.NET-Anwendungen lassen sich einfach
installieren und betreiben
Installation und Betrieb der .NET-Anwendungen
Installation

• Framework problemlos
• Anwendung DLLs kopieren, Dienst installieren

Stabilität

• keine Probleme mitCLR und Framework
• täglicher Neustart des Servers ? Garbage
  Collection ok

Performance

• Antwortzeit i. d. Regel lt 1 sec
• Kleine Verzögerung beim Laden
• Hauptlast auf DB-Server

21
Agenda
Agenda

• Einsatz von BizTalk 2004

22
Für ein führendes Touristikunternehmen wurde das
Buchungs- und Ticketingsystem auf Basis des MS
BizTalk Server 2004 neu gebaut.
Einsatz von BizTalk 2004
Projektsteckbrief Buchungs- und Ticketingsystem
Führendes Touristikunternehmen
Kunde
Verwaltung von Produkten und Preisen, Buchung von
Services, Ausstellen und Einlösen von Tickets
sowie die Steuerung der Be- und Endladevorgänge
Projekt
Einführung in 2005 erfolgt
Team
Bis zu 100 beim Kunden und 28 sdm-Mitarbeiter
Zeitraum
Windows Server 2003 für Anwendungs- und
Datenbankserver Clients unter Windows
2000 Einsatz von sdm-Standard-Komponenten aus
Quasar (Persistenz, Communication, Views,
Authorization) Oracle 9.i Microsoft BizTalk
Server 2004
Technische Umgebung
23
Das Ticketing System kommuniziert mit einer Reihe
von Systemen mittels BizTalk 2004
Einsatz von BizTalk 2004
External Booking System
Bonus System
Video Text
CMS
Checkin Terminal
Mobile Ticketing
Todo
Ticketing System
Replication Server
New Booking- and Ticketing-System
External Partners
Ticketing System
Replication Server
Ticketing System
Replication Server
Central DB
Internal Booking System
Ticketing System
Replication Server
Booking via Internet
Interfaces via BizTalk.
24
BizTalk kommuniziert mittels SAP Adapter und
IDocs mit SAP, mit den anderen Systemen über
Dateischnittstellen
Einsatz von BizTalk 2004
Verwendung BizTalk

• Verbindungen zwischen BizTalk Server und
  Anwendungssystemen über Dateiaustausch
• Ein generischer Batch Client wartet auf Use-Case
  Anfragen, die ihm von BizTalk per XML-Datei
  zugeführt werden.
• Diese Kopplung per XML-Datei hat sich als sehr
  vorteilhaft erwiesen
• Durch Abkopplung zwischen Use-Case Aufrufer
  (BizTalk) und System ist Gesamtsystem robuster.
• Durch Kopplung per Datei einfachere
  Nachvollziehbarkeit
• Einzige Ausnahme Verbindung zu SAP mittels SAP
  IDocs über einen SAP Adapter
• Der SAP Adapter stand nicht für BizTalk 2004 zur
  Verfügung.
• Hierfür eigenständiger BizTalk Server 2002,
  ermöglicht mit einem COM basierten SAP Adapter
  den Zugriff zum SAP
• Business-Mapping komplett auf BizTalk Server 2004
• BizTalk Server 2002 lediglich technische
  Transformation eines intern in XML beschriebenes
  IDoc in ein SAP IDoc sowie Übermittlung an SAP
  und umgekehrt.

25
Der BizTalk 2004 wird mit verhältnismäßig wenigen
Adaptern ausgeliefert.
Einsatz von BizTalk 2004
Erfahrungen Anwendungsentwicklung

• BizTalk Server wird nur mit einigen wenigen
  Standard Adaptern ausgeliefert. Weitere Adapter
• entweder mit Hilfe des Adapter Frameworks selbst
  entwickeln oder
• von Drittherstellern erwerben.
• Beides ist mit weiteren Kosten verbunden.
• Komplexe Integrationsanforderungen bzgl. Message
  Routing, Delivery oder Daten-Transformationen
  sind nur mit zusätzlichem Programmieraufwand bzw.
  Tools von Drittanbietern zu bewerkstelligen

26
Die Migration von BizTalk 2002 auf 2004 ist zwar
aufwändig, aber verhältnismäßig problemlos
Einsatz von BizTalk 2004
Erfahrungen

• Betrieb erfordert regelmäßige Kontrolle von
  Eingangs-, Ausgangs- und Fehlerverzeichnissen, um
  mögliche Verarbeitungsprobleme zu lokalisieren
• Es gibt kein aktives Monitoring Tool
• BizTalk Administrator muss sich regelmäßig einen
  Eindruck über den Verarbeitungszustand aller
  laufenden und abgeschlossenen BizTalk Prozesse
  verschaffen
• Hierzu dient das Tool "Health and Activity
  Tracking".
• Migration BizTalk 2002 auf BizTalk 2004
• Architekturwechsel von COM auf .NET
• Wechsel ohne Aufwärtskompatibilität bestehender
  BizTalk Entwicklungen wie Orchestrations und
  Mappings. Diese konnten nur zum Teil über
  Wizards in die .NET Welt überführt werden.
• Manuelles Eingreifen zur Migration der BizTalk
  Sourcen erforderlich
• Zusätzlichen Einarbeitungsaufwand in neue
  Konzepte und Werkzeuge für Entwickler und
  Administratoren
• Neuimplementierung einiger Adapter, wie z. B. des
  SAP Adapters

27
Agenda
Agenda

• Einsatz von Sharepoint Portal Server 2003

28
Für T-Online wurde das Management-Dokumentensystem
auf Basis von MS Sharepoint Portal Server 2003
realisiert
Einsatz von Sharepoint Portal Server 2003
Projektname EDM (Elektronisches Dokumenten
Management)
Kunde
Einführung Microsoft Sharepoint (Portal und
Services) Sharepoint wird für die
Kundenbedürfnisse konfiguriert und
erweitert. Themen sind Navigation,
Dokumentenablage, Berechtigungen, Datenschutz,
Papierkorb, minimale Workflowunterstützung,
Metadaten, Suchfunktionen.
Projekt
Team
bis zu 5 sdm-Mitarbeitern
Zeitraum
Nov. 2004 April 2005
Technische Umgebung
MS Sharepoint Portal Server MS Sharepoint
Services MS Office 2003 MS .NET (ASP.NET, C) MS
SQL Server
29
Das Vorstandsportal von T-Online wurde mit MS
Sharepoint Portal Server 2003 umgesetzt
Einsatz von Sharepoint Portal Server 2003
30
Die Funktionalität des SPS 2003 wurde sehr stark
erweitert sowie an die Vorgaben des Kunden
angepasst
Einsatz von Sharepoint Portal Server 2003
Hauptaufgaben im Projekt

• Erstellung von Webservices u.a. für
• Papierkorbfunktionalität
• initiale Datenablage
• Erstellen der Webparts für Menüs, Projekträume,
  Suchen, ...
• Implementierung der EventHandler für die
  Unterstützung der Workflows
• Customizing entsprechend der Kundenanforderungen
• Erstellung von Workarounds

31
Für das Backup-Recovery durfte die Datenbank SQL
Server nicht zu groß werden. Der Sharepoint
unterstützt im Hauptportal keine Verteilung auf
mehrere Datenbanken
Einsatz von Sharepoint Portal Server 2003
32
Daher gibt es ein Hauptportal sowie mehrere
Subportale, was die Verlinkung verschiedener
Sharepoint-Instanzen erforderte.
Einsatz von Sharepoint Portal Server 2003
33
Einige Aspekte wie das Deployment
unterschiedlicher Komponenten des SPS 2003 sind
nicht trivial
Einsatz von Sharepoint Portal Server 2003
Erfahrungen

• Im Team sollte mindestens ein erfahrener
  ASP.NET-Entwickler sein sowie ein Mitarbeiter mit
  tiefem IIS-Know-how.
• Die Zusammenarbeit mit externen Layoutern ist
  optimal, falls diese ASP.NET-Seiten erzeugen.
  Liefern diese HTML/CSS führt dies zu Mehraufwand.
• Anpassungsaufwand bei Nicht-Webpart-Themen kann
  teilweise groß sein.
• Für die Migration der Dokumente gibt es kaum
  Unterstützung durch Tools.
• Betriebliche Themen dürfen nicht unterschätzt
  werden.
• Deployment ist nicht trivial aufgrund der
  verschiedenen und andersartigen Komponenten, die
  beim Customization entstehen
• Webparts
• XML-Files
• EventHandler
• Webservices
• JavaSkript
• Alle Probleme konnten gut gelöst werden.

34
Tiefgreifende Anpassungen des Sharepoint Portal
Servers erfordern Spezialknow-how
Einsatz von Sharepoint Portal Server 2003
Thema
Erfahrungen
Fachlichkeit

• Fachlichkeit frühzeitig mit Kunden klären, vor
  allem
• Strukturierung der Dokumente
• Berechtigungskonzept
• Welche Inhalte/Informationen sollen als
  Metainformation zusätzlich verwaltet werden?
• Gestaltung der Arbeitsprozesse (Workflows)

• MSDN-Dokumentation für Sharepoint 2003 unter
  typischem MSDN-Niveau
• Viel Neuland, kaum Informationen für SPS 2003
  verfügbar
• Webparts sind sehr mächtig
• Tiefgreifende Änderungen (Volltextsuche,
  Workflow, Webservices) erfordern Spezialknow-how

Implemen-tierung

• Betriebliche Themen können großen Einfluss auf
  das Projekt haben
• Backup-Recovery erforderte Mehrportallösung
• Konzeption und Implementierung Loadbalancing
• Sizing Hardware ist wichtig

Betrieb
35
Durch die große Dokumentenmenge wurde eine
komplexe Infrastruktur erforderlich
Einsatz von Sharepoint Portal Server 2003
36
Die Integration in die MS Produktwelt sowie die
Nutzung von Webparts führt zu einer sehr
effizienten Arbeitsweise für die Anwender
Einsatz von Sharepoint Portal Server 2003
Stärken
Schwächen

• Sehr gute Volltextsuche, unterstützt verschiedene
  Formate und kann ggf. erweitert werden
• Organisation der Teams über die Arbeit in
  Projekträumen ist gut gelöst
• Anpassung und Erweiterung über Webparts
  funktioniert gut
• Integration in Windows Berechtigungssystem und
  Single Sign On komfortabel für Endanwender
• Sehr gute Integration mit Office 2003 (Metadaten,
  SSO, Ein- und Auschecken)

• Einige Aspekte sind unfertig
• Hauptportal nicht auf mehrere Datenbanken
  verteilbar
• Papierkorbfunktionalität
• Keine Workflowunterstützung mit- geliefert
  (lässt sich durch weitere Produkte, z.B. von
  Drittanbietern, beheben.
• 90 IE only, wichtige Funktionen (Kontextmenü,
  Officeintegration) sind im Firefox nicht sichtbar
  
• Betriebliche Themen teilweise aufwändig
• Unterscheidung zwischen SPS und WSS erhöht die
  Komplexität
• Kaum Tools für die Migration der Dokumente aus
  anderen DMS-Systemen vorhanden

37
Agenda
Agenda

• Fazit

38
Lessons Learned
Fazit

• Beim Datenbankzugriff Struktur der Objekte genau
  überlegen.
• Die Art der Kommunikation zwischen einzelnen
  Komponenten/Services kann sich entscheidend auf
  die Performanz auswirken.
• MS Biztalk Server 2004 lässt sich sehr effizient
  in die Anwendungen integrieren und arbeitet
  zuverlässig.
• MS Sharepoint Portal Server 2003
• bietet eine Fülle von nützlichen Funktionen
• der Aufwand für das Customizing entsprechend der
  Anforderungen sowie für betriebliche Themen
  sollte nicht unterschätzt werden.
• Insgesamt lässt sich hiermit eine sehr
  effiziente Arbeitsweise der Anwender
  sicherstellen.

39
Kontakt Dr. Harald Haller Tel. 089
63812-431 haller_at_sdm.de
sdm AG Carl-Wery-Str. 42 81739 München Telefon
089 63812-0 Fax [phone] info_at_sdm.de