Synkron och Asynkron kommunikation med Webbtjänster

Påstående: Man kan inte kommunicera fullständigt asynkront och löst kopplat med webbtjänster.

Det finns två sätt att anropa tjänster idag. Det är synkront eller asynkront. Synkront innebär att klienten väntar på svar medan tjänsten utför det som klienten har begärt. I asynkrona anrop skickar klienten sin begäran och fortsätter sedan att göra andra saker medan tjänsten utför det som klienten begärt.

Vissa arkitekter säger att man alltid först skall försöka skriva tjänster som kommunicerar med asynkrona anrop. Går det inte, får man ta till det synkrona alternativet.

En variant på asynkron kommunikation är något som man kallar “Fire-And-Forget” eller “One-Way”, vilket innebär att klienten skickar sitt meddelande till tjänstet och förväntar sig inget svar ifrån den. (Det finns mer avancerade varianter, där tjänsten skickar svar tillbaka via någon form av call-back, men det tar vi en annan gång.) Detta är den optimala sättet att kommunicera mellan tjänster. Skillnaden är att tjänsten som klienten anropar behöver inte vara igång, vilket den måste vara i det första fallet av asynkron kommunikation.

Grafisk beskrivning av de tre kommunikationsvarianterna
Vi använder oss av ett enkelt exempel där vi har en klient som skickar meddelandet SubmitOrder till tjänsten OrderService.

SYNKRONT

Klienten väntar medan OrderService utför den begäran som klienten har skickat till tjänsten.

ASYNKRONT MED WEBBTJÄNST

Klienten skickar samma meddelande till OrderService. I det här fallet skickar också klienten det som “One-Way”, alltså att han inte bryr sig om något svar. När man gör ett sådant anrop till tjänsten får man dock ett svar tillbaka. Det är en HTTP Response som talar om att tjänsten har emottagit meddelandet. Detta gör att OrderService måste vara igång när klienten skickar sitt meddelande.

HELT ASYNKRONA MEDDELANDEN

Detta innebär att klienten skickar sitt meddelande via en kanal som kan hantera att tjänsten kanske inte är igång när meddelandet skickas. Detta gör att klienten inte är lika beroende av tjänsten, som i fallet ovan. Hela arkitekturen blir lösare kopplat, vilket är en viktig princip hos många arkitekturer.

Kanalen, kan vara en köhanterare av något slag, exempelvis MSMQ.

Det här kan göra i sin förlängning att man inte endast kan använda sig av webbtjänsttekniken för att implementera tjänster i en tjänstebaserad arkitektur (SOA). Det finns andra tekniker, även om dessa inte diskuteras lika mycket just nu.

Sammanfattningsvis
I boken Enterprise Integration Patterns beskrivs fyra sätt att kommunicera mellan tjänster. Dessa är:

1. File Transfer
2. Shared Database
3. Remote Procedure Invocation
4. Messaging

De flesta av oss använder antingen Shared Database, vilket egentligen är att man har en stor databas vilka flera applikationer tillsammans använder sig av, eller Remote Procedure Invocation, där man anropar en annan tjänst via ett vanligt anrop med hjälp av COM/DCOM, RMI eller CORBA.

Vid första anblicken tror vi kanske att webbtjänster tillhör den fjärde typen, Messaging, men så är det inte. Det är en variant av Remote Procedure Invocation. (Det är i alla fall min nuvarande åsikt.) En webbtjänst beter sig mer på det viset. Det kanske bland annat av den anledningen som det är svårt att skilja på komponentbaserad arkitektur och SOA, eller varför inte, att skilja på objektorientering och SOA? Det är så liten skillnad mellan dem. Men om man istället börjar tänka hur Messaging fungerar, där man använder fullt asynkron kommunikation, blir det inte lika självklart att tänka Objektorienterat, detta för att vi inte längre använder objekt utan meddelanden.

Comments

[Jonas Ekström]

Rocky Lhotka skrev om synen på WS i http://www.theserverside.net/articles/showarticle.tss?id=IntersectionsObjectsandServices