Avella | Blir tjenestene dine for komplekse og rotete? – Bruk heller en tjenesteplattform
17017
post-template-default,single,single-post,postid-17017,single-format-standard,ajax_fade,page_not_loaded,,qode-theme-ver-10.1,wpb-js-composer js-comp-ver-5.0.1,vc_responsive
 

Blir tjenestene dine for komplekse og rotete? – Bruk heller en tjenesteplattform

 

Det finnes flere transportmekanismer og meldingsprotokoller som man må forholde seg til når man lager en tjeneste. Det blir dermed kompleks og kanskje til og med rotete å designe en tjeneste som kan støtte flere forskjellige mekanismer om gangen. Disse syv punktene understøtter hvorfor en god tjenesteplattform kan gjøre jobben lettere for deg. Da kan man heller fokusere på selve funksjonen til tjenesten og ikke på hvordan den skal forholde seg til andre tjenester eller forskjellige settinger.

 

Gjennom en tjenesteplattform kan du enkelt lage tjenester som eier disse 7 egenskapene:

1)     Tjenesten kan settes i gang uansett transportmekanisme som benyttes, enten det er JMS, HTTP eller noe annet. En tjenesteplattform oppfyller dette ved å tilby alle transportmekanismer og støtter på denne måten interoperabilitet langs alle typer av generelle protokoller.

2) Tjenesten kan kjøres uavhengig av destinasjon. Tjenesteplattformen støtter dette ved å levere «location-transparency». Med location-transparency, vil plasseringen av tjenester eller av en fil ikke spille noen rolle for brukeren.

Til ethvert tidspunkt bør en tjeneste ha mulighet for å kunne settes opp eller tas ned og bli flyttet umiddelbart eller eksistere flere steder på samme tid. Samtidig skal den også eksistere på logisk vis under ett tjenestenavn. En tjeneste kan for eksempel operere i London og New York når markedet er åpent i disses regionene, men når London stenger for dagen vil Tokyo-linjen settes opp på nettet.  Prosesser som bruker tjenesten vil referere til den med sitt logiske navn og infrastrukturen til tjenesteplattformen vil gjøre en ruting til den mest aktuelle instansen i det øyeblikket.

3)     Tjenesten trenger ikke ta hensyn til hvilke språk som brukes av tjenester den skal kommunisere med.

Dette oppnås ved å bruke en tjenesteplattform som en universell semantisk tolk. Hver tjeneste kommuniserer med tjenesteplattformen i hvert sitt språk og infrastrukturen vil oversette dette til et globalt fellesspråk som bare infrastrukturen har full oversikt over. Når informasjonen skal sendes videre, vil infrastrukturen oversette den til det riktige språket som mottakeren bruker.

4)     Tjenesten kan lett gjenbrukes med andre tjenester.

Man skal ikke designe en tjeneste slik at den blir bundet til en annen tjeneste på en måte som begrenser dens evne til å kunne gjenbrukes med andre tjenester. En måte for å komme seg bort dette problemet er å lage en sekvens, som er en form for tjenesteorkestrasjon. Det er evnen til å komponere en rekke tjenester til en sammensatt tjeneste for forretningsprosesser eller feilrettingsprosesser. For å kunne formidle meglingen mellom disse tjenestene videre til infrastrukturen, må infrastrukturen ha mekanismer for sammensetting av tjenester og tjenesteorkestrasjon. De fleste tjenesteplattformene leverer et rammeverk for sammensetting av prosesser. Markedet for mikrotjenesteplattformer vokser og vi ser at tradisjonelle tjenesteplattformer har utviklet støtte for mikrotjenester.

5)     Tjenesten trenger ikke ta seg av feilrettelse i prosessnivå.

En tjeneste bør ikke forsøke å selv fikse en prosessfeil da dette vil forverre problemet med dårlig gjenbruk. En bedre løsning kan være å plassere en tjenesteorkestrasjon inne i infrastrukturen og utenfor tjenestekonteksten, og bruke den til å utføre et bredt spekter av feilrettelsesmetoder.

Individuelle tjenestefeil kan håndteres av tjenesteinfrastruktur (f.eks. at Try/Catch blokker av EJB kan delegere gjenopprettelse av transaksjoner til sine J2EE containere, eller at resultater fra datatjenester leveres av informasjonsserveren sin cache når datakilden er utilgjengelig). En tjenesteplattform opererer med et omfang av mange heterogene tjenester og containere over store geografiske områder.

6)     Tjenesten slipper å ta seg av problemstillinger knyttet til QoS/QoP (Quality-of-Service/Quality-of-Protection).

