Jag ogillar inte visionen med tjänsteorinenterade arkitekturer, tvärtom jag tycker det är skit tufft och intressant. Men jag tycker vi har några problem... Jag håller med om att SOA verkligen inte är redo för "Big Time" ännu! Jag håller delvis med, men min uppfattning är att vi är redo för SOA, det är speciellt viktigt för dom som bygger system som ska integreras med varandra och andra system, där meddelanden ska skickas mellan dom, både protokoll och platformsoberoende, ex är system för banker mm. Men problemet som finns idag är prestanda, säkerhet och transaktioner mm. I framtiden kanske detta blir ett mindre problem, men idag är det enligt min uppfattning fortfarande ett stort problem. HTTP som ofta används när vi bygger tjänser som Web Services är ett tillståndslöst protokoll. Tex EDRA har inget bra transaktionsstöd och frågan är, kommer det gå om man använder tex HTTP som protololl!? (När jag menar gå, så menar jag att det verkligen kan fungerar pålitligt till 100%) Fredrik, Vem har sagt något om remote? Blev lite nyfiken bara ;) Det har varit mycket snack om att SOA eller inte. Alla är vi väl vid det här laget överrens om att SOA & DDD kan leva tillsammans och att det verkliga frågan handlar om två saker ...i min tolkning är detta ett system som finns idag ex ett B2B system som via en kanal behöver få tag i info från en annan... ex visakorts tjänst eller nått., Men det är inte SOA... Till något annat som har med SOA att göra. Fredrik, Andreas: Fredrik, Andreas: Fredrik, "En som är erfaren och bygger ofta efter DDD, börjar med UI och går nedåt. " UI i mitt sammanhang är abstrakt. UI i mitt sammanhan har tex inget med grafisk layout att göra. För att kunna veta vilka domain objects vi ska skapa, så utgår vi ifrån hur användern använder systemet, alltså utifrån användarens gränsnitt (Användaren vill kunna mata in ordernummer, adress etc). Efter att veta vad tex en använadere vill och förväntas av systemet som ska byggas, så utformas applikationen. Hum... "Ok. kul att alla har sina olika tolkningar. ;-) " >även om det kanske är fel terminologi i det här fallet. "Ubiquitous Language grabbar. ;) " Vi får sätta ihop en svensk "arkitekt-wiki" på swedarch sen. Så kan vi skriva in beskrivningar där och länka dit så fort vi använder ett tvetydigt ord. En petitess bara, User stories används väl bara som begrepp i Agile och att använda DDD har väl inget med user stories eller use case igentligen att göra. Tex några exempel i Evans bok så bygger de sin domain layer efter diskutioner med en domain expert (om jag har förstått rätt så är det ofta kunden). Jo, Use Cases och dylikt kommer väl från Agile och XP, men det betyder inte att man inte kan använda det i DDD. Tvärtom så funkar DDD väldigt bra i XP. DDD handlar ju bara om att man sätter domänmodellen i centrum och utgår från den när man designar sin applikation. Då finns det inget som hindrar att man använder Agile metoder för att ta fram domänen. japp precis... undra om vi inte ska fortätta prata om detta på swedarch istället ;) Andreas, Mats, Är vi redo för SOA? Andreas, Rocky Lhotka skrev just ett i mina ögon ganska intressant inlägg om SOA, Som vi alla vet så handlar inte SOA en tekologi utan ett nytt sätt att "modeller" eller tänka i form av tjänster som tillammans bildar ett gemesamt system. Jag har använt ordet "integration" tidigare för att tala om tjänster som tillsammans kommunicerar mellan varandra (för det är engligt mig en integration mellan olika system, alltså varje tjänst består av ett underliggande system som pratar med ett annan fast via tjänster). Fredrik, Andreas: Fredrik, Andres:Är vi redo för SOA?
1... Http är inte bra för SOA.
2... SOA har ingen standard där vi har state med tjänsterna...
3... Batch vs icke Batch hanterad data? (cuncurrancy?)
4... Uptime för andras tjänster? Stabila eller icke?
5... Säkerhet? Vad vet vi idag? Jag må säga att vi inte kan säga idag vilka risker som finns här, det är för ungt.
6... Skalbarhet?
7... Ökar det knutpunktsapplikationes spårbarhet?
Indigo kanske har svar på detta. Men är marknaden redo för en sådan värld nu? Vi har ju knappt fått
vårt värld att förstå OO. Java har men inte MS inte än, men troligen kommer det.
Kanske man skall lära folk gå innan vi lär dem flyga? Varför hypa om SOA när vi vet att det inte är redo att lösa alla problem vi kämpat för i en vanlig applikation arkitektur? Varför inte prata om det man _bör_ känna till idag och visa visionen med SOA? För det är vad jag ser SOA som just nu en vision en fantasi vi vill förverkliga så snart vi har svaren på alla frågor. Men innan dess måste vi ju lära de som inte kan gå att gå och sedan visa dem hur vi i framtiden ev kan flyga...
Det är flera utvecklare som sagt att de kan ASP .Net och OO för att de kan vanliga ASP3 (vb script). Jag blev rädd när lärare säger till sina elever att de kan ASP .Net om de kan ASP.
Ännu räddare blir jag när dessa och to m lärarna inte vet vad en hashtable är när man frågar dem.
Bör vi inte ta det lite lugnare och få dessa folk och en drös andra att först förstå OO och vanligt applikationesbygge som än idag är rellativt nytt innan vi kastar oss in i framtiden? Hur säkra tjänster kommer en person som knappt kan "Gå" bygga? Särkilt då man inte känner till historian om hur man byggde förr? Jag säger inte detta för att klaga på någon men vi måste verkligen få upp intresset och kunskaperna hos andra. Jag är skitglad när det kommer folk fram och säger, jag har märkt att jag inte hänger med i vad ni pratar om, jag är ny jag vet och vill lära mig har du några tips och idér hur? Älskar dem, jag är likadan själv, jag är inte bäst, men jag har idéer.
Mvh JohanSv: Är vi redo för SOA?
SOA funkar redan ganska ok för "icke-kritiska" tjänster, som t ex RSS för bloggar. Det kan också funka när samma team/företag bygger både service och klient (t ex en liten säljstödsapplikation till säljarna på fältet - är företagets server med servicar nere eller oåtkomliga ibland får man helt enkelt se till att komplementera med offline-stöd i klienten).
Men framtiden är definitivt inte här ännu :-)
/MatsSv: Är vi redo för SOA?
Det vi får tänka på är att det finns olika av utvecklare, de som vill och kan, de som inte vill och inte kan, och de som ännu lär sig etc. De som vill och kan anser jag är mogna för SOA, men frågan är om de andra är det!? Vilket jag inte tror att dom är. Men att veta vad SOA är och innebär, tycker jag borde vara något som alla borde lära sig, speciellt de som ska jobba med integration och skicka meddelanden mellan tjänster, och för att vara förbered inför framtiden.
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
Men SOA är ju inte enbart ett system som har ett litet remote gränsnitt. Utan där allt i princip är remote tjänster som knytsihop via en punkt som blir vår applikation.
Ett B2B system där du kanske har ett interface för import och ett annat för EDI medelanden men resten är lokala CM funktioner gör ju inte ens B2B till en SOA... Utan en applikation med några ingångar utifrån.
Mvh JohanSv: Är vi redo för SOA?
SOA enligt min uppfattning är ett sätt att utforma och skapa system med tjänster som ska kunna kommunicera mellan varandra. Där dessa tjänster skickar meddelanden mellan varandra. Men om du har en annan syn och anser att detta är fel, så får du gärna försöka övertala mig om att jag har fel ;)
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
(a) Hur bygger vi lämpligast applikationer som skall exponera data extern (SOA & Co)
(b) Hur bygger vi upp dessa applikationer internt (DDD & Co)
Så vad vi egentligen borde gör är att hålla oss till punkt (a) i denna tåden, med tanke på ämnet Johan valt. Och diskutera för&nackdelar med SOA och även lyfta fram andra achitekturer som kan användas för att uppnå "samma" architekturella möjligheter.Sv: Är vi redo för SOA?
Om jag inte missuppfattat SOA helt så är det ett tjänste orienterade arkitektur där tjänsterna är remote kanaler. (remote som i fjärrkontrollens remote) man har inget tillstånd till källan förrän man ropat på den. Där tunna eller smarta klineter är kärnan och bussiness ligger i de olika tjänsterna ute i det vida.
Men det är klart nu har det ju vart så mkt prat hit o dit att jag blivit helt snurrig i huvudet :-) Sv: Är vi redo för SOA?
När man deisgnar en SOA lösning, så tänker jag följande på följande steg (rätta mig om jag tänker fel):
1) Se först vilka tjänster som kan behövas för att skapa en kommunikation mellan tjänster.
2) Fokucera på tänsternas interface (Interfacen utgör kontrakten mellan tjänster).
Vilken information som sedan ska hämtas och levereras från och till tjänster, bestäms utifrån kontrakten mellan tjänster. Däför jobbar man först utifrån och sedan in, och inte tvärt om. När utsidan är klar så fokuserar man på insidan. Om man tex redan har en befintligt insida byggt tex efter DDD, så "kan" man ganska enkelt lägga till ett Anticurruption Layer ovanpå Service Layer (vissa fasader kan tänkas behövas). Om inte insidan finns, så skapas insidan utefter kontrakten.
När det gäller att skapa system efter DDD, så ser början man också ofta utifrån och in, genom att börja med interfacet mot användaren (vilket avgör vilken data och vilka operationer som kan behövs). Men jag anser dock att detta kan vara svårt att gå från utifrån och in, ofta kan det vara så att vi måste gå från båda hållen och mötas i mitten.
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
<b>När det gäller att skapa system efter DDD, så ser början man också ofta utifrån och in, genom att börja med interfacet mot användaren (vilket avgör vilken data och vilka operationer som kan behövs)</b>
Här säger du en intressant sak, kanske utan att tänka på det. I en tjänsteorienterad miljö så blir juh "användargränsnittet" det gränssnitt som man anropar tjänsten. Så samma tanke sätt måste gå att applicera i båda fallen.
Med detta sagt, så kan vi dra det lite hårdare och säga "när bygger vi verkligen innefrån-ut?" Om vi tänker oss att man gör som du säger, att man utgår lite ifrån vilken indata som skall komma från användaren (i form av ett UI) samt vilken utdata som skall returneras. Abstrahera nu bårt UI:t och tänk dig ett Service Layer istället. Samma metodik - vad kommer in och vad skall skickas tillbaka. Bygger vi verkligen bara innefrån-ut när vi bygger applikationer som skall köras obevakade, t.ex Windows Services ? ;)Sv: Är vi redo för SOA?
Kul att du såg likheterna ;)
Jag tog upp DDD just för att visa att man utgår ifrån samma tanke sätt, alltså ser på interfacet först..
Det finns många fall då man bygger innefrån ut, tex många av dagens apps byggda efter Windows DNA och flertal .Net applikationer gör det. Många börjar med databasen, komponenter och sist UI. Det är väldigt vanligt.
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
Det du beskriver är självklart korrekt men ta tanken ett steg längre genom att faktiskt överväga att databasens fält (ej struktur) bestäms av vilken information som måste finnas tillgänglig och på så sätt tänker man indirekt i form av UI. Utifrån det perspektivet kan man säga att man bygger databasen utifrån det tilltänkta gränssnittet (som i sin tur defineras av de datakrav som man har på projektet).
Det är givetvis en liten tankenöt, men det visar lite på hur lurigt innebörden av innefrån ut och utefrån in kan vara. Det beror på i vilket sammanhang man nämner det. För när du börjar speca kraven på en applikation så tänker man ofta datakraven genom att "fantisera" om vad man måste kunna mata in och läsa ut från ett gränssnitt. När du väl har dessa datakrav så modellerar du databasen och sen börjar koda. Det sista du bygger kanske är just gränssnittet men det har mer eller mindre blivit definierar (vad som skall finnas, inte exakt placering av kontroller kanske) redan vad kravhanteringen.
Så man går från konceptuellt UI -> Databas -> Buisness -> UI .. lite underligt flöde om man tänkte efter =P Tjänsteorienterade lösningar har samma sak bara det att man ofta bygger gränssnittet först, men du skulle kunna bygga det grafiska UI:t först oxå, men det är mer vanligt att UI:t byggs upp efterhand.Sv: Är vi redo för SOA?
Något att tänka på, är det inte för att vi är van att tänka så, alltså att det är därför många av oss börjar tänka utifrån en databas? ;)
När jag ofta designar så tänker jag på de objekt som ska finnas, sedan skapar jag databasen efter objekten. Sedan kommer ofta UI. Jag tror att i det flesta fall där vi vet att vi behöver ha en databas eller annan typ av datakälla från början, så behöver vi tänka från båda hållen och mötas i mitten.
En som är erfaren och bygger ofta efter DDD, börjar med UI och går nedåt.
EDIT:
För att förtydla detta så sa min bror Johan något som jag inte tänkte på och iställer för att använda UI som förvirrar så är USer stories bättre och utifrån User stories skapar man sin domain model. Där man från User stories (som jag använde orde UI för, helt fel) går från skapndet av domain objects går neråt mot data källan, alltså skapar Reposriotires.
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
Precis! Men har du en formell kravspec till hands så vet du redan från kod-dag #1 vilken information som skall finnas tillgängligt i ditt UI och då är det inga probs att börja i den delen. Men det är väl lite så att när kodare / architekter skall agera kund (som vi gör till oss själv i våra egna projekt) så är det lätt att man tänker i objekt och inte i krav, för ärligt talat - hur många av oss skriver en formell kravspec till privata projekt ? ;)Sv: Är vi redo för SOA?
Va?
nu snurrar det... UI som i presentations UI eller som UI för utvecklarna? APIerna för ens Domain objekt?
För DDD är just att man bygger Domainet först utan att ens bry sig om de runtliggande lagren. Sedan tar man och applicerar de lager man vill ha. Service layer. DAL, Infra, Transformation layer, proxy layer eller vad man vill kalla dem...
Mvh JohanSv: Är vi redo för SOA?
Exempel:
För att veta hur Customer entiteten ska utformas, så måste vi veta vad användaren vill kunna ange för uppgifter etc, vilket sker via ett interface. När vi vet detta interface, först då vet vi hur vi ska forma vår Customer entitet. Jag pratar inte om att "bygga" GUI:t utan att man utgår från ett gränsnitt, kanske just ordert user interface ställer till det. Kom inte på ett bra namn, kanske skulle det räcka med interface!?
/Fredrik Normén NSQUARD2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
Ok. kul att alla har sina olika tolkningar. ;-)
Så här är det... (eller det finns ju aldrig någon korrekt väg... men...)
Man har user stories eller Use cases. Dessa specar mkt väl vad kunden vill ha. DDD handlar om tänkandet för Domain Modellen. Det lager som hanterar Business. Det är här man fukuserar.
En användare skall kunna spara en artikel.
Aaa... Artikel. skit bra... Det kan bli en entitet i vårt Domain layer. Mer? jo man skall ha ordernummer, adress etc... Mm bra. Attribut. I specen kanske det även framstår att kund kan ha olika priser för sina artiklar och bör då kanske ha ett pris aggregat. Vi ritar upp vår modell. Sedan så måste ju dessa kunna fyllas med data och eller sparas ner. Det kan vi göra med en Repository... Sedan när man skissat klart sin Domain model och tänkt klart den (vilket DDD går ut på.) slänger man på övriga lager så som fasaden som pratar mot Domain layer och lagret som hanterar datan för Domain objekten.
Så ledes är DDD inside-out... Man fokuserar på det inre utifrån spec och bygger ut.
SOA kan byggas på samma sätt, men enligt vissa vill man hellre fokusera på interfacen och lägga kraften där då detta är vad kunden vill åt och känna till, han bryr sin inte om insidan, vad vi har för Business där i skiter han i... på så vis blir det outside-in...
Mvh JohanSv: Är vi redo för SOA?
Nu när jag står så här utanför diskussionen och läser era två "tolkningar" så undrar jag vad det är som gör de olika? Ni pratar ju faktiskt om samma sak men Johan har en mer abstrakt, och kanske "tekniskt korrekt" beskrivning. Men trots det så är ju ändå Fredriks "interface" också det Use Cases.
Genom att ta fram sina Use Cases så bestämmer man ju på sätt och vis ett "interface", även om det kanske är fel terminologi i det här fallet.
Ubiquitous Language grabbar. ;)
Det är i alla fall min tolkning. :)Sv: Är vi redo för SOA?
Det kan absolut stämma att det är fel termologi, problemt är bara att hitta ett bra ord som alla kan förstå och UI är inte ett bra ord. Det kanske inte finns ett bra ord utan måste bekskrivas som en mening!?
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
hehe... så sant... ett problem man alltid kommer leva med... Men det är lite villse att säga att ett UC (use case) eller US (user stories) är ett interface... Det beskriver ju nått man vill uppnå... Sedan blir ju oftast interfacet UC/US verb... Obs.. Oftast. Om vi nu pratar rent API och inte det UI användaren sedan går mot.
Vet du vad vi borde göra... När vi använder ord som kan betyda tusen olika saker, kanske vi skall skriva vad vi menar med dem, så har vi även följt Ubiquitous Language syfte...
För det är ju alltid så att man tänker som man gör efter hur man lever eller lärt... och har man lärt olika tänker man olika. För att då inte misstolka varandra bör vi förklara vad vi menar med våra ord.
Specielt de absrakta orden.
Ibland kan man sitta en hel dag o bara fundera vad pratar han egentligen om... oftast hjälper det ju mes att kunna rita kuliga skisser på papper eller väggen. Men på ett textbaserat forum går det ju inte lika bra.
Mitt liv började som designer inom reklam och inforamtion, samt video och film. Där använder vi oxå många av de ord man har i mjukvaruutvecklingarnas värld. Snacka om att det blivit en massa missförstånd där :-) Sv: Är vi redo för SOA?
Jotack, jag vet hur det är i reklambranschen. Jag började som webbutvecklare på en reklambyrå. Tror du att det var lätt att prata med traditionella reklamnissar. ;)Sv: Är vi redo för SOA?
Jag kan erkänna att mit ordföråd är begränsat, så en ordlista är något jag ska önska mig i julklapp ;)
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
Sv: Är vi redo för SOA?
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
"Precis! Men har du en formell kravspec till hands så vet du redan från kod-dag #1 vilken information som skall finnas tillgängligt"
Heh, fast eftersom den enda konstanten är förändring så är det väl snarare mest ett dokument som beskriver hur vi vet att kraven /inte/ kommer att se ut när vi är klara ;-)
/MatsSv: Är vi redo för SOA?
Fast om man har en kravspec som är validerad av kund så är det juh inte helt otänkbart att ett avtal skrivs med kravspecen som underlag. När den spiken är satt i kistan så medförförändingar också en högrekostnad för kunden - då tjänar man juh iaf en extra slant om de vill mecka om ;)Sv: Är vi redo för SOA?
Nej! ;)
*S* Fast allvarligt, att alltid tänka i banan SOA är nog inte helt galet, eller iaf väga in SOA värderingar.
Däremot tycker jag inte att vi har några verktyg att arbeta med, de som finns är alldeles för undermånliga.Sv: Är vi redo för SOA?
Ja visst är det så, men jag är ju alltid lite partisk för "Agile" - och där är sign-off på kravspecar underordnat kommunikation med kunden ;-)
/MatsSv: Är vi redo för SOA?
http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=05c18331-4e64-4d70-b880-5d748d0ca8f5
Håller nog med honom - inklusive slutklämmen om att SOAs styrka nog kommer som ett "emergent phenomenon" när servicar blir mer kombinerbara.
Det kan nästan kännas ibland som att bygga SOA servicar idag (som tex en Web Service som konverterar mellan valutor eller en som förtäljer vädret i södertälje) är lite som att bygga HTML-sidor innan det fanns browsers för dem - vi saknar fortfarande en IE/mozilla/RSS-läsare/Whatever-browser för Web Services som gör dem riktigt användbara.
/MatsSv: Är vi redo för SOA?
En gång i tiden hade jag en dröm om att dela upp ett B2B system till flera små system. Där det fanns en kunddatabas, en orderdatabas och en produktdatabas etc. Där alla system tillsammans bands ihop i form av vad vi idag kallar tjänser. Dessa tjänster skulle kommunicera mellan varandra med XML och över HTTP platformsoberoende. Dessa tjänster kunde i sin tur gå mot en gemensam tjänst som kunde gå utanför organisationen och kommunicera med andra organisationer via tjänster. Året var 2000. Jag tillsammans med Chris (Jobber på EAN), skapade ett system där vi via XML kunde skicka frågor för att hämta ut information om produkter, organisationer etc. Detta gjordes genom att skicka ett EAN-nummer eller Organisations-nummer till en tjänst som kopplades samman med flara andra tjänster, där varje tjänst va en ean-databas i ett land. Det fanns vid den tiden 6 st andra EAN-database som hade ett interface för att ta emot en XML fråga. Detta fungerade väldigt bra, för det var bara frågor och ingen lagring. Företaget jag jobbade då på (Emcat), implementade en kunddatabas (Emilia), som hade ett interface för att ta mot XML frågor för att tillbaka ge svara ifrom av ett meddelande, som representerade en kund. Emila utvecklades för att även kunna ta emot XML för att lagra nya kunder (istället för att sprida kunder i flera databaser runt om i en organisation, så gick alla mot en och samma databas). Innan jag slutade på Emcat så band jag ihop Emilia med den befintliga B2B lösningen så den lösningen kunde hämta kundinformation från Emilia. Här dök problemen upp. XML via HTTP = prestanda problem. Sökningen i sig var mycket snabb, men att skicka XML över HTTP blev inte lika snabb. Detta resulterade till slut att andra system som låg utanför organistationen kunde via ett interface skapa nya kunder via HTTP med XML, men internt mellan Emcat's B2B lösning fick det bli en intern koppling där binär data skickades för att få upp prestanda.
Med detta vill jag säga, att än idag så har vi problem med både prestanda och transaktioner mm över HTTP. Många SOA implementationer idag, bygger mycket på Web Services, som skickar data via HTTP och med XML, vilket inte är den bästa lösning. Det behövs en bättre teknik för att applicera SOA, där Indigo är på rätt väg att bli en bra teknik, dock tror jag det tar många år innan vi uppnår den ultimatalösningen (om vi någonsin når dit så att säga). Det kan vara bra att veta vad SOA är och vad det kan användas till redan idag, men min uppfattning är att med den tekink via har, så blir vi begränsade och vi kommer att kunna (OBS! kunna, innebär inte att vi böhver få problem) få problem, tex prestanda problem. Borde vi inte vänta med att bygga system efter SOA idag, utan istället då fokucera på de komponenter som ska i framtiden bli tjänster, och se till att de får en så bra design och struktur så när det finns en bra teknik att för att kunna utnyttja SOA, då ska det vara enkelt att göra det? För vi kommer garanterat få bygga om alla lösningar som bygger på SOA idag när det kommer en bättre teknik, och finns det verkligen ett stort behov av SOA i en organistation idag?
Men som sagt, det är min uppfattning och vem säger att den är rätt ;)Sv: Är vi redo för SOA?
I prestandakrävande miljöer kanske man skall tänka sig för en gång extra innan man rullar ut en web sevicebaserad lösning, men det gäller oavsett om man bygger enligt SOA modellen eller inte. Visst kan man rulla ut SOA baserade lösningar byggt på WS om de krav man har på applikationen uppfylls. Det finns idag, som bekant, väldigt många WS lösningar där man är nöjd med prestandan och där skulle man mycketväl bygga enligt SOA.
Det är summan av delarna som avgöra om SOA baserat på WS är en lösning som kommer att fungera i det enskillda fallet. Men det är inte utan att vi med spänning ser fram emot t.ex Indigo =)Sv: Är vi redo för SOA?
"väldigt många WS lösningar där man är nöjd med prestandan och där skulle man mycketväl bygga enligt SOA."
Hur många av dessa lösningar är skalbara!?
Vad händer om belastningen ökar!?
Om du har några referenser så får du gänra posta dom, inte för att jag inte tror dig, utan tvärt om, jag håller med dig att det finns, men att bygga ALLA lösningar baserat på SOA idag är inte den ultimatalösningen på alla problem. SOA ska appliceras där det verkligen behövs och inte annars. För de system som inte behöver SOA, så är det vikgitare med en bra komponent-orienterad design som kan enkelt i framtiden gör det möjligt att appliceras SOA, när det väl behövs.
"Det är summan av delarna som avgöra om SOA baserat på WS är en lösning som kommer att fungera i det enskillda fallet".
Stämmer utan tvekan.
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.comSv: Är vi redo för SOA?
<b>Hur många av dessa lösningar är skalbara!?
Vad händer om belastningen ökar!?</b>
Det är inte alla program som måste kunna skala upp i skyarna eller som kommer få en extrem ökning i belastning över de kommande tio åren. Jag tror det är lite en bidragande faktor till SOA hypen, alla har fått för sig att om man skriver ett program idag så måste man bygga det så flexibelt som möjligt för det KAN bli så att man måste skala applikationen längre fram, eller dela med sig av sin information utanför sin domän (företag). Trams! Visst blir det allt vanligare, men det är definitivt inte en regle
Svaret har du i min sista stycke som du själv håller med om
"Det är summan av delarna som avgöra om SOA baserat på WS är en lösning som kommer att fungera i det enskillda fallet"
För att citera dig "Agile handlar mycket om att bygga det som behövs idag och inte det som behövs imorgon." .. betyder juh att om man använder Agile så skulle man mycket väl kunna tänka sig WS, i en SOA lösning eller annan, om dagens behov inte ställer andra krav ? ;)Sv: Är vi redo för SOA?
<b>För att citera dig "Agile handlar mycket om att bygga det som behövs idag och inte det som behövs imorgon." .. betyder juh att om man använder Agile så skulle man mycket väl kunna tänka sig WS, i en SOA lösning eller annan, om dagens behov inte ställer andra krav ? ;)</b>
Hehehe, självklart!
<b>skulle man mycket väl kunna tänka sig WS, i en SOA lösning eller annan, om dagens behov inte ställer andra krav </b>
Har nämnt detta i mitt tidigare inlägg oxå ;)
Visst är SwedArch coolt! Ups, smyg reklam, men för vad!? ;)
/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.com