Infrastruktura pro SOA – oddělení vývoje a provozu Michael Juřek Software Architect Microsoft s.r.o.

Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita Bezpečnost Robustnost Doporučené postupy Různé, co dále, ...

Dnešní realita Pobočkové sítě Bezdrátové sítě Telefony, PDA Veřejný Web Portal Klienti Intranet Portal CRM systém ERP systém Bezdrátové sítě Pobočkové sítě Custom Systems Custom Systems Vlastní systém Telefony, PDA Různý fyzický formát Mobilita As the capabilities of technology grows, especially with ever increasing hardware communication, processing and storage capacities, the demand for software the leverages and integrates all those new abilities is creating intense pressure on software vendors and corporate IT departments. Just a few years ago introducing an ERP or CRM system into organizations was a strategic weapon to get ahead of the competition, but nowadays such system have become a necessity and nearly a commodity in any corporate environment. If corporate IT is a strategic tool to gain competitive advantages through optimized workflows leading to better customer service and shorter reaction times, applications need to communicate with each other. And it's not getting any simpler. As the corporate salesforce becomes increasingly equipped with personal digital assistants (PDA) and, thorugh the mobile phone carriers, almost automatically get a new, smarter and more capable phone every 12-24 months, these new form factors become attractive application platforms as well. Once customers (including the IT department's internal customers) get those new devices into their hands, the demand and pressure to utilize them for corporate applications will steadily grow. Applications that automate customer access to functionality like homebanking, tracking packages or making purchases are, at the same time, using a wide variety of devices and platforms. While the desktop computer is the predominant Internet terminal today, mobile phones will play a more important role in the future as Internet access becomes faster and cheaper and the presentation quality steadily increases. This diversity of client devices and platforms will inevitably lead to a shift away from the single client model, where the presentation surface of an application is either a client-side or a single browser application. Neither of these models is fit for these challenges. Instead, we will see multiple presentation surfaces, Web sites for full form factor computers, Web sites for small form factor devices, applications for online/offline operation and Web services for integration with applications fronting the same backend application at the same time. 3

Service-Oriented Architecture Nabízí služby prostřednictvím rozhraní, která jsou založena na standardech, publikovaná a lze je snadno lokalizovat Dostává na vyšší úroveň princip znovuvyužití kódu (code reuse) Aplikace využívají služeb, které se mohou časem vyvíjet a zlepšovat Aplikace, jež využívají služeb, není třeba modifikovat Nabízí jasný a čistý model pro integraci systémů Uvnitř organizace Mezi organizacemi Poskytuje základ pro globální propojování systémů

Služba - definice Softwarová entita, která nabízí funkčnost svému okolí a splňuje 4 hlavní zásady („four tenets“). Typicky spravuje svůj vnitřní stav a nedůvěřuje svému okolí. Má explicitní hranice Je autonomní Nabízí schéma a kontrakt Kompatibilita je popsána politikou

Má explicitní hranice Hranice služby je definována přesně pro tento účel – sloužit jako hranice Překročení hranice je v kódu konzumenta jasně patrné Opačný přístup – remoting, RPC, ... Aplikace psána proti lokálnímu objektovému modelu, objekty jsou pak eventuálně přeneseny na vzdálený server Ale co latence? Šířka pásma sítě? Zabezpečení a důvěra? Škálovatelnost?

Je autonomní Kontroluje svůj kontrakt Může se uvnitř rozvíjet nezávisle na ostatních, může být změněna, nahrazena apod. nezávisle na ostatních Pokud se nezmění schéma a kontrakt Kontroluje svůj stav (typicky databáze), který patří pouze jí a s okolím sdílí jenom to, co uzná za vhodné Žije svůj „vlastní život“ (vlákna kódu, ...)

Nabízí schéma a kontrakt Služba nemá žádné binární ani jiné závislosti, které by nebyly popsány v kontraktu Služba nesdílí žádné informace, které by byly specifické pro její vnitřní implementaci a sémantiku (interní datové typy, třídy objektů, vnitřní logika apod.) Služby nemají žádnou závislost mezi sebou s výjimkou sdílení kontraktu

