Som default er en SOAP service jo 100% stateless - det ligger i SOAP definition: Så hvad jeg skriver til dig nu er jo ikke noget man kan gå og reklamere med. Men samtidigt ved jeg, at det har løst problemet hos andre kunder, som jo har efterspurgt præcis samme facilitet du gør – og løsningen er følgende:
Man kan i IceBreak godt route sine SOAP WebSerive request direkte til en given session – enten for at performance optimere, lave load balancing eller bruge session stablilitet.
Dette gøres ved at DU opfinder den session som dit job skal afvikles under, istedet for at lade IceBreak gøre det. En session er givet ved et timestamp incl millisecs. Og den måde man angiver sin session er ved den virtuelle session system folder man giver i URL'en. Eks:
Hvis du har en application – SOAP eller bare et almindeligt program ser det f.eks sådan ud:
Altså protocol + ip adresse el. DNS navn + port + program navn
Ved at indskyde en virtuel session system folder med sit eget session id – har man en privat session / et privat job. Et session-id har format .CCYYMMDDHHMMSSmmmmmm f.eks. .20130102112233987654 denne virtuelle system folder har ingen indhold (i nuværende releases) og har ingen betydning for hives eller application libraries.
Hvis jeg anvender ovenstående session id, ser det sådan ud:
Og man vil altså få sin eget job og egen session for dette request.
Bemærk at IceBreak vil formatere session timestamp til ISO format så ovenstående session hedder internet 2013-01-02-11.22.33.987654 og det fysiske job vil (by default) arve de sidste seks cifre i job-navnet.
For at undgå kollision, samt bypass evt validering af ip-adresser vs. session for de sessions som uddeles af IceBreak selv skal man dog benytte et session id fra år 1. Best practice er at benytte dato 0001-01-01 efterfult af tidspunkt, efterfulgt af 6-cifret løbenummer:
Den algoritme som nu fra klientside tildeler session nummer, kan så være baseret på en given bruger, credentials, SOAP , request typer eller hvad du nu kan finde på.
Re: Webservices, og jobs
Hej Jens;
Som default er en SOAP service jo 100% stateless - det ligger i SOAP definition: Så hvad jeg skriver til dig nu er jo ikke noget man kan gå og reklamere med. Men samtidigt ved jeg, at det har løst problemet hos andre kunder, som jo har efterspurgt præcis samme facilitet du gør – og løsningen er følgende:
Man kan i IceBreak godt route sine SOAP WebSerive request direkte til en given session – enten for at performance optimere, lave load balancing eller bruge session stablilitet.
Dette gøres ved at DU opfinder den session som dit job skal afvikles under, istedet for at lade IceBreak gøre det. En session er givet ved et timestamp incl millisecs. Og den måde man angiver sin session er ved den virtuelle session system folder man giver i URL'en. Eks:
Hvis du har en application – SOAP eller bare et almindeligt program ser det f.eks sådan ud:
http://myibmi:12345/mypgm.aspx
Altså protocol + ip adresse el. DNS navn + port + program navn
Ved at indskyde en virtuel session system folder med sit eget session id – har man en privat session / et privat job. Et session-id har format .CCYYMMDDHHMMSSmmmmmm f.eks. .20130102112233987654 denne virtuelle system folder har ingen indhold (i nuværende releases) og har ingen betydning for hives eller application libraries.
Hvis jeg anvender ovenstående session id, ser det sådan ud:
http://myibmi:12345/.20130102112233987654/mypgm.aspx
Og man vil altså få sin eget job og egen session for dette request.
Bemærk at IceBreak vil formatere session timestamp til ISO format så ovenstående session hedder internet 2013-01-02-11.22.33.987654 og det fysiske job vil (by default) arve de sidste seks cifre i job-navnet.
For at undgå kollision, samt bypass evt validering af ip-adresser vs. session for de sessions som uddeles af IceBreak selv skal man dog benytte et session id fra år 1. Best practice er at benytte dato 0001-01-01 efterfult af tidspunkt, efterfulgt af 6-cifret løbenummer:
http://myibmi:12345/.00010101000000987654/mypgm.aspx
Den algoritme som nu fra klientside tildeler session nummer, kan så være baseret på en given bruger, credentials, SOAP , request typer eller hvad du nu kan finde på.
Best regards,
Niels Liisberg