Tech Life

Ilustrační obrázek

Problémy konzumace .NET webových služeb

08. 06. 2010 16:15    kategorie: Tech Life    autor: VMe    komentářů: 0

Jednou z hlavních výhod webových služeb je, že umožňují snadnou komunikaci mezi různými platformami. V dnešní době jsou často nejlevnějším prostředkem, jak propojit systémy vytvořené ve zcela odlišných prostředích. Java, .NET, C++, PHP, všechno jedno, pokud obě strany dodrží předepsané standardy (SOAP, WSDL, atd.).
 

Aby byla interoperabilita navíc snadná, nestačí jenom dodržení formálních standardů. Záleží zejména na vlastním návrhu API (a tedy výsledného WSDL) služby. Ten vyžaduje určitou zkušenost a také ohleduplnost ke konzumentům z odlišných platforem.

V článku rozebereme typický problém webových služeb vytvořených na platformě .NET a zaměříme se na obtíže, které způsobuje konzumentům služby (nejen) v Javě.

Tento problém se týká definice typů parametrů a návratových hodnot metod služby. Stejně jako u návrhu nativního API v příslušném programovacím jazyce, silná typová kontrola ulehčuje práci a pomáhá předcházet chybám.

Pokud se bavíme o typech v kontextu webových služeb, myslíme tím typy definované v XML schématu v rámci WSDL služby. Za slabě nebo příliš obecně typované pak považujme parametry, které mají typ xsd:any. Podobné problémy mají také parametry typu xsd:string, které v sobě nesou strukturovaná data v nějakém formátu (např. JSON nebo serializovaný XML dokument).

Pokud jsou typy parametrů nebo návratové hodnoty definované příliš obecně, nutíte konzumenta služby, aby si typy objektů hlídal sám a vycházel při tom z nějaké dodatečné dokumentace nebo dokonce empirických zkušeností s použitím implementace služby.

Navíc, pokud se změní skutečný typ parametru nebo návratové hodnoty, WSDL služby zůstane stejné a konzument se o změně může dozvědět až při analýze chyby, ke které došlo za běhu jeho aplikace.

Ve většině případů ale autor služby její WSDL ani XML schéma typů netvoří ručně. Většina nástrojů pro vývoj webových služeb umožňuje WSDL vygenerovat z kódu v příslušném programovacím jazyce a možná úplně nejčastěji se WSDL služby generuje dynamicky až za běhu. V tom případě by měl ale autor služby vědět, jak bude vygenerované WSDL vypadat, nebo si ho alespoň zpětně kontrolovat.

Může se totiž snadno stát, že i když v kódu používáte standardní typované objekty vašeho programovacího jazyka, vygenerované WSDL přesto obsahuje použití problematických typů xsd:any. Nástroje generující WSDL používají mapování typů programovacího jazyka do XML schématu, které obvykle dobře pokrývá “primitivní” typy (význam se může v různých jazycích lišit, ale obvykle jde pro typy pro čísla, textové řetězce atd.), které lze snadno převést na předdefinované typy v XML schématu, ale pro jiné, složitější typy, může být výsledný typ v XML schématu překvapivý.

U webových služeb vytvořených na platformě .NET je takovým problémovým typem DataSet. Programátor .NET webové služby si může ušetřit práci tím, že DataSet, který naplní výsledkem dotazu do databáze, rovnou použije jako návratovou hodnotu metody.

Ve WSDL pak takový typ vypadá nějak tahle:

.NET framework reprezentuje DataSet v XML schématu tzv. diffgramem. První xsd:any element obsahuje XML schéma dat, které jsou vložené do diffgramu, což je ten druhý xsd:any element. Microsoft se samozřejmě snaží vyjít vývojářům na své platformě vstříc, takže pokud tuto službu budete konzumovat také v prostředí .NET, tak v kódu vygenerovaném z WSDL se opět “magicky” objeví typ DataSet. Z hlediska interoperability webových služeb je tento “vstřícný krok” Microsoftu poněkud nešťastný, protože podporuje tento antipattern, ale z pohledu obchodní strategie Redmondu je asi pochopitelný. Nicméně už v dubnu 2003 vyšel v MSDN Magazine článek, který přesně před používáním DataSetů ve webových službách varuje. Kromě snížené interoperability způsobují DataSety i zvýšení objemu přenášených dat díky přibalení XML schématu DataSetu pro každý parametr tohoto typu. TheServerSide.NET řadí tento problém mezi 5 nejčastějších chyb při vývoji webových služeb na platformě .NET.

Pokud nemají vývojáři na jiných platformách páky na to, aby přinutili poskytovatele službu změnit, musejí si umět poradit sami. Ve zbytku článku ukážeme možné řešení, jak se v Javě za použití JAX-WS a JAXB vypořádat s metodou webové služby, která vrací DataSet.

Na první problém narazíte asi hned při generování Java kódu z WSDL. Pravděpodobně budete muset JAXB kompilátor použít v laxnějším režimu, aby XML schéma vůbec zpracoval. Až se vám podaří Java třídy vygenerovat, metoda pro přístup k DataSetu budou vypadat asi takhle:

List bude obsahovat dva DOM elementy odpovídající dvoum xsd:any elementům z ukázky schématu výše. První prvek je tedy XML schéma a druhý diffgram.

Pokud nechcete při manipulaci s DataSetem vždy přímo pracovat s DOM uzly, můžete si pomocí JAXB ulehčit práci. Zavolejte danou metodu webové služby a obsah prvního Elementu si lokálně uložte. Např. pomocí identity přes XSLT:

Pomocí JAXB potom můžete z tohoto schématu vygenerovat Java třídu, která bude reprezentovat DataSet. Manipulace s DataSetem potom bude snazší, nicméně pořád tu bude riziko, že poskytovatel služby strukturu DataSetu změní a při volání služby potom dojde k chybám.

Po zavolání metody webové služby pak musíte z obsahu diffgramu vyrobit pomocí JAXB unmarshalleru instanci objektu, který reprezentuje DataSet:

Závěrem je ještě nutno podotknout, že špatná interoperabilita webové služby není dána platformou, na které vzniká, ale vývojářem, který službu navrhuje. Problém DataSetů v .NET webových službách je ale natolik rozšířený, že si zaslouží zvláštní pozornost.

Sdílet odkaz:
tisk

Diskuze k článku

K článku nebyl zatím přidán komentář.

Přidat příspěvek

 

Kontakt pro média


Máte zájem o další informace, odborný článek či přednášku na konferenci? Kontaktujte nás prosím na pr@etnetera.cz.

RSS - Tech life


RSS kanál Tech Life Blogu

Offlineblog

Offlineblog

Ljama


Komix z prostředí imaginární firmy.

ljama

Ještě jste ho nečetli? Tak tudy ...

 
Doporučujeme: Nabídka práce, volná pracovní místa - pracovní portál SPRÁVNÝKROK.CZ