bloghoved rene løhde

Web Service er død - REST in peace! (1:3)

Microsoft har været med til at skubbe SOAP som det interoperable tryllestøv for distribuerede systemer. I den forbindelse er SOAP blevet synonym med webservice hos mange kunder, partnere og andre leverandører.

Mit 'elevator pitch' på SOAP er: en data konvolut brugt til at gøre IT systemer interoperable og udnytte eksisterende investeringer og teknologi. En protokol som kan gøre systemers kommunikation til service abstraktioner og indfri de løfter IT folkene har givet om en Service Orienteret Arkitektur.  

SOAP og specielt dets t(r)o følgesvende, metadatabeskrivelsen WSDL og SOAP udvidelserne, som går under navnet WS-* [WS-Stjerne], har i de sidste 5 år været Microsofts foretrukne teknologivalg ved kommunikation mellem systemer. Ud over Microsoft er specielt BEA og IBM meget aktive i arbejdet med at skubbe de værktøjer og standarder hen over isen, som skal understøtte denne stack (populært kaldet WS-* stakken eller SOAP stakken eller WebService teknologi stakken).

SOAP implementeringer i diverse sprog, er i 2. eller 3. generation hos flere leverandører og også i open source miljøer findes kendte produkter. Som 'customerfacing' employee hos Micrsoft oplever jeg at virksomheder i stigende grad integrerer  mellem deres eksisterende systemer ved hjælp af disse SOAP værktøjer ? naturligvis for at høste SOA gevinster.

Samtidigt med at jeg kan se SOAP finde vej ud til virksomhederne og offentlige udbud og systemer, kan jeg også iagttage at internettet ikke følger med. Eller måske er det forkert sagt ' jeg kan se at internettet store spillere følger en anden sti. Tiltrods for at de store software leverandører har skubbet på en 'enterpriese-ready' kommunikationsstak ved hjælp af SOAP, har internettets ' tør jeg sige Web 2.0's fortrop - Amazon, Flickr, Delicious, Google...osv holdt fast i de dyder, som har gjort HTTP anvendelig som WWW's rygrad. De har næsten ignoreret SOAP stakken tiltrods for at leverandørerne har skubbet voldsomt på.

Jeg har brugt de sidst 5 år i SOAP-land og kan dårligt forestille mig nye distribuerede systemer leveret uden SOAP baserede webservices.

Så hvad er det jeg er gået glip af når alle andre snakker om webservices ved hjælp af REST?

Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Dennis Krøger

Jeg har selv haft mine øjeblikke af ignorance over for hvad REST egentligt er. (Som kan ses i et halvdumt indlæg på ing.dk, noget i stil med "Er REST ikke bare SOAP-- ?").

Som jeg ser det (og jeg er stadig delvist ignorant her, så bare spark til mig hvis jeg tager fejl) er REST sådan set bare et begreb for hvordan man bør lave services, nemlig at holde state hos klienten, og lade den fortælle serveren hvad state den er i.

SOAP kan sagtens være RESTful, f.eks. ved ikke at have sessions der holder på information om hvad klienten har gjort ("der er den og den vare i kurven", "vi er ved trin 3" o.s.v.), men i stedet lade klienten styre det del. (Her skal vi selvfølgelig stadig have sikkerheds checks på serveren, ikke noget "jo jooooo, jeg er skam logget på" eller "Betalt? Ja da").

Statefull client, stateless server.

Der er så på andre punkter hvor SOAP bryder lidt med REST idéerne, såsom at bruge GET til requests, og PUT/POST/DELETE til opdatering, oprettelse og slette, men grundidéen med states ser jeg som det vigtigste.

Er forøvrigt helt enig i at SOAP er lækkert. (Har ikke rigtigt benyttet andre dele af WS-* stakken).

  • 0
  • 0
Rasmus Kaae

Hvis du spørger mig så er SOA blot endnu et buzzword vi kan tilføje til vore white papers så sælgerne kan lave flotte plakater. Det er ikke umiddelbart noget nyt og smart i mine øre.

