MSDN Live för utvecklare av utvecklare. Johan Lindfors Developer Evangelist Microsoft AB Avancerade XML WebServices.

En presentation över ämnet: "MSDN Live för utvecklare av utvecklare. Johan Lindfors Developer Evangelist Microsoft AB Avancerade XML WebServices."— Presentationens avskrift:

1 MSDN Live för utvecklare av utvecklare

2 Johan Lindfors Developer Evangelist Microsoft AB Avancerade XML WebServices

3 Förslag på utvecklingsprocess 1)Tänk serviceorienterat 2)Definera kontrakt a)Datatyper och meddelanden b)Säkerhet 3)Anamma rekommendationer 4)Implementera gränssnitten 5)Versionshantera och underhåll 6)Skaffa kunskap och använd bra verktyg!

4 Service 1) Tänk serviceorienterat  Hur har vi programmerat förr? –Funktionsorienterat –Objektorienterat  Service Orienterad Arkitektur –Meddelandeorienterat –Autonoma system Servicelogik Data

5 SOA i grunden  Services har explicita gränser –Funktionaliteten defineras vid gränsdragningen  Services är autonoma –De litar inte på någon annan än sig själv –De delar ”aldrig” med sig av data  Services delar schema och kontrakt –Inga atomiska transaktioner mellan services  Servicens kompatibilitet baseras på policies –Baserat på standards

6 Det finns en “gråzon”! Domänmodellen Affärs- modell Gråzonen Service Orienterad Arkitektur Teknisk modell

7 Domänmodellen Gråzonen Vad är gråzonen?... Namespace … class Order { … } Submit(Order NewOrder) { … }

8  Exekveringsmiljön –Infrastrukturen för webbservices  Verktygen –WSDL-baserade kodgeneratorer –XSD-baserade klassgeneratorer  Arkitekten –Definera de serviceorienterade aspekterna  Utvecklaren –Implementera de mappningar som krävs Vilka deltar i gråzonen?

9 Förslag på utvecklingsprocess 1)Tänk serviceorienterat 2)Definera kontrakt a)Datatyper och meddelanden b)Säkerhet 3)Anamma rekommendationer 4)Implementera gränssnitten 5)Versionshantera och underhåll 6)Skaffa kunskap och använd bra verktyg!

10 2) Definera kontrakt Kontrakt Service Agents Data Access Components Business Workflow s Business Compone nts Business Entities Service Interfaces Service Agents Data Access Components Business Workflow s Business Compone nts Business Entities Service Interfaces Service Agents Data Access Components Business Workflow s Business Compone nts Business Entities Service Interfaces Interaktion Kontrakt

11 Kontrakt för “servicen” Gränssnitt Datatyper Meddelanden Tjänstespecifika datatyper “Vanliga” datatyper Beskrivning Meddelanden WSDL XSD

12 Förhållanden “Service” “Binding” “Message” “PortType” “Types” “Endpoint” Transport Meddelande Interface Entitet “Värd” Impl. Klass Interface SOA KontraktOO

13 Ett vanligt scenario? CRM Service ERP Service E-Commerce Service ProcessOrder(Order) UpdateSalesTotal(Order) PlaceOrder(Order)

14 demo Scenariot - utmaningarna

15 2a) Datatyper och...  XSD är inte detsamma som CLR –Datatyper ”mappas” genom serialisering  Tänk till vid val av meddelandetyper –DataSet kan försvåra interoperabilitet –Ren XML kräver goda kunskaper i XML –Serialiserade objekt är ”lätt att förstå”  Meddelandeklasser –Underlättar vidareutveckling och versionshantering

16 ”Marshaling”  I.NET finns två serialiseringsmotorer –XmlSerializer används för parametrar –System.Runtime.Serialization + SoapFormatter  XmlSerializer hanterar bara ”träd” av typer –Publika fält –Inga dubbla pekare –Begränsat stöd för polyformism och samlingar  Attribut påverkar resultat  Använd alltid unika namnrymder

17 Viktiga attribut  [XmlType] –Namespace, IncludeInSchema, TypeName  [XmlRoot]  [XmlElement] eller [XmlAttribute]  [XmlInclude] –Används vid arv  [XmlArray] och [XmlArrayItem] –Returnera vektorer

