7 svar · 602 visningar · startad av Nickemannen
Hej jag är ute efter exempel på klientapplikationer som inte körs direkt mot en databas utan som har en typ av server imellan.
Finns det några sådana färdiga open source ramverk eller måste man sitta och komma på arkitekturen själv med wcf osv?
Som t.ex. hur en exchange server fungerar, där arbetar ju outlook mot ett program istället för en databas.
Att använda remoting är en bra utgångspunkt...
jo men jag är ute efter mer än bara kommunikationstekniken
nickemannen skrev:
jo men jag är ute efter mer än bara kommunikationstekniken
Varför det? Och ja givetviss!.
Att jobba mot en server/services istället för databasen gör ingen som helst skillnad i ditt sätt att skriva applikationer så länge du inte har några krav på dig. Det blir bara mer kod att skriva. Så du skulle iprincip kunna skriva det precis som du skriver din kod när du jobbar mot databasen, med den skillnaden att du flyttar alla din databasanrop till din server och så får din klient anropa din server, som anropar databasen och skickar tillbaka datan till klienten. Hur enkelt som helst....
Men... Det är nu som själva problemen börjar hopa sig. Hur går det med prestandan, många små anrop över nätverket är inte att rekomender, vad händer när din server går offline, skall din klient fortsätta att fungerar precis som vanligt, skall den fungera med begränsad funktion eller skall den bara dö? Skall man kunna ha flera klienter uppkopplade mot servern samtidigt och de skall jobba mot samma data, eller helt separat data. Vilka krav har du på klienterna, skall vilken klient som helst kunna ansluta (även java-klienter) eller är det endast din egen klient som skall kunna ansluta, och ingen annans...
Du får söka information om SOA, Client/Server, jag tror till och med MS har någon practis and patterns på hur man skall kunna skriva dessa client/server lösningar med disconnected funktion.
- M
Jag gör bara lite research om vad det finns för lösningar för intresseskull.
Min fråga var om det fanns några färdiga ramverk som man kan "plugga in" och konfigurera som t.ex. NHibernate som OR/Mapper.
Det går bra med hur simpla lösningar som helst till komplexare och kraftfullare.
Hur man kan lösa det med tcp/ip och bygga egna meddelanden till att använda remoting och skicka över meddelandeobjekt osv är inte relevant för dom principerna är jag någorlunda insatt efter de kurser jag gått samt egna efterforskningar.
Det du är ute efter är en ESB, Enterprise Service Bus. Hade den här frågan ställts i Java-forumet hade jag förslagit JBoss ESB, men eftersom att vi är i .NET-forat har jag inga ramverk som jag kan rekommendera rakt av - en snabb googling gav dock dessa resultat:
Ramverk:
Microsoft BizTalk
http://www.esb.net.au
http://www.codeplex.com/KeystrokeEsbNet
http://www.neudesic.com/Main.aspx?SS=7&PE=75
Samt en artikel i ämnet:
http://www.keystroke.com.au/MINAsBlog/tabid/59/EntryID/1/Default.aspx
SPiN skrev:
Det du är ute efter är en ESB, Enterprise Service Bus. Hade den här frågan ställts i Java-forumet hade jag förslagit JBoss ESB, men eftersom att vi är i .NET-forat har jag inga ramverk som jag kan rekommendera rakt av - en snabb googling gav dock dessa resultat:
Ramverk:
Microsoft BizTalk
http://www.esb.net.au
http://www.codeplex.com/KeystrokeEsbNet
http://www.neudesic.com/Main.aspx?SS=7&PE=75Samt en artikel i ämnet:
http://www.keystroke.com.au/MINAsBlog/tabid/59/EntryID/1/Default.aspx
Tack :)
Jaha.. Du var ute efter en ESB. Tja jag skulle ju knappast vilja jämför det med en O/R Mapper, mer som ett vanligt Interface med lite godis till.
Vi skrev en liten ESB där jag jobbade förut, och fördelen med denna var 2. Dels så får man ett "interface" för alla klienter som vill anropa olika services, det betyder att jag kan ändra och hålla på med mina services, bryta kontrakt osv osv så länge jag inte ändrar i kontraktet från ESB till klienten. Enorm hjälp när man är i tidigt skede av en SOA implementering.
Den andra stora vinsten var att eftersom ALL trafik gick igenom vår ESB så kunde vi logga ner precis alla anrop och med hjälp av ID och tid, så kunde vi återskapa flödena för en process och se var flaskhalsar var, och eftersom vi sparade ner både anropet och svaret, så hade vi dessutom riktigt data som vi kunde använda för unitest när vi gjorde förändringar i servicen.
Men det underlättade knappast för själva utvecklingen, helt plötsligt så skulle man förutom bygga sin services, så skulle man bygga adapter och frontends till vår ESB. Så rent utvecklingsmässigt så är det knappast lönsamt, men underhålls och driftmässigt så kan man har riktigt stora vinster med det. Vi byggde dessutom in idempotenta (hur stavas det? I allafall så betyder det att även om jag anropar 10 gånger så kommer det bara utföras 1 gång.)webservicesanrop eftersom det inte fanns vid den tidpunkten, vilket var ganska viktigt då det hela handlade om bankverksamhet :)
Men det är ju en fråga om hur mycket som redan finns färdigt som man kan använda sig av, till BizTalk finns ju riktigt många adapters färdiga som kan göra alla möjliga saker, vilket kan korta ner utvecklingstiden avsevärt inom visa områden.
- M