Bevares, protokollen SOAP er en nytækning, men er den smart? Når man skyder data afsted i distribuerede systemer skal man tænke over en masse ting, bl.a. hvor meget data der skal transmiteres per pakke, hvor ofte der skal afleveres pakker, osv. Hvis de data der skal transmiteres er mindre end størrelsen på konvolutten - er det så stadig smart? Og hvad nu hvis de små data skal sendes ofte?

Og hvad med encoding af data? At lave en service der opererer via SOAP er en smal sag, men at anvende den i et operationelt miljø kan godt være noget af en udfordring. Her tænker jeg specielt på transmitering af ting der skal overføres binært og derfor enten skal transformeres over i f.eks. en base-64 encoding eller tilsvarende.

Jeg er ikke i mod tanken om SOA/SOAP/netcentricitet men jeg er måske i mod en generaliserende standardisering der spises råt af sælgere (og arkitekter).

I mange tilfælde er de gode gamle RPC-protokoller klart SOAP overlegen i performancemålinger, da de er specialiserede og kompakte.

  • 0
  • 0
Dennis Krøger

Selvfølgelig er SOAP ikke løsningen på alt, ligesom specialiserede protokoller ikke er løsningen på alt.

At sælgere vil lege bullshit bingo med alle nye udtryk der lyder smarte har ikke noget med teknologien at gøre.

Hvis du skal sende bittesmå pakker over nettet konstant, burde du måske under alle omstændigheder overveje om dit design ikke er broken.

  • 0
  • 0
René Løhde

Rasmus,

"Jeg er ikke i mod tanken om SOA/SOAP/netcentricitet men jeg er måske i mod en generaliserende standardisering der spises råt af sælgere (og arkitekter)."

Jeg føler mig ramt og er tildels enig. However for projektleder eller løsningsarkitekt, afhængig af hvilken rolle man har i sin virksonhed eller på projekt, så er der andre hensyn som gør at det kan være fornuftigt at standardisere.

Anyway - jeg tror det er tid til næste post...

  • 0
  • 0
Rasmus Kaae

Det er måske lidt groft at sige et design er ødelagt blot fordi der kræves en del kommunikation via netværk. Tag f.eks. et netværksspil, er det også et resultat af "broken design" når der kommunikeres med bittesmå datapakker konstant via UDP?

Min pointe var blot at man ikke skal anvende SOAP blindt, men der i mod nok godt kan lade sælgerne bruge ordet SOA og lade teknikkerne vælge den faktiske implementation (måske SOAP, RPC eller noget tredje).

Hvad er mest vigtigt for en løsningsarkitekt:

1) Det faktum at en komponent stiller en række services tilgængeligt

eller

2) Det faktum at en komponent stiller en række services tilgængeligt via en specifik protokol

Inde i mit, måske forskruede, hoved skal en løsningsarkitekt bekymre sig om punkt 1 og en tekniskarkitekt bekymre sig om punkt 2. At der så kan være konkrete tilfælde hvor de to arkitekter er den samme person er en degenerering :)

  • 0
  • 0
René Løhde

"Min pointe var blot at man ikke skal anvende SOAP blindt, men der i mod nok godt kan lade sælgerne bruge ordet SOA og lade teknikkerne vælge den faktiske implementation (måske SOAP, RPC eller noget tredje)."

Helt enig - jeg tror at det efterhånden er en erkendelse som branchen er kommet til.

Tillad mig at supplere med en ekstra betragtning til de 2.

Jeg tror at valget om kommunikations- /integrationsprotokol nogle gange ikke er bevidst, men bestemmes af udviklingsvæktøj. Dvs min teori er at valget af programmeringsplatform eller off-the-shelf software til tider er det, som bestemmer protokol.

  • 0
  • 0
Michael Rasmussen

