BiPRO-Anbindung unter.net/wcf

Transkript

1 BiPRO-Workshop für Techniker 2013 BiPRO-Anbindung unter.net/wcf Möglichkeiten, Grenzen und Erweiterbarkeit der Framework-Unterstützung bei der consumerseitigen Anbindung vielfältiger Anbieter und Versionen von BiPRO-Services Markus Keim BCA AG

2 Vorstellung BCA AG Gegründet 1985 Sitz in Oberursel (seit Ende 2012) Ca. 90 Mitarbeiter > 9000 Produkte marktrelevanter Anbieter ~ Partner Einer der größten Maklerpools in Deutschland Business plus Umfassende elektronische Informations-, Beratungs- und Abwicklungsplattform für freie Versicherungs- und Finanzdienstleister SmartClient auf Basis von.net/wcf (WIF) 2

3 Agenda Vorstellung BCA AG Grundproblematik Verwendung von.net/wcf Standard-Tools Verwendung generischer BiPRO Service-Proxys Verwendung dynamischer Service-Endpunkte Nutzung APIs zum XSD-Import und zur Quellkodegenerierung Live-Präsentation Diskussion 3

4 Grundproblematik Consumerseitige Anbindung an BiPRO- Services (insb. Norm 42x, 430, 440) Mehrere Services pro Anbieter (und Norm!) Implementierung Norm 421: Haftpflicht-, Hausrat- und UnfallService Mehrere Anbieter pro Service Mehrere Services pro (BiPRO-) Version Gleiche BiPRO-Basisobjekte Mehrere Versionen pro Service Versionswechsel Zentrale, gemeinsame CCCs bzw. NFRs (Cross Cutting Concern, Non-Functional Requirement) Anbindung: Client-Zugriffklasse (Proxy), Endpunkt, Bindung, (Geschäfts-) Objekte 4

5 Verwendung.NET/WCF Standard-Tools Import der WSDL (inkl. XSDs) per svcutil.exe Komfortabler, weitgehend automatisierter Prozess Generiert clientseitige Zugriffsklasse (Service-Proxy) und Klassen für alle per XSD inkludierten (Geschäfts-) Objekte sowie Endpunkt- und Bindungskonfiguration Keine Unterstützung für BiPRO-SecurityPolicy (SCT per STS) Nicht standardkonform (WS-Trust) -> Keine benutzbare Bindung für Service-Endpunkte und STS Alle Klassen werden in einen servicespezifischen NS generiert Hochgradig redundant (standardisierte Basisobjekte) Jede Implementierungen verwendet eigene Geschäftsobjekte Keine Unterstützung/Übernahme Kommentare aus WSDL/XSD Keine Unterstützung von Aufzählungstypen mit String-Werten 5

