"Web services" - heretter "webtjenester" - er det store nye innen framstilling av programvare. Det er det bærende elementet i programvarestrategiene til blant andre Microsoft, IBM og Sun, og særlig Microsoft og IBM har gått i spissen for å sørge for standarder slik at Java og .Net konkurrerer som verktøy og plattformer for gjensidig kompatible webtjenester. Den teknologiske ideen er at programvare uttrykkes i form av kodebolker som legges ut på nett, med standard utvekslingsgrensesnitt (Simple Object Access Protocol eller SOAP), standard beskrivelse av funksjonalitet (Web Services Description Language eller WSDL) og standard for oppslag i kataloger (Universal Description, Discovery and Integration eller UDDI), slik at man kan finne fram til det man trenger og trekke dem inn i egne applikasjoner, uten at de behøver å kjøres på en egen maskin. Det er lagt ut slike webtjenester for alt fra valutakonvertering, validering av kredittkort og spesialiserte finanstjenester, til primtallsgeneratorer, astronomiske tabeller og bilutleietjenester. Og det er en stor bevegelse på gang for å ordne systemer fra giganter som Oracle, SAP og IBM, slik at de kan levere og gjøre bruk av webtjenester.
På lang sikt betyr dette at veien til den digitale næringskjeden forenkles. En liten bedrift som vil etablere seg i næringskjeden til en stor, behøver ikke lenger investere penger i spesialiserte løsninger som EDI, eller snekre sammen en spesialisert portal. Det holder å lage egne webtjenester for å håndtere informasjon inn og ut av sitt eget system.
- På kort sikt er det først og fremst snakk om at webtjenester vil gjøre det enklere og rimeligere å integrere alle slags interne applikasjoner i store organisasjoner, tror Craig Stewart, webtjeneste-evangelist for Progress Software der man er opptatt av å bygge en arkitektur som kan holde styr på myriader av webtjenester og sørge for at de utnyttes effektivt og hensiktsmessig.
- Applikasjonene er der. Webtjeneste-tankegangen innebærer at det innføres standardiserte protokoller og metoder for å få dem til å spille sammen, slik at de kan komme enda mer til nytte. Webtjenester betyr ikke at man gjør noe revolusjonerende nytt. Man gjør det samme som før, men fordi det standardiseres og forenkles, kan langt flere gjøre det.
Stewart mener man ikke behøver å velge mellom de to hovedplattformene som er i ferd med å ta form innen utvikling av webtjenester, det vil si Java og .Net.
- Det må skilles mellom utviklingsplattformen for en eller flere spesifikke webtjenester, og rammeverket som skal sørge for effektivt samspill mellom webtjenestene man vil dra praktisk nytte av. Webtjenester er diskrete komponenter som bør håndteres gjennom et underliggende rammeverk, som gjerne kan velges uavhengig av utviklingsplattformen.
Rammeverket som Progress tilbyr, hviler på selskapets arbeid innen meldingsbasert informasjonsutveksling mellom applikasjoner. Det er to hovedprodukter: SonicXQ organiserer arbeidsflyten (XQ står for XML-queuing), mens det underliggende SonicMQ håndterer informasjonsutvekslingen mellom applikasjonene (MQ står for message-queuing).
I denne tankegangen betraktes webtjenester ut fra et dokumentsentrert perspektiv, der hele eller deler av XML-dokumenter sendes fram og tilbake mellom applikasjoner, der de endres, samles, utløser nye dokumenter og så videre. Arbeidsflyten og meldingshåndteringen deler ansvaret for at endringene utføres planmessig, pålitelig og sikkert.
I SonicXQ spiller IBMs utkast til arbeidsflytstandard for webtjenester, Web Services Flow Language eller WSFL, en viktig rolle. En standard med spesiell betydning for bruken av SonicMQ, er Java Connect Architecture eller JCA. Oppgaven til JCA er å formidle informasjon til og fra komponenter som ikke selv er webtjenester. Det betyr at Sonic kan integrere for eksempel SAP og webtjenester, selv om ikke SAP har innebygget støtte for webtjenester.
- Vi tilbyr et underliggende lag for å styre meldinger mellom applikasjoner, og tvinge dem gjennom et lag med arbeidsflytlogikk. Vi mener det er en naturlig måte å håndtere webtjenester på. Vi har den fordelen i forhold til for eksempel veteranen MQSeries fra IBM at vårt er påtenkt fra starten av å fungere mot webtjenester og i et heterogent miljø. Det er vesentlig mer oversiktlig, og installasjon, konfigurasjon og drift er langt enklere og mer effektivt. SonicMQ tilbyr dessuten en integrert håndtering av alle sikkerhetsaspekter i åpne nettverk. IBM løser dette gjennom tilleggsfunksjonalitet som gjør produktet enda tyngre.
Stewart mener det skarpe fokuset i SonicMQ gjør at selv tunge applikasjoner og kompliserte lokale miljøer, kan integreres i løpet av timer, og ikke dager eller uker.
Han avviser at det er proprietær teknologi i ny drakt, fordi nye standarder integreres etter hvert som de oppstår. Han utdyper rammeverkets arkitektur slik:
- SonicXQ er der du legger inn regler for hvordan applikasjonene skal forholde seg til hverandre, altså arbeidsflyt og gjøremål, det du setter deg fore å få gjort gjennom et samspill av webtjenester og eksisterende systemer. SonicMQ er den under liggende transportinfrastrukturen for denne logikken.
SonicMQ har vært på markedet siden mars 2000. Det bygger på en spesifikasjon fra november 1999, kjent som JMS eller Java Message Service. JMS er altså en spesifikasjon, ikke et produkt. IBM har et JMS-grensesnitt som forener MQSeries med JMS. Det vil si at du kan beholde det du har gjort med MQSeries, og så bygge ut den nye integrasjonen mot webtjenester og andre eksterne applikasjoner gjennom SonicMQ.
Stewart oppgir gjerne referanser.
- I det europeiske kjernefysikklaboratoriet CERN brukes SonicMQ til å samle data fra innsamlingsapplikasjoner spredd gjennom hele akseleratoren, og til å sørge for å det samles på korrekt vis. Her håndteres både lokale og globale meldinger. Den franske byggevaregrossisten Lapeyre bruker SonicMQ til å koordinere opplysninger spredt på distribuerte databaser under et felles nettsted. En bestilling til nettstedet utløser en melding som sjekker varehusene i bestillerens lokalmiljø. Tilbakemeldingene koordineres for å gi en så hensiktsmessig beskjed som mulig om hvor de forskjellige varene kan hentes og når. Et eksempel fra Norge er online-aksjemekleren Stocknet der SonicMQ bærer infrastrukturen som henter inn opplysninger fra ulike Internett-baserte tjenester og formidler sikkert og pålitelig til applet-baserte klienter.
Ett alternativ til en meldingsbasert infrastruktur for slike tjenester, er en databasebasert arkitektur. Det er ikke noe godt basis for tjenester spredd over Internett, men kan fungere i spredte interne nettverk, mener Stewart.
Et annet alternativ, spesielt for Internett-orienterte tjenester, er å ty til integrerende applikasjonstjenere som webMethods. Stewart tror at denne modellen også vil stå for fall etter hvert som applikasjonstjenere blir gratisvare, og det blir enda enklere å ordne integreringsbiten gjennom meldinger og webtjenester.
Progress kunngjorde nylig en vesentlig oppgradering av SonicMQ til versjon 4.0. En egenskap ved denne er at det tas høyde for klienter som ikke er permanent tilknyttet et nettverk. Behovet stammet fra spesielt en kunde som ønsket å unngå katastrofer når klientene var midlertidig avskåret fra å kommunisere med et trådløst lokalnett.
SonicXQ er foreløpig i beta og vil slippes kommersielt i første kvartal 2002.
