MSDN Live för utvecklare av utvecklare

Johan Lindfors Developer Evangelist Microsoft AB Avancerade XML WebServices

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!

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

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

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

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

 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?

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!

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

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

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

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

demo Scenariot - utmaningarna

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

”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

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

“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”)

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

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

WS-MetadataExchange  WSDL och XSD räcker inte till –Krav på säkerhet och tillförlitlighet?

WS-MetadataExchange  WSDL och XSD räcker inte till –Krav på säkerhet och tillförlitlighet? Kerberosv5TGT X509v3

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!

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

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”

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

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?

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

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

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  –Wiki –Bloggar –Forum

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  –Wiki –Bloggar –Forum

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”

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

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

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

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

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

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

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

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

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

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

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

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) 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

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); }

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

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!

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

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

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!

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

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

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”

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

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