SOA als dood paard bij Geek and poke. Erg leuk.
(Hat tip Jan L.)
Posts tonen met het label SOA. Alle posts tonen
Posts tonen met het label SOA. Alle posts tonen
donderdag 17 december 2009
dinsdag 29 september 2009
Rik in de cloud
Rik Laurens meent: SOA en WOA komen elkaar tegen in de cloud, en hebben elkaar nodig. het is moeilijk het hiermee oneens te zijn, maar ik ga het denk ik toch proberen.
Maar eens een nachtje over slapen.
Maar eens een nachtje over slapen.
maandag 19 januari 2009
SOA is dood, deel 4
De Stem der Rede zei:
"Ironick zegt: "It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces".
Een mooie volzin, maar ik denk dat maar weinigen snappen wat hier wordt bedoeld. Dat het in de de IT moet gaan over "services", dat snappen we. Dat deze services WOA compliant in plaats van SOA compliant moeten zijn, dat kunnen software architecten - behalve elkaar - maar moeilijk uitleggen."
En vervolgens wordt mij om een uitleg gevraagd.
Het probleem zit m hier in het begrip "services". Moet het in de IT om de "services" gaan? Sja, dat hangt af wat er mee bedoeld wordt. In SOA in ieder geval wel: daar zijn de services doorgaans het uitgangspunt voor het ontwerp.
Je wordt verondersteld na te denken over welke services er zouden moeten zijn, en als je die eenmaal hebt bedacht, ze volgens de regelen der kunst(autonomie, stateless, etc, etc) te ontwerpen. Maar hoe bedenk je eigenlijk die services? Dat blijft schimmig. De beste manier is om dat te doen vanuit een objectmodel, waarbij de interfaces tussen de objecten worden getransformeerd naar services. Dit kan, en het werkt, alleen doet bijna niemand het.
In plaats daarvan zit men services uit de duim te zuigen, of ze te ontwerpen op basis van wat op dat moment nodig lijkt vanuit een of ander proces, of (nog erger) op basis van wat een bestaande legacy-component biedt. Het gevolg zijn services die ontworpen zijn vanuit de huidige behoefte of zelfs de behoefte (en de architectuur) van het verleden. De kans dat dit in de toekomst andersoortig gebruik vergemakkelijkt (de belofte van SOA tenslotte) is nihil.
Als dit klinkt als een slecht verhaal: dat kan kloppen, want het is een slecht verhaal.
Bij de WOA (of de ROA, dat is wat mij betreft hetzelfde) ontwerp je vanuit resources, zeg maar de gegevensstructuur. Ook als er geen expliciet object- of datamodel wordt gemaakt, moet je als je RESTful werkt een resource-structuur hebben. En het aardige is dat je daarbij weliswaar heel veel fout kunt doen, maar dat er vrijwel altijd toch een bruikbare structuur ontstaat, waarop de resource-oriented services makkelijk te ontwerpen zijn.
En die resource-oriented services zijn veel makkelijker te gebruiken op een manier die niet is voorzien, juist omdat ze zo simpel zijn: een resource kan op een aantal manieren informatie ter beschikking stellen, je kunt nieuwe informatie erin stoppen, je kunt een nieuwe resource van een bepaald type maken en vullen, en je kunt een resource verwijderen. Dat is het wel zo'n beetje.
Makkelijk te begrijpen, en makkelijk te hergebruiken, aangenomen dat de resource-definitie en -structuur ergens op slaat.
Korte samenvatting: de SOA route vereist teveel kennis en strategie van de IT-experts. Als je een goed model maakt en dat model op de geode manier vertaald in services, gaat het goed. Maar dat doet men dus niet.
De WOA-route is veel meer fool-proof. Daar moet men echt heel erg zijn best doen om er helemaal onbruikbare services uit te laten rollen.
Er zijn nog een paar andere voordelen van WOA/ROA, maar het door Ironick genoemde argument komt op het bovenstaande neer.
"Ironick zegt: "It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces".
Een mooie volzin, maar ik denk dat maar weinigen snappen wat hier wordt bedoeld. Dat het in de de IT moet gaan over "services", dat snappen we. Dat deze services WOA compliant in plaats van SOA compliant moeten zijn, dat kunnen software architecten - behalve elkaar - maar moeilijk uitleggen."
En vervolgens wordt mij om een uitleg gevraagd.
Het probleem zit m hier in het begrip "services". Moet het in de IT om de "services" gaan? Sja, dat hangt af wat er mee bedoeld wordt. In SOA in ieder geval wel: daar zijn de services doorgaans het uitgangspunt voor het ontwerp.
Je wordt verondersteld na te denken over welke services er zouden moeten zijn, en als je die eenmaal hebt bedacht, ze volgens de regelen der kunst(autonomie, stateless, etc, etc) te ontwerpen. Maar hoe bedenk je eigenlijk die services? Dat blijft schimmig. De beste manier is om dat te doen vanuit een objectmodel, waarbij de interfaces tussen de objecten worden getransformeerd naar services. Dit kan, en het werkt, alleen doet bijna niemand het.
In plaats daarvan zit men services uit de duim te zuigen, of ze te ontwerpen op basis van wat op dat moment nodig lijkt vanuit een of ander proces, of (nog erger) op basis van wat een bestaande legacy-component biedt. Het gevolg zijn services die ontworpen zijn vanuit de huidige behoefte of zelfs de behoefte (en de architectuur) van het verleden. De kans dat dit in de toekomst andersoortig gebruik vergemakkelijkt (de belofte van SOA tenslotte) is nihil.
Als dit klinkt als een slecht verhaal: dat kan kloppen, want het is een slecht verhaal.
Bij de WOA (of de ROA, dat is wat mij betreft hetzelfde) ontwerp je vanuit resources, zeg maar de gegevensstructuur. Ook als er geen expliciet object- of datamodel wordt gemaakt, moet je als je RESTful werkt een resource-structuur hebben. En het aardige is dat je daarbij weliswaar heel veel fout kunt doen, maar dat er vrijwel altijd toch een bruikbare structuur ontstaat, waarop de resource-oriented services makkelijk te ontwerpen zijn.
En die resource-oriented services zijn veel makkelijker te gebruiken op een manier die niet is voorzien, juist omdat ze zo simpel zijn: een resource kan op een aantal manieren informatie ter beschikking stellen, je kunt nieuwe informatie erin stoppen, je kunt een nieuwe resource van een bepaald type maken en vullen, en je kunt een resource verwijderen. Dat is het wel zo'n beetje.
Makkelijk te begrijpen, en makkelijk te hergebruiken, aangenomen dat de resource-definitie en -structuur ergens op slaat.
Korte samenvatting: de SOA route vereist teveel kennis en strategie van de IT-experts. Als je een goed model maakt en dat model op de geode manier vertaald in services, gaat het goed. Maar dat doet men dus niet.
De WOA-route is veel meer fool-proof. Daar moet men echt heel erg zijn best doen om er helemaal onbruikbare services uit te laten rollen.
Er zijn nog een paar andere voordelen van WOA/ROA, maar het door Ironick genoemde argument komt op het bovenstaande neer.
zaterdag 10 januari 2009
SOA is dood, deel 2
Stefan Tilkov geeft zijn mening.
Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.
En ik ben het met hem eens, maar dat zal geen verrassing zijn.
Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.
En ik ben het met hem eens, maar dat zal geen verrassing zijn.
donderdag 8 januari 2009
SOA is dood
per 1 januari j.l., volgens Anne Thomas Manes. Ik ben het er wel zo'n beetje mee eens, maar die slotconclusie: het gaat om "services" is mij veel te vaag. Daar schieten we niks mee op.
En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.
Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.
En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.
Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.
vrijdag 28 november 2008
Creatieve vernietiging
Voorpublicatie:
De Oostenrijks-Amerikaanse econoom Joseph Schumpeter heeft het begrip "creative destruction" geïntroduceerd. Dat hield in dat in een goed functionerende markteconomie steeds aan kapitaalvernietiging wordt gedaan, doordat bestaande bedrijven ter ziele gaan. Maar ze worden vervangen door nieuwe bedrijven die beter, sneller, efficiënter, goedkoper kunnen werken. Voor de bedrijven die verdwijnen is dat natuurlijk rampzalig, maar voor de samenleving als geheel is het juist goed: er treedt innovatie op, de productiviteit stijgt, en de welvaart neemt toe.
De neiging om bestaande bedrijven overeind te houden is dan ook weliswaar begrijpelijk, en voor de direct betrokkenen (eigenaars, werknemers, leveranciers) voordelig, maar op de wat langere duur desastreus. Immers, middelen die gestoken hadden kunnen worden in nieuwe welvaartsverhogende technieken en bedrijven, vloeien nu naar oude bedrijven die op den duur toch het loodje zullen leggen, en hoe dan ook minder produktief zijn dan de nieuwe bedrijven zouden zijn geweest.
Ik moet wel eens aan die "creative destruction" denken als ik deelneem aan de discussies over Service Oriented Architectures (SOA) en legacy integratie. Vaak wordt gezegd dat het mogelijk is om de investeringen in bestaande IT-systemen (de zogenaamde "legacy") te behouden, en toch die systemen op een flexibele wijze en via het web te kunnen gebruiken. Om dat te kunnen bereiken moet men dan een SOA inrichten, en daarbij een Enterprise Service Bus inrichten.
In de praktijk komt hier meestal weinig van terecht. Die SOA en ESB blijken erg ingewikkeld, en bovendien duur. En de voordelen van die "ontsluiting" van de legacy vallen vaak ook tegen, omdat die legacy zich helemaal niet goed als service laat ontsluiten, tenzij nog grotere investeringen worden gedaan.
En nu komen SaaS en cloud computing (ik zal het hierna op één hoop gooien onder de term "SaaS") om de hoek kijken. SaaS zet het business-model zoals dat tot nog toe in de IT opgeld deed op zijn kop. Je betaalt niet meer van te voren (voor een licentie of voor de bouw van maatwerk), maar voor het gebruik: per transactie, per gebruiker per maand, per opgeslagen MB. Standaardfunctionaliteit, afgerekend op gebruik. “Functionaliteit uit de muur”, zogezegd.
De voordelen zijn gigantisch: minder risico (want geen voorinvesteringen), meer mogelijkheden om van systeem of leverancier te veranderen, en vooral: lagere kosten.
Om deze voordelen te boeken moet je wel wat gangbare ideeën over IT overboord zetten. De kracht van SaaS zit in de standaardisatie. Je gaat dezelfde functionaliteit gebruiken als de buurman of concurrent die hetzelfde SaaS-systeem gebruikt. Voor gebruikers die nog leven met de illusie dat hun IT-systeem uniek is en een “strategisch voordeel” oplevert, is dat een forse stap. Aanpassen en customizen van SaaS kan meestal wel, maar is onverstandig. Het is toch weer een voorinvestering.
Ik hoor wel eens de tegenwerping: “Dan ben ik de greep op mijn IT kwijt!” Ja, dat is zo. Als je een blok aan je been kwijt bent, ben je de greep op dat blok kwijt.
Het is wel verstandig om te zorgen dat je niet met huid en haar aan de SaaS-leverancier bent overgeleverd. Dat kan door het maken van een model (een goed object- of datamodel is meestal voldoende) van de informatie die “uitbesteed” wordt. Dat model wordt geprojecteerd op het model van de leverancier, en door zo te werken is het mogelijk om betrekkelijk makkelijk gegevens te converteren, te up- en te downloaden, en dus ook van leverancier te wisselen.
En wat je vooral ook niet moet gaan proberen is de “integratie” van legacy “integreren” met SaaS. Natuurlijk, dat kan wel eens nodig zijn, maar je steeds moet heel goed kijken naar de alternatieven: gewoon niet integreren en los naast elkaar laten staan, of het legacy-systeem zelf ook vervangen door een SaaS-toepassing.
Want SaaS zal, denk ik, leiden tot de “creative destruction” van veel van de bestaande IT-systemen. Ze zullen worden vervangen door het gebruik van SaaS, wat veel goedkoper is, geen risico vormt, nauwelijks investeringen vergt, en de bedrijven niet meer vastklinkt aan enorme IT-systemen en de bijbehorende staf. Dat zal niet in één klap gaan. Sommige systemen zijn nog niet te vervangen, en sommige systemen misschien wel nooit.
Maar je moet wel bereid zijn om die “creative destruction” te laten gebeuren, en niet water in de wijn te doen door bestaande systemen nodeloos en tegen hoge kosten te integreren, en daarmee hun leven te verlengen. Want de concurrent die de radicale keuze maakt, heeft een groot kostenvoordeel, en dat zal op de markt te merken zijn.
De Oostenrijks-Amerikaanse econoom Joseph Schumpeter heeft het begrip "creative destruction" geïntroduceerd. Dat hield in dat in een goed functionerende markteconomie steeds aan kapitaalvernietiging wordt gedaan, doordat bestaande bedrijven ter ziele gaan. Maar ze worden vervangen door nieuwe bedrijven die beter, sneller, efficiënter, goedkoper kunnen werken. Voor de bedrijven die verdwijnen is dat natuurlijk rampzalig, maar voor de samenleving als geheel is het juist goed: er treedt innovatie op, de productiviteit stijgt, en de welvaart neemt toe.
De neiging om bestaande bedrijven overeind te houden is dan ook weliswaar begrijpelijk, en voor de direct betrokkenen (eigenaars, werknemers, leveranciers) voordelig, maar op de wat langere duur desastreus. Immers, middelen die gestoken hadden kunnen worden in nieuwe welvaartsverhogende technieken en bedrijven, vloeien nu naar oude bedrijven die op den duur toch het loodje zullen leggen, en hoe dan ook minder produktief zijn dan de nieuwe bedrijven zouden zijn geweest.
Ik moet wel eens aan die "creative destruction" denken als ik deelneem aan de discussies over Service Oriented Architectures (SOA) en legacy integratie. Vaak wordt gezegd dat het mogelijk is om de investeringen in bestaande IT-systemen (de zogenaamde "legacy") te behouden, en toch die systemen op een flexibele wijze en via het web te kunnen gebruiken. Om dat te kunnen bereiken moet men dan een SOA inrichten, en daarbij een Enterprise Service Bus inrichten.
In de praktijk komt hier meestal weinig van terecht. Die SOA en ESB blijken erg ingewikkeld, en bovendien duur. En de voordelen van die "ontsluiting" van de legacy vallen vaak ook tegen, omdat die legacy zich helemaal niet goed als service laat ontsluiten, tenzij nog grotere investeringen worden gedaan.
En nu komen SaaS en cloud computing (ik zal het hierna op één hoop gooien onder de term "SaaS") om de hoek kijken. SaaS zet het business-model zoals dat tot nog toe in de IT opgeld deed op zijn kop. Je betaalt niet meer van te voren (voor een licentie of voor de bouw van maatwerk), maar voor het gebruik: per transactie, per gebruiker per maand, per opgeslagen MB. Standaardfunctionaliteit, afgerekend op gebruik. “Functionaliteit uit de muur”, zogezegd.
De voordelen zijn gigantisch: minder risico (want geen voorinvesteringen), meer mogelijkheden om van systeem of leverancier te veranderen, en vooral: lagere kosten.
Om deze voordelen te boeken moet je wel wat gangbare ideeën over IT overboord zetten. De kracht van SaaS zit in de standaardisatie. Je gaat dezelfde functionaliteit gebruiken als de buurman of concurrent die hetzelfde SaaS-systeem gebruikt. Voor gebruikers die nog leven met de illusie dat hun IT-systeem uniek is en een “strategisch voordeel” oplevert, is dat een forse stap. Aanpassen en customizen van SaaS kan meestal wel, maar is onverstandig. Het is toch weer een voorinvestering.
Ik hoor wel eens de tegenwerping: “Dan ben ik de greep op mijn IT kwijt!” Ja, dat is zo. Als je een blok aan je been kwijt bent, ben je de greep op dat blok kwijt.
Het is wel verstandig om te zorgen dat je niet met huid en haar aan de SaaS-leverancier bent overgeleverd. Dat kan door het maken van een model (een goed object- of datamodel is meestal voldoende) van de informatie die “uitbesteed” wordt. Dat model wordt geprojecteerd op het model van de leverancier, en door zo te werken is het mogelijk om betrekkelijk makkelijk gegevens te converteren, te up- en te downloaden, en dus ook van leverancier te wisselen.
En wat je vooral ook niet moet gaan proberen is de “integratie” van legacy “integreren” met SaaS. Natuurlijk, dat kan wel eens nodig zijn, maar je steeds moet heel goed kijken naar de alternatieven: gewoon niet integreren en los naast elkaar laten staan, of het legacy-systeem zelf ook vervangen door een SaaS-toepassing.
Want SaaS zal, denk ik, leiden tot de “creative destruction” van veel van de bestaande IT-systemen. Ze zullen worden vervangen door het gebruik van SaaS, wat veel goedkoper is, geen risico vormt, nauwelijks investeringen vergt, en de bedrijven niet meer vastklinkt aan enorme IT-systemen en de bijbehorende staf. Dat zal niet in één klap gaan. Sommige systemen zijn nog niet te vervangen, en sommige systemen misschien wel nooit.
Maar je moet wel bereid zijn om die “creative destruction” te laten gebeuren, en niet water in de wijn te doen door bestaande systemen nodeloos en tegen hoge kosten te integreren, en daarmee hun leven te verlengen. Want de concurrent die de radicale keuze maakt, heeft een groot kostenvoordeel, en dat zal op de markt te merken zijn.
vrijdag 21 november 2008
SOA humor van Gartner
Lachen met Gartner. In ieder geval Frank Kenney heeft blijkbaar ook zijn vraagtekens bij de gangbare SOA.
maandag 29 september 2008
SOA: hoe in te voeren? (2)
Rik schrijft:
"ESB gedreven SOA". Bestaat er dan ook zoiets als "niet ESB gedreven SOA"? Volgens mij niet. Zelfs in een volledig geharmoniseerde en gestandardiseerde wereld zul je altijd berichten moeten routeren, gegarandeerd moeten transporteren en moeten orkesteren. Of zie jij een alternatief?
Ja, ik zie wel een alternatief.
Natuurlijk, dat routeren, transporteren, enzovoort is nodig. Maar is het nodig dat allemaal te integreren in één tool, namelijk de ESB? Die is duur om aan te schaffen, duur om te implementeren, en bovendien proprietary, wat in feite betekent dat het bedrijf in kwestie zich min of meer uitlevert aan de vendor.
Bovendien zijn heel veel van die "luxe" functionaliteiten van een ESB helemaal niet zo hard nodig, en worden ze zelden gebruikt.
Door dit alles worden die ESB-implementaties noodzakelijkerwijs company-brede projecten, en zoals we allemaal weten: die mislukken, zeker als ze niet 100% nodig zijn. En dat zijn die ESB-projecten niet, omdat er altijd een plan B is: een beetje halfwas invoeren, en de rest naar de toekomst schuiven. En plan C is: installeren, roepen dat je het gebruikt, maar in werkelijkheid gewoon de ouwe trouwe messagebroker blijven gebruiken.
Ik zie zeker twee alternatieven.
1. gebruik een mean&lean "ESB" voor de routering etc van het berichtenverkeer, en gebruik daarvan de functionaliteit op een dusdanige wijze dat je kunt switchen naar een ander tool. Een manier om dat te doen, is het gebruik van meer dan één ESB, maar dat stuit uiteraard nog wel eens op investeringsgrenzen.
2. gebruik een REST-route, en ga naar een ROA-architectuur. Dat kan ook, daar is nauwelijks extra tooling voor nodig, en kan incrementeel worden gedaan. Maar het sluit (in ieder geval op het eerste gezicht) veel minder goed aan bij de bestaande architectuur, en bovendien weten systeemarchitecten e.d. nit hoe ze dit moeten aanpakken.
Een extra argument voor deze alternatieve routes is dat de ver-SaaS-ing of ver-cloud-ing van de functionaliteit eraan komt, en dan zit een zware proprietary ESB ontzettend in de weg, zowel technisch als budgettair.
Niet doen dus, het zijn dinosaurussen.
"ESB gedreven SOA". Bestaat er dan ook zoiets als "niet ESB gedreven SOA"? Volgens mij niet. Zelfs in een volledig geharmoniseerde en gestandardiseerde wereld zul je altijd berichten moeten routeren, gegarandeerd moeten transporteren en moeten orkesteren. Of zie jij een alternatief?
Ja, ik zie wel een alternatief.
Natuurlijk, dat routeren, transporteren, enzovoort is nodig. Maar is het nodig dat allemaal te integreren in één tool, namelijk de ESB? Die is duur om aan te schaffen, duur om te implementeren, en bovendien proprietary, wat in feite betekent dat het bedrijf in kwestie zich min of meer uitlevert aan de vendor.
Bovendien zijn heel veel van die "luxe" functionaliteiten van een ESB helemaal niet zo hard nodig, en worden ze zelden gebruikt.
Door dit alles worden die ESB-implementaties noodzakelijkerwijs company-brede projecten, en zoals we allemaal weten: die mislukken, zeker als ze niet 100% nodig zijn. En dat zijn die ESB-projecten niet, omdat er altijd een plan B is: een beetje halfwas invoeren, en de rest naar de toekomst schuiven. En plan C is: installeren, roepen dat je het gebruikt, maar in werkelijkheid gewoon de ouwe trouwe messagebroker blijven gebruiken.
Ik zie zeker twee alternatieven.
1. gebruik een mean&lean "ESB" voor de routering etc van het berichtenverkeer, en gebruik daarvan de functionaliteit op een dusdanige wijze dat je kunt switchen naar een ander tool. Een manier om dat te doen, is het gebruik van meer dan één ESB, maar dat stuit uiteraard nog wel eens op investeringsgrenzen.
2. gebruik een REST-route, en ga naar een ROA-architectuur. Dat kan ook, daar is nauwelijks extra tooling voor nodig, en kan incrementeel worden gedaan. Maar het sluit (in ieder geval op het eerste gezicht) veel minder goed aan bij de bestaande architectuur, en bovendien weten systeemarchitecten e.d. nit hoe ze dit moeten aanpakken.
Een extra argument voor deze alternatieve routes is dat de ver-SaaS-ing of ver-cloud-ing van de functionaliteit eraan komt, en dan zit een zware proprietary ESB ontzettend in de weg, zowel technisch als budgettair.
Niet doen dus, het zijn dinosaurussen.
vrijdag 26 september 2008
SOA: hoe in te voeren?
Jonathan Mack op InfoQ, over hoe moeilijk het is om SOA in te voeren.
"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."
Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.
Conclusie: SOA, althans ESB gedreven SOA, werkt niet.
Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.
"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:
- Enterprise (top-down) SOA approach, which is an extremely high - risk approach with an initial price tag of a several million dollars. In addition, based on the size and complexity, such project can virtually never be accurately estimated.
- Grassroots (bottom-up) SOA approach - implementing elements of SOA (both services and infrastructure) as parts of existing business-driven IT undertaking. This approach typically does not succeed. On one hand, the scope of resulting services is limited to the specific business problem and might not be applicable (or even wrong) for the rest of enterprise. On another hand, the time and expense required to build the SOA layer can detract from other business needs of a project."
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."
Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.
Conclusie: SOA, althans ESB gedreven SOA, werkt niet.
Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.
vrijdag 4 juli 2008
Ik rest mijn case
In de zgn. REST-SOA-discussie lopen allerlei vragen door elkaar heen: hoe makkelijk moet een protocol zijn? hoe erg is het om ingewikkelde tools, zoals ESBs, nodig te hebben? heb je bijvoorbeeld transaction awareness nodig? enzovoort.
Dat zijn allemaal interessante en ook relevante vragen, maar ik denk dat het toch vooral om iets anders gaat, namelijk de manier waarop je objecten (en daarmee semantische modellen) kunt gebruiken op het Web.
Toen zo'n 20 jaar geleden OO doorbrak, werd hoog opgegeven van de voordelen: je maakte een model in objecten van het relevante domein, je implementeerde dat in een daartoe geëigende omgeving, en het werkte. Schaalbaarheid, onderhoudbaarheid, en wat niet al waren je deel.
En dat kon dankzij het feit dat goed ontworpen objecten een unieke identiteit hadden en vindbaar waren op een unieke lokatie, ze stelden functionaliteit beschikbaar via een interface, en de interne implementatie en gegevens waren afgeschermd van de buitenwereld. Objecten waren eigenlijk zelfstandige entiteiten die elkaar kennen en met elkaar samenwerken.
Natuurlijk bleek de werkelijkheid wat prozaïscher, en kon er erg veel misgaan. Maar desondanks: als eea goed werd aangepakt, konden de beloften worden ingelost. Althans: binnen de run-time omgeving van een OO-omgeving, bijvoorbeeld een SmallTalk-image. En dus: eigenlijk slechts binnen het geheugen van een applicatie en zolangs als die applicatie loopt.
Persistentie en distributie verstoorden dus de OO-droom, en maakten het nodig om ingewikkelde oplosssinngen te bedenken, waarmee verzekerd werd dat objecten bewaard en geditribueerd konden worden, en wel op een "transparante" wijze. En dus werd er heel wat afgemapt.
Het persistentie-probleem is min of meer opgelost. Er kwamen OO-databases die het applicatiegeheugen en de "echte" database naadloos ("transparant", jazeker) in elkaar over lieten lopen. Erg mooi, en vrijwel niemand gebruikte het. Maar ook de wat meer aardse oplossing via een ORM (object relational mapping) bleek na wat vijven en zessen goed werkend te krijgen.
Het distributie-probleem bleek persistenter. :) Hoe moest de "ruimte" van objecten in één applicatie op één machine worden uitgebreid naar andere ruimtes van andere applicaties op andere machines? Met andere woorden: hoe maken we van al die ruimtes één grote ruimte?
De meest voor de hand liggende oplossingsrichting was: maak bovenop het netwerk een protocol wat ervoor zorgt dat objecten war dan ook elkaar kunnen kennen en direct boodschappen sturen. Java RMI is van deze route een voorbeeld.
Dat werkte, althans tot op zekere hoogte. Binnen een closely-knitted LAN was het netwerk stabiel genoeg om van het netwerk te kunnen abstraheren. Maar daarbuiten bleek dat een fictie: het netwerk was niet stabiel genoeg, en dan kun je het ook niet transparant maken. Bovendien waren de RMI-objecten niet echt persistent, omdat ze in feite afhankelijk waren van de applicatie waarbinnen ze bestonden. En tenslotte was de bovenop het netwerk vereiste laag dusdanig ingewikkeld dat het nooit een algemene standaard kon worden. En dat is ook niet gebeurd: RMI kun je alleen binnen de Java-architectuur gebruiken, en die is niet universeel.
Men kon er niet onderuit: het was niet mogelijk om een werkend object-netwerk te maken volledig geabstraheerd van het netwerk. Dus werd het begrip "component" (opnieuw) ingevoerd. Componenten waren entiteiten die op het netwerk draaiden, en als zodanig bekend waren, en via een functioneel interface aangeroepen konden worden.
Maar hoe verhielden de componenten zich tot de objecten?
Een eerste schot was: laat elk object, althans elk zelfstandig domeinobject, een component zijn. Maar er zijn verschrikkelijk veel domeinobjecten. Die allemaal een echte zelfstandige component maken zou veel te veel resources vergen. Immers, de functionaliteit die nodig is om iets een zelfstandige, vindbare, persistente eintiteit op een netwerk (een component dus) te maken, is fors.Dus moest er een oplossing worden bedacht waarin de object-componenten weliswaar algemeen bekend en bereikbaar waren, maar voor de standaard-component functionaliteit gebruik maakten van een soort component voedingsbodem.
De J2EE-EntityBeans waren een poging in deze richting, maar al ras bleek dat zelfs in deze aanpak veel te veel componenten ontstonden om een acceptabele performance te halen. Bovendien konden J2EE-componenten alleen goed met J2EE-componenten praten, dus van een universele ruimte was sowieso geen sprake. En vergelijkbare nadelen golden voor andere pogingen in deze richting zoals COM/DCOM.
Goed, objecten konden dus niet allemaal componenten worden. Dan maar een hybride benadering: we hebben componenten, en daarbinnen leven objecten. En we gaan een standaard ontwikkelen volgens welke componenten met elkaar, in via die route gedistribueerde objecten met elkaar, kunnen praten. En dat niet gebonden aan één talomgeving (zoals bij RMI). Dat was Corba.
Ingewikkeld? Ja, en ook nog eens slechts een standaard, nog geen implementatie. En je had er meestal dure en in ieder geval moeilijk te begrijpen tools voor nodig.
Een andere variant was: laten we het niet te ingewikkeld maken. We zien de componenten gewoon als objecten (ze hebben tenslotte al een unieke lokatie, en een interface met mooie functies, en we proberen zo'n beetje de OO-ontwerp principes voor het ontwerp van die componenten te gebruiken. Daar is weinig op tegen, en als er goede standaarden zijn of komen voor de communicatie tussen de componenten, dan heeft dit een goede kans van slagen. O ja, en heel belangrijk: we noemen het anders, dan lijkt het nieuw.
Ziedaar SOA, en dankzij XML, SOAP en de WS-* standaarden is het inderdaad een behoorlijk succes. En dankzij het Web en HTTP is de ruimte van componenten nu ook universeel.
Maar het lost het oorspronkelijke probleem niet op. Want SOA-services of -componenten zijn geen domeinobjecten, al lijken ze er een beetje op. Eigenlijk zijn we weer terug bij af: we hebben componenten (services) die elkaar kunnen vinden en met elkaar kunnen praten. Objecten bestaan wel, maar zitten binnenin de componenten. En als ee object een boodschap wil sturen aan een object in een andere component, moet eerst worden uitgezocht waar het doelobject zich eigenlijk bevindt, moet de boodschap vervolgens worden vertaald naar een serviceaanroep, moet daarbij worden aangegeven voor welk object de boodschap eigenlijk is bedoeld, en kan daarna de service-aanroep worden gedaan. En aan de andere kant moet de booschap dan weer worden uitgepakt en ontcijferd, en worden doorgestuurd naar het doelobject. Het kan wel, maar het is erg omslachtig. (Al is dat bij gebruik van MDD-technieken midner bezwaarlijk.)
Stand van zaken: we hebben eindelijk een universele ruimte, maar alleen voor componenten. Die gebruiken om echte objecten direct aan elkaar te hangen is niet gelukt, vanwege gebrek aan eenvoud, gebrek aan standaardisatie, en gebrek aan persistentie.
En toen kwam REST.
De resources van REST vormen een universele ruimte, ze zijn (uiteraard) persistent, ze zijn vindbaar en uniek dankzij de URI, het is een bestaande en zeer wijdverbreide standaard (HTTP in feite), en hij is bewezen makkelijk te gebruiken: het hele Web is erop gebaseerd.
Zouden objecten dan te mappen zijn op HTTP-resources?
Op het eerste gezicht is de mapping lastiger dan op RPC-style componenten. Objecten hebben een unieke identificatie ne locatie nodig, en dat biedt de resource inderdaad dankzij de URI. Maar niet elke via een URI te identificeren resource is een echt object, sommige zijn een "representation" van een object, in OO-termen een returnwaarde van een method.
En de REST-methods passen ook niet zonder meer op de methods in een objectmodel. Immers, REST kent slechts een beperkt aantal methods (GET, PUT, POST, DELETE zijn relevant in dit verband). De eerste drie hebben een heel strikte betekenis, en de consequentie is dat extra informatie (parameters in een method van een object) in de URI wordt gestopt. En methods die niet kunnen worden gezien als een GET, PUT of DELETE moeten via POST worden "getruct".
Vanuit OO ziet het er dus op het eerste gezicht niet zo heel goed uit. Maar als je wat beter kijkt, lijkt dat erg mee te vallen. De object-methods uit een goed ontworpen OO-domeinmodel blijken vrijwel alle zonder veel problemen te kunnen worden vertaald naar HTTP-methods.
Maar dan nog steeds: het wringt. HTTP-resources zijn brokken informatie die aan elkaar zij gerelateerd, met verscheidene representaties. Het zijn geen objecten die potentieel een zeer specifiek hebben. Resources hebben juist zoveel mogelijk een standaard-interface.
De claim van REST-voorstanders is dat dat standaard-interface juist een voordeel is. Doordat bijvoorbeeld de betekenis van GET is gedefineerd als: een GET mag een resource niet wijzigen, kunnen HTTP-servers GET-resultaten cachen. En door de simpele method + URI structuur zouden hergerbuikers makkelijker in staat zijn te snappen wat er gebeurt dan als ze bv een WSDL-file moeten lezen voor een SOA-service. Bij REST is de structuur van de resources en de informatie binnen de resources (te verkrijgen als representatie) primair.
In OO is dat van oudsher anders: daar is het functionele interface primair, en de informatie is juist geëncapsuleerd. Althans: volgens de OO-puristen. Als je kijkt naar een goed domeinmodel, dan blijkt dat veel meer een "semantic web" achtig ding te zijn, waarbij het interface helemaal niet zo'n leidende rol speelt.
(Voor de duidelijkheid: voor OO-toepassingen op een ander nivo dan de implementatie van domeinmodellen ligt dat anders, maar die worden ook niet geraakt door deze problematiek.)
En dus is het verschil met de REST/resource-oriented denkwijze helemaal niet zo groot als het op het eerste gezicht lijkt. En het voordeel van REST, namelijk dat je een universele ruimte met dingen (resources, objecten) krijgt, met unieke locaties, met de mogelijkheid daar via een standaard protocol boodschappen aan te sturen, en dat zonder dat je last hebt van het begrip component, dat voordeel is immens.
Is REST dus de toekomst? Ja, ik denk het wel. Maar we moeten nog wel uitzoeken hoe goed die mapping van OO op REST nou echt werkt, en ik denk dat er toch soort REST-standaard bovenop HTTP (bij via een nadere uitwerking van POST) nodig blijkt. Ook al is dat tegen het zere been van de REST-puristen.
Betekent dit dat "gewone SOA" ten dode is opgeschreven? Dat weet ik niet zo zeker. Voor "semantic web" achtige webservices is REST de eerste keus, maar er zijn ook webservices die andere eisen stellen. In de beruchte WS-* stack zitten een aantal zaken (bijvoorbeeld op het gebied van reliability en security) die wat lastig zijn vorm te geven in een REST-context. Het zou kunnen dat we die veel minder vaak nodig hebben dat we nu denken, maar of dat echt waar is moet nog maar blijken.
Maar er zijn zeker een hoop SOA/SOAP-etc interfaces die makkelijk via REST zouden kunnen werken, en ik denk dat we REST-facades bovenop SOA-interfaces gaan zien. Dat zal de migratie ook makkelijker maken.
Dat zijn allemaal interessante en ook relevante vragen, maar ik denk dat het toch vooral om iets anders gaat, namelijk de manier waarop je objecten (en daarmee semantische modellen) kunt gebruiken op het Web.
Toen zo'n 20 jaar geleden OO doorbrak, werd hoog opgegeven van de voordelen: je maakte een model in objecten van het relevante domein, je implementeerde dat in een daartoe geëigende omgeving, en het werkte. Schaalbaarheid, onderhoudbaarheid, en wat niet al waren je deel.
En dat kon dankzij het feit dat goed ontworpen objecten een unieke identiteit hadden en vindbaar waren op een unieke lokatie, ze stelden functionaliteit beschikbaar via een interface, en de interne implementatie en gegevens waren afgeschermd van de buitenwereld. Objecten waren eigenlijk zelfstandige entiteiten die elkaar kennen en met elkaar samenwerken.
Natuurlijk bleek de werkelijkheid wat prozaïscher, en kon er erg veel misgaan. Maar desondanks: als eea goed werd aangepakt, konden de beloften worden ingelost. Althans: binnen de run-time omgeving van een OO-omgeving, bijvoorbeeld een SmallTalk-image. En dus: eigenlijk slechts binnen het geheugen van een applicatie en zolangs als die applicatie loopt.
Persistentie en distributie verstoorden dus de OO-droom, en maakten het nodig om ingewikkelde oplosssinngen te bedenken, waarmee verzekerd werd dat objecten bewaard en geditribueerd konden worden, en wel op een "transparante" wijze. En dus werd er heel wat afgemapt.
Het persistentie-probleem is min of meer opgelost. Er kwamen OO-databases die het applicatiegeheugen en de "echte" database naadloos ("transparant", jazeker) in elkaar over lieten lopen. Erg mooi, en vrijwel niemand gebruikte het. Maar ook de wat meer aardse oplossing via een ORM (object relational mapping) bleek na wat vijven en zessen goed werkend te krijgen.
Het distributie-probleem bleek persistenter. :) Hoe moest de "ruimte" van objecten in één applicatie op één machine worden uitgebreid naar andere ruimtes van andere applicaties op andere machines? Met andere woorden: hoe maken we van al die ruimtes één grote ruimte?
De meest voor de hand liggende oplossingsrichting was: maak bovenop het netwerk een protocol wat ervoor zorgt dat objecten war dan ook elkaar kunnen kennen en direct boodschappen sturen. Java RMI is van deze route een voorbeeld.
Dat werkte, althans tot op zekere hoogte. Binnen een closely-knitted LAN was het netwerk stabiel genoeg om van het netwerk te kunnen abstraheren. Maar daarbuiten bleek dat een fictie: het netwerk was niet stabiel genoeg, en dan kun je het ook niet transparant maken. Bovendien waren de RMI-objecten niet echt persistent, omdat ze in feite afhankelijk waren van de applicatie waarbinnen ze bestonden. En tenslotte was de bovenop het netwerk vereiste laag dusdanig ingewikkeld dat het nooit een algemene standaard kon worden. En dat is ook niet gebeurd: RMI kun je alleen binnen de Java-architectuur gebruiken, en die is niet universeel.
Men kon er niet onderuit: het was niet mogelijk om een werkend object-netwerk te maken volledig geabstraheerd van het netwerk. Dus werd het begrip "component" (opnieuw) ingevoerd. Componenten waren entiteiten die op het netwerk draaiden, en als zodanig bekend waren, en via een functioneel interface aangeroepen konden worden.
Maar hoe verhielden de componenten zich tot de objecten?
Een eerste schot was: laat elk object, althans elk zelfstandig domeinobject, een component zijn. Maar er zijn verschrikkelijk veel domeinobjecten. Die allemaal een echte zelfstandige component maken zou veel te veel resources vergen. Immers, de functionaliteit die nodig is om iets een zelfstandige, vindbare, persistente eintiteit op een netwerk (een component dus) te maken, is fors.Dus moest er een oplossing worden bedacht waarin de object-componenten weliswaar algemeen bekend en bereikbaar waren, maar voor de standaard-component functionaliteit gebruik maakten van een soort component voedingsbodem.
De J2EE-EntityBeans waren een poging in deze richting, maar al ras bleek dat zelfs in deze aanpak veel te veel componenten ontstonden om een acceptabele performance te halen. Bovendien konden J2EE-componenten alleen goed met J2EE-componenten praten, dus van een universele ruimte was sowieso geen sprake. En vergelijkbare nadelen golden voor andere pogingen in deze richting zoals COM/DCOM.
Goed, objecten konden dus niet allemaal componenten worden. Dan maar een hybride benadering: we hebben componenten, en daarbinnen leven objecten. En we gaan een standaard ontwikkelen volgens welke componenten met elkaar, in via die route gedistribueerde objecten met elkaar, kunnen praten. En dat niet gebonden aan één talomgeving (zoals bij RMI). Dat was Corba.
Ingewikkeld? Ja, en ook nog eens slechts een standaard, nog geen implementatie. En je had er meestal dure en in ieder geval moeilijk te begrijpen tools voor nodig.
Een andere variant was: laten we het niet te ingewikkeld maken. We zien de componenten gewoon als objecten (ze hebben tenslotte al een unieke lokatie, en een interface met mooie functies, en we proberen zo'n beetje de OO-ontwerp principes voor het ontwerp van die componenten te gebruiken. Daar is weinig op tegen, en als er goede standaarden zijn of komen voor de communicatie tussen de componenten, dan heeft dit een goede kans van slagen. O ja, en heel belangrijk: we noemen het anders, dan lijkt het nieuw.
Ziedaar SOA, en dankzij XML, SOAP en de WS-* standaarden is het inderdaad een behoorlijk succes. En dankzij het Web en HTTP is de ruimte van componenten nu ook universeel.
Maar het lost het oorspronkelijke probleem niet op. Want SOA-services of -componenten zijn geen domeinobjecten, al lijken ze er een beetje op. Eigenlijk zijn we weer terug bij af: we hebben componenten (services) die elkaar kunnen vinden en met elkaar kunnen praten. Objecten bestaan wel, maar zitten binnenin de componenten. En als ee object een boodschap wil sturen aan een object in een andere component, moet eerst worden uitgezocht waar het doelobject zich eigenlijk bevindt, moet de boodschap vervolgens worden vertaald naar een serviceaanroep, moet daarbij worden aangegeven voor welk object de boodschap eigenlijk is bedoeld, en kan daarna de service-aanroep worden gedaan. En aan de andere kant moet de booschap dan weer worden uitgepakt en ontcijferd, en worden doorgestuurd naar het doelobject. Het kan wel, maar het is erg omslachtig. (Al is dat bij gebruik van MDD-technieken midner bezwaarlijk.)
Stand van zaken: we hebben eindelijk een universele ruimte, maar alleen voor componenten. Die gebruiken om echte objecten direct aan elkaar te hangen is niet gelukt, vanwege gebrek aan eenvoud, gebrek aan standaardisatie, en gebrek aan persistentie.
En toen kwam REST.
De resources van REST vormen een universele ruimte, ze zijn (uiteraard) persistent, ze zijn vindbaar en uniek dankzij de URI, het is een bestaande en zeer wijdverbreide standaard (HTTP in feite), en hij is bewezen makkelijk te gebruiken: het hele Web is erop gebaseerd.
Zouden objecten dan te mappen zijn op HTTP-resources?
Op het eerste gezicht is de mapping lastiger dan op RPC-style componenten. Objecten hebben een unieke identificatie ne locatie nodig, en dat biedt de resource inderdaad dankzij de URI. Maar niet elke via een URI te identificeren resource is een echt object, sommige zijn een "representation" van een object, in OO-termen een returnwaarde van een method.
En de REST-methods passen ook niet zonder meer op de methods in een objectmodel. Immers, REST kent slechts een beperkt aantal methods (GET, PUT, POST, DELETE zijn relevant in dit verband). De eerste drie hebben een heel strikte betekenis, en de consequentie is dat extra informatie (parameters in een method van een object) in de URI wordt gestopt. En methods die niet kunnen worden gezien als een GET, PUT of DELETE moeten via POST worden "getruct".
Vanuit OO ziet het er dus op het eerste gezicht niet zo heel goed uit. Maar als je wat beter kijkt, lijkt dat erg mee te vallen. De object-methods uit een goed ontworpen OO-domeinmodel blijken vrijwel alle zonder veel problemen te kunnen worden vertaald naar HTTP-methods.
Maar dan nog steeds: het wringt. HTTP-resources zijn brokken informatie die aan elkaar zij gerelateerd, met verscheidene representaties. Het zijn geen objecten die potentieel een zeer specifiek hebben. Resources hebben juist zoveel mogelijk een standaard-interface.
De claim van REST-voorstanders is dat dat standaard-interface juist een voordeel is. Doordat bijvoorbeeld de betekenis van GET is gedefineerd als: een GET mag een resource niet wijzigen, kunnen HTTP-servers GET-resultaten cachen. En door de simpele method + URI structuur zouden hergerbuikers makkelijker in staat zijn te snappen wat er gebeurt dan als ze bv een WSDL-file moeten lezen voor een SOA-service. Bij REST is de structuur van de resources en de informatie binnen de resources (te verkrijgen als representatie) primair.
In OO is dat van oudsher anders: daar is het functionele interface primair, en de informatie is juist geëncapsuleerd. Althans: volgens de OO-puristen. Als je kijkt naar een goed domeinmodel, dan blijkt dat veel meer een "semantic web" achtig ding te zijn, waarbij het interface helemaal niet zo'n leidende rol speelt.
(Voor de duidelijkheid: voor OO-toepassingen op een ander nivo dan de implementatie van domeinmodellen ligt dat anders, maar die worden ook niet geraakt door deze problematiek.)
En dus is het verschil met de REST/resource-oriented denkwijze helemaal niet zo groot als het op het eerste gezicht lijkt. En het voordeel van REST, namelijk dat je een universele ruimte met dingen (resources, objecten) krijgt, met unieke locaties, met de mogelijkheid daar via een standaard protocol boodschappen aan te sturen, en dat zonder dat je last hebt van het begrip component, dat voordeel is immens.
Is REST dus de toekomst? Ja, ik denk het wel. Maar we moeten nog wel uitzoeken hoe goed die mapping van OO op REST nou echt werkt, en ik denk dat er toch soort REST-standaard bovenop HTTP (bij via een nadere uitwerking van POST) nodig blijkt. Ook al is dat tegen het zere been van de REST-puristen.
Betekent dit dat "gewone SOA" ten dode is opgeschreven? Dat weet ik niet zo zeker. Voor "semantic web" achtige webservices is REST de eerste keus, maar er zijn ook webservices die andere eisen stellen. In de beruchte WS-* stack zitten een aantal zaken (bijvoorbeeld op het gebied van reliability en security) die wat lastig zijn vorm te geven in een REST-context. Het zou kunnen dat we die veel minder vaak nodig hebben dat we nu denken, maar of dat echt waar is moet nog maar blijken.
Maar er zijn zeker een hoop SOA/SOAP-etc interfaces die makkelijk via REST zouden kunnen werken, en ik denk dat we REST-facades bovenop SOA-interfaces gaan zien. Dat zal de migratie ook makkelijker maken.
vrijdag 21 maart 2008
JaBoWS
Nick Malik is tegen JaBoWS: Just another Bunch of WebServices. Leuke post:
"Tools + existing processes = JaBOWS"
Ik betwijfel of ik zijn enthousiasme voor Enterprise SOA helemaa kan delen, maar hier heeft ie wel gelijk in.
"Tools + existing processes = JaBOWS"
Ik betwijfel of ik zijn enthousiasme voor Enterprise SOA helemaa kan delen, maar hier heeft ie wel gelijk in.
Tilkov over REST
Aardig stuk van Stefan Tilkov op InfoQ, met een weerlegging van gangbare argumenten waarom REST niet goed bruikbaar zou zijn voor business services.
Vooral het stukje over transacties en REST is raak, wat mij betreft (punt 6). Tilkov zegt in essentie: inderdaad, met REST is het nauwelijks mogelijk over verscheidene REST services een atomaire transactie te maken. Met WS-AT etc kan dat in theorie wel, maar dan zijn die webservices wel erg strak gekoppeld, en het is waarschijnlijk organisatorisch niet mogelijk, laat staan wenselijk. (Atomaire transacties over grenzen van bedrijven heen? Hoezo loose coupling?)
Het is eigenlijk gewoon slecht design.
Vooral het stukje over transacties en REST is raak, wat mij betreft (punt 6). Tilkov zegt in essentie: inderdaad, met REST is het nauwelijks mogelijk over verscheidene REST services een atomaire transactie te maken. Met WS-AT etc kan dat in theorie wel, maar dan zijn die webservices wel erg strak gekoppeld, en het is waarschijnlijk organisatorisch niet mogelijk, laat staan wenselijk. (Atomaire transacties over grenzen van bedrijven heen? Hoezo loose coupling?)
Het is eigenlijk gewoon slecht design.
donderdag 17 januari 2008
Steve Vinosky over SOA, REST en serendipiteit
Steve Vinosky maakt een case voor REST als voorkeursstijl van Webservices. Naast de bekende argumenten (hij hamert met name op het caching/scalability-argument), vestigt hij ok de aandacht op de stelling dat REST-services, dankzij het feit dat het om standaard-methods gaat, veel makkelijker vanuit een "onverwachte richting" zijn te hergebruiken dan SOA-stijl services.
Hij noemt dat "serendipitous reuse". En hij stelt dat dit niet alleen voor het Web als geheel geldt, maar ook voor het reuse binnen de architectuur van een onderneming. Hij sluit af met:
"It's highly ironic that many enterprise architects seek to impose centralized control over their distributed organizations. In many cases, such centralization is a sure recipe for failure. A proven framework based on a well-constrained architectural style like REST allows for decentralized development that, because of the architectural constraints, still yields consistency. The Web itself is proof that this form of "control without controlling" works. In the long run, this approach is far more likely to achieve what architects seek than trying to enforce collections of ad hoc governance rules."
Zo.
Heeft ie gelijk? Ik denk dat het in ieder geval voor webservices die publiek zijn, en op het web staan te wapperen naar hergebruikers, wel waar is. En misschien ook wel binnen ondernemingen.
Maar dan moeten die REST-services wel netjes zijn ontworpen. Je ziet nu geregeld GET-commands die eigenlijk een POST-bevatten, of andersom. Dat is niet alleen lastig te begrijpen en dus lastig te hergebruiken, maar bovendien raakt de caching ervan in de war.
Vinosky heeft wellicht gelijk, maar maakt zich wel afhankelijk van het goede design van service-ontwerpers. Zou er een manier zijn om dat in goede banen te leiden, of moeten we hier gewoon rekenen op de natuurlijke selectie?
Want die natuurlijke selectie zal wel werken, op den duur. Als je drie services heb die alledrie hetzelfde doen, en een is met SOAP in de SOA-RPC-stijl ontworpen, een met HTTP, maar met de "verkeerde" method, en een derde netjes volgens de RESTful regels, dan zal op den duur waarschijnlijk de derde het meest worden gebruikt. Ceteris paribus, uiteraard.
En zo verdringt goed design langzamerhand slecht design, en worden de voorbeelden steeds beter.
Tsja, het kan natuurlijk wel effe duren.
Hij noemt dat "serendipitous reuse". En hij stelt dat dit niet alleen voor het Web als geheel geldt, maar ook voor het reuse binnen de architectuur van een onderneming. Hij sluit af met:
"It's highly ironic that many enterprise architects seek to impose centralized control over their distributed organizations. In many cases, such centralization is a sure recipe for failure. A proven framework based on a well-constrained architectural style like REST allows for decentralized development that, because of the architectural constraints, still yields consistency. The Web itself is proof that this form of "control without controlling" works. In the long run, this approach is far more likely to achieve what architects seek than trying to enforce collections of ad hoc governance rules."
Zo.
Heeft ie gelijk? Ik denk dat het in ieder geval voor webservices die publiek zijn, en op het web staan te wapperen naar hergebruikers, wel waar is. En misschien ook wel binnen ondernemingen.
Maar dan moeten die REST-services wel netjes zijn ontworpen. Je ziet nu geregeld GET-commands die eigenlijk een POST-bevatten, of andersom. Dat is niet alleen lastig te begrijpen en dus lastig te hergebruiken, maar bovendien raakt de caching ervan in de war.
Vinosky heeft wellicht gelijk, maar maakt zich wel afhankelijk van het goede design van service-ontwerpers. Zou er een manier zijn om dat in goede banen te leiden, of moeten we hier gewoon rekenen op de natuurlijke selectie?
Want die natuurlijke selectie zal wel werken, op den duur. Als je drie services heb die alledrie hetzelfde doen, en een is met SOAP in de SOA-RPC-stijl ontworpen, een met HTTP, maar met de "verkeerde" method, en een derde netjes volgens de RESTful regels, dan zal op den duur waarschijnlijk de derde het meest worden gebruikt. Ceteris paribus, uiteraard.
En zo verdringt goed design langzamerhand slecht design, en worden de voorbeelden steeds beter.
Tsja, het kan natuurlijk wel effe duren.
woensdag 5 december 2007
SOA en EDA
Een erg aardig stuk over de toepassing van een SOA in EDA-vorm (Event Driven Architecture). Het gaat om een netwerk waarbij elektrische apparaten e.d. steeds op de hoogte worden gehouden van de prijs van elektriciteit, en op basis daarvan "besluiten" of ze wel of niet aangaan, op een spaarstand gaan, of iets dergelijks. Stroomgebruik werd daardoor aanzienlijk beperkt.
maandag 1 oktober 2007
BPM en de architectureluur
Een vraag:
"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.
De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."
Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.
Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.
Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.
Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.
Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.
Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.
In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.
Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.
Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.
Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.
"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.
De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."
Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.
Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.
Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.
Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.
Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.
Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.
In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.
Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.
Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.
Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.
maandag 24 september 2007
Vastberaden, maar soepel en met mate
Vorige week vrijdag ben ik naar het BEA-symposium over de BEA-ESB, SOA, etc geweest. Uitstekend georganiseerd, goede presentaties, en een hoge opkomst.
En toch, en toch.... Ik liep er rond, luisterde naar de verhalen, en vroeg me af: wat zouden we hiervan over vijf jaar denken? En over drie jaar?
Dat begon gelijk met het betoog van Massimo Pezzini, Gartner-expert op het gebied van SOA. Hij schetste het bekende beeld voor wat betreft de beloftes van de SOA, maar hij liet ook zien hoe ingewikkeld eea wel niet is: het kiezen en implementeren van een ESB, de organisatorische vereisten, en dan al die dingen waarmee je rekening moet gaan houden. Security! Choreography!! Orchestration!!! En vooral: GOVERNANCE!!!!
Hij eindigde met een reeks zeer ingewikkelde plaatjes, gevolgd door de mededeling dat het mogelijk was om succes te hebben met al dit moois, maar dat je dan wel aan de ene kant doelgericht en zeer gedisciplineerd moet zijn, en aan de andere kant realistisch en pragmatisch.
Wat zou een klant (dat wil zeggen: een niet IT-er) hier nou van denken? Het zal wel voordelen hebben, en misschien moet ik er aan geloven, maar het is allemaal wel erg ingewikkeld, ik heb er natuurlijk weer dure externe jongens voor nodig, en vooral: dit dus gaat klauwen met geld kosten. En het korte-termijn resultaat is onzeker, om niet te zeggen: vaag.
Maar stel dat SaaS zometeen werkelijkheid wordt, en we de functionaliteit "uit de muur" laten komen, is dan die ESB en al dat gedoe nog nodig? Komt die BPM-laag dan niet ook bij een SaaS-provider te liggen? Zit dat wat ik nodig heb dan niet gewoon in de browser, of in het OS? (Als er tussen die twee dan nog een verschil waarneembaar is.) Er zal dan natuurlijk een SOA zijn, en ook zoiets als een ESB, maar de vraag is in hoeverre een "gewoon bedrijf" dat zelf moet regelen en zelf moet aanschaffen.
Zullen al die SOA-trajecten achteraf goede investeringen blijken te zijn? Ik denk het niet, al is het is natuurlijk mogelijk om "toekomstvast" te investeren, dat wil zeggen: een scherp oog gericht te houden op de SaaS-ontwikkelingen. En soms zijn de SOA-investeringen nu onmiddellijk de moeite waard omdat ze een concreet en urgent probleem oplossen met de bestaande systemen, en dan vooral de integratie daarvan.
Een goed voorbeeld van een succesvol project werd geboden in het uitstekende verhaal van de CTO van Nuon, Jeroen Scheer. Maar hij benadrukte ook dat een groot deel van het werk daar in de organisatie zat, en dat de systeemintegratie daar een weliswaar noodzakelijk, maar toch niet al te groot deel van uitmaakte.
Ik denk dat zelfs bij legacy-integratie projecten het pragmatisme en het gezonde verstand zal leiden tot beperkte investeringen in de technische architectuur, omdat juist dat deel waarschijnlijk in de SaaS-infrastructuur zal "verdwijnen", en dientengevolge veel goedkoper zal worden.
Want dat is uiteindelijk de belofte: standaard IT wordt als service geleverd, tegen lage prijzen op gebruiksbasis. Voor standaardzaken hoeven dus geen grote investeringen meer te worden gedaan. Maar als dat waar is voor functionaliteit, dwz: voor de systemen zelf, waarom dan niet ook voor de ondersteunende infrastrcutuur, zoals een ESB?
En toch, en toch.... Ik liep er rond, luisterde naar de verhalen, en vroeg me af: wat zouden we hiervan over vijf jaar denken? En over drie jaar?
Dat begon gelijk met het betoog van Massimo Pezzini, Gartner-expert op het gebied van SOA. Hij schetste het bekende beeld voor wat betreft de beloftes van de SOA, maar hij liet ook zien hoe ingewikkeld eea wel niet is: het kiezen en implementeren van een ESB, de organisatorische vereisten, en dan al die dingen waarmee je rekening moet gaan houden. Security! Choreography!! Orchestration!!! En vooral: GOVERNANCE!!!!
Hij eindigde met een reeks zeer ingewikkelde plaatjes, gevolgd door de mededeling dat het mogelijk was om succes te hebben met al dit moois, maar dat je dan wel aan de ene kant doelgericht en zeer gedisciplineerd moet zijn, en aan de andere kant realistisch en pragmatisch.
Wat zou een klant (dat wil zeggen: een niet IT-er) hier nou van denken? Het zal wel voordelen hebben, en misschien moet ik er aan geloven, maar het is allemaal wel erg ingewikkeld, ik heb er natuurlijk weer dure externe jongens voor nodig, en vooral: dit dus gaat klauwen met geld kosten. En het korte-termijn resultaat is onzeker, om niet te zeggen: vaag.
Maar stel dat SaaS zometeen werkelijkheid wordt, en we de functionaliteit "uit de muur" laten komen, is dan die ESB en al dat gedoe nog nodig? Komt die BPM-laag dan niet ook bij een SaaS-provider te liggen? Zit dat wat ik nodig heb dan niet gewoon in de browser, of in het OS? (Als er tussen die twee dan nog een verschil waarneembaar is.) Er zal dan natuurlijk een SOA zijn, en ook zoiets als een ESB, maar de vraag is in hoeverre een "gewoon bedrijf" dat zelf moet regelen en zelf moet aanschaffen.
Zullen al die SOA-trajecten achteraf goede investeringen blijken te zijn? Ik denk het niet, al is het is natuurlijk mogelijk om "toekomstvast" te investeren, dat wil zeggen: een scherp oog gericht te houden op de SaaS-ontwikkelingen. En soms zijn de SOA-investeringen nu onmiddellijk de moeite waard omdat ze een concreet en urgent probleem oplossen met de bestaande systemen, en dan vooral de integratie daarvan.
Een goed voorbeeld van een succesvol project werd geboden in het uitstekende verhaal van de CTO van Nuon, Jeroen Scheer. Maar hij benadrukte ook dat een groot deel van het werk daar in de organisatie zat, en dat de systeemintegratie daar een weliswaar noodzakelijk, maar toch niet al te groot deel van uitmaakte.
Ik denk dat zelfs bij legacy-integratie projecten het pragmatisme en het gezonde verstand zal leiden tot beperkte investeringen in de technische architectuur, omdat juist dat deel waarschijnlijk in de SaaS-infrastructuur zal "verdwijnen", en dientengevolge veel goedkoper zal worden.
Want dat is uiteindelijk de belofte: standaard IT wordt als service geleverd, tegen lage prijzen op gebruiksbasis. Voor standaardzaken hoeven dus geen grote investeringen meer te worden gedaan. Maar als dat waar is voor functionaliteit, dwz: voor de systemen zelf, waarom dan niet ook voor de ondersteunende infrastrcutuur, zoals een ESB?
vrijdag 10 augustus 2007
Archetypes (vv)
Ruim twee weken geleden kondigde ik aan te gaan onderzoeken wat het nut is van archetypes, en die te gaan beoordelen op de volgende criteria:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
En daar kwam later bij:
6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
De onderzochte aanpakken zijn:
- de REA aanpak (Resources, Events, Agents), in de variant van Pavel Hruby c.s.
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak (pleomorphs) van (o.m.) Arlow en Neustadt.
Ik ben nog lang niet klaar, maar dit is de eerste inventarisatie.
Ad 1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
- REA: ja. Daar is de aanpak bij uitstek voor bedoeld. Het gehanteerde metamodel (REA, duality, conversion process, etc) is ook expliciet uit de abstractie van business-domeinen ontleend (mn uit accounting). De aanpak is compleet: elk business-domein wordt in principe volledig bestreken, zij het dat soms wat kunstgrepen nodig zijn. REA is ook alleen maar voor business-domeinen geschikt.
- colors: ja. De Domain Neutral Component (PPT, Role, Description, Moment/Interval) is een zeer abstract model, en eigenlijk een metamodel dat overal (niet alleen voor business-analyse) kan worden toegepast. Maar er zijn specialisaties mogelijk voor business-analyse, en Coad c.s. geven daarvan ook voorbeelden. De aanpak is compleet: elk business-domein wordt volledig bestreken.
- pleomorphs: ja. De aanpak biedt een set aan (samenhangende) analyse-patronen, die uitstekend geschikt zijn om een business-analyse te doen. Of elk business-domein compleet wordt afgedekt, betwijfel ik.
Ad 2. is de aanpak bruikbaar in een MDE-traject?
- REA: ja, mits verder uitgewerkt. Er zijn iig aanzetten voor MDA/MDE-achtige zaken, maar er zal wel nog het nodige meoten worden gedaan om eea te laten werken. Nadeel is wel dat de REA-aanpak niet uit de hoek van de software-ontwikkeling komt, waardoor de mapping van REA-concepten op bv componenten of classes nog wel eens lastig kan zijn (zie bijvoorbeeld het ontbreken van een Role).
- colors: ja, mits doorontwikkeld. Deze aanpak stamt van voor de MDA-hype, en dus zitten er geen expliciete aangrijpingspunten voor MDA of MDE in. Echter, de aanpak zit zo strak in elkaar als het gaat om de afleiding van modellen dat dit geen groot probleem zal zijn. (opvallend in dit verband is dat Coad c.s. de term "metamodel" niet gebruiken voor hun abstracte patronen, hoewel ze wel bij uitstek zo te gebruiken zijn).
- pleomorphs: ja. Is expliciet opgenomen, en er worden zelfs voorbeelden gegeven met ArcStyler als tool.
Ad 3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
- REA: waarschijnlijk wel. Echter, de mapping van analyse concepten naar services is nog niet triviaal, mede omdat een REA-model puur op het punt van bv object-orientatie (cohesie interfaces, etc) nog niet helemaal klaar is.
- colors: ja. Weliswaar zitten services etc. niet in de aanpak, maar dankzij de strak uitgewerkte interfaces, de keurig aansluitende domein-concepten en vooral de roles die al in het model als koppeling optreden, is een mapping op een SOA niet moeilijk.
- pleomorhs: waarschijnlijk wel. Deze aanpak resulteert in goede OO-modellen, waaruit services normaliter makkelijk af te leiden zijn.
Ad 4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
- REA: ja. Ik voorzie geen problemen.
- colors: ja.
- pleomorphs: ja, is er zelfs specifiek op gericht (compleet met voorwoord van de onvermijdelijke Richard Mark Soley, Ph.D.)
Ad 5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
- REA: zeer twijfelachtig. REA is goed in het adhv de business analyseren van die business, maar is niet gericht op software. Ik betwijfel of dit werkt, al zullen proeven dat moeten uitwijzen.
- colors: ja, uitstekend. De top-down benadering helpt ook bij zeer rommelig in elkaar zittende legacy-software. Colors is eigenlijk een soort patroon-taal, en dat is hier een groot voordeel.
- pleomorphs: ja. Het opzoeken van de patronen is goed mogelijk, maar ze moeten wel al zichtbaar zijn.
Ad 6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
- REA: redelijk. REA gebruikt expliciet AO voor bepaalde vormen van gedrag (asymmetrische aspecten vooral). Om het echt in een MDE-aanpak te laten werken is nog wel wat werk nodig, maar het begin is er.
- colors: redelijk. Aspecten zitten er niet expliciet in, maar de aanpak (weer dankzij de roles) leent zich er goed voor. Om het in een MDE-aanpak te laten werken is nog wel werk nodig.
- pleomorphs: matig. Voorzover ik kan overzien is er geen rekening mee gehouden. Aan de andere kant; het zijn wel OO-modellen, dus het is er in te breien. Maar er zal meer werk voor nodig zijn dan bij colors.
Zo, dit is de eerste inventarisatie. Het is duidelijk: er is nog veel uit te zoeken. En er is ook nog veel meer te zeggen van deze aanpakken, de voor- en nadelen, enzovoort. Dat zal allemaal gebeuren.
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
En daar kwam later bij:
6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
De onderzochte aanpakken zijn:
- de REA aanpak (Resources, Events, Agents), in de variant van Pavel Hruby c.s.
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak (pleomorphs) van (o.m.) Arlow en Neustadt.
Ik ben nog lang niet klaar, maar dit is de eerste inventarisatie.
Ad 1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
- REA: ja. Daar is de aanpak bij uitstek voor bedoeld. Het gehanteerde metamodel (REA, duality, conversion process, etc) is ook expliciet uit de abstractie van business-domeinen ontleend (mn uit accounting). De aanpak is compleet: elk business-domein wordt in principe volledig bestreken, zij het dat soms wat kunstgrepen nodig zijn. REA is ook alleen maar voor business-domeinen geschikt.
- colors: ja. De Domain Neutral Component (PPT, Role, Description, Moment/Interval) is een zeer abstract model, en eigenlijk een metamodel dat overal (niet alleen voor business-analyse) kan worden toegepast. Maar er zijn specialisaties mogelijk voor business-analyse, en Coad c.s. geven daarvan ook voorbeelden. De aanpak is compleet: elk business-domein wordt volledig bestreken.
- pleomorphs: ja. De aanpak biedt een set aan (samenhangende) analyse-patronen, die uitstekend geschikt zijn om een business-analyse te doen. Of elk business-domein compleet wordt afgedekt, betwijfel ik.
Ad 2. is de aanpak bruikbaar in een MDE-traject?
- REA: ja, mits verder uitgewerkt. Er zijn iig aanzetten voor MDA/MDE-achtige zaken, maar er zal wel nog het nodige meoten worden gedaan om eea te laten werken. Nadeel is wel dat de REA-aanpak niet uit de hoek van de software-ontwikkeling komt, waardoor de mapping van REA-concepten op bv componenten of classes nog wel eens lastig kan zijn (zie bijvoorbeeld het ontbreken van een Role).
- colors: ja, mits doorontwikkeld. Deze aanpak stamt van voor de MDA-hype, en dus zitten er geen expliciete aangrijpingspunten voor MDA of MDE in. Echter, de aanpak zit zo strak in elkaar als het gaat om de afleiding van modellen dat dit geen groot probleem zal zijn. (opvallend in dit verband is dat Coad c.s. de term "metamodel" niet gebruiken voor hun abstracte patronen, hoewel ze wel bij uitstek zo te gebruiken zijn).
- pleomorphs: ja. Is expliciet opgenomen, en er worden zelfs voorbeelden gegeven met ArcStyler als tool.
Ad 3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
- REA: waarschijnlijk wel. Echter, de mapping van analyse concepten naar services is nog niet triviaal, mede omdat een REA-model puur op het punt van bv object-orientatie (cohesie interfaces, etc) nog niet helemaal klaar is.
- colors: ja. Weliswaar zitten services etc. niet in de aanpak, maar dankzij de strak uitgewerkte interfaces, de keurig aansluitende domein-concepten en vooral de roles die al in het model als koppeling optreden, is een mapping op een SOA niet moeilijk.
- pleomorhs: waarschijnlijk wel. Deze aanpak resulteert in goede OO-modellen, waaruit services normaliter makkelijk af te leiden zijn.
Ad 4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
- REA: ja. Ik voorzie geen problemen.
- colors: ja.
- pleomorphs: ja, is er zelfs specifiek op gericht (compleet met voorwoord van de onvermijdelijke Richard Mark Soley, Ph.D.)
Ad 5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
- REA: zeer twijfelachtig. REA is goed in het adhv de business analyseren van die business, maar is niet gericht op software. Ik betwijfel of dit werkt, al zullen proeven dat moeten uitwijzen.
- colors: ja, uitstekend. De top-down benadering helpt ook bij zeer rommelig in elkaar zittende legacy-software. Colors is eigenlijk een soort patroon-taal, en dat is hier een groot voordeel.
- pleomorphs: ja. Het opzoeken van de patronen is goed mogelijk, maar ze moeten wel al zichtbaar zijn.
Ad 6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?
- REA: redelijk. REA gebruikt expliciet AO voor bepaalde vormen van gedrag (asymmetrische aspecten vooral). Om het echt in een MDE-aanpak te laten werken is nog wel wat werk nodig, maar het begin is er.
- colors: redelijk. Aspecten zitten er niet expliciet in, maar de aanpak (weer dankzij de roles) leent zich er goed voor. Om het in een MDE-aanpak te laten werken is nog wel werk nodig.
- pleomorphs: matig. Voorzover ik kan overzien is er geen rekening mee gehouden. Aan de andere kant; het zijn wel OO-modellen, dus het is er in te breien. Maar er zal meer werk voor nodig zijn dan bij colors.
Zo, dit is de eerste inventarisatie. Het is duidelijk: er is nog veel uit te zoeken. En er is ook nog veel meer te zeggen van deze aanpakken, de voor- en nadelen, enzovoort. Dat zal allemaal gebeuren.
donderdag 2 augustus 2007
SaaS en SOA, hypes die voorbijgaan?
Will SOA still be ‘SOA’ five years from now?
Nee, zegt Joe McKendrick. SOA zal alomtegenwoordig zijn, net als GUIs dat al zijn, en Webservices bezig zijn het te worden.
Hij heeft daarin gelijk, maar er is nog een andere reden waarom SOA snel weer hype-af zal zijn. De SOA hype is een interne IT-hype, eigenlijk alleen interessant voor software-architecten, developers, etc. SOA is een architectuur die "services" mogelijk maakt (en zelfs dat is niet helemaal waar: het is mogelijk services te leveren of zelfs te consumeren zonder een echte SOA). Maar een SOA brengt helemaal neit noodzakelijk gebruik of beschikbaarstelling van services as vanzelf met zich mee, laat staan dat dat zal leiden tot de business-voordelen die klanten wordt beloofd.
SOA is eigenlijk het zoveelste voorbeeld waarbij een technische vernieuwing zonder meer als een business-voordeel wordt verkocht. De pretentie wordt natuurlijk niet waargemaakt, en vervolgens zijn we verbaasd als men cynisch wordt over de prachtige vergezichten die door de IT steeds worden geschilderd.
SaaS is een echte belofte, voor de business, en vooral voor de organisatie (en daarmee de kosten) van de IT. Om SaaS waar te kunnen maken, is er een SOA nodig. Dat is alles.
maandag 23 juli 2007
Het nut van archetypes
Ik ben inmiddels begonnen met een onderzoek naar aanpakken van (business-) analyse met behulp van archetypes (zeer abstracte analyse-patronen die in varianten elk business-domein beschrijven.
Ik kijk daarbij naar iig 3 aanpakken:
- de REA aanpak (Resources, Events, Agents)
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak van (o.m.) Arlow en Neustadt.
Bij alle drie moet de "aanpak" ruim worden opgevat. Arlow en Neustadt bv bouwen voort op al bekende analysis patterns, en van zowel de colors- als de REA-aanpak bestaan verscheidene varianten en afgeleiden. Die zullen worden meegenomen, voorzover nuttig en mogeljk.
Ik ga iig naar de volgende criteria kijken:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
Ik ben benieuwd...
Ik kijk daarbij naar iig 3 aanpakken:
- de REA aanpak (Resources, Events, Agents)
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak van (o.m.) Arlow en Neustadt.
Bij alle drie moet de "aanpak" ruim worden opgevat. Arlow en Neustadt bv bouwen voort op al bekende analysis patterns, en van zowel de colors- als de REA-aanpak bestaan verscheidene varianten en afgeleiden. Die zullen worden meegenomen, voorzover nuttig en mogeljk.
Ik ga iig naar de volgende criteria kijken:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
Ik ben benieuwd...
Abonneren op:
Posts (Atom)