Helo,

Någon som arbetat med SOA?

Vad är fördelarna och vad är nackdelarna?

mvh
/Patrik

Oj vilken fråga.
Prata gärna om det inne på www.swedarch.com om du vill. Finns ett ämne där ochj diskussioner har redan vart igång.

Fördelar och nackdelarna baseras på kraven man har så det går inte direkt säga för och nackdelar om man inte vet för vad det är tänkt att använda, om det passar och om det kan lösa dina krav.

Mvh Johan

Inte fullskaligt men i vissa delar av våra system.
Fördelar: väldigt enkelt att återanvända komponenter. Snabb utv. tid.
Enkelt att verifiera/testa att komponenter fungerar.
Nackdelar: inga jag har märkt. Möjligen när man bygger det med XML, att det är lite overhead med XML. Men det är inget som jag hitills har upplevt som ett problem. Kan potentiellt bli ett problem om det blir väldigt mycket data som ska skickas iväg.

Fördel: Systemutvecklingen tenderar att handla om hur olika komponenter ska kunna integreras för att skapa ett stabilt och produktivt _system_. Utan SOA (eller vanlig sund objektorientering) så tenderar problemen handla om att återuppfinna hjulet så kostnadseffektivt som möjligt. Ofta är det då dokumentationen kommer i kläm.

Se upp med förkortningsdjungeln. SOA är ett väldigt abstrakt begrepp som används mellan köpmän utan djupare teknisk insikt. Två programmerare säger istället:
"typ, vilka parametrar ska jag skicka då da?"

Två erfarna programmerare vet dessutom att de skickar parametrarna i XML utan att behöva tala om det för varandra.

Ola,

Jag är inte alls med på varför det skulle korta ner tiden än om man inte bygger Service Orienterat?
SOA är ju mer moduler som man i vanlig OO bygger upp, där man istället lägger på ett onödigt tranformeringslager som tar mer tid än om man körde vanlig Marshaling mellan objekten.
Dock är detta tranformationslager bara onödigt om kraven säger att kommunikationen mellan modulerna måste vara distruberbara åt andra. Annars är SOA helt tokigt :-)

Tänk dig Photoshop med SOA arkitektur ;-) hehe... retas lite...

SOA ser jag endast som ett bra allternativ när systemet måste kunna prata mellan olika parter.
Så länge det skall pratas lokalt med sitt egna system är SOA helt och hållet slöseri, vinsten existerar inte ens.

En stor nackdel med SOA idag är hanteringen av 2 face commit. Den är krånling. Cuncurrancy-hanteringen kan oxå vara bökig att hantera. Man måste även bygga rutiner (om man bygger stabila lösningar) för att se om tjänsten är uppe så inte oväntade fel inträffar m.m.

Mvh Johan

Kristofer,

Måste vara lite bakom då jag inte fattade det där med två utvecklare och erfarna med XML bla bla jumbu jumbu... Vill du vidare utveckla det lite? Kul att höra en djupare teori i den frågan.

Och sedan vill jag upplysa dig om att SOA och OO är inte samma sak. Hur OO helt plötligt handlar om att återuppfinna hjulet kostnadseffektivt och att då inte SOA (om jag tolkat dig rätt) gör mig lite förvirrad då en tjänst inom SOA är minst lika OO som alla andra applikationer, enda skillnaden är egentligen hur man väljer att kommunicera med dess API, remote eller ej. Så även om man bygger applikationer med SOA är ju OO en viktig grund.

Mvh Johan

I min värld så är SOA ett rätt så hypat ord. Skulle vilja se det mer som en förlängning av komponentbaserade programmering (vilket det faktiskt är) och det hela blir då inte lika "coolt" längre.

Vad man skall ta fasta på är de fördelar som man får med SOA och det är faktiskt inte så många fler än med vanlig komponentbaserade programmering, utan nackdelarna är nästan fler :)

Några fördelar:
- Du har ett starkt isolering av din kod och när du rättar i denna kod så slår det igenom för alla applikationer som använder sig av den direkt, jmf med komponenter så ändrar du i komponenten och så glömer du deploya ut den till något program i organisationen och vips så har du program som skall göra samma sak men gör det inte. Detta är stor fördel med SOA.
- SOA gör de tväldigt enkelt att bygga löstkopplade system, vilket i sin tur gör en migrering från en plattform till en annan smidigt, man bytar helt enkelt ut de olika servicerna i den takt som det går.
- SOA som använder WebServices som protkoll blir platforms oberoende, vilket (ialla fall i vår organisation som har 4 plattformar) gör att de olika system kan kommuicerar med varandra på ett enkelt sätt.

