Hmmm. Dobrý námět na qalitní blog-post, třeba mne to donutí zase otevřít ORESTování...
Zkusím být teďka stručný: verzování ve světě WebServis, o kterém mluvíš, je třeba rozlišit do několika kategorií podle způsobu řešení a čeho tím chceme dosáhnout: a) jsme na konferenci o Javě, takže začnu tady: typické řešení verzování v Javě ala RMI, tedy s přístupem class->WSDL. Kdo chce danou věc řešit na bázi Mám třídu, doplním anotace, udělám instanci a vypublikuji, jediné řešení je KOMPLETNÍ oddělení classloaderů - nemusí jít pouze o konkrétní třídu, ale může se změnit verze knihovny,... Takže přímočaré řešení je rozstřílet do WARů, každé vlastní endpoint. Prostě EJB jak vyšité. verzí ze světa WS je hafo zkusím je letmo načrtnout. Nejdřív je nutné si zodpovědět PROČ vlastně řešímě novou verzi plus pár dalších otázek a 1) mění se jenom pajšl a to drobně - pak není nutné dávat světu vědět, že se něco změnilo - prostě jenom nahradíme starou implementaci tou novou 2) měníme výrazně vlastní chování - mění se chování při stejných datech, nebo je změna pouze pro nová? Aneb stačí zpětná kompatibilita či nikolivěk? 3) měníme datové schema - mění se výrazně schéma a mohlo by tedy znemožnit starším klientům v používání nové verze, nebo se jedná jen o rozšíření a opět stačí pouze zpětná kompatibilita? 4) Budou novou verzi využívat pouze nové verze klientů, nebo i ti stávající? Teď něco o teorii, konkrétně o pojmu Kontrakt - klíčový termín pro verzování. Na něm totiž závisí řešení (jeho qalita). Pod kontraktem rozumíme: A) způsob, jakým klient zjišťuje cíl zprávy, kterou chce odeslat a na kterou očekává odpověď - možností je několik - natvrdo URL endpointu, přístup přes registry (typicku UDDI), broker, cíl je v obsahu zprávy (třeba WS-Addressing) B) těsnost vazby na data - jedná spíše o JAX-RCP, DocLit, nebo RESTový message bus? C) sémantická závislost - vyžaduje klient naprosto přesné chování WebServisy či nikolivěk? a teď k těm řešením, nebo vlastně doporučením: b) maximálně zastřít verzi před klientem. Tedy navrhnout celou architekturu tak, aby klienti i WebServisy byly co nejvíce autonomní a nevyžadovali přesné chování druhých stran; co nejvíce rozhodovací logiky přenést na příjemce zprávy; napsat každou servisu tak, aby si dokázala poradit se změnami schématu a rozšířením logiky To znamená stabilní endpointy ve stabilních volných kontraktech. c) dalším zastíracím manévrem je před různé verze implementací předřadit brokera - tedy WebServisu, která akceptuje různé formáty dat v různých požadavcích a sama se rozhoduje, kdo bude zavolán. Díky tomu, že logika správy různých verzí by se měla řešit samoregistrováním se WebServis, nikoli zakódovávat do zdrojáku, je vhodné tento broker implementovat jako Registry nebo se k ní připojovat. Vhodným kandidátem k použití se jeví UDDI nebo něco trošičku více sofistikovaného (jako například HP SOA Center https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-130-27_4000_100__ [ano, přihřívám si vlastní polívčičku, já vím, ale když na tomto produktu jsem se podílel nejen vývojářsky, ale i "malinko" architektonicky... :-)] ) d) když už je třeba verzovat i směrem ke klientům, tak bych se držel starého osvědčeného BuzzWordu "Provisioning". Poskytnout klientům možnost říct si, co chtějí. Velmi se mi líbí, jak tento problém vyřešili ve specce UDDI - jedno jediné WSDL, které includuje namespacem oddělené verze. Ve spojení s registry je to správné použití. Když už tedy zveřejňujeme verze ven, umožněme klientovi, aby si mohl vybrat. Je tedy třeba onu informaci o verzi nějak dohledatelně vypublikovat. A to buď ve formě metadat držených v nějaké registry, nebo ve formě množiny WSRF endpointů, kde si každý endpoint ve svých atributech verzi propaguje. Udržovat znalost o verzích na úrovni znalosti endpointů není verzování, ale pasqil. e) z déčka přímo vyplývá způsob verzování datové struktury - namespace f) je také si potřeba uvědomit, zda nová verze už není jinou servisou se společnou implementační částí. Dost často to tak totiž je. Ano, toto velmi zavání problémy s udržováním obrovského množství WebServis. Jenomže když je špatně navržený kontrakt, dost často ani jiná možnost není - jednou jsem viděl košatý acyklický graf "verzí" téže WebServisy. Různé větvení a spojování verzí bylo pímo k zblití. A přitom to šlo jednoduše rozdělit do několika málo různých WebServis, které pod sebou využívaly opět několik málo sdílených ... Fuj, to jsem se rozkecal, už raději skončím a zkusím to, až bude čas, sesumírovat si a někde to shrnout. Oto 'tapik' Buchta 2009/11/10 Michal Lašák <mla...@gmail.com>: > Zdravím konferenciu! > > > > Píšem diplomovú prácu, ktorej téma je zhodná s názvom predmetu tejto správy, > teda "Verzovanie webových služieb". > > Pravdupovediac, mám s daným "problémom" minimum praktických skúseností. > Práve preto by som chcel poprosiť vás, odborníkov, o zopár cenných > informácií. > > > > K riešeniu tejto problematiky ma viedla situácia vo firme, v ktorej > pracujem. Budujeme webové služby, ktoré majú za cieľ sprostredkovať > komunikáciu medzi informačným systémom (IS) a eshopmi. Platforma, na ktorej > WS budujeme, je Java a ako aplikačný server nám slúži JBoss. > > > > Teraz k samotnému problému. > > Pri výmene verzie IS sa často mení DB štruktúra, preto musíme na dané zmeny > reagovať upravením zdrojového kódu webovej služby (úprava SQL dotazov, > prepared statementov...). Ďalší typ zmien je úprava stávajúcich algoritmov > vo WS, prípadne nová funkcionalita. V jednom momente existuje viacero > klientov s rôznymi verziami IS. Webová služba momentálne beží na aplikačnom > serveri len ako 1 WAR inštancia (väčšina klientov totižto hosťuje priamo vo > firme) a WS pracuje vlastne ako centrálny článok pre všetky eshopy (líšia sa > len data sourcom, na ktorý sa WS pripája). > > Preto som chcel nájsť čo najlepší spôsob, ako začať WS verzovať, aby som čo > najjednoduchšie vedel udržovať jej zdrojový kód (ideálny stav by bola stále > jedna a jediná inštancia WS bežiaca v aplikačnom serveri - čo som zistil, že > bude NEMOŽNÉ) a aplikácie by bežali bez problémov u každého z klientov > (resp. s minimom zmien nutných na strane zákazníka). > > > > Začal som teda bližšie pátrať na internete. Dosť ma prekvapil fakt, že > žiadne oficiálne stanovisko k verzovaniu WS neexistuje, našiel som len > best-practices. Dospel som zatiaľ k nasledovným bodom: > > > > Čo všetko bude treba verzovať > > 1. zdrojový kód - používame SVN, takže jednotlivé verzie by sa > riešili formou vetiev. > > 2. WSDL > > 3. XSD > > > > Deployment z hľadiska zdrojákov a riešenie problémov s class loadingom > > 1. Každá verzia do zvláštneho EAR súboru > > 2. Jeden EAR s viacerými WAR súbormi (1 WAR = 1 verzia) - každá > verzia by musela mať vlastný class loader > > 3. Premenovanie packagov v Jave pri vzniku novej verzie (de-facto > nová služba s novými triedami) - automaticky zavrhujem > > 4. Použitie špecializovaných riešení, napr. OSGI - obtiažnosť? > oplatí sa? -- mám s tým nulové skúsenosti > > > > Kedy sa budú vytvárať nové verzie => pri každej zmene, ktorá môže mať dopad > na konzumenta služby > > => "major changes" = odstránenie operácie, premenovanie operácie, > zmena parametrov operácie (dátový typ, poradie), zmena komplexného dátového > typu v XSD > > => pozor na implementačné zmeny, ktoré "zvonka nevidíme": validácie > vstupu/výstupu, security credentials, porušenie SLA (napr. náročnejším > algoritmom sa zväčší doba vykonania) > > > > Nasadzovanie WS + volanie služieb zo strany konzumenta > > - nasadzovať všetko na jeden endpoint alebo použiť pravidlo > nová verzia = nový endpoint > > - priamy prístup k endpointom alebo použitie routera, ktorý > bude smerovať požiadavky podľa identifikátora (IP, parameter verzie v > URL...) > > - použitie UDDI registra Apache jUDDI > > > > Zaujímalo by ma, či máte skúsenosti s niektorými zo spomínaných bodov. Budem > veľmi vďačný za akékoľvek informácie, s ktorými sa podelíte. > > Ďakujem za ochotu. > > > > S pozdravom > > --ml > > Michal Lašák > > __________ Informacia od ESET Smart Security, verzia databazy 4592 > (20091110) __________ > > Tuto spravu preveril ESET Smart Security. > > http://www.eset.sk >
