Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

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

Podobné prezentace


Prezentace na téma: "Infrastruktura pro SOA – oddělení vývoje a provozu Michael Juřek Software Architect Microsoft s.r.o."— Transkript prezentace:

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čnostRobustnost Doporučené postupy Různé, co dále,...

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

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čnostRobustnost 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...

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

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

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 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 KlientSlužba Zpráva EndpointEndpoint Endpoint

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

19 Address, Binding, Contract KlientSlužba Zpráva ABCAB AB AddressBindingContract (Kde?) (Jak?) (Co?) C

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 Co je to binding? KlientSlužba ProxyDispatcher ProtocolProtocol EncodingEncoding TransportTransport Zpráva BindingBinding BindingBinding

22 Binding - složky TransportEncoderSecurityReliabilityProtocol Pipes MSMQ Custom HTTPText TCPBinary MTOM Custom WS-* Custom WS-* HTTPTextTCPBinary

23 Metadata KlientSlužba Zpráva ABCABC ABC Metadata Umožňují volajícímu zjistit informace o službě (kontrakt, binding)

24 Behaviors (chování) KlientSlužba Zpráva ABCABC ABC BvBv BvBv Metadata Vnitřní záležitosti klienta nebo serveru, které by druhé straně měly být lhostejné

25 Hostování KlientSlužba Zpráva ABCABC ABC Metadata BvBv BvBv Proxy ServiceHost()

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

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

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

29 Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita BezpečnostRobustnost 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 31 Modulární skládání hlaviček Addressing dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD 10 520W 3MPH Security Reliability

32 32 Kompletní obrázek Modulární funkční bloky Popis Doručení Transport Security XSD, WSDL, UDDI, Policy, MetadataExchange XML, SOAP, Addressing HTTP, HTTPS, SMTP Reliable Messaging Transactions From joint IBM/MSFT WS Whitepaper at

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čnostWS-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) 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 IBM – ETTK for Web Services Systinet (-> Mercury -> HP) Server for Java/C++

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

38 Agenda Service Oriented Architecture (SOA) WCF – architektura Standardy a interoperabilita BezpečnostRobustnost 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“ 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í 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 Zdroje v aplikaci (imperativní kód) Operace (PrincipalPermission) Hostitel (soubor, URL, konfigurace služby) Zpráva Možnost vlastní správy rolí: Možno využít RoleProvider z ASP.NET Možnost vlastní autorizační politiky

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 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čnostRobustnost 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

51 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

52 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

53 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

54 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

55 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

56 Robustnost WS-ReliableMessaging WS-AtomicTransactions

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

58 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

59 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 Za zapnutí bezpečnosti, transakcí,... platíte časem CPU, latencí a šířkou pásma – to je život

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

61 Slepice nebo vejce? Code-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

62 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

63 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

64 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 OperationContractJméno Akce pro žádost a odpověď Jednosměrnost anebo žádost/odpověď

65 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 Minimální úroveň zabezpečení Žádná, podpis, šifrování a podpis

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

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

68 Standardní bindingy T = Transport Security | S = WS-Security | O = One-Way Only InteropSecuritySessionTransxDuplexStream BasicHttpBinding WsHttpBinding WsDualHttpBinding NetTcpBinding NetNamedPipesBinding NetMsmqBinding BP WS WS T TS TS TS TS TS O O NetPeerTcpBinding TS

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

70 Nasazení – chování Služba 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,... Time-out...

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

72 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

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

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

75 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

76


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

Podobné prezentace


Reklamy Google