Na TheServerside je k vidění zajímavý rozhovor s Tedem Newardem. Podívat se na něj můžete na této adrese: http://w.on24.com/r.htm?e=19126&s=1&k=ED9190F7D1537FC293E026FEFA2CF8B1&partnerref=atssc_sitepost_04_03_06

Zde je pár bodů, které mě zaujaly:

Co se týče největších problémů s WS, vidí je ve dvou věcech

  1. Různé přístup k složitějším datovým typům na různých platformách. Jako krásný případ uvádí datum. V Javě je datum obvykle reprezentováno jako instance java.util.Date. To je objekt a reference na něj může být null. V .NET je datum reprezentováno jako system.datetime což je value type. Takže funguje stejně jako třeba int v Javě. Null se do něj rozhodně uložit nedá. A tady se dostáváme do problému co dělat když z Javy do .NETu pošleme null.

  2. Object – XML mismatch (nesoulad mezi XML a objekty). Naráží se na to, že nemusí být snadné mapovat objekty na XML a zpět. Jako příklad uvádí problém s referencemi při převodu do XML.

Velice důležitá myšlenka, která se nesla celým rozhovorem byla, že WebServicies by neměly být brány jako další z forem RPC. Pokud bychom brali WS jen jako další formu RPC, pak by nepřinášely žádnou výhodu nad CORBou.

WS by měli umožňovat větší svobodu. Docela mě zaujal citát „Buďte přísní v tom co posíláte, buďte velkorysí v tom co přijímáte“ (John Postel). Ted Neward říká, že pokud mi přijde zpráva, která úplně nesouhlasí s dohodnutým formátem, ale já jsem schopen z ní odvodit smysl, měl bych ji přijmout. Může se využít element nebo atribut schématu xsd:any, kterým řekneme, tady je schéma, jakýsi základ, ale ve zprávě může být i něco navíc. Podobný přístup má usnadňovat evoluci a rozšiřování protokolu zpráv. Ted Neward také říká, že programátoři podobný přístup opravdu nemají rádi. (To má pravdu). Jako příklad uvádí HTML. Prohlížeč se pokusí interpretovat HTML i když není úplně dobře. Neřekne vám „moje specifikace HTML je jiná než vaše, stránku neukážu“. Když narazí na atribut, který nezná, prostě ho ignoruje.

Rozhovor se také dost věnuje bezpečnosti. V zásadě říká, že HTTPS je pěkná věc, ale jsou případy kdy nestačí. Jako klasický případ uvádí využití prostředníka. Představme si, že komunikuji přes prostředníka, který potřebuje znát část zprávy, například proto aby věděl kam ji má přeposlat. V tom případě musím komunikovat pomocí HTTPS s prostředníkem, který rozšifruje celou zprávu, rozhodne co s ní, poté ji zas zašifruje a pošle dál. Tento stav značně komplikuje implementaci bezpečnosti. Já i příjemce zprávy musíme prostředníkovi důvěřovat. Při použití WS security mi podobné problémy odpadají, mohu zašifrovat jen citlivé části zprávy.

Další důležitou myšlenkou je, že WS by měly být nezávislé na protokolu (HTTP). Zprávu by mělo být v průběhu jejího zpracování možné poslat za pomocí více protokolů (například výměnou ve sdílené paměti pro vyšší výkon).

Rozhovor se dále věnoval vztahu mezi RESTem a WS. Zaznělo, že jednoduchost je zároveň silou i slabinou RESTu. Problém je v silné vazbě na HTTP což mimo jiné opět přináší potíže s bezpečností.