Blogg

Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på Twitter

Callista medarbetare Johan Eltes

Asynkrona tjänster i fokus för WS-I

// Johan Eltes

WS-I är standardiseringsorganet för interoperabilitet inom Web Services. WS-I driver sitt arbete genom att skapa profiler för användandet av olika webbservice standarder. Det har visat sig att leverantörers implementation av enskilda Webbservice standards inte leder till friktionsfri interoperabilitet. Genom att definiera profiler, begränsar WS-I hur enskilda specifikationer ska tillämpas, för att säkra interoperabilitet. Hittills har WS-I framgångsrikt skapat profiler för att säkra säker interoperabilitet för synkrona webbservices. Nästa version siktar på att säkra förutsättningarna för interoperabilitet av asynkrona webbservices.

WS-I och Enterprise Java

Den första profilen - Basic Profile - var en stor framgång för operabilitet inom synkrona SOAP-baserade tjänster utan “attachments” (binära bilagor). J2EE 1.4 definierar sitt stöd för Web Services i termer av Basic Profile version 1.0. Sedan dess har Basic Profile 1.1 anlänt i sällskap med en Security Profile och en Attachment Profle. Stödet för Web Services i JavaEE 5 integrerar Basic profile 1.1. Callista rapporterade om Basic Profile och interoperabilitet mellan J2EE 1.4 och .Net på Cadec 2005.

Mot asynkrona Web Services

WS-I panerar att släppa nästa version (1.2) av “Basic Profile” före september månads utgång. Den nya profilen blir en påbyggnad av BP 1.1, i syfte att ge klara riktlinjer för användningen av WS-Addressing 1.0 och “attachments” (SOAP 1.1 Bindning for MTOM 1.0). WS-Addressing är viktig, eftersom den definierar förutsättningarna för orkestrering av asynkrona/händelsedrivna processer. En Enterprise Service Bus förknippas ofta just med möjligheten att kunna skapa nya webbservices som integrerar befintliga system som asynkrona händelsekedjor. WS-Addressing standardiserar SOAP-headers för hantering av adresserings- och korreleringsdata som behövs för att asynkrona svar ska kunna hitta tillbaka till den tjänst som ska ta emot svaret (svarsadress) och den processinstans som svaret avser (korrelering).

JMS blir Webbservices?

JMS är en välkänd standard inom Enterprise Java, som låter Java-program hantera asynkron meddelandetrafik utan att programkod binds till specifika meddelandehanteringssystem. Motsvarande standard saknas för Microsoft .Net, som istället pekar ut produkten MSMQ. WS-ReliableMessaging syftar till att etablera en Web Servicebaserad branch-standard för köhanterare. Parallellt med Basic Profile 1.2, pågår arbete med WS-I Reliable Secure Profile i syfte att nå interoperabilitet för säker, asynkron meddelandehantering (baserat på kö-konceptet vi känner från ena halvan av JMS), vilket bl.a. täcker WS-ReliableMessaging. Publish/subscribe-delen av JMS adresseras av WS-Notification. WS-Reliable Messaging har den stora fördelen att det inte introducerar någon ny programmeringsmodell. Man deklarerar helt enkelt en WS-Policy Assertion specifik för WS-Reliable Messaging i WSDL-filen. För programmeraren uppstår ingen konceptuell skillnad - man anropar fortfarande en operation på en tjänst. Beroende på applikationens behov, kan anrop till att API för att markera slutet på en meddelandesekvens, vilket därmed blir undantaget som bekräftar regeln. Till skillnad mot JMS, blir transportformatet interoperabelt. Till skillnad från JMS standardiserar WS-RM enbart aktiviteter på protokoll-nivå - inte leverans till applikationslogik. En WS-RM-implementation behöver därmed utvärderas m.a.p. s.k. garanterad leverans (a’la JMS med persistenta köer och 2PhC). Om man jämför med produkten WebSphereMQ, kan man säga att WS-RM löser samma behov som en s.k. “Channel” som binder samman en remote-kö på sändarens server med en local-kö på mottagarens maskin. WS-ReliableMessaging typ-användningsfall är lättviktig B2B. 1.0 av specifkationen var ett samarbete mellan IBM, Microsoft, BEA och Tibco (2005-02). Det är den versionn som implementeras av dagens applikationsservar (t.ex. Microsoft WCF, IBm WebSphere 6.1 WebService Feature Pack, SAP Netweaver 7.0, Sun Project Glassfish med WSIT). 2007-10 färdigställde Oasis en formell standard med versionsnummer 1.1.

En WS-baserad Enterprise Service Bus?

Det växande intresset för produkter inom området Enterprise Service Bus, kan ses som ett tecken på att organisationer ser minst lika stora värden i asynkrona/händelsedrivna tjänster som i synkrona webbservices. Det har hittills lett till behov av leverantörsspecifika lösningar för meddelandebaserad integration. Blir BP 1.2 lika framgångsrik som sina företrädare, kommer vi nog att få se en förändring i de hittills ganska traditionsbundna produkterna inom applikationsintegration.

Tack för att du läser Callistas blogg.
Hjälp oss att nå ut med information genom att dela nyheter och artiklar i ditt nätverk.

Kommentarer