Dirk von der Weiden, Olaf Meyer C1 SetCon. REST in the Enterprise

Transkript

1 Konferenz Dirk von der Weiden, Olaf Meyer C1 SetCon REST in the Enterprise

2 REST in the Enterprise C1 SetCon GmbH Stand: Januar 2010 Copyright 2010 C1 SetCon GmbH Member of C1 Group

3 Einleitung Worum geht es in der kommenden Stunde Organisation Umgebung Technologie Projekt-Erfahrungsbericht

4 Einsatzmöglichkeiten Frontend und Middleware Frontend Web-Container Get, Post, Delete Resourcen SOAP, CORBA, Applications Frontend Web-Container Get, Post, Delete Resourcen Get, Post, Delete Resourcen Applications

5 Begriffsbestimmung Was ist Rest Representational State Transfer Begriffsdefinition von Roy Fielding in 2000 REST ist eine Architektur und kein Protokoll Nutzung des vollen Potential von HTTP Alles dreht sich um Ressourcen Client-Server Stateless Cache Layered System Uniform Interface

6 Richardson s Maturity Model Reifegrade

7 Level 0 und 1 Reifegrade Level 0 Übertragen von XML Daten an eine definierten URL. Aus den XML Daten wir bestimmt was zu tun ist. Beispiel SOA - SOAP: Ein Eintrittspunkt (eine URI) Ein HTTP-Verb (Post) Level 1 Greift auf eine Ressource über definierten URL zu. Beispiel verschiedene SOAP- Services: Verschiedene URL für Services Gleiches HTTP-Verb

8 Level 2 Reifegrade Nutzung unterschiedlicher HTTP Verben Nutzung von HTTP Returncodes URL Methode Result /acme/customer/{id} Get Kunde mit der {id} /acme/customer/{id} Put Modifiziert Kunde mit {id} /acme/customer/{id} Post Erstellt Unterelement zum Kunde mit {id} /acme/customer/{id} Delete Löscht Kunde mit {id}

9 Level 3 Reifegrade Verlinkung innerhalb der Ressourcen auf Aktionen und Unterelemente. <?xml version="1.0" encoding="utf-8" standalone="yes"?> <book xmlns:atom=" title="foo" author="bar > <title>rest in Practice</title> <name>somebody</name> <atom:link href=" rel="list"/> <atom:link href=" rel="add"/> <atom:link href=" rel="self"/> <atom:link href=" rel="update"/> <atom:link href=" rel="remove"/> </book>

10 Die aktuelle Architektur wie sie in vielen Unternehmen vorzufinden ist B2C B2B B2E Application Private Customer Business Customer Middleware Billing Hotline CRM Logistic Billing Network Backend Layer

11 Zielarchitektur So wie es seit den Zeiten von EAI sein sollte B2C B2B B2E Application HTTP: GET POST PUT - DELETE REST based Service Layer Composite Services C1 SetCon GmbH 10 Order Customer Contract Stock Backend Layer

12 Nutzen dieser Architektur Management Sicht, technische Sicht Verringerung der Einarbeitungszeiten Sourcing/Skillset homogener Skalierbarkeit Verfügbarkeit Vereinheitlichen der Interface Technologien Kosten: Entwicklung, Wartung, Betrieb Verringerung der Schnittstellenanzahl Rückgabe von verschieden Content-Typen Aufbereitung der Informationen Werden die Versprechen diesmal gehalten Nutzung HTTP Technologien: Caching, Skalierbarkeit etc.

13 Projektparameter Setup 9 Monate Laufzeit 3 Milestones mit Deliverables 10 Iterationen Teamstärke: 8 Entwickler, 2 Tester, 2 Deployer, 1 Projektleiter, 1 Architekt Skillset erfahrene Java-Entwickler; kaum Erfahrung mit REST

14 Projektvorgehen Setup Arbeiten mit Iterationen Regelmässiges Codereview und Refactoring Daily Standups Sprint-Demos Retrospektiven Task-Tracking Festpreis für Milestone Sprintplanung vorgegeben durch Projektleiter und Architekt CRs wurden innerhalb der Sprints mit angenommen.

15 Ziel des ersten Milestones Erstellung der Infrastruktur Codegenerierung aus Schnittstellenspezifikation Erste Ressourcen implementieren Authentifizierung und Autorisierung Datenmodifikation nach Vertrauenswürdigkeit Request-Logging Schemavalidierung

16 Steps Development Auswahl Ziel-Framework: Kundenvorgabe -> Jersey Definition Applikationsarchitektur Anforderung einer definierten und dokumentierten Schnittstelle der REST Services und Ressourcen Dokumentationsgenerierung aus WADL Beispiele gefunden und erweitert Codegenerierung: Client OK, Server Nichts vorhanden. Server-Code-Generator erstellt

