Schnittstellen

7 goldene Regeln
für den Aufbau eines funktionalen Interfaces

Ivan Schwab-Germann / Intersim AG

Agenda

Thema: Schnittstellen im serviceorientierten Umfeld

Umsetzung

Architektur / Change
Aufgabe Performance Sicherheit
Datenformat Mgt

Konzeption

Mai 2012 © Ivan Schwab-Germann - Intersim AG

Aufgabenstellung (Problemstellung)

 Heterogene Netzwerkprotokolle
 Heterogene Schnittstellen
 Mangelnde Konnektivität
 Heterogene Datenstrukturen
 Fehlende (ungenügende) Dokumentationen
 Fehlendes Know-How


Aufgabenstellung (Problemstellung)

Format? IDOC
IDOC
Stammdaten Conn.

+ Produkt- Verfügbarkeit
+ Rabattierung / Nettopreise
+ Aussendienst-Verantwortliche
Internet
+ Getätigte Bestellungen
ERP-System
E-Shop + Vorbestellungen
+ Kundenstatus

Auftragsdaten
Konnektivität?


Konzeption der Schnittstelle

In die Konzeptionsphase gehören
 Definition der Zielsetzungen
 Technische Spezifikationen
 Regeln für die Daten-Validierung
 Mengengerüst
 Definition der Sicherheits-Standards
 Prototyping (inkl. Datenübermittlung)
 Performance- und Konsistenz-Tests

Nur ein Prototyping inkl. Review gibt die Garantie, dass
alle dasselbe unter den Definitionen verstanden haben.



Aus der Praxis:
SOAP/XML Web-Service (.NET)
 Definition der Zielsetzungen 
 Technische Spezifikationen 
 Regeln für die Daten-Validierung 
 Definition der Sicherheits-Standards 
 Prototyping 
 Performance-Tests 



IST: Web-Service live, Testing
Erwartungen Resultat
Sicherheit (https)  (Firewall)
Dateninhalt All data  (partielle Übermittlung)
Performance (Records einzeln)
Datenformate   (kein Proxy)

Nie mehr ohne Prototyping


Performance-Aspekte

Was gilt es zu berücksichtigen
 Datenmenge (Bytes)
 Datendurchsatz
 Daten-Granulierung (Arrays)
 Aufruf: 0.2-0.4 Sekunden (Footprint ca. gleich wie HTTP-Aufruf)
 HTTPS vs. HTTP?


Performance-Aspekte

Welche Ansätze gibt es
 Grosse Datenmengen und kleiner Datendurchsatz  feine
Granulierung, Binaries auslagern, asynchrone Übermittlung
 Viele Records  Array-Unterstützung
 Real-Time Aufruf: möglichst nur ein Aufruf (0.2-0.4 s initial)
 Öffentliche Daten  HTTP anstatt HTTPS
 Stabilität gefordert  feine Granulierung

Real-Time: Wenig Aufrufe i.d.R. besser
Asynchron: Höhere Granulierung


Performance-Aspekte

Aus der Praxis:
Zugriffsgranulierung
Request WS
Token Security Token
Proxy
Request+Token WS
Data Business Object

 Array
Unterstützung


Intermezzo Architektur

Simple Object Access Protocol Representational State Transfer

SOAP / XML REST

 Grosse Freiheit bei der  Client unabhängig
Umsetzung  keine Anwendungs-
 Overhead durch XML funktionalität auf
Ressourcen
 XML Aufruf
 URL basierend
 XML Rückgabedaten  einfacher Javascript Aufruf


Intermezzo Architektur

Simple Object Access Protocol Representational State Transfer

SOAP Envelope

SOAP Header
HTTP-Call

SOAP Body Content
Content (XML)

HTTP-Call


Sicherheits-Aspekte

Network Server (Host) Interface
Applikation
 Router  Patches
 Firewall  Antivirus  Paketverschlüsselung
 Punkt-Punkt  Access Mgt (SOAP – Security)
Verbindung  Verbindungs-  Authentifizierung
verschlüsselung  Security Token
(HTTPS)
 … mit Client Zertifikat


Sicherheitsaspekte

Security ganz gross

HTTPS mit Client Zertifikat Punkt-Punkt

Konsument Service
Nur SOAP
SOAP Security Authentifizierung
SOAP Envelope Security
Content Service


Sicherheitsaspekte

Praxis-Empfehlungen:
 Security wo nötig
 Wenn möglich: Punkt-Punkt Verbindung
 SOAP bietet erhöhte Sicherheit
 SOAP Security nur bei hohen Anforderungen

Wenn erhöhte Sicherheit gefordert wird, ist SOAP mit
Security-Token Konzept zu empfehlen.


Transport-Layer / Architektur

Im Zweifelsfall SOAP/XML weil
 system- und plattform-neutral (Basis-Datentypen +
Arrays verwenden)
 programmiersprachen-neutral (keine spezifischen
Datenkonstrukte)
 http Transport-Protokoll
 Datenvalidierung möglich
 Erhöhte Sicherheit möglich

SOAP eignet sich bestens für WS Schnittstellen mit
hohen Anforderungen – REST für Ajax.


Datenformate

Gegenüberstellung

SOAP / XML REST / JSON

 XML Aufruf  Einfachere Strukturen
 XML Rückgabedaten  Einfache Handhabung
 Für Browserverarbeitung
ideal


Datenformate

Aus der Praxis:
 Umsetzungsprobleme (Know-How)
 Fat-Files nicht über Services
(Security ist meist nicht gleich)
 Beim Kunden oft «Old World» Formate

JSON liefert Nutzdaten. SOAP dann verwenden, wenn
Validierung der Daten nötig ist (via XSD)!


Change Management

 Aufgesetzte Dreistufigkeit leben:
- Development, Integration, Live
 Ticketing-System
 Fixe Release-Zyklen
 Rückwärtskompatibilität
 (Permanente Überwachung)
Definieren Sie für Change Request fix geltende Regeln
und Prozesse!


Do’s and Dont’s

1. Real-Time Warenkorb-Berechnung beim ERP
funktioniert
2. Abbilden von Netto-Preis Kalkulationen beim
Client kann funktionieren
3. Wenn HTTPS mit Client-Zertifikat, dann auch auf
dem Integration-System
4. Wenn Stabilität gefragt ist, dann ein WS-Interface
mit SOAP/XML
5. Vertrauen ist gut, Kontrolle ist besser


Die 7 goldenen Regeln

1. Konzeption: Prototyp erstellen
2. Performance: Real-Time - Wenige Aufrufe
Asynchron - Höhere Granulierung
3. SOAP bei hohen Anforderungen – REST für Ajax
4. Sicherheit: SOAP mit Security-Token
5. Datenformat: SOAP bei Datenvalidierung
6. Change: Fixe Regeln definieren
Falls Sie ein Problem vermuten und mich anrufen
wollen, super. Rufen Sie während der Konzeption an!


Besten Dank fürs Zuhören

Kontakt: Ivan Schwab-Germann
Mail: ivan.schwab@intersim.ch
Telefon: 034 424 11 24
Xing: http://www.xing.com/profile/Ivan_SchwabGermann
ONE: Stand 101


Schnittstellen

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Schnittstellen

Semelhante a Schnittstellen (20)

Mais de ONE Schweiz

Mais de ONE Schweiz (20)

Schnittstellen