Kompatibilita je popsána politikou Chování a požadavky pro přístup ke službě jsou odděleny od kontraktu služby Politika dynamicky definuje chování služby za běhu – bezpečnost, transakčnost, spolehlivost doručení apod. Politika je soubor předpokladů, které je nutné splnit pro přístup ke službě Politika je přiložena nebo jinak asociována s kontraktem služby, ale kontrakt je na ní nezávislý

Služby a transakce? Z formálního hlediska je sdílení transakce napříč hranicí služby (mezi klientem a službou) jasným porušením autonomie služby: Např. služba ztrácí kontrolu nad zámky ve své databázi Ideální vstupní bod pro útok „denial of service“ Realita si často žádá pragmatický přístup – operace služby je třeba provést jako součást většího atomického celku Povolte pouze tehdy, máte-li důvěru k volajícímu kódu

Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita Bezpečnost Robustnost Doporučené postupy Různé, co dále, ...

Distribuované aplikace nyní Různé technologie WSE, Remoting, RMI, EJB, COM+, JMS, ... Technologie nejsou dostatečně flexibilní, každá má jiné silné a slabé stránky Navzájem nekompatibilní Vývoj je závislý na zvolené technologii Při změně technologie nutný velký zásah do aplikace

Pohled zpět... -2002 2002-2006 2006-

Sjednocený model Interoperabilita .NET Remoting ASMX Interoperabilita Extenzibilita Nezávislost na umístění objektu Vývoj pomocí atributů Komunikace pomocí zpráv Podpora posledních WS-* specifikací Enterprise Services System.Messaging WSE 14

Komunikace klient-server Volající Volaný Klient Zpráva Služba Zpráva Speaker Notes: Let’s start by discussing how services communicate. We won’t be discussing any particular network topology (decentralized, hub and spoke, etc), as that’s specific to your application scenario. Instead, we’ll go over how two services communicate, and you can apply that information to the right topology for your application. Services communicate by sending messages to one another. <Click> One service initiates the communication by sending the message. This is the “caller”, or the “client”. The other service receives that message, processes it, and reacts to it by executing some code. For example: The caller could be part of a voting application. It sends a message to a centralized service that instructs the service to increment the number of votes for a particular candidate by 1 (or 2-4 if you’re in Florida). The caller could be part of a Web-based online store application that sends a message to an order processing service with shopping cart information, which causes the service to process a user’s order. The caller could be part of the order processing pipeline, without any UI. The caller has just validated a credit card number, so it sends a message to another service instructing that service to continue processing the order. Of course, this doesn’t have to be a one-way conversation. The service could respond to the caller, or initiate communication with another service based on the caller’s message. This is the basic communication model for WCF. Transition: In order for two services to interact, the caller needs to establish a connection to the service. How is that done?

Způsoby komunikace Jednosměrná (one-way): Události, notifikace, spuštění dávky, apod. Nečeká se na odpověď Spolehlivé doručení je záležitost infrastruktury, ne aplikace Synchronní (request/response) Interakce na způsob RPC Očekává se relativně rychlá odpověď Klient nemůže bez odpovědi dále pokračovat Duplex Pár nezávislých kanálů oběma směry

Endpoint Klient Služba Zpráva Endpoint Endpoint Endpoint Speaker Notes: Services define endpoints and expose these endpoints so that clients can connect to them. <Click> An endpoint is similar to an interface on an object in object-oriented programming. Objects expose interfaces, and a client walks up to the object and picks an interface with which to communicate. The client doesn’t need to know anything about the implementation details of the object; it just uses the interface to access the object. In the same way, an endpoint on a service contains all the information a client needs to communicate with the service. Because we want our WCF services to be loosely coupled, we don’t want the caller to be dependent on any implementation details of the service. Instead, the caller manufactures a copy of the endpoint (we call this a proxy) on its side. When the caller wants to communicate to the service, it makes local calls to its proxy; the proxy endpoint then takes care of communication with the service endpoint. Services only communicate through these endpoints, which means that the implementation details of a service can change without breaking any communication patterns. A service can define multiple endpoints. This enables you to specify different ways to communicate with a given service through different endpoints. For example: One endpoint might specify HTTP/text-based communication for traversing the corporate firewall and maximizing interoperability. Another endpoint might specify TCP/binary-based communication for optimized communication within the firewall. Transition: Let’s examine the components of an endpoint.

