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 sd&m

3. Kurzvorstellung sd&m sd&m AG – software design & management Geschäftsfelder • Entwicklung und Integration maß-geschneiderter Informationssysteme für unternehmenskritische Prozesse • IT-Beratung mit Umsetzungskompetenz Hamburg Berlin Düsseldorf Köln/Bonn Wrocław 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 Forschung Aktionär

4. Agenda Agenda Projektvorstellung

5. Projektvorstellung Im Projekt MIRA wurde in .NET ein Pflegesystem für ein Risikobewertungssystem der Münchener Rück entwickelt Projektname: MIRA Kunde Münchener Rück: Weltweit führende Rückversicherung, 6.000 Kunden (Erstversicherer) in 150 Ländern MIRA Munich Re Internet Risk Assessor Risikobewertungssystem für personenbezogene Versicherungen Weltweit in verschiedenen Markt- und Sprachversionen 09/01 – 03/03 (Stufe 1) Zeitraum Team Bis zu 15 Mitarbeiter Projekt Neues internationales Pflegesystem für MIRA mit - Dokumentenmanagement - Workflow-Unterstützung - MS-Office-Integration Mengengerüst ca. 100 Nutzer, generische und konfigurierbare Dialoge ca. 90 DB-Tabellen mit ca. 600 Attributen ca. 1.200 Programmklassen (C#)

6. Projektvorstellung MIRA (Munich Re Internet Risk Assessor) ist ein weltweit im Einsatz befindliches Risikobewertungssystem Auskunftssystemfür Erstversicherer Pflege der Wissensbasis durchMitarbeiter der MR Webbrowser .NET –Client MS Office Internet Remoting Webserver .NET –Server JDBC ADO.NET Wissensbasis Oracle

7. Projektvorstellung Das Kernsystem für die Immobilienfonds-gesellschaft Real I.S. AG gewann den Microsoft .NET Solutions Award 2004 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 Controller Model 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. Unsere Erfahrungen im Design mit .NET .NET unterstützt moderne Architekturen für Zugriffsschichten Wahl des DB-Treiber beeinflußt Performanz

11. Unsere Erfahrungen im Design mit .NET Eine zentrale Frage für die Architektur ist die Art des Datenbankzugriffes ADO.NET bietet zwei Alternativen für den Datenbankzugriff DataReader+ eigene Objekte DataSet Vorteile • umfangreiche Funktionalität„Hauptspeicher-Datenbankmit Replikation“ • schlanker • effizienter • sehr gute Antwortzeiten Nachteile • Overhead bei - Instanziierung - Speicherbedarf - Serialisierung • höherer Programmieraufwand in der Zugriffsschicht verwenden bei (Richtlinien) • Funktionalität wird verwendet • Stand-alone Anwendungen • Web Clients • Web Services • großen Datenmengen • Loading on Demand • Client-Server-Kommunikation • kritischer Performanz

12. Unsere Erfahrungen im Design mit .NET Zeit (localhost) Netzlast Die Art der Kommunikation hat einen entscheidenden Einfluss auf die Performanz Netzlast bei verschiedenen Kommunikationsvarianten Netzlast bei verschiedenen Kommunikationskanälen Basierend auf Senden und Empfangen eines Array von 1000 zufälligen Strings

13. Unsere Erfahrungen im Design mit .NET Die Art der Kommunikation hat einen gravierenden Einfluss auf die Performanz verteilter Anwendungen • 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 (!)

14. Agenda Agenda Installation und Betrieb der .NET-Anwendungen

15. Installation und Betrieb der .NET-Anwendungen .NET-Anwendungen lassen sich einfach installieren und betreiben 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 < 1 sec • Kleine Verzögerung beim Laden • Hauptlast auf DB-Server

16. Agenda Agenda Einsatz von BizTalk 2004

17. Einsatz von BizTalk 2004 Für ein führendes Touristikunternehmen wurde das Buchungs- und Ticketingsystem auf Basis des MS BizTalk Server 2004 neu gebaut. Projektsteckbrief: Buchungs- und Ticketingsystem Kunde Führendes Touristikunternehmen Projekt Verwaltung von Produkten und Preisen, Buchung von Services, Ausstellen und Einlösen von Tickets sowie die Steuerung der Be- und Endladevorgänge Einführung in 2005 erfolgt Zeitraum Team Bis zu 100 beim Kunden und 28 sd&m-Mitarbeiter Technische Umgebung Windows Server 2003 für Anwendungs- und Datenbankserver; Clients unter Windows 2000 Einsatz von sd&m-Standard-Komponenten aus Quasar (Persistenz, Communication, Views, Authorization) Oracle 9.i Microsoft BizTalk Server 2004

18. Einsatz von BizTalk 2004 SAP Accounting System Das Ticketing System kommuniziert mit einer Reihe von Systemen mittels BizTalk 2004 External Booking System CMS Video Text Bonus System Checkin Terminal Mobile Ticketing Todo Replication Server New Booking- and Ticketing-System Ticketing System External Partners Replication Server Ticketing System Replication Server Ticketing System Central DB Internal Booking System Replication Server Ticketing System Booking via Internet Interfaces via BizTalk.

19. Einsatz von BizTalk 2004 BizTalk kommuniziert mittels SAP Adapter und IDocs mit SAP, mit den anderen Systemen über Dateischnittstellen • 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. Verwendung BizTalk

20. Einsatz von BizTalk 2004 Der BizTalk 2004 wird mit verhältnismäßig wenigen Adaptern ausgeliefert. • 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: Erfahrungen Anwendungsentwicklung

21. Einsatz von BizTalk 2004 Die Migration von BizTalk 2002 auf 2004 ist zwar aufwändig, aber verhältnismäßig problemlos • 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 Erfahrungen

22. Agenda Agenda Einsatz von Sharepoint Portal Server 2003

23. Einsatz von Sharepoint Portal Server 2003 Für T-Online wurde das Management-Dokumentensystem auf Basis von MS Sharepoint Portal Server 2003 realisiert Projektname: EDM (Elektronisches Dokumenten Management) Kunde Projekt 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. Team bis zu 5 sd&m-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

24. Einsatz von Sharepoint Portal Server 2003 Das Vorstandsportal von T-Online wurde mit MS Sharepoint Portal Server 2003 umgesetzt

25. Einsatz von Sharepoint Portal Server 2003 Die Funktionalität des SPS 2003 wurde sehr stark erweitert sowie an die Vorgaben des Kunden angepasst • 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 Hauptaufgaben im Projekt

26. Einsatz von Sharepoint Portal Server 2003 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

27. Einsatz von Sharepoint Portal Server 2003 Daher gibt es ein Hauptportal sowie mehrere Subportale, was die Verlinkung verschiedener Sharepoint-Instanzen erforderte.

28. Einsatz von Sharepoint Portal Server 2003 Einige Aspekte wie das Deployment unterschiedlicher Komponenten des SPS 2003 sind nicht trivial • 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. Erfahrungen

29. Einsatz von Sharepoint Portal Server 2003 Tiefgreifende Anpassungen des Sharepoint Portal Servers erfordern Spezialknow-how 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 Betrieb • Betriebliche Themen können großen Einfluss auf das Projekt haben: • Backup-Recovery erforderte Mehrportallösung • Konzeption und Implementierung Loadbalancing • Sizing Hardware ist wichtig

30. Einsatz von Sharepoint Portal Server 2003 Durch die große Dokumentenmenge wurde eine komplexe Infrastruktur erforderlich

31. Einsatz von Sharepoint Portal Server 2003 Die Integration in die MS Produktwelt sowie die Nutzung von Webparts führt zu einer sehr effizienten Arbeitsweise für die Anwender 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

32. Agenda Agenda Fazit

33. Fazit Lessons Learned • 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.

34. Kontakt Dr. Harald Haller Tel. 089 63812-431 haller@sdm.de sd&m AG Carl-Wery-Str. 42 81739 München Telefon 089 63812-0 Fax 089 63812-330 info@sdm.de