Entwicklung einer SaaS-Lösung mit Standardtechnologien ein Praxisbericht

Transkript

1 CAS Software AG Erfolg durch Customer Excellence Entwicklung einer SaaS-Lösung mit Standardtechnologien ein Praxisbericht VKSI-Sneak-Preview Entwickeln für die Cloud Markus Bauer

2 Agenda Einführung CAS, SaaS und PIA Architektur Technische Architektur, Deployment Logische Architektur Technologien Ausgewählte Schwerpunkte Anpassbarkeit durch Metadaten Integrationsfähigkeit, Offenheit Sicherheit Qualität, Monitoring Randnotizen Zusammenfassung

3 CAS Software AG CRM-Produkte für den Mittelstand Über Anwender weltweit 145 nationale, 60 internationale Partner in 25 Ländern 39 Mio. Euro* Umsatz Rund 220 Mitarbeiter, ca. 400 CAS-Gruppe* Beteiligungen: *Beteiligungsunternehmen anteilig berücksichtigt

4 CAS Produktportfolio CRM Standard-Lösungen genesisworld, PIA + Module CRM Branchen- und Speziallösungen Lösungen für Hochschulen und Schulen + Mehrwertdienste und CRM Individuallösungen

5 Warum SaaS? Grundidee: Ausnutzung von Skaleneffekten Aus Kundensicht: Geringe TCO: geringe Anfangsinvestitionen (Hardware/Software), keine Aufwände für sicheren Betrieb, Backup, Upgrade Vereinfachte Planung: Lösung wächst dynamisch nach Bedarf Aus Anbietersicht: Größeres Marktpotenzial ( Selling to the long tail ) Stetige Einkünfte (Mietmodell) Kostenreduktion durch einheitliche Releasestände Quelle: Rainer Stropek, Microsoft Software Architecture Conference, Vienna 2010

6 CAS PIA und Zielgruppe Die Zielgruppe Kleinunternehmen und Selbständige (< 20 Mitarbeiter) Unternehmen mit verteilten Arbeitsplätzen, Verbundgruppen, Verbände etc. und deren Herausforderungen Kundenbeziehung wird maßgeblicher Wettbewerbsfaktor Individuelle Kundenpflege benötigt hohe Automatisierung Preis-Leistung ist zentrales Entscheidungskriterium Kein IT-Knowhow, keine IT- Infrastruktur notwendig Zentrale Datenablage Umsatzstruktur Unternehmen in D > < 20 #PCs

7 CAS PIA das Produkt

8 Erwartungen an SaaS-Produkte Leichte Bedienbarkeit, Einstieg ohne Hürden Gute Anpassbarkeit an eigene Bedürfnisse Geringe Kosten Hohe Verfügbarkeit Gute Performance, Skalierbarkeit Sicherheit Gutes Zusammenspiel mit existierenden Lösungen

9 Technische Architektur Nutzung von Standardinfrastruktur, deploybar in VMs oder auf Standardservern Günstiger Betrieb Skalierfähigkeit, unterschiedliche Einsatzszenarien

10 Logische Architektur Datenschicht Geschäftslogik GUI Browser Interface/API Präsentationslogik Business Operationen Data Access Server Core Spring OSGi (Equinox) RAP RAP Javascript-RT qooxdoo Datenbank Target Platform

11 Logische Architektur Datenschicht Geschäftslogik GUI Browser Datenbankabstraktion: Kapselung der DB-Spezifika Präsentationslogik Mandanten Interface/API Isolation der Durchsetzung des Rechtesystems Business Operationen CAS-interner SQL-Dialekt mit mächtigen Zusatzprädikaten, Data Access Server CoreAbbildung auf natives SQL Implementierung mit Spring- Templates Spring RAP RAP Javascript-RT OSGi (Equinox) qooxdoo Datenbank Target Platform

12 Aufgaben Modulare, erweiterbare Schnittstelle für Datenversorgung und Businesslogik verfügbar via SOAP; RMI oder in- Process, Teilmenge zusätzlich über Datenschicht Geschäftslogik REST GUI Browser Logische Architektur Data Access Datenbank Interface/API Business Operationen Server Core Spring OSGi (Equinox) Target Platform Aufgaben Präsentationslogik finden, Serienmail Modular aufgebaute Fachlogik, z.b. Dubletten senden, freie Terminsuche Managementoperationen, z.b. Account anlegen Aufgaben Basisinfrastruktur, RAP RAP z.b. Javascript-RT dynamische Verwaltung von Komponenten qooxdoo Bereitstellung generischer Datenobjekte und Metadaten Verwaltung von Kontexten und Security-Informationen Protokollierung