Endpoint má 3 složky Address Binding Contract Adresa, kde služba běží Způsob komunikace (politika) Contract Poskytované rozhraní (metody, data) Nezávislé na AB

Address, Binding, Contract Klient Služba A B C A B C Zpráva A B Speaker Notes: Each endpoint has three parts: an Address, a Binding, and a Contract, or “the ABCs”. Addresses are the where of services. They define the location of the service, like “http://localhost/myService”. Bindings are the how of services. They describe how the service communicates through that endpoint: what transport (HTTP, TCP, UDP, etc) it uses, what encoding (Text, Binary), and any additional capabilities such as security and reliable messaging that are available at a given endpoint. These communication details are usually separate from what the service actually does, and are often the concern of the person deploying the application, not the developer. That’s why bindings in WCF enable you to write and compile your entire WCF service separately from configuring how that service communicates. This provides a lot of flexibility after deployment: you can fundamentally change the way your app communicates without recompiling and redeploying it. Contracts are the what of services. This is what we care most about as developers. Contracts define what the service actually does – its operations, the methods it can carry out, etc. Transition: So endpoints define everything a client needs to communicate with a service, but how does a caller find information about the various endpoints? Address Binding Contract (Kde?) (Jak?) (Co?)

Kontrakt Definuje aplikační protokol služby: Je zárukou volné vazby Formát a schéma všech zpráv Platné sekvence zpráv Je zárukou volné vazby Neobsahuje žádné skryté závislosti

Co je to binding? Binding Binding Klient Služba Proxy Dispatcher Protocol Binding Binding Encoding Transport Zpráva

Binding - složky Transport Encoder Security Reliability Protocol HTTP Text TCP Binary WS-* HTTP Text TCP Binary WS-* Pipes MTOM Custom Custom Custom MSMQ Custom Custom

Metadata Umožňují volajícímu zjistit informace o službě (kontrakt, binding) Metadata Klient Služba A B C A B C Zpráva A B C

Behaviors (chování) Vnitřní záležitosti klienta nebo serveru, které by druhé straně měly být lhostejné Metadata Klient Služba Speaker Notes: The system semantics of a service are called behaviors. Behaviors are usually internal to the service. Some examples of behaviors: Instancing – what the instancing model is -- should a new instance of the service be created for each incoming call, or should a single instance of a service process all incoming calls, etc? Concurrency – whether the service is single- or multi-threaded Throttling – whether there’s a limit on the maximum number of messages, instances, or threads for your service. Transition: Now that we know all the pieces of the architecture, what happens at runtime? A B C Bv Bv Bv A B C Zpráva A B C Bv

ServiceHost<T>() Hostování Metadata Klient Služba A B C Bv Bv Bv A B C Zpráva A B C Bv Speaker Notes: WCF services are just managed code, so a WCF service can be hosted anywhere – in a Windows Form, a managed console window, IIS, etc. One hosting mechanism is a class called the ServiceHost. The ServiceHost looks at the configuration of your service and generates all the infrastructure needed to expose the service endpoints and publish the service’s metadata. To expose a service, you simply create a new ServiceHost and open it. Or, if you deploy your service into IIS, it’ll open for you. The caller examines the service metadata and uses it to generate a proxy on the caller side which communicates with a service endpoint. Transition: Let’s see how we can use these basic concepts in code. Proxy ServiceHost<T>()

Hostitel služby Každá služba má svého hostitele Stará se o běh služby Hostitel musí „žít“ v nějakém procesu: Internet Information Server (IIS) Pro verzi <= 6 pouze HTTP(S) Pro verzi 7 všechny protokoly Váš proces Win32 služba, desktopová aplikace, ...

Proxy Proxy nabízí komfortní volání služby proti lokálnímu objektovému modelu Odstiňují klienta od komunikace, protokolu, zpráv ... Lze dodat další funkce (měření SLA, cachování výsledku, ...) Dva způsoby: Vygenerování z metadat služby (svcutil.exe) Sdílení definice rozhraní a použití factory přístupu pro emulaci vzdáleného rozhraní V kombinaci s modelem instancí PerSession částečně emuluje funkci vzdáleného objektu (se SOA nemá nic společného !!!)

