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
-
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. -
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í.