From: Dennis Mister x
Date: Fri, 22 Dec 2006 16:53:41 +0000
To:
Subject: RE: Ang. Viderudvikling

helt enige; en ting der skal realateres til er det 3 princip for SOA, som
jeg netop nævner under de 3 krav til vores SOA. – da det det først er ved at
være skrevet færdigt nu, er det ikke postet i de tekster jeg har sendt; Det
handler om at vores SOA SKAL kunne parse xml filer (er et krav for at være
et rigtigt SOA)

Jeg har skrevet følgende, du kan bare relatere til det i teksten, altså
skrive det er noget der skal laves i fremtiden, så vores program, kan
relatere til andre programmer (eller sagt anderledes, så man kan gemme
resultatet fra produktet via xml):

Her er hvad jeg har skrevet indtil nu, det bliver kortet ned:

“Princip 3: En services udveksler xml beskeder fremfor klasser”

Som tidligere nævnt skal services kun udveksle på forhånd definerede
beskeder som er defineret ud
fra en service kontrakt. En af de mest anvendte service kontrakt typer er
den xml baserede WSDL.

NÃ¥r man designer og implementerer en applikation anvender man klasser som
repræsenter entiteter
i et forretnings specifikt problem (Indstilling, Ejendom, Interessent).
Disse klasser indeholder kun
data. En klasse er både programmeringssprog og platform afhængig. Hvis
services udvekslede
klasser fremfor xml beskeder, ville to forskellige services, der er udviklet
i forskellige sprog og
platforme ikke kunne kommunikere med hinanden. For at kommunikere skal
parterne have en
fællesnævner som de begge forstår, i dette tilfælde er det xml. En SOA
service udstiller datatyperne
som php konverterer xml baseret beskeder som er platform uafhængige. Det er
i kraft
af XML teknologien at SOA services kan opnå platform uafhængighed og
interoperabilitet. XML
beskederne som udveksles mellem service aftager og udbyder kan defineres i
en WSDL fil. Denne
service kontrakt indeholder information om de xml beskeder som servicen skal
bruge. BÃ¥de service
aftageren og udbyderen skal bruge disse xml beskeder til at kommunikere. Det
er derfor meget
vigtigt, især for service aftageren at kontrakten er statisk og ikke ændrer
sig. En service kontrakt
skal tage højde for at beskederne kan ændre sig uden at det påvirker service
aftagerne. Dette vil
tvinge service udvikleren til at implementere muligheden for udvidelser i
besked strukturen.
· Service kontrakten skal være statisk.
· Service kontrakten bør designes med henblik på at services kan udvides.
Udvidelsen skal
ikke have indflydelse på service aftagerne. Dette kan man opnå ved at
versionere service
interfacet.
· Grænsen mellem en privat og tilgængelig data skal styrkes. Servicens
interne data bør
skjules fra service aftageren mens de tilgængelige datatyper bør være
‰immutable‰ (Kan
ikke ændre sig)
· Hvis det er nødvendigt kan man versionere service kontrakten. Denne
fremgangsmetode
bevirker at man ikke bryder kontrakten med eksisterende service aftagere.
“

>From: Marlene Hørfarter
>To: Dennis Mister x
>Subject: Ang. Viderudvikling
>Date: Fri, 22 Dec 2006 17:07:11 +0100
>
>Vi er enige om at jeg skriver om viderudvikling ikke? Det er det samme som
>fremtid…