Verzovanie webových služieb
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
Re: Verzovanie webových služieb
Ahoj. Tiez nie som v tejto veci profik, ale skusim dat par postrehov. 1. zmena struktury v db, alebo cokolvek v podvozku Pokial oddelis podvozok od webservice ( napr. pomocou ejb ), tak zmena sql dotazov bude nutna len v tom danom ejb. Webservicy sa o zmene nemusia vobec dozvediet. Toto sa da tusim naklikat v netbeans, je to webservice from existing java bean, alebo take daco. Vyhodou je, ze ten podvozok mozes za behu servera menit bez zastavenia sluzieb. 2. Zmena API danej webservice ... znamena, ze sa jedna o uplne novu webservice. Imho jedina moznost ako prevadzkovat ws so starym a novym api su 2 samostatne ws. Ja osobne to robim tak, ze cislo verzie ws je sucastou url. Neviem, ako inak a ci vobec by sa to dalo obist. Ciste teoreticky ma napada nejaka specialna http proxy, ktora by zo soap message urcila, o akeho klienta sa jedna a nasledne transparentne presmerovala request na ws spravnej verzie. To je ale z rise rozpravok, takze s5 na zem. 3. Zmena API podvozku Ak potrebujes zmenit API pod tou ws, vsetko zavisi na tom, o aku zmenu pojde. Niekedy nebudes musiet do ws vobec hrabat a pokial aj ano, zmenis nanajvys par riadkov. Urcite existuju este nejake sofistikovanejsie sposoby, dal som len hruby nacrt, povolanejsi nech sa vyjadria. > > Č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 > Wsdl aj xsd mozu byt v svn, nie? -- Dusan ... tykajte mi
Re: Verzovanie webových služieb
Zdravim, zaujimava publikacia na danu temu je: Thomas Erl - Web Service Contract Design and Versioning for SOA http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/ref=sr_1_2?ie=UTF8&s=books&qid=1257957547&sr=1-2 vseobecne postupy a patterny ktore su tam uvedene sa zhoduju s tym co chcete riesit aj vy. Michal Lašák wrote / napísal(a): 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
RE: Verzovanie webových služieb
Zdravim, dakujem za tip. Tato publikacia je uz momentalne objednana mojou veducou DP, takze som velmi rad, ze mi pomoze. --ml From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf Of Richard Holly Sent: Wednesday, November 11, 2009 5:43 PM To: Java Subject: Re: Verzovanie webových služieb Zdravim, zaujimava publikacia na danu temu je: Thomas Erl - Web Service Contract Design and Versioning for SOA http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/r ef=sr_1_2?ie=UTF8 <http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/ ref=sr_1_2?ie=UTF8&s=books&qid=1257957547&sr=1-2> &s=books&qid=1257957547&sr=1-2 vseobecne postupy a patterny ktore su tam uvedene sa zhoduju s tym co chcete riesit aj vy.
Re: Verzovanie webových služieb
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 : > 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 > i
RE: Verzovanie webových služieb
Zdravim. 1.zmena struktury v db, alebo cokolvek v podvozku Pokial oddelis podvozok od webservice ( napr. pomocou ejb ), tak zmena sql dotazov bude nutna len v tom danom ejb. Webservicy sa o zmene nemusia vobec dozvediet. Toto sa da tusim naklikat v netbeans, je to webservice from existing java bean, alebo take daco. Vyhodou je, ze ten podvozok mozes za behu servera menit bez zastavenia sluzieb. Ano, dakujem za dobry postreh. Problemom ostava to, ze problem verzovania posuniem z WS casti do EJB casti. Dalsie instacie WS so zhodnym API budem musiet potom bundlovat spolu s roznymi verziami EJB (predpokladam, ze asi ako EAR aplikaciu). Nie je mi celkom zrejme, ako by sa to dalo upgradnut bez zastavenia sluzieb (ak teda nedeployujem novy EAR, ale chcel by som napr. upgradnut cisto len EJB). Mohol by si mi to prosim trosku upresnit? Asi som ta spravne nepochopil. 2.Zmena API danej webservice ... znamena, ze sa jedna o uplne novu webservice. Imho jedina moznost ako prevadzkovat ws so starym a novym api su 2 samostatne ws. Ja osobne to robim tak, ze cislo verzie ws je sucastou url. Neviem, ako inak a ci vobec by sa to dalo obist. Ciste teoreticky ma napada nejaka specialna http proxy, ktora by zo soap message urcila, o akeho klienta sa jedna a nasledne transparentne presmerovala request na ws spravnej verzie. To je ale z rise rozpravok, takze s5 na zem. Ano, zmena URL sa mi zda ako najjednoduchsie riesenie. Co som nasiel na internete, tak pomocou by mohlo zevraj UDDI, pripadne existuju asi nejake komercne riesenia (nasiel som nieco specialne od Oraclu co robi prave routing a dokonca vytvara aj adapter medzi roznymi verziami sluzieb). Momentalne mam postavene provizorne riesenie na baze, ze klient posle svoj identifikator a my interne mame v DB ulozene, na akej verzii bezi a podla toho sa zariadime. 3.Zmena API podvozku Ak potrebujes zmenit API pod tou ws, vsetko zavisi na tom, o aku zmenu pojde. Niekedy nebudes musiet do ws vobec hrabat a pokial aj ano, zmenis nanajvys par riadkov. Mna budu trapit hlavne zmeny, ktore budu suvisiet s WS a ich dopad na konzumentov. Cize co najmenej zasahov do volani sluzieb zo strany klienta atp. --ml
Re: Verzovanie webových služieb
Zdravim, nahodou jsem narazil na http://www.ibm.com/developerworks/webservices/library/ws-version/ a vzpomnel si na tohle vlakno, mozna se Vam to bude hodit. S pozdravem, Pavel Bucek Michal Lašák wrote: Zdravim, dakujem za tip. Tato publikacia je uz momentalne objednana mojou veducou DP, takze som velmi rad, ze mi pomoze. --ml *From:* konference-boun...@java.cz [mailto:konference-boun...@java.cz] *On Behalf Of *Richard Holly *Sent:* Wednesday, November 11, 2009 5:43 PM *To:* Java *Subject:* Re: Verzovanie webových služieb Zdravim, zaujimava publikacia na danu temu je: Thomas Erl - Web Service Contract Design and Versioning for SOA http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/ref=sr_1_2?ie=UTF8&s=books&qid=1257957547&sr=1-2 <http://www.amazon.com/Web-Service-Contract-Design-Versioning/dp/013613517X/ref=sr_1_2?ie=UTF8&s=books&qid=1257957547&sr=1-2> vseobecne postupy a patterny ktore su tam uvedene sa zhoduju s tym co chcete riesit aj vy. __ Informacia od ESET Smart Security, verzia databazy 4596 (2009) __ Tuto spravu preveril ESET Smart Security. http://www.eset.sk
RE: Verzovanie webových služieb
Zdravim, dakujem este raz za vsetky prispevky (obzvlast za ten obsiahly od p. Buchtu). Uz mi dorazila kniha Web Service Contract Design and Versioning for SOA, takze mam o zabavu pocas vianoc postarane a pilne studujem :) Clanok, na ktory ste narazili som uz prezrel. Ak by to niekoho zaujimalo, to je internetovo dostupna literatura, ktora mi pomaha pri praci: == http://soa.sys-con.com/node/143883 http://www.ibm.com/developerworks/webservices/library/ws-version/ http://www.jboss.org/community/wiki/ClassLoadingconfiguration http://soa.sys-con.com/node/44356 http://www.jboss.org/index.html?module=bb&op=viewtopic&t=104843 http://www.jboss.org/community/wiki/JBossWS-JAX-WSTools http://www.jboss.org/community/wiki/JBossWS-UserGuide http://msdn.microsoft.com/en-us/library/ms954726.aspx http://msdn.microsoft.com/en-us/library/ms731060.aspx http://soa.sys-con.com/node/250503 http://soa.sys-con.com/node/453060 http://www.ibm.com/developerworks/webservices/library/ws-wsdl/ http://www.ibm.com/developerworks/webservices/library/ws-wsdl2.html http://www.ibm.com/developerworks/webservices/library/ws-wsdl3/ http://msdn.microsoft.com/en-us/library/bb491124.aspx http://msdn.microsoft.com/en-us/library/cc304741.aspx http://soa.sys-con.com/node/39678 http://www.gridshore.nl/blog/index.php?/archives/68-Web-service-versioning-i n-the-java-world.html http://www.oracle.com/technology/pub/articles/web_services_versioning.html == Dufam teda, ze to nebude vyhodnotene ako spam :) S pozdravom --ml Michal Lašák -Original Message- From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf Of Pavel Bucek Sent: Wednesday, December 02, 2009 8:03 PM To: Java Subject: Re: Verzovanie webových služieb Zdravim, nahodou jsem narazil na http://www.ibm.com/developerworks/webservices/library/ws-version/ a vzpomnel si na tohle vlakno, mozna se Vam to bude hodit. S pozdravem, Pavel Bucek __ Informacia od ESET Smart Security, verzia databazy 4655 (20091202) __ Tuto spravu preveril ESET Smart Security. http://www.eset.sk