Procházka po WCF Ilustrace jednotlivých konceptů

Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita Bezpečnost Robustnost Doporučené postupy Různé, co dále, ...

Principy návrhu WS-* Obecnost Standardizace Federativnost Modularita 4/10/2017 5:02 PM Principy návrhu WS-* Obecnost Žádná vazba na specifickou oblast aplikací Standardizace Podpora klíčových SW výrobců Federativnost Žádný centrální bod pro kontrolu, administraci nebo selhání celku Modularita Jednotlivé standardy mohou fungovat odděleně nebo v libovolné kombinaci Základem jsou metadata/politika © 2003-2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Modulární skládání hlaviček 4/10/2017 5:02 PM Modulární skládání hlaviček <S:Envelope … > <S:Header> <wsa:ReplyTo> <wsa:Address>http://business456.com/User12</wsa:Address> </wsa:ReplyTo> <wsa:To>http://fabrikam123.com/Traffic</wsa:To> <wsa:Action>http://fabrikam123.com/Traffic/Status</wsa:Action> <wssec:Security> <wssec:BinarySecurityToken ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary">      dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD </wssec:BinarySecurityToken> </wssec:Security> <wsrm:Sequence> <wsu:Identifier>http://fabrikam123.com/seq1234</wsu:Identifier> <wsrm:MessageNumber>10</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> <S:Body> <app:TrafficStatus xmlns:app="http://highwaymon.org/payloads"> <road>520W</road><speed>3MPH</speed> </app:TrafficStatus> </S:Body> </S:Envelope> Addressing Security Reliability © 2003-2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Modulární funkční bloky XSD, WSDL, UDDI, Policy, MetadataExchange 4/10/2017 5:02 PM Kompletní obrázek Security Reliable Messaging Transactions Modulární funkční bloky XSD, WSDL, UDDI, Policy, MetadataExchange Popis XML, SOAP, Addressing Doručení HTTP, HTTPS, SMTP Transport From joint IBM/MSFT WS Whitepaper at http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp © 2003-2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Kontrakt a metadata XML Schema WSDL/XML Schema WSDL WS-Policy Datové typy WSDL/XML Schema Složení zpráv z datových typů WSDL Podporované posloupnosti zpráv WS-Policy Požadavky na komunikaci s webovou službou WS-MetadataExchange Získání politiky k dané službě konzumentem

Bezpečnost WS-Security Zahrnutí tokenu do SOAP zprávy pro integritu, důvěrnost a autentizaci odesilatele zprávy WS-SecurityPolicy Specifikace bezpečnostní politiky služby za pomoci standardu WS-Policy WS-SecureConversation Ustanovení bezpečnostního kontextu mezi komunikujícími stranami a použití symetrické kryptografie WS-Trust Doplňuje postup pro vyžadování, vydávání a předávání bezpečnostních tokenů WS-Federation Doplňuje WS-Trust o popis procesu pro získání tokenu v prostředí s federovanou bezpečností (Single Sign On)

Doručení, komunikace, ... SOAP 1.1/1.2 WS-Addressing Formátování zprávy (hlavička, tělo, ...) WS-Addressing Identifikace zpráv a subjektů komunikace WS-ReliableMessaging Doručení s garantovanou kvalitou na aplikační úrovni WS-AtomicTransactions Koordinace transakcí mezi subjekty

Interoperabilita s Javou Interoperabilita průběžně testována Sun - WSIT (Web Services Interoperability Technology) Open-source WS-* implementace od Sunu http://java.sun.com/webservices/interop/ IBM – ETTK for Web Services http://www.alphaworks.ibm.com/tech/ettkws Systinet (-> Mercury -> HP) Server for Java/C++ http://www.systinet.com/products/ssj/overview ...

Interoperabilita s dalšími MS technologiemi ASMX/WSE3 WS-* Protocols WCF COM+/ES Moniker WS-* Protocols WCF MSMQ Moniker MSMQ Protocol WCF

Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita Bezpečnost Robustnost Doporučené postupy Různé, co dále, ...

Bezpečnost je o překročení hranic důvěry Zprávy překračující hranice s různou úrovní důvěry: Mezi systémy a počítači Mezi organizacemi Mezi procesy v operačním systému Různé organizace mají různé požadavky Bezpečnost musí být nezávislá na platformě Důvěra založená na obecném „tokenu“