Problemstillingene knyttet til QoS/QoP håndteres av tjenesteplattformen. I en tjenesteplattform blir disse problemstillingene abstrahert bort fra implementasjon av tjenesten slik at at beslutninger på tilgjengelighetsnivå, topologisk virtualisering, lastfordeling, pipelining, kø pålitelighet (utholdenhet) og kardinalitet settes ikke lenger i tjenestedesignerens perspektiv.

Utover hensyn til hastighet, skala og ventetid, strekker QoS seg videre til å omfatte meldingsintegritets og holdbarhets problemstillinger. Her briljerer tjenesteplattformen med sin evne til å levere en pålitelig kø. I tillegg støtter den formidlingen fra synkront til asynkront samspill. For eksempel, om en person stiller deg et spørsmål over telefon i sanntid (synkront) og du er ikke tilgjengelig, kan personen legge igjen en beksjed. Beskjeden settes i kø og lagres i telefonsvareren som (asynkront) vil formidle spørsmålet til deg. Dette er en form for garantert leveranse som formidler synkront til asynkront samspill og det muliggjør et nivå for løskobling ( i både tid og dialog modus), samtidig som den forsikrer riktig leveranse. Slike samspill er ikke alltid en-til-en. Noen ganger er disse egenskapene også nødvendig i en-til-mange eller mange-til-mange kommunikasjon. Et eksempel er publiser-og-abonner kommunikasjon der tjenestene kan slå seg sammen rundt relevant informasjon og motta varslinger som sendes når en hendelse(event) oppstår. Man kan argumentere for at en-til-mange kardinalitet av kommunikasjon er den viktigste driveren for bruk av tjenesteplattform.

Med hensyn til QoP, er det i visse tilfeller mulig å se på en tjenesteplattform som en felles lag for sikkerhetsuttalelse, kontroll og håndheving for all samspill langs en bedrift. Se på det som en festningsmur som omringer tjenestemiljøet for å beskytte det under alle omstendigheter der samspill foretas. Hensynet til sikkerhet utvides videre til autentisering, autorisering, revisjon, kryptering og andre relaterte problemstillinger. Det muliggjør for håndtering av alle disse problemstillingene på en deklarativ måte som følger retningslinjene. Ved å gjøre dette etableres en felles håndhevelsespunkt langs brannmur, DMZ og domenets grenser. Dette frigjør alle tjenester fra de mange hensyn til sikkerhet og bedriften kan stole på at all QoP uttalelser kan implementeres på lik måte på tvers av alle tjenestene i det tidspunktet, og når nye tjenester dukker opp i fremtiden.

7)      Tjenester vil kunne samhandle uten en felles interaksjonsmodell.

Tjenester kommuniserer ved hjelp av en av de fire følgende interaksjonsmodeller: Request/Reply, Pub/Sub, Store-and-Forward (også kalt Fire-and-Forget) og Batch Files. Selv om det en dag blir slik at alt blir fullstendig kompatible med webtjenester, kan det fortsatt oppstå tilfeller der tjenester ikke får kommunisert med hverandre. For eksempel, en tjeneste velger WS-ReliableMessaging (den som støtter store-and-forward og Request/Reply variantene) og en annen tjeneste bruker WS-Eventing (en variant av Pub/Sub). Selv om begge tjenestene er fullstendig kompatible med standardene vil de fortsatt ikke klare å samspille. Dette er fordi den ene vil publisere eventer når informasjon oppdateres og den andre vil sende forespørsel når den trenger informasjon. Det er derfor upraktisk å tenke at alle tjenester kan bli standardisert til å samhandle gjennom en fellesmodell. En tjenesteplattform gjør det mulig å delegere forskjellene mellom interaksjonsmodeller videre til infrastrukturen for megling, uten å måtte skrive tilpasningslogikk. Det blir dermed mulig for de to tjenestene å samspille med hverandre til tross for forskjeller i dialogen, som resulterer i at tjenestene kan gjenbrukes over et større spekter av sammenhenger og er mer smidige til å reagere på nye situasjoner.

Med en tjenesteplattform går det altså mye raskere å skape og implementere en tjeneste. Du slipper å fokusere på noe mer enn hva tjenesten din i hovedsak skal levere. Du sparer også tid for å lage nye tjenester hvis du allerede har en tjeneste fra før med samme funskjon som kan gjenbrukes. Har du lyst å avlaste deg selv og dine tjenester, kan du sette deg mer inn i hvordan en tjenesteplattform kan hjelpe deg. Ta kontakt om du vil diskutere eller trenger hjelp på hvordan en tjenesteplattform kan passe deg eller din bedrift.

avella-portrett-hvit-rose-1_349x500

Kontakt Rose for mer informasjon rundt tjenesteplattformer

Chrisrosemarie Delabahan

Integrasjonskonsulent
Tlf: +47 902 00 826