[Ursäkta det långa inlägget.]
Enligt tekniken "Contract First" skall man beskriva kontraktet på en tjänst innan man implementerar denna. (Detta kallas också top-down.) Rekommendation för att beskriva dessa kontrakt brukar ofta Wsdl och Xsd. (Jag har själv gjort detta ett flertal gånger.) Men min fundering är om det egentligen är det bästa sättet?
Nackdelar
* Wsdl och Xsd är svårt att jobba med om man skall skriva den själv.
* Det finns inga bra produkter än så länge som hjälper utvecklarna på ett effektivt sätt hjälper till med Xsd och Wsdl. Det finns vissa produkter som är duktiga på att göra en viss del, men ingen som klarar av helheten.
* Wsdl och Xsd är hårt knutna till Webbtjänster, vilket inte alltid är bra.
Fördelar
* Är en standard.
* Är textbaserat.
* Flera leverantörer har stöd för att generera kod ifrån Xsd och Wsdl.
En tjänst, alltså en SOA-tjänst, inte en webbtjänst, har inga tekniska krav kopplade till sig. SOA är ett sätt att strukturera en organisations systemlandskap. Hur tjänsten sedan implementeras är en helt annan fråga. De två viktigaste aspekterna vid implementation av en tjänst är: 1) Hur den skall kommunicera 2) I vilken miljö som den skall köras.
Hur skall den kommunicera
Den främsta kommunikationstypen som idag framhålls är webbtjänster. (Detta av flera goda skäl. Men om man likställer SOA och webbtjänster kan man låsa in sig i ett hörn, där man egentligen inte behöver vara.) Men det kan också vara CORBA, COM/DCOM eller någon form av meddelandebaserat system. (Det finns flera andra.)
Kommunikationen brukar också delas upp i synkron respektive asynkron överföring.
I vilken miljö som tjänsten exekveras
Om man bygger webbtjänster med .NET så exekveras webbtjänsten inuti ASP.NET. Men det är inte den enda miljön, eller motorn, som kan användas. Det kan exempelvis vara i någon applikationsserver eller liknande.
Dessa båda saker brukar kallas "Service Bus" och kan på ett sätt efterlikna en hårdvarubus i en dator. Det viktiga här är att se att vi aldrig kommer att få en Service Bus som endast består av en teknik för kommunikation och exekveringsmiljö. Vi bör ha en Service Bus som är mer generell och som ger oss möjligheten att koppla in nya typer.
Hur ser en tjänst ut ifrån detta perspektiv?
För det första skall egentligen inte en tjänst innehålla någon kodning för kommunikationen. Den läggs på utanför själva tjänsten som stubbar. Dessa stubbar kan man skriva själv eller, och som är bäst, få hjälp med det på något sätt. Ett vanligt sätt idag är att använda sig av kodgeneratorer, vilka genererar stubbarna. Om man använder sig av Wsdl och Xsd, tillsammans med .NET, finns det program som skapar dessa stubbar så att det går att anropa tjänsterna med hjälp av webbtjänster. (Det finns liknande system inom Java.)
Kommunikationssättet och exekveringsmiljön påverkar varandra. Viss typ av kommunikation är bättre lämpad i viss exekveringsmiljö. En annan viktig fråga när det gäller exekveringsmiljö är hur typ säkerhet fungerar. Hur för man exempelvis över ett "context" mellan DCOM/COM och en webbtjänst?
Varför kan det vara problem att använda Wsdl och Xsd för definiering av kontraktet?
Wsdl och Xsd använts uteslutande, gäller speciellt Wsdl, för att beskriva webbtjänster i dagsläget. Det innebär att det "generella" språket att beskriva kontrakt tyvärr pekar emot en speciell typ av teknisk implementering.
Vad kan vi göra istället?
Både MDA (Modell Driven Architecture) och "Software Factories" diskuterar att beskriva dessa kontrakt på en ändå mer generell nivå. MDA förordar att man använder UML, medan "Software Factories" lutar sig mer på Mircrosofts Visual Studio Team Systems (DSL - Domain Specific Languages) sätt att beskriva.
Båda dessa system tror jag redan idag har stöd för att generera Wsdl-filer. (Jag har inte kunnat verifiera detta, men tror att det är så.)
Hur skulle det så ut om vi gjorde på det här sättet?
* Vi skulle använda ett grafiskt verktyg för att definiera tjänsterna, dess metoder och meddelanden. Sättet att beskriva datatyperna måste klara av allt som Xsd kan. (Där tror jag att UML har en begränsning. Jag vet inte heller om Microsofts DSL-initiativ har denna funktionalitet?) Beskrivningen av datatyperna måste klara av att hantera olika namespaces och också hanteringen av generella typer, vilka återanvänts på flera ställen.
* Denna grafiska modell skall generera Xsd-filer. Dessa filer skall kunna läggas i biblioteksstrukturer som är möjliga att själv bestämma. Vidare skall de olika Xsd-filerna länkas samman, genom (<xsd:include> och <xsd:import>) på ett bra sätt.
* Wsdl-filerna skall också skapas utifrån den grafiska modellen.
* Både modellen och filerna skall vara synkroniserade med varandra. Det innebär att vare sig man ändrar i modellen eller i någon av filerna skall det omedelbart och automatiskt synkroniseras med varandra.
* Eventuellt skall också kodgenereringen kunna skötas av systemet.
Avslutning
Det här är endast några funderingar som jag har. Jag har inte riktigt tänkt färdigt. Det innebär att jag kommer att använda mig av Xsd och Wsdl tills jag hittar något bättre, vilket jag inte kan se finns idag.
När man diskutera kontrakt hamnar man ofta i den här delen av kontraktet, alltså hur man beskriver det mer formella gränssnittet. Ett kontrakt innehåller mycket mer. Men detta kommer jag att ta upp i ett annat inlägg.
Comments