Bezpečnostní aspekty Spolehlivý záznam o provedených akcích: Data nemohou být neoprávněně přečtena Důvěrnost Data nemohou být svévolně změněna Integrita Původce dat nemůže popřít svoji akci Neodmítnutelnost odpovědnosti Spolehlivá identifikace subjektů Autentizace Zjištění oprávnění volajícího Autorizace Spolehlivý záznam o provedených akcích: Auditování

Zabezpečení transportu „Vše co běží po drátě.“ Zajišťuje: autentizaci, důvěrnost, integritu Výhody: Osvědčená, kompatibilní s existujícími systémy Rychlost, možnost HW akcelerace Nevýhody: Pouze mezi dvěma body (co prostředník, přeruší kanál?) Omezené množství autorizačních mechanismů Závislá na použitém protokolu

Zabezpečení zpráv „Vše co přijde z drátu“ Zajišťuje: autentizaci, důvěrnost, integritu Výhody: Vztah mezi koncovými body bez kompromisů Nezávislost na použitém protokolu Libovolný způsob autentizace Nevýhody: Vyšší režie (CPU, šířka pásma) Relativně menší zralost

Bezpečnostní model WCF Jednoduchost a konzistence: Deklarativní (atributy) a konfigurační XML Interoperabilní: Založená na WS-* standardech Využívá existující standardní bezpečnostní infrastrukturu „Secure by default“: Standardně zapnutá Výjimka BasicHttpBinding Výchozí ochrana „encrypt and sign“

Dvě části bezpečnosti WCF Zabezpečení zpráv vyměňovaných mezi entitami (osoba, firma, software, ...) Autentizace, důvěrnost, integrita, neodmítnutelnost odpovědnosti Zabezpečení přístupu k nabízeným zdrojům (soubory, služby, operace, ...) Autorizace, auditování

Autentizace Proces identifikace entity: Podporované typy tokenů: Předloží tzv. token Obsahuje tzv. tvrzení o entitě (claims) Kryptograficky prokáže jeho pravost a oprávněnost použití Podporované typy tokenů: Jméno/heslo (zabezpečit transportem!) X509 certifikát Kerberos tiket SAML token (WS-Federation) Definice vlastního

Autorizace Možnost vlastní správy rolí: Zpráva Hostitel (soubor, URL, konfigurace služby) Operace (PrincipalPermission) Zdroje v aplikaci (imperativní kód) Možnost vlastní správy rolí: Možno využít RoleProvider z ASP.NET Možnost vlastní autorizační politiky

Auditování Konfiguračním zásahem – přidáním prvku ServiceSecurityAuditBehavior Výběr protokolu, do kterého se zapisuje Volitelné úrovně: Nic, Úspěch, Neúspěch, Vše Volitelné události: Autentizace příchozí zprávy Autorizace využití služby

Optimalizace protokolu Asymetrická kryptografie je výpočetně i objemově mnohem náročnější než symetrická Pokud se vyměňuje více zpráv, je možné dohodnout pro druhou a další zprávu symetrický klíč: Security Context Token (STC) Na bázi WS-SecureConversation Zcela transparentní pro oba účastníky

Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita Bezpečnost Robustnost Doporučené postupy Různé, co dále, ...

Zdroje problémů Distribuované zpracování má řadu míst, kde může vzniknout problém: Síť není dostupná nebo má výpadky Zprávy se ztratí při přenosu Selže-li zpracování, zpráva se rovněž ztratí Zprávy nedorazí v přesném pořadí Přijde-li zpráva vícekrát, může to službě způsobit vážné problémy a vést k chybám

Spolehlivé doručení Kvalita je garantována: Každá zpráva dorazí právě jednou Zprávy dorazí ve správném pořadí (volitelně) Založeno na WS-ReliableMessaging Podobné číslování TCP paketů, ale na aplikační úrovni (v SOAP hlavičkách) Odolné vůči jakémukoliv selhání MEZI klientem a serverem Používá buffer zpráv na klientovi i serveru