17 Code Generierung <wadl:method name="get"> charset=utf-8"}) name="bankaccountno" type="xsd:string" style="query" required="true" /> public Response checkbank( String accountno, <wadl:response UriInfo uriinfo, <wadl:representation mediatype="application/xml; HttpHeaders httpheaders) { element="types:banks" /> LOG.info("Entered checkbank with:" + accountno); </wadl:response> if (accountno == null) { <wadl:response status="303"> runtimeutility.handlemissingrequiredparameter("accountno");} <wadl:representation mediatype="application/xml; charset=utf-8" element="types:banks" BusinessDelegateResponse /> response = delegate.validatebankdata (httpheaders, uriinfo, routingno, accountno, name); </wadl:response> utility.checkforerror(response, uriinfo); <wadl:response status="400"> LOG.info("exit checkbank with result:" + response.tostring()); <wadl:representation mediatype="application/xml; charset=utf-8" element="types:validationerrors" Response createresponse /> = runtimeutility.createresponse(httpheaders, response); </wadl:response> return createresponse;} </wadl:method>

18 Architektur REST-Client Authentication Logging Inbound/Outbound Logging (Request- Tagging, Statistics.. ) Authorisation Content-Type XML to JSON, HTML Content-Type Converter Schema Validation Client XML Converter Client XML to Full Schema, Data Enrichment Schema Validation REST-Facade

19 Tests und Demos Backend-Emulation über SetCon MockToolKit Tests mit Soap UI Soap UI für Sprint Demos

20 Lessons Learned Erstellung eines Test-Tools HTTP Status-Code Mapping problematisch RPC Resourcen Verständnis

21 Paradigmenwechsel RPC Resource RPC Setzt immer auf ein Protokoll auf z.b. HTTP, TCP/IP Funktionsname Parameter Rückgabewert Übertragungsmethode Fehlermeldung Beliebig Beliebig Beliebig Fix z.b. HTTP-Post Fehlermeldung im Rückgabewert verpackt

22 Paradigmenwechsel RPC Resource Resourcen (REST) nutz HTTP direkt Resource Parameter Rückgabewert Übertragungsmethode Fehlermeldung Beliebig Beliebig Repräsentation der Resource : Content Type der Resource Linkung zu Resource Fehlerresource Def. Durch HTTP- Methoden Basierend auf HTTP- Status Code

23 Prüfung von Resourcen URL Methode Result /acme/customer/{id} Get Kunde mit der {id} /acme/validationcustomer Post Legt Validierungsresource an. Fehler -> Validierung fehlgeschlagen /acme/bank?name=dab&kto=1234 &blz=395 Get Suche nach Resource: Erfolgreich -> Validierung Ok Nicht erfolgreich -> Validierung NOK

24 Lessons Learned <Customer> <CustomerId>20097</CustomerId> <FirstName>Hamburg</FirstName> <LastName></LastName> <Address> <Zip>80336</Zip> <City>München</City> <HouseNumber>6a</HouseNumber> <Street>Kapuzinerstraße</Street> </Address> </Customer> <Customer> <CustomerId>20097</CustomerId> <FirstName>Hamburg</FirstName> <LastName></LastName> <Address> <Link href="/addresses/10" name="contact" rel="address"/> </Address> </Customer>

25 Request Vermehrung Company Name=ACME Subcompany Name= ACME Germany Subcompany Name= ACME France Subcompany Name= ACME UK Division Name= München Division Name= Berlin Division Name= Hamburg

26 Optimierung von Requests <Company> <Name>ACME</Name> <Subcompanies> <SubcompanyInfo> <Name>ACME Germany</Name> <Link href="/subcompany/11" rel="subcompany"/> <DivisionInfo> <Name>München</Name> <Link href="/division/11" rel="division"/> </DivisionInfo> </SubcompanyInfo> <SubcompanyInfo> <Name>ACME UK</Name> <Link href="/subcompany/12" rel="subcompany"/> C1 SetCon GmbH </SubcompanyInfo> 25 </Subcompanies>...

27 Fazit technisch REST ist keine Wunderwaffe. Aber es ist einfach und auf das Wesentliche reduziert! Strenges Schnittstellenmanagement ist nicht vorgesehen, aber erreichbar Komplexe Resourcen können in unterschiedlichsten Repräsentationen dargestellt werden. Es bietet einen standardisierten Werkzeugkasten zum Aufbau einer zentralen Kommunikationsschicht

28