18 “SOAP Encodings”  doc-literal –”SOAP body” defineras i XSD –Helt meddelandeorienterat  doc-literal wrapped –Specialfall av doc--literal –Metodnamn (”operation”) blir namn på ”request”  rpc-literal (finns inte i.NET) –Ingen metadata som beskriver ”SOAP body” –XSD används bara för att beskriva parametrar  rpc-encoded (kallas även ”Section 5 encoding”)

19 2b) Säkerhet  Börja tidigt med att beakta: –Roller och identiteter –Säker kommunikation  Web Services Enhancements 2.0 –WS-Security –WS-Trust –WS-SecureConversation –WS-Policy

20 WS-Policy  Beskriver krav på meddelanden –Inkommande och utgående  Kan användas för att styra WSE Body... Body... Body

21 WS-MetadataExchange http://schemas.xmlsoap.org/ws/2004/09/policy  WSDL och XSD räcker inte till –Krav på säkerhet och tillförlitlighet?

22 WS-MetadataExchange http://schemas.xmlsoap.org/ws/2004/09/policy  WSDL och XSD räcker inte till –Krav på säkerhet och tillförlitlighet? Kerberosv5TGT X509v3

23 Förslag på utvecklingsprocess 1)Tänk serviceorienterat 2)Definera kontrakt a)Datatyper och meddelanden b)Säkerhet 3)Anamma rekommendationer 4)Implementera gränssnitten 5)Versionshantera och underhåll 6)Skaffa kunskap och använd bra verktyg!

24 3) Anamma...  Designmönster –Patterns & Practices –Fasadobjekt, lager, skikt  EDRA (ShadowFax) –Enterprise Development Reference Architecture  EDAF –Enterprise Development Architecture Framework  WS-I Basic Profile

25 Microsoft RAF UI Components UI Process Components Service Interfaces Business Workflows Business Components Business Entities Data Access Components Service Agents UsersServices Data Sources Services Communications Operational Management Security  Arkitekturellt ramverk –Utvecklare –Arkitekter  Dokumenterad –Patterns & Practices  ”Service Master” –”Fiefdoms”  ”Service Agents” –”Emissaries”

26 ServerKlient ”Patterns & Practices”  Mönster: ”Service Interface” –Serversidan –Fasadobjekt, DataSet  Mönster: ”Service Gateway” –Dynamisk hantering av URL Applikations logik ”Service Gateway” ”Service Interface” Kontrakt

27 Mönster: “Service Interface”  Sammanhang (“Context”): –Du designar en distribuerad applikation med funktionalitet som måste nås från olika system. –Interoperabilitet är en nyckelfaktor! –Du kommer också behöva supportera olika kommunkationssätt och protokoll.  Utmaning (“Problem”): –Hur får du delar av din applikations funktionalitet att nås från andra applikationer, samtidigt som du är säker på att gränssnitten är separerade från affärslogiken?

28 Mönster: “Service Interface”  Drivkrafter (“Forces”): –Du vill separera affärslogiken från infrastrukturen –Din applikations konsumenter/klienter kan vilja få svar som är optimerade vissa specifika scenarios –Konsumenter kan komma att vilja kommunicera med olika tekniker och protokoll –Applikationen kan komma att ställa olika krav på olika konsumenter –Du behöver snabbt kunna göra förändringar i din applikation baserat på krav från miljön och affärsprocesser

29 Lösning: ”Enligt boken”  Service Interface –Anropar ”Gateway” –Får tillbaka ett DataSet –Använder ”mapper” –Serialiserar ”Recording” –Returnerar XML

30 Service Implementation Service Interfaces Service Interface ServicesUsers EDRA (Shadowfax) UI Components UI Process Components Business Workflows Business Components Business Entities Data Access Components Service Agents Client Application Services Data Sources Services Communications Operational Management Security Communications Operational Management Security  Arkitekturellt ramverk –Utvecklare –Arkitekter  www.gotdotnet.com –Wiki –Bloggar –Forum

31 EDRA (Shadowfax) Service Interface Service Implementation Business Workflows Business Components Business Entities Data Access Components Service Agents Client Application Services Data Sources Services Communications Operational Management Security Interface Transports Cross-Cutting Logic AuthenticationTimeoutsValidation Dispatching Transports Cross-Cutting Logic LoggingBusiness EventMonitoring  Arkitekturellt ramverk –Utvecklare –Arkitekter  www.gotdotnet.com –Wiki –Bloggar –Forum

32 Lösning: Enligt EDAF  Separerar “servicens” interface från dess implementation –De kan variera oberoende –Kan separeras fysiskt  SI element utför endast funktioner i gränssnittet –Ta emot, hänvisa och svara meddelanden  BA-objekt aktiveras av “implementationen”