Trvalé fronty – MSMQ WS-ReliableMessaging není odolné vůči selhání vlastního klienta a serveru, je realizováno pouze paměťovým bufferem Chcete-li robustní asynchronní doručení zpráv, použijte MSMQ jako WCF transport Dvě varianty: NetMsmqBinding – včetně SOAP obálky hlaviček, vhodná pro komunikaci WCF-WCF MsmqIntegrationBinding – bez SOAP obálky, sami formátujete zprávu, vhodné pro komunikaci WCF-cokoliv

Výhody MSMQ front Zvyšuje dostupnost – asynchronní služba nemusí být v okamžiku volání dostupná Robustní transakční zpracování Fronta tlumí jednorázové špičky Výkonné – možnost více instancí služby obsluhujících tutéž frontu Obsluha chyb – po vyčerpání nastavených pokusů -> “poison queue” Na “poison queue” lze navázat službu provádějící kompenzující operaci nebo obsluhu chyb Pozor, pouze one-way a duplex, ne request/response

Konzistence - transakce Atomické transakce jsou mnohem jednodušší než ošetření chyb a kompenzace provedených akcí ... ale tok transakce přes hranice služby porušuje zásady SOA ... a může mít negativní výkonnostní dopady (více zámků na delší dobu) Přesto se často hodí, zejména při voláních uvnitř zóny s vysokou důvěrou Vždy zvažte, zda důvěřujete klientovi natolik, aby mohl kontrolovat transakci uvnitř služby

Transakce – bezpečnost V kontraktu je nutné specifikovat operační požadavek na chování k „přitékající“ transakci Při implementaci je nutné deklarativně vyjádřit transakční chování služby V konfiguraci klienta i serveru musí být pro příslušný binding povolen tok transakce mezi klientem a službou .NET klient pak může využít TransactionScope jako obvykle

Robustnost WS-ReliableMessaging WS-AtomicTransactions

Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita Bezpečnost Robustnost Doporučené postupy Různé, co dále, ...

Kdy (ne)použít WCF? Můžete-li si vybrat, použijte WCF pro jakoukoliv komunikaci S výjimkou komunikace uvnitř procesu Remoting mezi aplikačními doménami je lepší Pro existující projekty zvažte náklady na konverzi: Z ASMX/WSE relativně snadná konverze i slušná interoperabilita Z EnterpriseServices a remotingu konverze nákladnější Velmi dobrá interoperabilita s MSMQ Existující technologie budou podporovány ještě nejméně 10 let, nemějte obavy

Výkonnost Kritické názory typicky nejsou podloženy žádnými fakty Nelze porazit vlastní binární serializaci a TCP sockety, ale proč s nimi soutěžit WCF bez zapnuté bezpečnosti je rychlejší než ekvivalentní technologie: NetTcpBinding rychlejší než remoting BasicHttpBinding rychlejší než ASMX Za zapnutí bezpečnosti, transakcí, ... platíte časem CPU, latencí a šířkou pásma – to je život 

Rozdělení odpovědnosti Vývoj Služba: Definice kontraktu Implementace služby Výběr hostitele Konfigurace adresy Konfigurace bindingu Monitorování Klient: Získání metadat Vygenerování proxy Použití proxy třídy Vygenerování adresy Vygenerování bindingu Monitorování Nasazení

Slepice nebo vejce? Code-first vývoj: Contract-first vývoj: Snazší, lepší podpora v nástrojích Vytvořte příslušné třídy a rozhraní včetně potřebných atributů Kontrakt (XSD, WSDL) generován automaticky Contract-first vývoj: Fundamentalisticky čistší, ale pracnější Začněte od definice XSD schématu a WSDL služby svcutil.exe vám vygeneruje ekvivalentní rozhraní a třídy

Kontrakt a kontrola zprávy Čím vyšší kontrola nad zprávou, tím větší flexibilita, ale i více práce a méně pohodlí při vývoji: DataContract – kontrola serializace jednotlivých typů (-> XSD) MessageContract – kontrolujete jednotlivé části zprávy, pořadí, hlavičky (->WSDL) Netypové zprávy – sami jste odpovědni za serializaci a obsah zprávy, ztrácíte automatické generování metadat

Návrh kontraktu (-> XSD) Pro daný typ Jméno, jmenný prostor Styl – dokument anebo RPC Pro jednotlivé členy Jméno Zda je povinně vyžadován Pořadí při serializaci Zda se má serializovat výchozí hodnota

