Vlákno názorů k článku
Akta X: HTML 5 jako alternativa ke XHTML

Tak tohle me zvedlo ze zidle, lomitko ze je k nicemu >-] Jestli si nekdy pani web patlaci zkusili naparsovat naky jejich spatlany html (treba s IDOSem je velka prdel). Osobne preju HTML jen smrt a to nejhorsi, melo by skoncit v prachu dejin, stejne jako lidi co ho patlaj.

souhlas

html 5 je paskvil z pravěku

moje rec =)

aby se nemusel parsovat vystup urceny puvodne pro prohlizec byl vymyslen WebService (http://en.wikipedia.org/wiki/Web_service) a par dalsich podobnych mechanismu

IDOS, to jsou ty jizdni rady? Nebylo by jednodusi se rovnou domluvit s autory?

Ne, WS-* stack byl vymyšlen jako zbraň hromadného ničení duševního zdraví nebohých vývojářů, kteří musejí s tím nepřehledným bastlem pracovat :)

LOL, ty asi píšeš WS v assembleru, ne? :-)

Zkus to někdy v javě pomocí průvodce z Netbeansů nebo Eclipse, případně v C# ve Visual Studiu -- a zjistíš, že je to pro programátora nejsnadnější cesta jak volat vzdálené metody. A to jak z pohledu serveru, tak i klienta ;-)

Ale neznamená to, že bych byl jednoznačným zastáncem WS -- z výkonnostních hledisek to není optimální, data se obalují velkými kusy textu... ale to je cena za snadný a rychlý vývoj a schopnost integrace mezi různými jazyky a platformami.

Souhlasim. Jen je otazka, jestli ten komfort neni vyvazen zbytecne velkou nepruhlednosti vygenerovaneho kodu (ted mluvim predevsim o .NETu)..

Dot net není moje hlavní doména, takže to nemůžu až tak posoudit. Ale když jsem si to zkoušel, tak mě zaujalo hlavně to, jak snadno se dají přegenerovat třídy na straně klienta, když se změní WSDL. Neprůhledné to jistě je, ale dovedu si představit uplatnění u věcí, které člověk potřebuje rychle naklikat. Nicméně celý dot net mi přijde jako spíš taková hračka než nástroj pro seriórní práci.

???

No, moje poznámka byla míněna jako takové drobné rýpnutí, ale když už je tu ta odpoveď... :)

Průvodce v Eclipse (Web Tools) jsem použil pro několik web service, které jsou nyní v produkčním nasazení a do teď si za to nadávám, rvu vlasy a chodím bezmála kanály. Jednak je to celé postavené na Axisu, což není zrovna nejkvalitnější kus kódu na světě (narazil jsem minimálně na tři dost nepříjemné bugy - Axis posílal nějkteré elementy v jiných namespacech než v jakých měl, jeden element mi dokonce přejmenoval...) a co je důležitější, nad vygenerovaným WSDL, při postupu code-wsdl, nemám plnou kontrolu, takže jakákoliv změna do interface je sázka do loterie, zda bude rozšíření interface skutečně rozšířením konzervativním, například. Z tvého "nejsnadnější cesta jak volat vzdálené metody" soudím, že WS-* stack používáš přesně tímto způsobem - jako formu RPC.

Tedy code-wsdl a wizardi vedou k neudržovatelnosti výsledného kódu.

Opačný postup, z XML schematu či hotového WSDL ke kódu, je mnohem příčetnější, z dlouhodobého hlediska. Problém je v tom, že XSD je mimořádně nabubřelý a složitý standard, interoperability issues beztak existují (ne nadarmo vznikla skupina WS-I dospecifikovávající ty kusy SOAPu a WSDL, které jsou nejasné a neinteroperabilní) a tak se člověk začne ztrácet v pojmech jako WS-I, wrapped, document/literal, rpc/encoded, sporech, zda SOAPAction používat či ne apod. Zkrátka nic, co by jednomu, který nemá čas pročítat tuny specifikací napsaných specification freaks z velkých korporací, nějak ulehčilo život.

WS-* je bastl. Nedospecifikovaný (wsdl je pouze W3 note!), na toolech (wizardy, IDE, drahé aplikační servery) závislý, mezi platformami nekompatibilní. Zaslouží si osud corby.

Hlavní přínos WS vidím právě v rychlosti a snadnosti implementace a ta se projeví právě při přístupu: kód --> WSDL. Obrácený přístup je IMHO tak pracný, že se vyplatí použít jinou technologii.