Några nackdelar:
- Oftas så får du en overhead i prestandan när du implementerar en SOA lösning eftersom den "kräver" kommunikation över nätverket.
- Du har som Johan säger (än så länge) problem med transaktioner och säker leverering eftersom du inte alltid kan vara garanterad på om operationen i din Service är genmförd eller inte, vilket betyder att du måste implementerar en egen hantering för detta och att detta då måste implementeras både på klient och server så att funktionen blir idempotent.
- W3C standard för webservice anrop, de är satt till MAX 2 samtidiga anrop ut från en applikation, det betyder att vill du kalla 4 olika servicar samtidigt, och även om du skapar 4 trådar som gör det så är det som default satt till att endast gör 2 åtgången (allafall i .NET), nu kan man konfigurerar sig ur det.
- IIS:ens hantering av trådar gör att WebServices inte är lämpade att använda när du anropar en Service som tar långtid att exekverar. Default är IIS:en satt till att endast hantera 20 samtidiga trådar, vilket snabbt kan bli en flaskhals om din service gör någon tung beräkning som tar några sekunder att genomföra.

Med det sagt så måste jag säga att jag är helt förtjust i de möjligheter som SOA faktiskt innebär, vi har precis byggt en EnterpriseGateway/Messagebus till vår organistation som skall göra att vi kan bygga löstkopplade system (typ Biztalk). Detta har gett oss en del fördelar när det gäller spårbarhet av "transaktioner" igenom system fram och tillbaka över flera olika plattformar, vi kan alltså se precis hur långt man har kommit i ett flöde om ett system skall kalla flera olika services, vi kan även se precis vad som har kommit in och vad som skickades tillbaka (all kommunikation sparas i en databas) men det som kanske är den bästa biten är den med felhantering där alla lager kan logga in sina fel som de får och tillsammans med ett XceptionId som vi sätter på felet så kan vi följa ett fel nerifrån stordator miljön i genom en JavaService, igenom EnterpriseGateway (skriven i .NET) och vidare upp i UI (notes), i en och samma databas (det är bara så fet!!!).

IMHO!
Magnus

Patrik,

Är du nöjd med de svar du fått? I så fall kan du väl sätta tråden som löst eller nått.
Annars kommer jag göra detta i slutet av veckan. Detta för att hålla Forumen rena.

Mvh Johan

Jo, jag e nog nöjd .... ämnet är ju inte helt lättförklarat om fördelar och nackelar.

Våra konsulter förklarade för oss i ett 2 dagars möte :o) (man kan ju inte lita på konsulterna *ler*) så jag tyckte nog att man kanske skulle "fråga fler" expert. Inte frågan om att jag inte är nöjd med konsulterna för det är jag ... de är mycket duktiga och är MS Gold parnters ;-)

Det är så att vi har ett antal applikationer, flera av dem använder "samma data" så man måste börja speca lite annorlunda om vilken app som konsumerar eller erbjuder data/tjänst/etc.

Lite om vårat läge:
Vi har ca 7 fabriker i olika länder, ett 10-tal olika egna säljbolag (max ett per land), reservdelsförsäljning separat osv.
Varje enhet har sitt eget lokala ERP-system. Just nu implementerar vi ett OrderManagementSystem, ett system för reservdelsförsäljning ska byggas om då systemet är gammalt och behöver "fräshas" upp.
Processerna ska vara gemensamma för varje enhet kan tilläggas.

Dessa 2 skulle konsulterna vilja starta med att bygga efter SOA. (resterande appar tas när behov finnes)

Nu skulle man kunna tro att alla kör "samma ERP". Tyvärr, så enkelt är det inte. Alla säljbolagen kör iScala, tyvärr ej med samma "set-up", ej heller samma språkversion. Fabrikerna kör olika ERP som BaaN IVc2 & IVc4, Sage m fl. Jag tror att vi totalt kommer upp i ca ett 20-tal lika ERP-system (eller olika set-up av ERP-systemen).

Dvs, inte speciellt enkelt att införa ett globalt gemensamt/gemensamma system ..... med singel-sign-on osv.

Här låter SOA mycket bra då man på ett lättare sätt kan "bygga in" fler enheter eller "avknoppa enheter" .. allt efter behov, lättare att underhålla systemen (se vart fel uppstår osv).

cya,
/PatrikB