Návrh kontraktu (-> WSDL) ServiceContract Jméno, jmenný prostor Callback - kontrakt pro případný duplexní kanál (opačný směr) FaultContract – jaké jsou očekávané chybové zprávy OperationContract Jméno Akce pro žádost a odpověď Jednosměrnost anebo žádost/odpověď

Operační požadavky kontraktu ServiceContract Minimální úroveň zabezpečení Žádná, podpis, šifrování a podpis Garance doručení (fronta zpráv, v pořadí) Udržování session Povinné, možné, nedovolené OperationContract Použití asynchronního návrhového vzoru Zahájení/ukončení seance Chování k „přitékající“ transakci

Implementace - chování ServiceBehavior Způsob vytváření instancí (Single, PerCall, PerSession) Chování vůči více současným vláknům Transakční chování (úroveň izolace, time-out) ... OperationBehavior Transakční chování (požadování TransactionScope, auto-complete) Postoj k impersonifikaci

Výběr bindingu Binding je kolekcí jednotlivých elementů Tři úrovně výběru: Standardní binding s výchozí konfigurací Standardní binding s vlastní konfigurací Vlastní binding Namíchejte si jednotlivé elementy sami Při výběru musíte respektovat operační požadavky kontraktu (transakce apod.)

T = Transport Security | S = WS-Security | O = One-Way Only Standardní bindingy Interop Security Session Transx Duplex Stream BasicHttpBinding BP T WsHttpBinding WS TS WsDualHttpBinding WS TS NetTcpBinding TS O Speaker Notes: Each of the standard bindings defines a differently configured communication stack for our services. They span a variety of options: some are interoperable, some provide default security, some allow for sessions, etc. These standard bindings are designed to solve most application needs out of the box. Transition: Bindings are also one of the ways WCF services integrate with applications you’ve built on existing Microsoft technologies. Let’s take a closer look. NetNamedPipesBinding TS O NetMsmqBinding TS NetPeerTcpBinding TS T = Transport Security | S = WS-Security | O = One-Way Only

Standardní binding s vlastní konfigurací Nejčastěji používaný přístup Jednoduchý a pokrývá drtivou většinu scénářů Velké množství parametrů (závislé na bindingu) Transakční chování (povolení toku, protokol) Spolehlivé doručení (povolení, požadavek na zachování pořadí, time-out) Time-out (otevření, požadavek, odpověď, ...) Limity přenesených dat... ...

Nasazení – chování Služba Endpoint Generování metadat – standardně vypnuto !!! Pomocné stránky pro ladění Autorizace – role, oprávnění, ... Credentials – autentizace služby apod. Throttling – omezení spojení, instancí, ... Time-out ... Endpoint Odesílání plné výjimky ClientCredentials – autentizace klienta, ...

Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita Bezpečnost Robustnost Doporučené postupy Různé, co dále, ...

Další směry rozvoje WCF Další typy protokolů: SQL Service Broker SMTP POX (Plain Old XML) – XML přes HTTP GET, např. pro AJAX stránky ... Podmnožina WCF součástí budoucího kompaktního .NET frameworku Plná podpora ve VS - modelování: Kontrakt služby Kompozice služeb pomocí WF

Adapter Framework (AF) Runtime pro zpřístupnění externích systémů na bázi WCF bindingu AF se stará o komunikaci a standardně zpřístupňuje metadata Externí systémy se po formální stránce stávají WCF službami, které lze přidat do projektu (bez nutnosti psát wrapper) Využití: BizTalk Server 2006 Release 2 Další budoucí produkty – SQL Server Integration Services, ADO.NET, MIIS, ...

WCF Service Programming Model WCF Channel Architecture Adapter Framework (AF) WCF Apps BTS MIIS SQL-SSIS MIIS Controller ADO.NET provider WCF Service Programming Model WCF Channel Architecture WCF Binding AF Runtime AF Runtime AF Runtime Siebel adapter SAP adapter Custom adapter Web Service Siebel SAP My System

Závěrem WCF je univerzální komunikační technologie pro SOA řešení nad .NET frameworkem Jednotný programový model Naprostá flexibilita a rozšiřitelnost Plná interoperabilita a podpora standardů Bezpečnost a robustnost