33 Flexibilitet vid installation  En server –Exekvering inom samma process –”Maximal prestanda”  Två servrar –Installeras bakom separata brandväggar –”Maximal säkerhet”

34 Sårbarheter  Svårt att få “faktoreringen” av interface helt korrekt –Inkorrekt faktorering kan leda till prestandaförlust  “Service Interface”-mönstret adderar komplexitet och vissa utmaningar i prestanda –Kan vara omotiverat i enklare SOA lösningar

35 Mönster: “Delegator”  Sammanhang (“Context”): –Du har en process som du vill erbjuda flexibiltitet/förändring vid exekvering  Utmaning (“Problem”): –Hur erbjuder du en “extensibility point” som låter flera objekt hantera förfrågan?  Drivkrafter (“Forces”): –Några objekt kommer att neka förfrågan och inte tillåta vidare processering! –Några objekt kräver förmågan att processera före och efter den slutliga destinationen –Några objekt kommer att ha krav på “ordning” och även behov av att skicka information mellan sig

36 Lösning: “Delegator” (EDAF)  EDAF introducerar två “pipelines” i processflödet  “Pipelines” låter systemet delegera vanliga uppgifter  “Service Interface” –Säkerhet och validering –“Timeouts”  “Service implementation” –Loggning –“Business Events” –Övervakning

37 Tillståndslösa och atomiska “handlers”  Atomiska “handlers” processerar innan eller efter BA  Tillståndslösa “handlers” processerar före och efter BA  “Pipeline” –Läser listan av “handlers” från konfigurationen –Anropar “handlers” i ordning och bifogar meddelandet

38 Tillståndshantering  “Handlers” med tillstånd hanteras för sig  Andra hanterar exekverar i samma “stack frame”, liksom BA –Möjliggör transaktioner  Måste placeras både före och efter BA

39 “Handlers” i EDAF  ClientTrace  Transaction  Identity  DuplicateMessageHandling  AuthenticationIdentity  AuthorizationDatabase  AppInstrumentationExecutionTime  AuthenticationInfrastructure  AuthorizationInfrastructure  SignedMessageAuthentication  PasswordAuthorizationHandler  SyntacticValidation  ExecutionTimeout  AppInstrumentation  MessageTransformation  PublishBusinessEvent

40 1.En klient skickar en “KontoSaldo”-förfrågan över transportprotokollet för WebServices. 2.“Service Interface”-transportadaptern (WebServiceInterfaceAdapter” är en “SOAP extension” som fångar upp förfrågan. 3.“SOAP extension”-komponenten skapar ett “context”-objekt och bifogar detta objekt till pipelinen som exekverar på begäran 4.Pipeline laddar listan av “handlers” i “Service Interface” och invokerar dessa. Den sista adaptern i listan anropar målet som skapar “WebServiceDispatchingAdapter” 5.Målet anropar “Submit”-metoden på “WebServiceDispachingAdapter” och bifogar det serialiserade “context”-objektet 6.Transportadaptern anropar sedan pipeline i “Service Implementation”-lagret, och bifogar “Context”-objektet 7.“Service Implementation” pipeline anropar “handlers” individuellt i sekvens. När den sista nås anropas pipeline-målet som instansierar BA 8.BA anropas genom att använda information i det som bifogas. BA utför den riktiga frågan och sparar kontosaldos i svaret, som finns i “Context” 9.Anropskedjan snurrar tillbaka genom båda “pipelines” till Web Services transporten, som extraherar svaret från “Context”, och returnerar detta till klientapplikationen. “Service Implementation” IIS / ASP.NET “Service Implementation” IIS / ASP.NET Exempel på förfrågan “Service Interface” IIS / ASP.NET “Service Interface” IIS / ASP.NET Web Service Interface Adapter Web Service Dispatching Adapter Business Action Pipeline

41 WS-I Basic Profile  Rekommendationer för interoperabilitet –Inte en certifiering  Testverktyg som konfigureras med XML –Monitor –Analyzer  Rapport i XML –HTML KlientWeb Service ”Monitor” ”Analyzer”Report Logg Konfiguration Testfall

42 WS-I Basic Profile  Rekommendationer för Web Services –Parametrar –Mekanismer för utbyggbarhet –Utsagor om ”conformance” –”Cookies” –”Encoding” –Hänvisning –Attribut: WebServiceBinding, SoapDocument[Method/Service] –SOAP huvuden –Felhantering

43 WS-I Basic Profile  Rekommendationer för Web Services klienter –Utsagor om ”conformance” –Meddelandeformat –Parametrar –Cookies –Envägsoperationer –SOAP huvuden

44 Förslag på utvecklingsprocess 1)Tänk serviceorienterat 2)Definera kontrakt a)Datatyper och meddelanden b)Säkerhet 3)Anamma rekommendationer 4)Implementera gränssnitten 5)Versionshantera och underhåll 6)Skaffa kunskap och använd bra verktyg!