6 Verwendung.NET/WCF Standard-Tools Import von XML-Schemata per xsd.exe Generiert (C#) Quellkode für alle Objekte der XML-Schemata Namespace frei konfigurierbar Ermöglicht zentrale Bibliothek(en) von BiPRO-Basisobjekten Service-Proxy sowie Endpunkt- und Bindungskonfiguration müssen anderweitig (manuell) erstellt werden (-> svcutil) Daher auch keine (automatische) Unterstützung für BiPRO- Authentifikationsschema (SCT/STS) Benötigte Serialisierungs-Attribute ( XmlIncludeAttribute ) werden nur innerhalb eines NS generiert -> Fehler beim Serialisieren/Deserialisieren NS-übergreifender Ableitungen Keine Unterstützung/Übernahme Kommentare aus WSDL/XSD Keine Unterstützung von Aufzählungstypen mit String-Werten 6

7 Verwendung generischer BiPRO Service-Proxys Problem: Querschnittliche Belange (CCCs) bzw. nichtfunktionale Anforderungen (NFRs) werden durch Standard-Tools nicht unterstützt Insbesondere Authentifikationsschema (SCT/STS) Spezielle Anforderungen für HTTP- und SOAP-Header.NET/WCF bietet Hooks für viele Aspekte in der Verarbeitung von (SOAP-) Nachrichten ServiceChannelManager (Erstellen/Verwalten von Proxys) EndpointBehavior/MessageInspector (Anpassung Endpunkt-Verhalten und Inspektion/Modifikation SOAP- Nachrichten) 7

8 Verwendung generischer BiPRO Service-Proxys Lösung: Implementierung abstrakter, generischer BiPRO-ServiceProxy Erstellung und vorhalten typisierter Service-Proxys ( Channels ) Prüfung des Sitzungsstatus für einen Proxy (SCT) Anfordern und Setzen eines SCT über den zuständigen STS Modifikation der von WCF generierten SOAP-Nachrichten Hinzufügen HTTP-Header SOAPAction, Entfernen SOAP-Header ( Action, To, ), Hinzufügen ConsumerID, Instantiierung eines konkreten BiPRO- ServiceProxy per Typ-Parameter Typ entspricht WSDL-PortType (Interface, derzeit per svcutil generiert) Beispiel (vereinfacht): public class Bipro421ServiceProxy : BiproServiceProxy<IKompositServicePortType>{} 8

9 Verwendung dynamischer Service-Endpunkte Problem: Es ist nicht sinnvoll (praktikabel) für jede Implementierung einer BiPRO-Norm einen eigenen Endpunkt zu definieren 9 Endpunkt-Eigenschaften sollten bis aus die Endpunkt-Adresse für alle Implementierungen einer Norm/Version identisch sein Standard-Tools erzeugen keine (verwendbaren) Endpunkte Lösung: Dynamisches Erzeugen der Service- Endpunkte zur Laufzeit Client-Konfiguration enthält pro Service und Version generische Endpunkt-Definition ohne Adresse Informationen zu Normen und Implementierungen sind in DB abgelegt (1:n, inkl. Authentifikations-Informationen) Generischer BiPRO-Proxy erstellt Service-Proxy und setzt Endpunktadresse dynamisch (fragt DB ggf. selber ab)

10 Verwendung dynamischer Service-Endpunkte Beispiel (vereinfacht): <!-- BiPRO 421 (KompositService 2.1.5) --> <endpoint address="" binding="custombinding" bindingconfiguration="biproservicebinding contract="kompositservice_2_1_5.ikompositserviceporttype" name= "> </endpoint> Bipro421ServiceProxyBanania bipro421serviceproxy = new Bipro421ServiceProxyBanania(); Bipro421ServiceProxyBanania ist Bipro421ServiceProxy, kann also Informationen zu BiPRO- Norm 421 aus DB abfragen Spezielle Ableitung für VU, kann also Informationen zur VU- Implementierung der Norm 421 (inkl. zentrale Zugangsdaten) aus DB abfragen Bipro421ServiceProxy können aber auch mit zuvor abgefragten Daten zu Endpunktadresse und Zugangsdaten (benutzerspezifische Authentifikation) instantiiert werden 10

11 Nutzung APIs zum XSD-Import und zur Quellkodegenerierung Problem: Direkte Nutzung der Standard-Tools ist inneffizient bzw. nicht praktikabel Hohe Redundanz, schlechte Wartbarkeit, hoher Aufwand zur manuellen Nachbearbeitung von generiertem Quellkode, Lösung: Nutzung von (z. T. nicht öffentlichen) APIs aus verschiedenen Namespaces die auch von svcutil etc. verwendet werden System.Xml.Schema (Unterstützung XML-Schemata) System.Xml.Serialization (Serialisieren/Deserialisieren) System.CodeDom (Struktur und Elemente Quellkodedateien) Microsoft.Csharp (Kompilierung/Generierung C# Quellkode) 11

12 Nutzung APIs zum XSD-Import und zur Quellkodegenerierung Grundidee: Two-pass Importprozess und Quellkodegenerierung mit expliziter Steuerung über API-Methoden Import eines Satz von BiPRO-Schemata (Release, Normpaket) und optionaler VU-Erweiterungen in temporären Namespace Zwischenspeichern von Quelldatei-Schema-Objekt Beziehungen, XML-Importdeklarationen, XML-Annotations, Nochmaliges Einlesen der generierten Schema-Objekte in Ziel- Namespace pro Schema-Quelldatei Generieren C#-Quellkodedatei pro Zielnamespace Generieren von C#-Importdeklarationen Generieren/Modifizieren von Serialisierungs-Attribute Übernahme von XML-Annotations in Quellkodekommentare 12

13 Live-Präsentation 13

14 Diskussion 14

15 Vielen Dank für Ihre Aufmerksamkeit! 15