SOA reflektioner: June 2005 Archives
Efterhånden som jeg får gravet mig dybere ned i SOA finder jeg flere og flere eksempler på at SOAs principper er mere nuanceret end som sådan og nødvendigvis må fortolkes for også at give mening.
Hvis man tager fat i Henrik Hvid Jensens fire principper for serviceorienteret arkitektur består arkitekturen af følgende principper: distribueret; baseret på åbne standarder; procesorienteret og løst koblet (man kan diskutere om disse er tilstrækkelige - Lublinsky har også business driven og stateless invocation som to principper).
Ubetinget af 4 eller 6 principper så er den grundlæggende ide stadig understøtningen af interoperable arkitekturer på tværs af organisationer - her er man nødt til at overholde de standarder og principper igennem noget der ligner en fælles referencemodel.
Men det bliver mere og mere tydeligt at principperne må være op til fortolkning i SOA indenfor organisationers fire mure.
I et interview med Kåre Kjelstrøm fra Silver Bullet redegjorde han for hans tanker omkring "intern" og "ekstern" SOA - hvor den eksterne SOA følger principperne meget rigid er der "room for more slack". I den interne SOA hvor man af performance hensyn kan vælge at sige - "vi kører .NET eller J2EE som vores standard platform".
Microsofts nye Indigo udviklingsplatform kommer til at understøtte noget lignende - i systemkald imellem systemer vil den etablere det mest gunstige kommunikationsform - hvis det andet system også er Microsoft anvendes deres proprietære standard ellers anvendes webservices.
En sådan pragmatisk holdning er nødvendig for at komme i gang med "the learning experience of SOA". Små skridt af gangen. I en survey af webservices.org snakker man på samme måde om Webservices version 1 og version 2 - I version 1 anvendte 35% af adspurgte firmaer webservices til at skabe en standardiseret kommunikationsform imellem heterogene systemer. I version 2 vil fokus være ekstern for organisation og måske også over imod anvendelsen af service repository selvom jeg dog tror at det vil vare lidt endnu (især for private virksomheder).
Til at understøtte hele SOA arkitekturprocessen har Oasis-Open arbejdet på en SOA Reference Model som nu er i working draft. Modellen er udsprunget fra erkendelsen at SOA er anvendt i så mange forskellige kontekster at der er behov for at rydde op og klart definere arkitekturmodellen for SOA. I OASIS' SOA-RM har en SOA flere komponenter som alle er rettet imod arkitekturens centrale element - "services".
Services nedbrydes i fire afgrænsede aspekter nærmere betegnet:
⢠Descriptor
⢠Policy
⢠Contract
⢠Data Model
Derudover er der nogle tværgående anliggender:
⢠Semantics
⢠Discovery, Presence and Availability
SOA-RM udgør et abstrakt rammeværk til at forstå betydningsfulde entiteter og deres indbyrdes relationer i en serviceorienteret miljø og modellen understøtter udviklingen af konforme standarder og specifikationer som understøtter miljøet.
Jeg hilser denne udvikling meget velkommen da det vil kunne hjælpe med at få spredt SOA ud til ikke kun at være defineret af konsulenternes markedsføringsafdelinger men også akademisk anvendeligt med udgangspunkt i forskningsarbejde.
Samtidig vil en uniform model gøre det nemmere for virksomheder i at kortlægge deres roadmap for hvordan de vil tilbyde ekstern eller version 2 SOA.
SOA-RM eller ej så tror jeg at Ronald Schmelzer, senior analytiker ved ZapThink har ret i hans postulat i et Infoworld interview "Architecture is very difficult -- in fact, architecture is mostly a challenge for people, rather than technology [...] So, the SOA Reference Model will go a long way to helping people deal with the human aspects of making architecture work, but it will be up to companies to adopt and implement the reference model in ways that directly impact their businesses."
Hvis man tager fat i Henrik Hvid Jensens fire principper for serviceorienteret arkitektur består arkitekturen af følgende principper: distribueret; baseret på åbne standarder; procesorienteret og løst koblet (man kan diskutere om disse er tilstrækkelige - Lublinsky har også business driven og stateless invocation som to principper).
Ubetinget af 4 eller 6 principper så er den grundlæggende ide stadig understøtningen af interoperable arkitekturer på tværs af organisationer - her er man nødt til at overholde de standarder og principper igennem noget der ligner en fælles referencemodel.
Men det bliver mere og mere tydeligt at principperne må være op til fortolkning i SOA indenfor organisationers fire mure.
I et interview med Kåre Kjelstrøm fra Silver Bullet redegjorde han for hans tanker omkring "intern" og "ekstern" SOA - hvor den eksterne SOA følger principperne meget rigid er der "room for more slack". I den interne SOA hvor man af performance hensyn kan vælge at sige - "vi kører .NET eller J2EE som vores standard platform".
Microsofts nye Indigo udviklingsplatform kommer til at understøtte noget lignende - i systemkald imellem systemer vil den etablere det mest gunstige kommunikationsform - hvis det andet system også er Microsoft anvendes deres proprietære standard ellers anvendes webservices.
En sådan pragmatisk holdning er nødvendig for at komme i gang med "the learning experience of SOA". Små skridt af gangen. I en survey af webservices.org snakker man på samme måde om Webservices version 1 og version 2 - I version 1 anvendte 35% af adspurgte firmaer webservices til at skabe en standardiseret kommunikationsform imellem heterogene systemer. I version 2 vil fokus være ekstern for organisation og måske også over imod anvendelsen af service repository selvom jeg dog tror at det vil vare lidt endnu (især for private virksomheder).
Til at understøtte hele SOA arkitekturprocessen har Oasis-Open arbejdet på en SOA Reference Model som nu er i working draft. Modellen er udsprunget fra erkendelsen at SOA er anvendt i så mange forskellige kontekster at der er behov for at rydde op og klart definere arkitekturmodellen for SOA. I OASIS' SOA-RM har en SOA flere komponenter som alle er rettet imod arkitekturens centrale element - "services".
Services nedbrydes i fire afgrænsede aspekter nærmere betegnet:
⢠Descriptor
⢠Policy
⢠Contract
⢠Data Model
Derudover er der nogle tværgående anliggender:
⢠Semantics
⢠Discovery, Presence and Availability
SOA-RM udgør et abstrakt rammeværk til at forstå betydningsfulde entiteter og deres indbyrdes relationer i en serviceorienteret miljø og modellen understøtter udviklingen af konforme standarder og specifikationer som understøtter miljøet.
Jeg hilser denne udvikling meget velkommen da det vil kunne hjælpe med at få spredt SOA ud til ikke kun at være defineret af konsulenternes markedsføringsafdelinger men også akademisk anvendeligt med udgangspunkt i forskningsarbejde.
Samtidig vil en uniform model gøre det nemmere for virksomheder i at kortlægge deres roadmap for hvordan de vil tilbyde ekstern eller version 2 SOA.
SOA-RM eller ej så tror jeg at Ronald Schmelzer, senior analytiker ved ZapThink har ret i hans postulat i et Infoworld interview "Architecture is very difficult -- in fact, architecture is mostly a challenge for people, rather than technology [...] So, the SOA Reference Model will go a long way to helping people deal with the human aspects of making architecture work, but it will be up to companies to adopt and implement the reference model in ways that directly impact their businesses."