Johan, jag kan se två orsaker till att det kortar ner tiden att utveckla mha SOA:

På kort sikt: du får en klok uppdelningen av systemet i autonoma komponenter som kan testas och verifieras var för sig. Men ordentliga specar är det lätt att sprida utvecklingen till flera personer.
Samordningsarbetet blir inte så klurigt.

På lång sikt: När du har massor med sådana komponenter i ditt företagsnät t.ex. blir det lätt att utveckla nya saker som bygger på dessa komponenter. Du kanske har ett ordersystem. Du bygger en WS för att lista ordrar för en viss kund. Denna tjänst anropas av ett internt system som säljarna på företaget använder. Några månader sedan frågar chefen om det går att lista ut detta på en webbsida som kunderna kan komma åt. Ja, med SOA har du redan byggt 80% av den funktionaliteten. Du behöver bara smeta på lite HTML/CSS sen är saken klar, ungefär. Eller säg att säljarna vill komma åt det interna systemet med mobilen i stället för WindowsFormulären som du bar byggt åt dem.. Overheaden med XML finns där men det är i regel ingen flaskhals när man oftast har rejält med både RAM och bandbredd i dag. Fördelen att kunna utveckla snabbare i framtiden, och vidareutveckla på ett smidigt sätt, överväger nackdelarna. Därför försöker vi bygga en del nya komponenter som SOA, ungefär i de lägen där följande gäller:
1. Man kan tänka sig att komponenten skulle kunna återanvändas av andra system/gränssnitt.
2. Prestanda/svarstider/antal samtidiga användare för den specifika tjänsten riskerar inte att stiga till en kritisk nivå som gör att XML blir en problematisk flaskhals.
Man får alltså avgöra från fall till fall om SOA är rätt. Det är inte alltid rätt.

Ola,

Har två svar.
OO och TDD ;-)

SOA är bara ett annat sätt att exponera ett API för en Modul. Ett Distribuerande lager för andra parter.
Det är allt. Om du modulbaserar din domän får du exakt samma fördelar. Grunden för en tjänst är detsamma oavsett hur gräns APIet mot kund ser ut.

Så du kortar inte alls ner utvtiden genom SOA då du ändå (hoppas jag) nyttjar OO för domänen bakom.
Du ökar däremot utv-tiden och risker om du skall ha ett remotegränsnitt om det inte ens skulle behövas.

Mvh Johan

"Så du kortar inte alls ner utvtiden genom SOA då du ändå (hoppas jag) nyttjar OO för domänen bakom.
Du ökar däremot utv-tiden och risker om du skall ha ett remotegränsnitt om det inte ens skulle behövas. "

Det är sant men ändå inte sant, det är sant i en miljö där du utgår ifrån att alla kan referera till din komponent.
I en miljö med flera olika plattformar så kortar du faktiskt ner utvecklingstiden om övriga plattformar behöver exakt den funktionen som du implementerar som en Service och gör den tillgänglig via ett gränssnitt som de kan uttnytja. Det är det som är styrkan i SOA att oberoende av platform så kan man bara hanterar WebServices så kan man uttnytja andra plattformars kod på ett enkelt sätt (med visa begränsningar).

- M

"SOA är bara ett annat sätt att exponera ett API för en Modul.
Ett Distribuerande lager för andra parter.
Det är allt. Om du modulbaserar din domän får du exakt samma fördelar. "


Jag håller inte med om det.
Genom att bygga SOA får du plattformsoberoende komponenter gratis.
Och komponenter som inte behöver distribueras.
Vem som helst som förstår XML och något programmeringsspråk kan direkt använda din tjänst.
Kombinerar man det med UDDI (katalog för att exponera vilka tjänster du har)
måste man inte ens informera andra utvecklare att nya komponenter finns.
De behöver bara titta i katalogen.
Annars måste du både informera och distribuera komponenterna.
Var det någon som sa.. DLL-hell, gacutil? ;)
I XSD/Soap har du inbyggt stöd för kommentarer. Du behöver alltså i teorin aldrig förklara/visa/dokumentera för någon hur de ska använda tjänsten.
Utan den dokumentation som finns och behövs, kan ingå i tjänsten.
Exempel på frågeställningar du med SOA kan glömma bort:
- var finns komponenterna?
- var finns dokumentationen?


" Så du kortar inte alls ner utvtiden genom SOA då du ändå (hoppas jag) nyttjar OO för domänen bakom. "


