Suns JAXB 2.1 ger förbättrat stöd för SOA

05 January 2007 // Johan Eltes

Typisk Enterprise Architecture-syn på SOA

När man modellerar tjänsterna för en tjänstebaserad arkitektur (SOA), eftersträvas lös koppling mellan tjänstegränssnitt och IT-stödet. Tjänsterna och den tillhörande informationsmodellen styrs av verksamhetens processer och delas vanligen in efter verksamhetsdomäner. För att säkra integration av verksamhetens processer, baseras tjänsterna på en för verksamhetsdomänen gemensam meddelandemodell (informationsmodell skapad i syfte att beskriva meddelanden).

För realisering i form av web services, transformeras meddelandemodellerna till XML-scheman. Tjänsterna transformeras till gränssnittsdefinitioner enligt web-service standarden WSDL. WSDL-filerna beskriver tjänsternas operationer, medan formatet för in- och ut-meddelanden till operationerna definieras genom hänvisning till gemensamma meddelandemodeller. Det betyder rent praktiskt att WSDL-filer importerar (xsd:import) den eller de XML-scheman som definierar in- och ut-meddelanden för tjänsternas operationer.

Problem med transformering från logisk modell till Java-klasser

I en tidigare kommentar beskrev jag hur detta möjliggörs för Java EE, tack vare generation 2 av JAXB och JAX-WS. I och med JAXB 2.1, kan vi få en ännu tydligare koppling mellan vår SOA modell och den teknik vi använder för att konsumera och realisera tjänsterna (Java EE).

Med JAXB 2.0 var man tvungen att generera Java-modellen som motsvarar en web-service och tillhörande meddelandeformat från grunden för varje tjänst, trots att meddelandeformaten återkommer i många tjänster. Meddelandemodellen är dessutom en struktur i sig, där mer specifika format (t.ex. Kundorder) använder mer generella format (t.ex. Adress) som byggstenar. Detta medförde ett antal nackdelar:

1. Man kan inte återanvända logik för att hantera t.ex. Adress-meddelanden, mellan olika tjänste-implementationer
2. Varje utvecklare av en tjänst måste hantera samtliga inblandade xml-scheman som bygger upp operationernas in- och ut-meddelanden.
3. Byggprocessen för ett web-service-projekt kompliceras av att man för varje tjänst måste definiera bindningsregler för gemensamma meddelandeformat
4. Ansvaret för att generera och paketera Java-versionen av verksamhetens standardiserade meddelandemodell (för SOA) skulle vinna på att centraliseras, på samma sätt som framtagningen av meddelandemodellerna. Stöd saknas dock i JAXB 2.0.

Komponentbaserad ansats med JAXB 2.1

Suns implementation av JAXB 2.1 möjliggör komponentbaserad paketering och återanvändning av genererade Java-modeller. Varje XML-schema i verksamhetens meddelandemodell kan nu transformeras till en Java-komponent i form av ett jar-arkiv. Man förutsätts då börja med grundläggande meddelanden, så som Adress. JAXB 2.1 producerar en Adress-jar från XML-schemat för Adress-meddelandet. När detta väl är gjort ber man JAXB producera en Kundorder-jar från XML-schemat för Kundorder-meddelandet. Istället för att peka ut eller ladda ner xml-scheman för de format Kundorder beror av (d.v.s. Adress), hänvisar man istället direkt till de färdiga Java-modellerna (d.v.s. jar-filen för Adress). Effekten blir att java-klasserna i Kunderorder-jar:en hänvisar till Java-klasserna i Adress-jar:en, istället för att (som tidigare) Kundorder-jar:en har en egen kopia av Adress-klasserna och som eventuellt hamnat i samma Java-paket som Kundorder-klasserna.

På så sätt kan organisationen som är ansvarig meddelandemodellerna också ansvara för java-versionen av dessa modeller. När projekten ska definiera nya tjänster baserade på företagets meddelandemodell, kan de direkt hänvisa till färdiga, centralt tillhandahållna jar-filer, utan att alls behöva hantera xml-scheman.

Länkar

Blog hos Sun med exempel