9 svar · 637 visningar · startad av Walker
Hejsan
Vet inte om jag använder ordet applikationsserver rätt så börja beskriva vad jag menar med det. En server som endast innehåller logiken för ett helt projekt. Man har ytterst tunna klienter som jobbar mot denna, all validering sker här och eventuell distribution av data också.
Min fråga är när behöver man en sådan? Jag har inte sett något som system som använder sig av detta men det används säkert vid större projekt. Men hur stora är dessa projekten? Någon som har erfarenhet av detta?
Menar du isolering av projekt på samma fysiska maskin eller rent av dedikerade maskiner till enskilda projekt?
Stresstesta är det generella tipset jag kan ge angående flera fysiska maskiner.
Det du är ute efter är en SOA (Server Orienteted Aritchture) eller hur det nu stavas.
När behöver man ett sådant system? Enklaste form av SOA möter du varje dag, nämligen en webserver.
Så fort du känner ett behov av Webservices så har du behov av SOA. Alltså när du vill kunna dela med dig av data i en kontrollerad form, alltså du vill kunna kontrollera vad som skickas till dig och vad som skickas från dig och när du kan tänka dig att du har flera olika sorters klienter av olika typer: Webbrowser, winforms, PocketPC, mobiltelefoner.
Här är SOA en utmärkt lösningen eftersom du då endast behöver göra mycket tunna skal till de olika klienterna medans all logik ligger på din applikationsserver. Det betyder givetviss mer nätverkstrafik men samtidig en högre utvecklingshastighet och bättre underhållsmässigt. Skall du endast använda dig av en klient så tar det längre tid att utveckla i SOA.
På vårt jobb så går vi över mer och mer till SOA dock så vill vi behålla OO känslan i klienten vilket gör att vi får en del extra lager samt mer att koda. Här kommer ett lite exempel.
Säg att du har en Bank. Du skall kunna ta fram alla konto för en kund, och även se alla transaktioner för dessa konto.
I OO så blir det så här:
Kund kund = new Kund();
kund.Konto[0].Transactioner()
I SOA så har du inge logisk koppling mellan Kund och Konto och inte heller mellan Konto och Transactioner, utan man måste hela tiden skicka med ett id för att hämta rätt konto/transaction (detta dols i OO för slutprogrammeraren)
så i SOA skulle man skriva så här:
Kund kund = Bank.GetCustomer(KUND_ID);
KontoCollection kontos = Bank.GetAccounts(kund.id);
TransactionCollection transaction = Bank.GetTransaction(kontos.id);
Detta eftersom du i en SOA miljö vill få så löstkopplade system som möjligt (eftersom du vill att andra system också skall kunna använda dig av banken).
Tyvärr så är det inte så enkelt att förstå att en kund har konto kopplade till sig då man måste gå via Bank objectet (som är din väg in på applikationsservern), så det vi gör är att vi wrappar om bank objectet i vårt klientlager:
Det betyder att i vårt Kund objekt som vi skapar lokalt så skriver vi.
public class Kund{
public ICollection Accounts{
get{
return Bank.GetAccounts(this.id);
}
}
}
Nu kan vi i vår webklient skriva Kund.Accounts så får vi alla konto som tillhör denna kund, det är intuativt samt att vi använder SOA så om vi skall skapa en ny applikation som skall använda sig av banken så kan vi kalla på vår Bank.GetAccounts(KUND_ID) och det kommer att ge exakt samma sak. Man kan säga att Bank är en komponent som du har skrivit som lever ett eget liv på en egen server som du kan kalla från vilken klient som helst.
Projekten behöver inte vara speciellt stora, utan då man ser en vinst i att kunna återanvända sig av det man skriver samt att man vill att andra system skall kunna komma åt din funktionallitet. Är det så att du programmerar i .NET och vill att Java applikationer skall kunna komma åt din applikation så är webservices väggen att gå, är det endast .NET applikationer som skall komma åt din applikation så är det .NET Remoting som är lösningen.
Håller precis på med en Banklösning och till detta enkla exempel så har jag inte mindre än 7 olika projekt där 5 av dem iprincip bara är wrappers som wrappar ett underliggande lager. Det gör att det tar lite längre tid att skriva i början men sedan kan jag återanvända min Bank-applikation från andra applikationer.
Hoppas jag inte rörde till det för mycket för dig.
- Magnus
Service Oriented Architecture heter det, allt handlar om tjänster där klienten (som innefattas i SOA) inte ska behöva veta något om implementationen utan endast få tillgång till interfacet till tjänsten. En sak som Gladh skriver är att med denna arkitektur gör man tjänster publika till många olika typer av enheter, där av bör man också ha detta i åtanken när man skapar SOA arkitekturer.
För övrig är SOA en rätt gammal arkitektur som försökts implementeras tidigare med t ex CORBA, där det lyckades med nackdelar så som att det blev väldigt komplext. Vi får väl se var Web Services hamnar när tekniken mognat.
r: Gladh, jag har inte superkoll på det du menar med bank-exemplet. Men menar du att ni inte implementerar OO på serversidan (service providern)?
Gladh, jag har inte superkoll på det du menar med bank-exemplet. Men menar du att ni inte implementerar OO på serversidan (service providern)?
Jodå, det finns en domän model bakom den fasad som syns utåt. Typ så här:
Webservicen har en Method som heter GetCustomer(personnummer) som i sin tur skapar ett nytt objekt Customer (finns i Bank.Domain lagret) som laddas med data från en databas (O/RMapper) och implementerar interfacet IDomainCustomer, detta interface skickas sedan tillbaka från GetCustomer methoden i webservicen.
Klasserna i Domain lagret är dock så tunna och dumma som möjligt, alltså de skall endast innehålla data och veriferingslogik. Resten av logiken som kan behövas hamlar i Process lager alltså i min klass Bank.
Man kan sedan i sin klient välja att skapa en nytt objekt som implementerar detta interface eller bara ha interfacet som en medlemsvariable i denna klass, allt beroend på vilka propertys som skall synas för just denna Customer objektet som defineras i ett Business lager för klienten. Min applikation kanske inte skall kunna visa en massa uppgifter om kunden, och då är det dumt att mitt "FrontEnd Customer" object implementerar alla de properties och methoder som finns på det.
Det betyder att i Bank.InternetBank.Business lager (som känner till Webservicen) så kan jag definerar vilka methoder och properties från IDomainCustomer som skall visas för Customer klassen i Frontend. Det är sedan denna Customer klass uppgift att wrappa in åtkomst till webservicen (eller om det är .NET Remoting som gäller, eller DCOM, whatever!) så att frontend programmeraren inte behöver känna till detta.
För att göra det enklare att byta ut transportlager så känner Customer (i Bank.InternetBank.Business) klassen endast till ett DispatcherInterface och detta interface kallar på ett receiverInterface som i sin tur kallar på Bank klassen. Enkelt uppritat blir det så här:
Bank.InternetBank.FrontEnd.Web
|
Bank.InternetBank.Business
|
Bank.InternetBank.Business.Dispatcher (impl IBusinessDispatcher)
|
(Internet eller lokal nätverk)
|
Bank.Process.Receiver (t.ex en WebServices) (impl IProcessReceiver)
|
Bank.Process
|
Bank.Domain
|
ORMapper
|
Databas
Lager Bank.InternetBank.Business ner till Bank.Domain känner alla till assemblyn Bank.Defenition som innehåller implementationer av Interfacen och övrigt, detta är bra vid .NET Remoting då man annars får lite svårt veta hur IDomainCustomer interfacet ser. Om man använder WebServices så är det inget problem eftersom en WebService genererar denna information till mig så att jag kan skapa de interface och simpla typer som behövs för att kalla webservicen.
- Magnus
Ja, det var ett rätt uttömmande svar på en kort fråga ;) Intressant. Har ni implementerat klienter på pocket-pc sidan eller andra mindre enheter? Jag gjorde ett examensarbete förra året där det skapades klienter på både .NET och java sidan. Där upptäktes problem med att ta emot komplexa objekt på mobila enheter (då j2me). Det hade varit intressant att höra om ni lyckats med detta på .NET och pocket-pc. Jag frågan då du nämnde pocket-pc som tänkbar klient i tidigare inlägg.
Nope har inte sysslat med PocketPc. Lär aldrig göra det på mitt jobb heller (endast internprogrammering för ett kreditinstitut). Nämnde bara PocketPC för att visa på styrkan med SOA.
Om man tar mitt exempel ovan så behöver man ju bara skapa de 3 översta lagerna för få en fungerande lösning på en PocketPC (i teorin alltså).
Anledningen till att vi går över till SOA mer och mer är mest att vi inte vill att andra system skall gå rakt ner i vår databas och hämta och skriva data, utan vi vill ha bättre styr på vad som händer med datan i databasen, så vi ställer ett gränssnitt till förfogande för andra system att använda om de vill ha tag i data hos oss.
Vi har också märk att när man utvecklar en ny applikation så brukar man stötta på att denna applikation skall kunna hämta och processa data som andra applikatiner redan har implementerat och då vinner man ju mycket på att endast kalla en "SOA Fasad" istället för att börja implementerar redan skrivna klasser och skapa logik till dessa. Man blir klokare med tiden och snart så kommer man väl på att SOA inte var så bra och så kommer det en ny teknologi för att lösa alla problem.
Tycker dock att både SOA och webservice är lite hypade ord, båda har ju som du sagt funnits tidigare och är inget nytt. Bara att det kanske har kommit bättre standards och verktyg för att implementera lösningar, men iden är ju inte ny...
- M
Hej, intressanta å bra svar.. webforum e kanon!!
Jag ser fortfarande inte riktigt nyttan med detta. Om du gör ett system så får du väl avgränsade lager, varje modul har sitt eget interface som man arbetar mot och modulerna sätts ihop av det som Gladh nämner som wrappers. SOA ser jag mer som ett interface mot ett annat system/tjänst, denna tjänst kan vara en fasad på datalagret eller ett annat system. Anledningen till att jag frågar är att jag har haft en diskussion på jobbet med en kund och om att vi måste implementera tunna klienter i ett projekt och jag ser inte riktigt nyttan med att flytta ut saker på en separat server. Det blir nog så som Gladh beskrivit men jag har svårt att se hur klienterna blir tunnare och hur man förbättrar systemet. I det här projektet rör det om en typ av system men ett par olika typer av klienter. För jag kommer ändå att behöva validering i mina objekt, jag kommer att behöva objekt som hämtar data från min datakälla oavsett om det är en webbtjänst eller en databas. Man skulle kunna sköta all validering på servern och bara skicka ”dumma” databehållare mellan server och klienten (och jag tror det är detta som de vill), men jag ser fortfarande inte vad man tjänar på detta. Jag kan se nyttan med det om man lämnar systemet och behöver gå mot andra system (men detta rör sig om ett system). Då vill jag ha det ungefär som Gladh beskriver. Anledningen till att kunden vill ha det så här tror jag är att de har varit å lyssnat på MS och hört att man bör ha.
UI
|
Fasader
|
Business Rules
|
Datakälla som snart stavas Yukon
UI och fasaderna skall då ligga på klienten och all validering sker på ”servern”.
Aja får se var detta slutar..
/w
Skall du ha olika typer av klienter som alla jobbar mot samma applikation så är SOA vägen att gå. Är det så att du endast har en klient och inte har några andra system som behöver tillgång till din applikation så är SOA overkill (kul att implementera, men kund uppskatar nog inte den extra kostnad det blir).
Om du tittar på min lösning så behöver du egentligen endast byta ut det översta lagret för att implementera en ny klient. Business och Dispatcher lagret kommer ju vara samma och i business lagret så lägger du validering på respektive objekt, det gör ditt system flexibelt och samtidigt så får kunden sin SOA model. Det är dessutom så att man ha gjort sitt system "framtidssäkert" om man nu kommer på att något annat system behöver tillgång till det.
- Magnus
Gladh skrev:
Gladh, jag har inte superkoll på det du menar med bank-exemplet. Men menar du att ni inte implementerar OO på serversidan (service providern)?
Jodå, det finns en domän model bakom den fasad som syns utåt. Typ så här:
Webservicen har en Method som heter GetCustomer(personnummer) som i sin tur skapar ett nytt objekt Customer (finns i Bank.Domain lagret) som laddas med data från en databas (O/RMapper) och implementerar interfacet IDomainCustomer, detta interface skickas sedan tillbaka från GetCustomer methoden i webservicen.
Klasserna i Domain lagret är dock så tunna och dumma som möjligt, alltså de skall endast innehålla data och veriferingslogik. Resten av logiken som kan behövas hamlar i Process lager alltså i min klass Bank.
Man kan sedan i sin klient välja att skapa en nytt objekt som implementerar detta interface eller bara ha interfacet som en medlemsvariable i denna klass, allt beroend på vilka propertys som skall synas för just denna Customer objektet som defineras i ett Business lager för klienten. Min applikation kanske inte skall kunna visa en massa uppgifter om kunden, och då är det dumt att mitt "FrontEnd Customer" object implementerar alla de properties och methoder som finns på det.
Det betyder att i Bank.InternetBank.Business lager (som känner till Webservicen) så kan jag definerar vilka methoder och properties från IDomainCustomer som skall visas för Customer klassen i Frontend. Det är sedan denna Customer klass uppgift att wrappa in åtkomst till webservicen (eller om det är .NET Remoting som gäller, eller DCOM, whatever!) så att frontend programmeraren inte behöver känna till detta.
För att göra det enklare att byta ut transportlager så känner Customer (i Bank.InternetBank.Business) klassen endast till ett DispatcherInterface och detta interface kallar på ett receiverInterface som i sin tur kallar på Bank klassen. Enkelt uppritat blir det så här:
Bank.InternetBank.FrontEnd.Web | Bank.InternetBank.Business | Bank.InternetBank.Business.Dispatcher (impl IBusinessDispatcher) | (Internet eller lokal nätverk) | Bank.Process.Receiver (t.ex en WebServices) (impl IProcessReceiver) | Bank.Process | Bank.Domain | ORMapper | DatabasLager Bank.InternetBank.Business ner till Bank.Domain känner alla till assemblyn Bank.Defenition som innehåller implementationer av Interfacen och övrigt, detta är bra vid .NET Remoting då man annars får lite svårt veta hur IDomainCustomer interfacet ser. Om man använder WebServices så är det inget problem eftersom en WebService genererar denna information till mig så att jag kan skapa de interface och simpla typer som behövs för att kalla webservicen.
- Magnus
När man kör med flera stycken webservices, hur löser man "problemet" med transaktioner. Har letat lite efter bra exempel på hur man kan lösa detta men hittar inte något bra.. Några tips?