Service Component Architecture Spec

28 February 2006 // Johan Eltes

Specifikationen “Service Component Architecture” är ännu i version 0.9, men är ändå mödan värd att bevaka. Jag har skrivit en artikel som förhoppningsvis ska väcka din nyfikenhet. SCA definierar framtidens landskap för SOA och leverantörernas produkter är mer än halvägs…

Introduktion till SCA

Ett antal leverantörer har gemensamt arbetat fram en specifikation inom SOA-området. Specifkationen kallas “Service Component Architecture” - eller kort - “SCA”. Specen syftar till att definiera en hög-nivå-modell för realiser tjänster i en SOA. Ansatsen sträcker sig från tillverkning av återanvändbara byggstenar till koncept för att definiera en SOA för en hel verksamhetsdomän. Det är den första specifikationen som lyfter SOA från infrastruktur till dess faktiska värden: en helhet skapad av återanvändbara byggstenar, fristående från beslut om infrastruktur.

Från infrastruktur till funktionell arkitektur

Med SCA flyttas fokus från infrastruktur till funktionell arkitektur. Specen standardiserar en modell för att å ena sidan definiera återanvändbara komponenter - legobitar och å andra sidan en modell för att logiskt binda samman legobitarna (“service components”) till nya legobitar (“composites”), frikopplat från beslut kring kommunikationsteknologier och annan infrastruktur.

Plattformen definierar komponenter på olika nivåer - där en “Composite” kan utgöra en deploy-bar eller en endast internt återanvändbar modul, uppbyggd av andra “composites” och atomära “service components”. Components och Composites på alla nivåer binds samman av logiska länkar (wires). Beslutet om hur en “Wire” ska realiseras, kan fördröjas till slut-paketering i ett “deploy-arkiv”. Genom att varje “composite” inte gör några antaganden om hur eller till vem dess “wire” är bunden, kan en “composite” återanvändas i många “composites”.

[Bild saknas]

Comsposites kan vara realiserade i olika teknologier. Det finns en under-specifikation per realiseringsteknik - så som Java, BPEL, Spring, EJB och C++. I praktiken ska man nog initialt se specen i ljuset av Java-relaterade tekniker och olika XML-standards, även om den vore fullt tänkbar för .Net. Microsoft håller sig än så länge utanför samarbetet.

SCA standardiserar också hur man definierar bindningar mellan “wires” och olika typer av infrastruktur, i form av binsningsspecifkationer. För närvarande finns fastlagda bindningar för WebServices, remote-EJB, JMS och JCA.

Vem står bakom SCA?

Branchens ledande aktörer inom SOA- ovh EAI-plattformar står bakom specifikationen: IBM, BEA, Sun, Iona, SAP, Oracle, Tibco m.fl.Ur leverantörernas perspektiv, ger SCA en möjlighet att integrera moduler skapade i olika leverantörers verktyg med infrastruktur från andra leverantörers infrastruktur (infrastruktur med stöd för att driftsätta SCA-paketerade lösningar).

SCA-specen etablerades i November 2005, i.o.m. introduktionen av version 0.9. Den fanns då att ladda hem från respektive företags hemsida, t.ex. BEA. Sun stod inledningsvis utanför. I Juli 2006 formaliserades arbetet ytterligare, i form av version 0.95. Sun gick med och Service Component Architecture fick ett självständigt liv i form av en Wiki (liksom Callistas dito baserad på Confluence).

Hur arbetar man i praktiken med SCA?

Design mönstret Dependency Injection utgör grundbulten i SCA-specen. Man kan säga att SCA är Spring Dependency Injection för SOA. I praktiken kan Spring + en J2EE-serveranvändas för att realisera och deploya en SOA som är logiskt definierad av tjänster publicerade av återanvändbara “composites”. Det används redan som en hörnsten för SOA-strategin för nästa generations system inom logistik och produktionssyrning hos ett globalt bilföretag.Se Cadec 2006 om SCA samt ExpertZone 2006. Det är troligt att framtida versioner av Spring kommer att ge fullt stöd för SCA. Interface21 - företaget som startats av personerna bakom Spring-ramverken - är ytterligare ett av företagen bakom SCA.

Vilka mervärden ger SCA?

SCA syftar till att leverera ett antal värden:

• Skilja på driftsatt tjänst (subsystem) och återanvändbara komponent-bibliotek (module component) för realisering av (många) tjänster.
• Kunna utveckla en hel SOA-somän utan att binda sig till infrastruktur - inte ens till WebServices. Innan man driftsätter en tjänst måste förstås bindingarna till infrastrukturen definieras, men detta görs separat från den funktionella SOA man definierat med hjälp av SCA.
• Skapa förutsättningar för robust testning och versionering av byggstenarna i en SOA.

Dessa värden kan, vilket bevisats! - uppnås utan att binda sig till SCA-specifikationen. När verktyg kommer, som stödjer SCA-specen, ersätter man Spring-XML på modul- och subsystem-nivå med SCA-xml.Då uppnås ytterligare värden:

• Vi kan utgå från en grafisk modell av en hel SOA-domän när vi utvecklar och förändrar tjänster utgående från katalogiserade komponenter (module components).
• Vi får verktygsstöd för att binda en SOA-lösning till den infrastruktur vi valt för att deploya tjänster inom vår SOA-domänen.
• Verktyget stödjer säkerligen fler språk än Java och BPEL, så som Workflow, regelmotorer, beslutstabeller m.m, där grafiska editorer har ett stort värde. Men oavsett verktyg och “språk”, blir resultatet “composites” som knytas samman logiskt till en funktionell arkitektur.

Samma SOA-domän / system kan deployas i olika verksamheter på olika infrastrukturer. Exempel på infrastrukturer skulle kunna vara olika kombinationer JBI, EJB, WebService / http, ESB / JMS etc.

Vill du veta mera?

Vill du höra mer om våra praktiska erfarenheter kring SCA? Vi kommer gärna och berättar i detalj om olika aspekter av SCA-baserad SOA: Att införa i en organisation, införandetid, Komponent/Service-modellering, Versionering, Infrastruktur-kopplingar (ESB, WebServices etc), Spring-baserad SCA, driftserfarenheter m.m. Det brukar fungera bäst om vi startar med ett möte för att lyssna av er situation och sedan anpassar presentationen / workshopen efter konkreta affärsmål som finns på din agenda.