Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Lars Arne Skår
Is this you? Claim Profile »
1 year ago
in Fire påstander om SOA on Thinking inside a bigger box
Bra du tok bryet med å skrive denne på norsk også - det er mer enn nok av folk her hjemme som også engasjerer seg i dette "fenomenet", "problemet", "løsningen" eller hva man ønsker å kalle det.
Har egentlig ikke så mange kommentarer, annet enn at jeg nok er mer optimistisk enn deg ift. at jeg regner det som sannsynlig at utviklingen på dette vil føre noe bra med seg.
Greit nok at WS-* greiene minner om Corba utviklingen, og dermed også har skapt tette bindinger i praksis, og dermed undergravet håpet/intensjonen med SOA og fokus på løse(re) koplinger.
Det med BPM kan jeg være med på er veldig oppskrytt - minner overraskende mye om håpet vi satte til case-verktøy på begynnelsen av 90-tallet som gjorde at vi måtte fjerne oss enda mer fra det vi egentlig skulle løse til vi endelig kunne løse det.
Men punkt 2 - det å samle integrasjonen til et knutepunkt for å gjøre sammensetning av systemer enklere tror jeg både er viktig og at vi begynner å få konsepter og teknologi som kan fungere. Det tar ikke nødvendigvis bort noe arbeid eller kompleksitet, men det samler det, slik at en kan rette fokus der. Mye tyder på at systemer av systemer blir en viktigere organisasjon av løsninger enn de enkeltvise løsningene osm skal løse sine egne behov. En viktig grunn til dette, er ønske om felles forretningsmessig oppførsel mot ulike typer av bruker, kanaler uavhengig av hvor de kom fra. Det vi tidligere kalte multi-kanal. For å få til det på en bra og riktig måte, så er det beste å faktisk knytte seg til de systemene denne oppførselen styres på framfor å duplisere det.
Greit nok at vi ikke har sett de beste eksempler på dette enda, men jeg mener å ha sett kimen til det der man fokuserer på å få det til. På slutten av 90-tallet var det hot å etablere en middleware man gikk mot - og det fikk man faktiskt til. Så ble det "ødelagt" når internett løsningene kom, og man reimplementerte nye spesifikke løsninger oppå dette igjen, som gjorde at man fikk ny fragmentert og duplisert forretningslogikk spredt over mange løsninger. Her vil jeg regne med og håper det vil skje en ny oppryddingsjobb, som gjør at vi igjen kan få renere løsninger som kjører den samme forretningslogikken et sted. Greit nok at man hevder en har unike behov i ulike kanaler og grensesnitt, men når en faktisk forventer like oppførsel i ulike kanaler, så vil det faktisk være det riktigste å sluse det til samme sted.
Der jeg tror mange SOA-prester har gjort feil og skuffet, er der de har presset på at WS-* er svaret, og brukt det som en intern applikasjonsarkitektur stil. Det er klart det ikke vil gi noen særlig fordeler. En for en særdeles kompleks SW stack å forholde seg til, som egentlig ikke løser noe som helst i en slik setting.
Derimot har jeg tro på at en bevisst segmenter system porteføljen sin til rene løsninger med veldefinerte oppgaver, som en gjerne kan kalle tjenester, og gjør det enkelt å bruke de. Da krever det forvaltning av disse tjenestene, og bevisst fokus på at de brukes konsistent i virksomheten. Med flere brukere av disse tjenestene kan det være behov for systemstøtte for å få rask tilgang til de, og transformasjon mellom ulike kontrakter for å få til fleksibilitet på dette området. Dette bør da ligge utenfor selve applikasjonen (tjenesten), slik at en kan rendyrke logikken der. Mao. helt vanlig abstraksjon, med fokus på å få integrasjon ut av applikasjonen.
Ble litt kommentarer allikevel - ikke til artikkelen i seg selv, den synes jeg er kjempebra. Kun en meningsytring fra en som fortsatt er optimistisk (men er enig med deg at vi har langt igjen...)
Har egentlig ikke så mange kommentarer, annet enn at jeg nok er mer optimistisk enn deg ift. at jeg regner det som sannsynlig at utviklingen på dette vil føre noe bra med seg.
Greit nok at WS-* greiene minner om Corba utviklingen, og dermed også har skapt tette bindinger i praksis, og dermed undergravet håpet/intensjonen med SOA og fokus på løse(re) koplinger.
Det med BPM kan jeg være med på er veldig oppskrytt - minner overraskende mye om håpet vi satte til case-verktøy på begynnelsen av 90-tallet som gjorde at vi måtte fjerne oss enda mer fra det vi egentlig skulle løse til vi endelig kunne løse det.
Men punkt 2 - det å samle integrasjonen til et knutepunkt for å gjøre sammensetning av systemer enklere tror jeg både er viktig og at vi begynner å få konsepter og teknologi som kan fungere. Det tar ikke nødvendigvis bort noe arbeid eller kompleksitet, men det samler det, slik at en kan rette fokus der. Mye tyder på at systemer av systemer blir en viktigere organisasjon av løsninger enn de enkeltvise løsningene osm skal løse sine egne behov. En viktig grunn til dette, er ønske om felles forretningsmessig oppførsel mot ulike typer av bruker, kanaler uavhengig av hvor de kom fra. Det vi tidligere kalte multi-kanal. For å få til det på en bra og riktig måte, så er det beste å faktisk knytte seg til de systemene denne oppførselen styres på framfor å duplisere det.
Greit nok at vi ikke har sett de beste eksempler på dette enda, men jeg mener å ha sett kimen til det der man fokuserer på å få det til. På slutten av 90-tallet var det hot å etablere en middleware man gikk mot - og det fikk man faktiskt til. Så ble det "ødelagt" når internett løsningene kom, og man reimplementerte nye spesifikke løsninger oppå dette igjen, som gjorde at man fikk ny fragmentert og duplisert forretningslogikk spredt over mange løsninger. Her vil jeg regne med og håper det vil skje en ny oppryddingsjobb, som gjør at vi igjen kan få renere løsninger som kjører den samme forretningslogikken et sted. Greit nok at man hevder en har unike behov i ulike kanaler og grensesnitt, men når en faktisk forventer like oppførsel i ulike kanaler, så vil det faktisk være det riktigste å sluse det til samme sted.
Der jeg tror mange SOA-prester har gjort feil og skuffet, er der de har presset på at WS-* er svaret, og brukt det som en intern applikasjonsarkitektur stil. Det er klart det ikke vil gi noen særlig fordeler. En for en særdeles kompleks SW stack å forholde seg til, som egentlig ikke løser noe som helst i en slik setting.
Derimot har jeg tro på at en bevisst segmenter system porteføljen sin til rene løsninger med veldefinerte oppgaver, som en gjerne kan kalle tjenester, og gjør det enkelt å bruke de. Da krever det forvaltning av disse tjenestene, og bevisst fokus på at de brukes konsistent i virksomheten. Med flere brukere av disse tjenestene kan det være behov for systemstøtte for å få rask tilgang til de, og transformasjon mellom ulike kontrakter for å få til fleksibilitet på dette området. Dette bør da ligge utenfor selve applikasjonen (tjenesten), slik at en kan rendyrke logikken der. Mao. helt vanlig abstraksjon, med fokus på å få integrasjon ut av applikasjonen.
Ble litt kommentarer allikevel - ikke til artikkelen i seg selv, den synes jeg er kjempebra. Kun en meningsytring fra en som fortsatt er optimistisk (men er enig med deg at vi har langt igjen...)
1 year ago
in Four bold claims about SOA on Thinking inside a bigger box
I think you hit the spot about popular claims. In addition, myself and others throw in a claim that this SOA-fad also put an emphasis on semantic interoperability as well as the technical interoperability; i.e. we often times get into an argument "what is a good service". A similar claim was given with OO-fad ("What is good object"). For some reason still does not get that wide attention. Maybe because the technical stuff is easier to disagree/agree on.
Of these claim, I have to admit it is the 2. one I have the most faith in at the moment. The WS-* gang went into the same trap as the Corba-gang did with to much focus on solving all possible techical interoperability challenges which in turn created tight coupling in practice which again violated the originial intention. The WS-thing was so much easier to deal with when it was only XML and HTTP. Maybe that is the reason why REST is getting so popular these days.
Many smart people claim that REST is insufficient for "real stuff"; in particular vendors of tools supporting SOAP and the other WS-* stuff. However, we are clearly observing that the use of REST tend to be much more dynamic and agile in "real life" than these "ultra-flexible" and "ultra-powerful" standardized WS-stuff.
The usefulness of the BPM stuff is greatly overrated to say the least - at least at the current state. In many ways it resembles the state of the case tools we had in the 80s and the 90s. Still, I like to live in the hope that one day this could be really useful; the fact that BPEL is being used and getting some support - even outside of the vendors providing tools for BPEL show some promise. BPEL doesn't solve everything, but being fairly simple and "low-key" is in my mind a good thing. Maybe it should be kept that way.
Getting back to claim nr. 2, I am in much favour of the view that a service bus is no more than a "galvanic divider" between a service provider and a service requestor, and in some circumstances this gives value; i.e. when you want loose coupling between systems. The reason why there is issues with this claim, is all the other stuff vendors put in the ESB. They create ambiguity in where to put stuff, and also introduces yet another operational complexity which again also gives even more deployment complexity which is hard enough as it is.
My faith lies on the open source movement and that the vendors will react constructively to what is usually called light weight ESB which again may lead to more practically oriented ESBs. Similar things did happen to J2EE/Java EE with Spring and some important adjustments to the EJB spec in EJB 3.0. While not being perfect yet - the movement seems to be healthy.
- My reaction to this very insightful blog. Thanks!
Of these claim, I have to admit it is the 2. one I have the most faith in at the moment. The WS-* gang went into the same trap as the Corba-gang did with to much focus on solving all possible techical interoperability challenges which in turn created tight coupling in practice which again violated the originial intention. The WS-thing was so much easier to deal with when it was only XML and HTTP. Maybe that is the reason why REST is getting so popular these days.
Many smart people claim that REST is insufficient for "real stuff"; in particular vendors of tools supporting SOAP and the other WS-* stuff. However, we are clearly observing that the use of REST tend to be much more dynamic and agile in "real life" than these "ultra-flexible" and "ultra-powerful" standardized WS-stuff.
The usefulness of the BPM stuff is greatly overrated to say the least - at least at the current state. In many ways it resembles the state of the case tools we had in the 80s and the 90s. Still, I like to live in the hope that one day this could be really useful; the fact that BPEL is being used and getting some support - even outside of the vendors providing tools for BPEL show some promise. BPEL doesn't solve everything, but being fairly simple and "low-key" is in my mind a good thing. Maybe it should be kept that way.
Getting back to claim nr. 2, I am in much favour of the view that a service bus is no more than a "galvanic divider" between a service provider and a service requestor, and in some circumstances this gives value; i.e. when you want loose coupling between systems. The reason why there is issues with this claim, is all the other stuff vendors put in the ESB. They create ambiguity in where to put stuff, and also introduces yet another operational complexity which again also gives even more deployment complexity which is hard enough as it is.
My faith lies on the open source movement and that the vendors will react constructively to what is usually called light weight ESB which again may lead to more practically oriented ESBs. Similar things did happen to J2EE/Java EE with Spring and some important adjustments to the EJB spec in EJB 3.0. While not being perfect yet - the movement seems to be healthy.
- My reaction to this very insightful blog. Thanks!