13 Logische Architektur Aufgaben Darstellung (deklarativ erstellter) Oberflächen Datenschicht (Anwendungsrahmen, Geschäftslogik GUI Masken, Listen, ) Zugriff auf Serverinterface Interface/API Präsentationslogik Browser Business Operationen Data Access Server Core Datenbank Spring RAP Aufgaben OSGi (Equinox) Serverseitiges Java-Framework für Rich- Clients im Browser Grundprinzip: Target serverseitiger Platform Komponentenbaum wird mit browserseitigem über Lifecycle-Prinzip und XML-HTTP-Requests konsistent gehalten RAP Javascript-RT qooxdoo

14 Technologien Linux-basierte Server mit Apache Tomcat und MySQL (mit Percona Patches), ggf. als VMs Spring, inkl. Dynamic Module Support (Blueprint), Spring-Security und Spring JDBC-Templates OSGi (Equinox) EH-Cache (inkl. Cache-Sync zwischen Servern) Eclipse Frameworks, insbesondere RAP, jface und EMF

15 Anpassbarkeit durch Metadaten Werkzeuge (basierend auf Eclipse, EMF) GUI Designer XML Backends Basisplattform CAS Open Präsentationsschicht Business Rule Designer Datenbank Designer XML XML Geschäftslogik- Schicht Datenschicht Metadaten Repository beeinflusst Schema Datenbank

16 Integrationsfähigkeit API-Design Plattformgedanke: Jede wichtige Funktion als Webservice Vorsehen von Anpassungs- und Erweiterungspunkten Modulare Schnittstellen über generische Typen und durch Dispatcher/Registry ergänztes Command-Pattern Vorteile: Konzentration der Logik im Backend gute Konfigurierbarkeit, Ausbaubarkeit Neue Clients (z.b. mobile Apps) können einfach entwickelt werden

17 Sicherheit Teilsystemübergänge Isolation von Mandanten Angriffspunkt DB-Schnittstelle Vermeidung von SQL- Injection durch überwachte, echte SQL-Übersetzung Erzwingen der Mandanten- Isolation Angriffspunkt Service-Schnittstelle Operationen werden stets mit Benutzerkontext ausgeführt Integration von Ressourcenüberwachung Angriffspunkt AJAX-Schnittstelle RAP-bedingt logikloser Browser Sessionhijacking schwer aufgrund RAP-Mechanismen

18 Qualität Verschärfter Qualitätsbegriff: kritische Fehler betreffen alle Kunden auf einen Schlag Verhältnismäßig kleine Perfomancekiller addieren sich schnell auf Maßnahmen: Trimmen der Prozesse auf Qualität Werkzeuggestützte Untersuchung, entwicklungsbegleitende Lastund Performance-Tests Monitoring: Sensoren für Standard-Lösung Nagios :03 20:06 20:09 20:12 20:15 20:18 20:21 20:25 20:28 20:31 20:34 20:37 20:40 20:43 20:46 20:49 20:52 20:55 20:58 21:02 21:05 21:07 21:10 21:14 21:17 21:20 21:23 21:26 21:29 21:32 21:35 21:38 21:42 21:45 21:48 21:51 21:54 21:57 22: , , , , , , ,00 0,00

19 Randaspekte Nutzerperspektive: Einstiegshürden vermeiden Anbieter muss sich auf neue Kundengruppe einstellen Beratung durch Self-Service-Mechanismen ersetzen (Videos, ) Billing Support Trotzdem: Kunden fordern persönlichen Kontakt! Konventionelle Schulungen und Dienstleistungen bleiben gefragt

20 Zusammenfassung SaaS-Anwendungen attraktiv durch Skaleneffekte für Anbieter und Kunden (offene) Standardtechnologien lassen sich gut dafür verwenden, erlauben gleichzeitig aber auch on-premise- Betrieb Skalierbarkeit über preisgünstige Standardkomponenten oder über (elastische) VMs möglich Metadaten-basierte Ansätze und dynamische Strukturen erleichtern Anpassbarkeit API-Bildung und Anpassungspunkte explizit vorsehen Sicherheit, Qualität (Robustheit) sind Kernherausforderungen für SW-Entwickler Zum Betrieb einer SaaS-Anwendung gehört mehr als nur deren Entwicklung!

21 Kontakt Markus Bauer CAS Software AG