1 / 76

Infrastruktura pro SOA – oddělení vývoje a provozu

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. Klienti.

oliana
Download Presentation

Infrastruktura pro SOA – oddělení vývoje a provozu

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Dnešní realita Klienti Intranet Portal VeřejnýWeb Portal Pobočkovésítě Bezdrátovésítě Různý fyzický formát ERP systém CRMsystém CustomSystems CustomSystems Vlastnísystém Telefony, PDA Mobilita

  4. 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ů

  5. 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

  6. 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?

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

  8. 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

  9. 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ý

  10. 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

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

  12. 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

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

  14. Sjednocený model .NET Remoting ASMX Interoperabilita ExtenzibilitaNezávislost naumístění objektu Vývojpomocíatributů Komunikacepomocí zpráv PodporaposledníchWS-* specifikací Enterprise Services System.Messaging WSE

  15. Zpráva Zpráva Komunikace klient-server Volající Volaný Klient Služba

  16. 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

  17. Endpoint Endpoint Endpoint Endpoint Klient Služba Zpráva

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

  19. C B B B A A A Address, Binding, Contract Klient Služba C Zpráva Address Binding Contract (Kde?) (Jak?) (Co?)

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

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

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

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

  24. C C C B B B A A A Behaviors (chování) • Vnitřní záležitosti klienta nebo serveru, které by druhé straně měly být lhostejné Metadata Klient Služba Bv Bv Zpráva Bv Bv

  25. C C C B B B A A A Hostování Metadata Klient Služba Bv Bv Zpráva Bv Bv Proxy ServiceHost<T>()

  26. 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šechnyprotokoly Váš proces Win32 služba, desktopová aplikace, ...

  27. Proxy • Proxy nabízí komfortní volání služby proti lokálnímu objektovému modelu • Odstiňují klienta od komunikace, protokolu, zpráv ... • Lzedodatdalší 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 !!!)

  28. Procházka po WCF Ilustrace jednotlivých konceptů

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

  30. 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

  31. 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

  32. 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

  33. Kontrakt a metadata XML Schema 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

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

  35. Doručení, komunikace, ... • SOAP 1.1/1.2 • 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

  36. 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 • ...

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

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

  39. 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“

  40. Bezpečnostní aspekty 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í

  41. 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

  42. 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

  43. 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“

  44. 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í

  45. Autentizace • Proces identifikace entity: • 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

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

  47. 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

  48. 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

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

  50. 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

More Related