45 4) Implementera gränssnitt  WSDL.EXE /server –Ärv från genererad basklass  ”WebMethod” erbjuder en RPC-modell  Arv från WebService är inte ett krav – Ger snabb åtkomst åt HttpContext.Current –Kan ärva från andra klasser istället  Se upp för ”tighta” kopplingar –Fokusera på kontrakten  Använda [WebService] attributet –Sätt en korrekt namnrymd

46 Implementera ”interface” public interface IAddCalculatorPortType { AddResponseType Add(AddRequestType addRequest); } public class AddServiceInterface : IAddCalculatorPortType { [WebMethod] public AddResponseType Add(AddRequestType addRequest) { AddServiceFacade asf = new AddServiceFacade(); // handle authentication... return asf.Add(addRequest); } Public class AddServiceFacade : IAddCalculatorPortType { public AddResponseType Add(AddRequestType addRequest) { AddImlementation aimp = new AddImplementation(); return imp.Add(addRequest); }

47 Säkerhet igen...  SOAP 1.1 är mycket förlåtande –Och det är även XmlSerializer  Det är svårt att identifiera felaktiga element  Det finns dock sätt... –”Intercept”-baserad validering mot XSD –Ett trick med XmlSerializer

48 Förslag på utvecklingsprocess 1)Tänk serviceorienterat 2)Definera kontrakt a)Datatyper och meddelanden b)Säkerhet 3)Anamma rekommendationer 4)Implementera gränssnitten 5)Versionshantera och underhåll 6)Skaffa kunskap och använd bra verktyg!

49 5) Versionshantera... Kontrakt Service Agents Data Access Components Business Workflow s Business Compone nts Business Entities Service Interfaces Service Agents Data Access Components Business Workflow s Business Compone nts Business Entities Service Interfaces Service Agents Data Access Components Business Workflow s Business Compone nts Business Entities Service Interfaces Kontrakt Versionshantering

50 5) Versionshantera...  Vad ska vi versionshantera? –Service interface –Implementationen –Data- och meddelandetyper  Versionshantering –Kontrollen ägs av schemats ägare –Erbjuder bakåtkompatibilitet  Utbyggnad –Erbjuder ny funktionalitet bredvid den gamla

51 Förslag på utvecklingsprocess 1)Tänk serviceorienterat 2)Definera kontrakt a)Datatyper och meddelanden b)Säkerhet 3)Anamma rekommendationer 4)Implementera gränssnitten 5)Versionshantera och underhåll 6)Skaffa kunskap och använd bra verktyg!

52 6) Skaffa kunskap och...  Internetresurser –msdn.microsoft.com/webservices –www.gotdotnet.com/  MSDN Workshops –Inside Pellesoft – 11:e november  MSDN Laborationer –ASP.NET StarterKits 17:e, 18:e, 19:e –EDRA?  Utbildningsföretag  MSDN Prenumerationer

53 Vart är vi på väg - Indigo Indigo ASMX.NET Remoting COM+ Enkel konfiguration Interoperabilitet Serviceorineterat Attribut Transaktioner Komponenter Bred vision Utbyggbart Objektorienterat MSMQ Meddelanden “En-vägs” Tillförlitlighet

54 Indigos hörnstenar  Channel: Mekanism för I/O med meddelanden  Message: Data som skickas  Service: Mål för meddelanden  Contract: Vilka meddelanden som accepteras “Message” “Channel” “Service” “Transport” “Contract”

55 Sammanfattning  Datatyper i implementationen är inte detsamma som typer i transporten  Kontrakt måste utvecklas för att gälla länge  Använd designmönster och andra rekommendationer  Det handlar inte om SOA mot OO –Det handlar om att implementera SOA med OO

56 Nästa presentation  Introduktion till.NET Framework 2.0 –Lite presentation –Lite demonstration

57