WS-Duck-typing February 25, 2007 13:20 over 3 years ago
Det var Dave Thomas der under en tale på RubyConf i London udtalte de berømte ord som senere skabte det mentale fundament der nu forstås ved ducktyping.
“If it walks like a duck and quacks like a duck, it must be a duck”
Ikke mere pjat men direkte til koden:
class Elephant {
wash_dish() {}
}
class Man {
taking_a_nap() {}
}
class Woman {
wash_dish() {}
}
Tre klasser der på udemærket vis repræsentere et stykke virklighed. Det er “design by capability” og nogen vil sikkert nikke genkendende til de egenskaber der er langt vægt på.
Hvis jeg som bruger af disse klasser og skal have hjælp med opvasken, kan jeg kalde metoden(wash_dish) på hver af de tre instanser. Kun de to besidder evnen til at hjælpe mig. Manden lader jeg sove, ingen grund til at smide en exception af den grund ham.
- “Duck typing er at bruge objekter ud fra deres adfærd og ikke deres type”
I dynamiske programmeringssprog kigger man altså ikke på klasse typen men mere om de har den ønskede affærd i form af metoder. WS-duck-typing er lidt det samme dog uden programmeringssproget.
Men hvad har de kornfede ænder i det hele tage med webservices af gøre kunne man spørge? Jo det bunder i en fælles holdning hos medlemmerne af http://soa-manifesto.org og hos mange andre software trendssættere.
- “Service orienteret software er det rigtige at stræbe efter og Service Orienteret Arkitektur(SOA) opstår som afledt effekt af service orientering”
Med andre ord er de alle enige om at SOA som princip er godt for alle service orienteret applikationer men de er også samtidig enige om at SOAP og andre WS* (dødsstjerne teknologer) stinker. Det viser sig at WS-duck-typing er en fin måde at udveksle information på, endda mellem meget forskellige systemer. Det essentielle ved en webservice er at dele information og så længe den går som en and ,,,, osv
Der er lidt forskellige meninger omkring hvor mange, eller rettere sagt hvor få steps der skal til for at skabe webservice docktyping. Jeg bruger den lette model der består af tre enkle skridt.
- Validere ikke indkommende beskeder.
- Brug XPath til udtrækning af information.
- Generer aldrig stubs og skeletons.
1. Validere ikke indkommende beskeder.
Der ingen som gider bruge tid på at validere dine beskeder. Der er heller ikke noget som gider definere dem, opdatere dem eller overholde dem og de sætter unødigt meget fokus på maskinkraft. Har du nogen sinde set en komma separeret fil med typer?
Her kommer det næste citat fra Postel lov:
- “be conservative in what you do; be liberal in what you accept from others”
2. Brug XPath til udtrækning af information.
XPath er en fremragende måde at udtrække information fra et XML dokument. Kode skrevet fra XML API’er er ofte for urobust når det kommer til element ordning, nestede fragmenter og ikke forventede elementer. Når man bruger XPath opdager man ikke hvilken orden elementer kommer i ej heller om det er første eller andet element. De tider hvor XPath var langsom er over.
3. Generer aldrig stubs og skeletons.
Det er med sikkerhed det mest kontroversielle punkt af dem alle. Hvis du opretter flere klient side “stubs” eller flere server side “skeletons” i et typet sprog som Java, mister du muligheden for at være liberal omkring dine XML beskeder. Til trods for at SOA WS produkt sælgerne påstår at du er løs koblet systemer har du med den fremgangsmåde oprette et stærkt typet API der ovenikøbet er stærkt bundet til WSDL kontrakten. Hvis en af disse parameter ikke findes, er forkert forkert type eller der er indsat en ekstra kommentar vil informations udvekslingen fejle.
Anbefalingen lyder på at behandle web tjenester som XML beskeder i stedet for RPC kald. På den måde kan man skabe XML services der er mere fleksible og interoperable.
By Frank Vilhelmsen - 3 tags: ws* xml pattern - Add comment