"Jeg tror at valget om kommunikations- /integrationsprotokol nogle gange ikke er bevidst, men bestemmes af udviklingsvæktøj"
Og her ligger vel årsagen til den manglende succes/gennemslagskraft for SOA. SOA bør trancendere snævre platforms og værktøjsbegrænsninger, men verden af Danmark i dag er, hvad jeg vil kalde uoplyst enevælde, hvor IT-inkompentente ledelser og politikere er underlagt Microsofts lemmingeeffekt, og blidt navigerer efter Redmonds fyrtårn. Så længe monokulturen hersker, vil vi aldrig se SOA's fulde potentiale, da fundamentet for SOA er diversitet, og valg af det bedste system/platform til det givne problemdomæne.

  • 0
  • 0
Dennis Krøger

Bemærk at jeg skrev "overveje om dit design ikke er broken", der er altid ting der kan gøre at man ikke har andet valg.

Selvfølgelig er det ikke i alle tilfælde, men man kan ret generelt godt sige at der skal overvejes en anden løsning, ved almindelige services, hvis man har konstante minipakker væltende rundt.

Protokoller til (action) spil, og fjernkontrol af f.eks. kirurgiske instrumenter er nogle af de ekstreme tilfælde hvor der ikke er nogen vej udenom.

Og vi er bestemt enige i at man ikke bare skal sige "Hep hey, lad os bruge det første buzzword vi støder på", men til services som skal consumes af et bredt publikum bør man bruge noget som er selvbeskrivende og nemt at implementere, og WSDL/SOAP's måde at beskrive kaldene, gør at de mange sprog/frameworks kan lave dem direkte om til objekter, så de (dem der skal lave klienterne), kan bekymre sig så lidt som muligt om den egentlige protokol.

Dette er selvfølgelig også det der gør at SOAP har en del overhead, men det er (ofte) prisen værd.

  • 0
  • 0
Rasmus Kaae

Jeg er glad for at den generelle opfattelse herinde ikke er at man blot skal anvende SOAP bare fordi man ønsker at understøtte SOA/netcentricitet/osv.

Beslutningen om hvilken protokol, f.eks. RPC, Corba, DCOM, SOAP eller tilsvarende der skal anvendes bør besluttes af teknikkere. Alle de nævnte er til en vis grad standardiserede og kan derfor nemt anvendes af tredjeparts integratorer.

Hvis man binder sig til en SOAP-løsning giver det en række sideeffekter som man måske ikke ønsker, f.eks. kræver det i visse tilfælde at man har en IIS installeret, som så yderligere kræver andre komponenter.

Desuden tror jeg at jeg er enig i Michael Rasmussens indlæg om at mange følger trop med MS fordi udviklingsværktøjerne dikterer bestemte design og arkitekturvalg. Dog tror jeg faktisk at MS's Visual Studio er en af de IDE'er der har bedst understøttelse for SOA via SOAP, da .NET frameworket understøttet det direkte via WSDL-proxygenerering m.v. -- Og heri mener jeg der ligger en fare, da folk så blindt vil anvende SOAP uden at overveje alternativer.

  • 0
  • 0
Dennis Krøger

"Hvis man binder sig til en SOAP-løsning giver det en række sideeffekter som man måske ikke ønsker, f.eks. kræver det i visse tilfælde at man har en IIS installeret, som så yderligere kræver andre komponenter."

Det kræver en webserver eller J2EE server, ja, men på ingen måde at det er IIS.