Co myslíš tím "mezi platformami nekompatibilní"? Vždyť je jedno, v čem implementuješ klienta a v čem server.

Nikoliv, postup kód - wsdl vede k tomu, že nemáš plnou kontrolu nad interfacem jako takovým - interfacem jsou XML zprávy, ne (kupříkladu) Javovský interface.

Problémy s platrofmami a jazyky existuje - právě proto existují specifikace jako je WS-I. Zkus konzumovat v Javě perlovské serializované objekty...

O tom, proč je code-wsdl přístup špatný se píše například tady: http://www.hpl.hp.com/techreports/2005/HPL-2005-83.pdf

Stack, který je si toho plně vědom a umožňuje dobře dělat schema first development je kupříkladu Spring WS: http://www.springframework.org/spring-ws

Říkám to nerad, kód-wsdl je pohodlná cesta, ale po zkušenostech, dost bolestivých, nikdy více.

"Nikoliv, postup kód - wsdl vede k tomu, že nemáš plnou kontrolu nad interfacem jako takovým" Nechápu, kterou část mého příspěvku neguješ tím "nikoli"

Kód-->WSDL je rychlý a bezpracný a jako takový se na pár věcí hodí, nemá smysl ho zavrhovat, uplatnění pro něj existuje. Daní za tu rychlost je, že nemáš plnou kontrolu nad WSDL, ale to je tak vždycky: něco za něco. Pokud tenhle přístup přinese uspokojivé řešení, tak přece nevadí, že nemáš plnou kontrolu nad WSDL.

Pokud bych si měl psát WSDL ručně, tak se raději poohlédnu po jiné technologii než WS.

Btw: když začneme psaním WSDL, tak zase nemáme kontrolu nad těmi vygenerovanými javovskými (případně C) třídami. Pak je ještě možnost psát ručně úplně všechno, ale tím se člověk připravuje o hlavní výhodu WS a nemá to už vůbec smysl je používat.

Neguju tím celý nápad generování wsdl z kódu, zhruba :)

Nemusíš psát ručně WSDL celé. Nejdůležitější je část se schematem, to napsat ručně můžeš a zbytek WSDL nechat generovat (při zachování plné kontroly nad tím, co bude jeho obsahem) například z JSR181 anotací v třídě implementující onu službu. Tato třída pak bude používat třeba JAXB2 generované nebo Castor třídy.

To, že nemáš konktrolu nad těmi třídami není taková katastrofa - vrstva služby je jistě tenká a pracuje nad nějakými business objekty, které jsou na ní nezávislé. Jde o to, že při generování Javovských tříd neřešíš problém toho, že bys mohl rozbít konktrakt s druhou stranou, maximálně rozbiješ svou tenkou vrstvu WS, kterou opravíš během chvíle.

Zažil jsem peklo toho, kdy jsem musel do nějakého poměrně důležitého interface dodávat další pole a metody a pak generovat WSDL. Jeden konzumující systém ty změny vyžadoval, druhý jej mohl implementovat až někdy za půl roku... Opravdu nepříjemné. Kdybych měl plnou kontrolu nad schematem, mohl bych mnohem snadněji interface rozšířit a mít jistotu, že jsem nerozbil konktrakt s druhou stranou.

A o to jde, o konktrakt interfacujících systémů. Všechno ostatní je podružné.

Pokud změna spočívala v přidání metody, pak by se mělo vygenerovat totožné WSDL, které by mělo navíc pouze novou metodu. Tím se kontrakt nerozbije a pokud ano, tak je to chyba generátoru WSDL a měla by se nahlásit (btw: co to bylo za prostředí?)

Pokud jde o přidání parametru do existující metody, pak je to v podstatě změna "protokolu" a změna na straně klienta je tak jako tak nevyhnutelná.

Axis, mimochodem, pokud jen trochu lze, držet se od tohoto co nejdál.

Přidání parametru nemusí nutně znamenat změnu na straně klienta. Je-li parametr nepovinný (minOccurs nastavený na 0), pak jej neposílající klient vůbec nemusí znát, zatímco jiný klient jej může zvesela posílat.

Ještě ke všemu jsou požadavky takové, že je formát správ prostě daný externím systémem - zrovna teď jsem to řešil - a pak vyjít od schematu prostě musíš.