Jo om din organisation någonsin skall göra mer än ett program/system så är chansen väldigt stor att man vinner på det....



"Du ökar däremot utv-tiden och risker om du skall ha ett remotegränsnitt om det inte ens skulle behövas. "


Njae, med VS.NET får du ju XML-gränssnittet gratis.
I minst 9 fall av 10 räcker det som genereras.
Dessutom har du fördelen med enkla enhetstester.
Skriver du en assembly som innehåller objekt som måste skapas i kod,
då måste du skriva testprogram för de komponenterna som ska testas.
Om det är XML som in/output räcker det med ett program som postar XML till tjänsten och som kan visa upp svaret. Sådana program är gratis. Ibland funkar det bra att använda det i .Net medföljande testformuläret.

Ola,

Vad är skillnaden på en modul med remote API vs icke remote API förutom att det är remote o inte remote API ;-)

Med andra ord, om du har en modul som kör via marshaling eller remote är sak samma i användar och utvecklingsynpunkt. Den störa skillnaden är bara ett extra lager för att distribuera modulen world wide inget annat.

SOA är typ moduler med remote gränsitt istället för marshaling.

mvh johan

" SOA är typ moduler med remote gränsitt istället för marshaling. "


JA, plus de andra fördelarna som jag radade upp i mitt inlägg... ;)

Ola,

Fördelar mot vad? ;-) Marshaling?

SOA har ingenting med Web Services att göra. Du kan bygga SOA med IBM MQ eller SMTP/POP3. Det är den första myten som måste dödas.

SOA är däremot sättet att tänka när du vill ta fram autonoma tjänster i ditt enterprise och lämpar sig ypperligt när man har, som i scenariot här, en massa system på olika plattformar som behöver prata med varandra. Genom att använda sig av soa, skapa tjänster runt systemen och sedan orkestrera (med tex BizTalk) kan man enkelt samla upp den informationen man behöver i sina nya system.

Alternativet till tjänsteorienterat i ett sådant här fall kan vara tex att interoperera på databasnivå, inte fullt så trivialt som det låter.

Sen är det som Johan säger, om du bestämmer dig för att bygga med SOA (som är en arkitektur) så kan du välja att nyttja OOP (som är en implementations teknik) och bygga dina domänmodeller.

Mycket kan man säga om SOA och jag håller inte med om allt som sägs, men att användas som lösning på interopabilitetsproblem det är det idag bäst på.

Som Patrik säger så har SOA inget med WebService att göra. De som idag bygger interna system och använder WebServices bör vara försiktiga. Om ni vet att systemet ska kunna integreras med andra system och platformsoberoende, då kan det vara ett bra alternativ att implementera web services, men om ni förbereder för att ni "tror" att det kommer att hända. Då skulle jag rekommendera er att inte bygga WebServices (mkt pga prestanda). När ni väl behöver "integrera", lägg till ett nytt service layer istället.

Tänk även på att Web Services är långsam jämförelse med tex binär remoting.

Indigo kommer lösa många problem som finns idag, men inte alla. Tanken med Indigo är att skapa ett verktyg för att bygga SOA lösningar. Där en tjänst kan skapas utan att behöva veta hur den ska kommunicera med andra tjänster. Vi kan alltså efter att en tjänst är skapad, bestämma om den ska kommunicera via remoting eller Web Services etc. Om det är mellan två Windows miljöer, då är remoting bäst (Prestanda skäl). Är det mellan två olika platformar, ja då är Web Services ett bra alternativ. Med Indigo så blir en tjänst fört en tjänst ;) En tjänst ska inte vara en Web Service, den ska vara en Service, om det är med SOAP över HTTP eller binärt via TCP vi kommunicerar mellan tjänster, spelar ingen roll, för en tjänst ska återanvändas oberoende platform etc.

Intressant diskussion. Håller själv på att plugga det nu (mcp) och behöver lite perspektiv från er som jobbat med det lite mer än jag.

Så om jag förstår detta rätt, i princip det enda SOA handlar om är att det är en arkitektur, ett sätt att strukturera upp applikationer på ett tjänstorienterat sätt. Så då spelar det ingen större roll om om man publicerar tjänsten via t.ex marshaling .net remoting, webservices, m-m ? Och i princip borde man kunna göra det i vilken teknologi som helst, t.om som inte är OO baserade? Och allt detta innefattar då SOA ?

ja i princip. En av de viktiga faktorerna i SOA dock är att man använder sig av meddelandebaserade protokoll, så vad som helst kan du inte implementera det med ...