Der er service backends til både PHP(NuSOAP eller den indbyggede i PHP5), Java (SOAP/Axis/Axis2), C++ C++ (gSoap, Axis

  • 0
  • 0
René Løhde

Tak Michael, Rasmus og Dennis,

Det var lige præcis den disskussion jeg gerne ville have. Jeg sidder til dagligt med en udviklingsplatform - hvor man til tider kan høre en indvending som "nogen gange er det FOR nemt" og at det måske er en direkte konsekevens af det Michael skriver (kan dog ikke se hvorfor det skal udlægges som et isoleret Microsoft problem - det er min opfattelse at andre softwareleverandører skubber meget kraftigere på en SOA platform via SOAP).

  • 0
  • 0
René Løhde

...dette ligger lige i forlængelse af en problemstilling vi ofte diskuterer internt.

Hos Microsoft er der 4 læresætninger for udarbejdelsen af services formuleret af Pat Helland og gjort kendt af Don Box. En af disse er at servicegrænser skal beskrives og opfattes som noget eksplicit.

Tag så f.eks denne klientkode til en tænkt SOAP service:

ServiceProxy proxy = new ServiceProxy();
proxy.Getdata();

Problemet med den kode er at jeg ofte ikke kan se omkostningen. Jeg kan ikke se om det er et lokalt objekt jeg arbejder på eller om jeg laver message passing over 3 verdensdele til 2000 kr pr stk.

Det giver mig den problemstilling at jeg skal veje den forholdsvis nemme implementering mod gennemskuelighed af omkostningen (og iøvrigt også protokolvalg, som er mig implicit givet).

For .net 1.0, 1.1 og 2.0 er det tilfældet. For .net 3.0 og 3.5 er der lavet en smule om på det så der bliver en deklarativ måde at konfigurere klienten på og dermed en metode til at belyse problemstillinger omkring servicegrænser for udvikler, arkitekt og administrator.

  • 0
  • 0
Michael Rasmussen

Jeg vil gerne medgive, at jeg også synes, at SOA/Webservices(WS) ofte kædes sammen med SOAP. Jeg kan dog ikke se, hvorfor man ikke også skulle kunne benytte CORBA, (XML-)RPC eller lignende. Hvad angår .NET (MS Visual Studio), er der også fin integration mellem .NET Remoting og WS. Der findes endog også en hybrid dokumenteret - SOAP/Remoting, men sidst jeg undersøgte det, var det stadigvæk ikke anbefalelsesværdigt i en produktionsløsning (Rene, forholder det sig stadigvæk sådan?).

Jeg har ikke noget at udsætte på MS's implementation af WS, så mit sidste indlæg skal ikke læses som en kritik af MS, men var mere en eksemplificering af status pt. hvor mange med begrænset viden om teknologien ser den som en MS' teknologi. Virkeligen er jo, at det vel med stor ret kan kaldes en standard, der har lige stor udbredelse blandt leverandørerne som webbet i dag, hvorfor jeg gerne vil plædere for, at man på ledelsesniveau hellere skulle fokusere på den optimale løsning - mix af platform, sprog, leverandør og teknologi, da alle væsentlige spillere har en fuld fungerende WS-stak, RPC-stak og CORBA-stak tilgændelig.

QeD: Det væsentlige i dag er en problemorienteret tilgang, og ikke at lave en kompromisløsning med ens nuværende værktøj.

  • 0
  • 0
René Løhde

Hej Michael,

Som jeg læser din kommentar så tror jeg at du tænker på den interne "fejde" der var blandt SOAP folket for et par år siden om man via SOAP section 5 skulle tillade "flertydig arkitektur" for fremsendelse af xml dokumenter. Helt konkret udmyntet i brugen af document/literal eller rpc/encoded. Hvor doc/lit første var en fremsendelse af et xml dokument med mere eller mindre komplekse datatyper, som kan beskrives i et xml schema. Rpc/enc er en arkitektur som et xml dokument hvis "rod" fortæller noget om hvilken metode i servicen som ønskes kaldt og "indholdet" er en parameterliste.

I SOAP gik man væk fra rpc/enc med WS-I.org's første profile - den såkaldte WS-I Basic Profile 1.0.

Så jo, best practice er stadig at man holder sig fra denne. Faktisk faktisk forholder det sig sådan at Visual Studio (jeg ved ikke om dette også eksisterer i andre udviklingsmiljøer) kan konfigurere udviklingen af SOAP services til at være WS-I Basic Profile 1.1 compliant - lige som at man kan angive at en web-app skal være xhtml complient.

  • 0
  • 0
Log ind eller Opret konto for at kommentere