Denna analys omfattar ett tillvägagångssätt i .NET Web Services för att bygga tjänsteorienterad miljö (SOA) som uppfyller Avantras behov. Teoretiska studier av .NET Web Services har varvats med praktiska exempel i form av små
exempellösningar (prototyper) för att på så sätt få en bättre och djupare
kunskap om .NET Web Services och därmed kunna göra en mer korrekt analys.
4.3.1 Gränssitt och funktionalitet
Genom att definiera en webbtjänsts gränssnitt och detaljer för implementation kan en tjänstebaserad arkitektur byggas med hjälp av Web Services. Olika partners kan då integrera mot lösningen. För att bygga en .Net Web Service måste en modell för gränssittet bestämmas.
Det finns flera modeller för utformning av gränssnitt men utifrån Avantras behov har två huvudsakliga modeller anammats; metodorienterad respektive meddelandeorienterad. Lösningen utformas utifrån dessa med avseende på protokollet, arkitekturen och produkten som ska integrera mot upphandlings‐
systemet. Sannolikt kommer en metodorienterad gränssnittsmodell att användas mest frekvent.
• Metodorienterat gränssnitt.
Gränssnittet består av anropbara operationer med väldefinierade parametrar och beskriver funktionaliteten i tjänsten. I gränssnittet exponeras alltså metoder som applikationer (system) kan dela på.
Klientimplementationer är strikt kopplade mot denna typ av tjänster, vilket medför att alla klienter måste uppdateras om ändringar görs i gränssnittet.
• Meddelandeorienterat gränssnitt.
Gränssnittet består endast av ett fåtal operationer och i extrema fall endast av en operation (ta emot eller skicka meddelande). Genom att använda detta gränssnitt spelar strukturen på meddelandet mindre roll, vilket innebär att klientimplementationer har en lös koppling mot
gränssnittet. Med denna typ av gränssitt är det ofta svårare att förstå hur tjänsten används och vad den utför.
Sedan ska en utvecklingsmetod väljas, det vill säga hur utvecklingsarbete av Web Servicen ska utföras. Det finns två metoder att välja bland; Code‐first respektive Contract‐first. Metoden Contract‐first kommer att användas i
utvecklingen. Denna innebär enligt oss ett bättre sätt att utveckla Web Services jämfört med Code‐first med tanke på Avantras behov, detta diskuteras nedan.
.NET WSCF Web Service Contract‐First
Ett kontrakt (WSDL‐fil) över vilka variabler och funktioner som ska användas i tjänsten skapas med hjälp av XML‐schema (XSD) före fortsatt implementation av tjänsten. En fullständig Web Service struktur genereras sedan utifrån WSDL‐
filen. Sedan implementeras funktionalitet för Web Servicens metoder.
Fig. 4.1 WSCF:s tillvägagångssätt
Fördelar gentemot Code First:
− Färre iterationer om samarbetsparter är överens om gemensam gränssnittsdesign före implementering. Detta minimerar riskerna för missförstånd angående tjänstestrukturen och omfattande ändringar i efterhand.
− Tidsbesparande; efter samarbetsparternas överenskommelse angående kontraktet kan var och en påbörja sin implementation av tjänsten.
− Enkelt att ange entiteters specifika egenskaper (typ, storlek, förekomst m.fl.) och möjliggör valideringen av dessa egenskaper direkt via XML‐
schemat (XSD), vilket innebär mer flexibel design.
− Valideringen ”direkt” mot XML‐schemat, leder till att mindre kod för felhantering behöver implementeras.
− XML‐schemat kan skapas med ett grafiskt verktyg och blir mer åskådligt än ett textbaserad sådant, speciellt för komplexa webbtjänster.
Nackdelar gentemot Code First:
− Kräver närvaro och engagemang av inbladade parter i början för att komma överrens om det slutgiltiga kontraktet.
− I fall omfattande ändringar måste utföras i XML‐schemat, till följd av en större uppdateringar, innebär detta ofta att hela tjänsten genereras på nytt.
− Skapandet av kontraktet är mer komplicerat än med code‐first där kontraktet ofta genereras automatisk av Visual Studio.
Genom att göra Web Servicen anropbar via en virtuell mapp på Microsoft Internet Information Server (IIS) kan integration mot den ske över HTTP och port 80, en så kallad ASP.NET Web Service. Tjänster kan agera på fyra olika sätt utifrån Avantra perspektiv:
• One‐Way, tjänsten tar emot ett meddelande (import).
• Request‐response, tjänsten tar emot ett meddelande och skickar tillbaka ett svar (import eller export).
• Solicit‐response, tjänsten skickar ett meddelande och tar emot ett svar (export eller import).
• Notification, tjänsten skickar ett meddelande (export).
Envägskommunikationen kan inte ge bekräftelse, på lyckat anrop eller
misslyckat (SOAP‐fault), som ofta är nödvändigt för en fungerande tjänstemiljö.
Vilket kommunikationssätt som välj beror på vad tjänsten ska utföra och partners krav. Data som skickas från Avantra kan ha ett format som inte överrensstämmer med mottagarens önskemål och kan då vara i behov av transformation. Meddelandeorienterad gränssnittsdesign kan med fördel användas då strukturen på meddelandet transformas innan det skickas,
eftersom den ger en mer flexibel lösning för att hantera olika format. Data som tas emot av Avantra kan också ha olika format och måste då transformeras.
Metodorienterad gränssnittsdesign kräver att detta sker på sändarens sida.
Meddelandeorienterad gränssnittsdesign ger däremot möjligheten att behandla tranformeringen på ”Avantras‐sida”.
För att hantera tranformering av XML‐dokument används XSL‐stilmallar och stilmallsomvandlaren XSLT. I processen skapas det ett nytt dokument, som inte behöver följa samma DTD eller Schema som ursprungsdokumentet.
Web Servicen måste åtminstone omfatta metoder för att skicka, ta emot men lägga till, ta bort, hämta och ändra kan vara ett annat sätt att organisera metoderna. Skicka och ta emot är meddelandeorienterade medan lägg till, ta bort, hämta och ändra är metodorienterade med varierade kopplingsstyrka beroende på hur gränssnittet är definierat. Ett detaljerat gränssitt där metodens parametrar är definierade för varje element som ska hanteras skapar ett hårt kopplat gränssitt där tjänstens funktionalitet tydligt beskrivs.
Meddelandeorienterat gränssnitt
Skicka
Lös Metodorienterat gränssnitt
Koppling Hård
Lägg till Ta bort Hämta Ändra Ta emot
Lägg till* Ta bort* Hämta* Ändra*
OdetaljeradStrukturDetaljerad
* = Meddelandet har en bestämd detaljerad struktur (parametrar för metodanrop) för att hantera anrop.
Fig. 4.2 Gränssnittsmodeller
4.3.2 Säkerhet och transaktionshantering
Eftersom Web Services körs över HTTP och TCP/IP kan många av
säkerhetskraven för Web Services uppfyllas med protokollen Secure Socket Layer (SSL) och det nyare Internet Protocol Security (IPSec). SSL tillämpas på punkt till punkt meddelanden skickade över HTTP och IPSec möjliggör kryptering av meddelanden i nätverkslagret.
Enligt analysen av Avantras behov finns tre säkerhetsaspekter att ta hänsyn till;
kryptering, autetisering och verifiering. SSL och IPSec uppfyller kraven för kryptering och verifiering, men inte om det finns en tredje part mellan sändaren och mottagaren (inte troligt i Avantras fall). Däremot uppfyller de inte kravet på autentisering. Detta kan dock lösas genom HTTP‐identifikation över SSL på Microsofts webbserver Internet Information Server (IIS) eller genom
autentisering baserad på asymmetrisk kryptering via klientcertifikat.
Rättigheter till autentiserade användare kan hanteras direkt i ASP.NET.
Skulle säkerhetskraven öka ytterliggare eller inte vara applicerbara enligt ovannämnda modell kan WS‐Security användas. Den är en säkerhets‐
specifikation som antagits som standard av OASIS (februari 2006). Den behandlar säkerhetsaspekterna för Web Services; bland annat kryptering av delar eller hela SOAP‐meddelanden och digital signering i SOAP‐huvudet som garanterar verifiering av meddelandet.
Avantra har tillämpat transaktionshantering i databasens lagrade procedurer och i dagsläget täcks behoven, men i framtiden kan andra modeller av
transaktionshantering krävas. Detta kan lösas på olika sätt:
• Utökade databastransaktioner; definieras i databasens lagrade procedurer.
• Manuella transaktioner; implementeras direkt i funktionalitetskoden för Web Servicen.
• Automatiska transaktioner; använder sig COM+ tillsammans med Microsofts Distributed Transaction Coordinator (DTC) och löser transaktionshantering av heterogena datakällor i .NET.
Transaktioner mellan Web Services kan leda till låsningar av datakällorna eftersom de är tillståndslösa och kan ha relativt långa svarstider. Därför lämpar sig Web Services dåligt för transaktioner. Dock kan transaktioner mellan Web Services bli realitet i framtiden med hjälp av den icke standardiserade WS‐
transaction som byggs tillsammans med andra specifikationer för Web Services som WS‐Coordination, WS‐Security och andra applikationsspecifika protokoll till en fungerade transaktionshantering.
För att garantera pålitlig leverans av meddelanden kan standarden WS‐Reliable Messaging, antagen av OASIS som standard 15 november 2004, användas. Den definieras i SOAP‐huvudet, är oberoende av underliggande protokoll och garanterar meddelandens leverans, ordning och att inga dubbelexemplar har distribuerats.
4.3.3 Driftövervakning
Det är möjligt att spåra ett meddelande för att se exakt vilka mellanliggande processer det har gått igenom när det kommer fram till sin slutdestination.
Detta kräver dock en utökning av SOAP‐meddelandets huvud med spårningstaggar som inkluderar information om alla klienter och
mellanliggande processer längs meddelandets väg från klient till server.
Spårningstaggar i SOAP‐meddelandets huvud används för att upprätthålla en lista över mellanliggande processers namn associerade med element för
tidsangivelse. När meddelandet passerar genom varje mellanliggande process, bifogar en meddelandehanterare ett nytt element till spårningstaggarna.
Elementet innehåller namnet på mellanliggande processen tillsammans med datum och tid för när meddelandet kom fram eller skickades vidare.
Elementlistan formar därför ett granskningsspår för meddelandet.