Skulle vara tacksam för förslag på hur jag ska kommunicera mellan klient och server?

http://www.freeimagehost.de/image.php?i=23563-jpg

Det är den delen mellan Local clients och Application Server jag undrar över.

PS. Ledsen för den konstiga länken. Hittade inte hur man bifogar bilder till sina inlägg DS.

Edit: PSS. Fatta inte varför inte lägen fungerar. Ledsen för det också DSS.

Hej,

Vet inte exakt vad du är ute efter, är det ett program som på klienten som skall kommunicera med servern?

ex. går att använda MSMQ, webservice m.m beroende på hur programet fungerar beskriv lite mer så kommer det säkert att dyka upp några bra svar.

/Hendrik

Länk: <url : http://www.freeimagehost.de/image.php?i=23563-jpg> (utan mellanslag)
http://www.freeimagehost.de/image.php?i=23563-jpg

I vilken miljö rullar detta? Tänkbara lösning .NET är t.ex. remoting eller webservice. Har själv bara erfarenhet av webservice-kommunikation för denna typ av lösningar, tycker det fungerar bra, men det beror ju givetvis lite på hur applikationerna jobbar och hur mycket data som överförs.

/Johan

Hej,

Tack för svaret.

Tanken är att klienterna som ligger inom samma nät ska kommunicera med någon slags serverapplikationen. Helst vill jag inte använda webservice för att slipper ha webbservrar på klienterna.

Tanken med att ha en serverapplikation som har en webbserver och kommunicerar via webbservice över internet är att kunderna inte behöver öppna för fler ipnummer än serverns. Om samtliga klienter skulle kommunicera direkt via webbservice skulle man behöva öppna för fler ipnummer.

Tufft att vi postade exakt samtidigt! :)

Är det verkligen ett problem att klienterna kommunicerar över servern via internet? Har inte klienterna möjlighet att köra HTTP mot valfri server ändå?

/Johan

Hej Johan,

Tack för svaret. Vi skrev samtidigt. Och tack för hjälpen med länken.

Som jag skrev är web service inte intressant på kundens interna nät. Ska kolla in remoting och MSMQ.

Det är .NET/C# som gäller.

Du skrev

"Är det verkligen ett problem att klienterna kommunicerar över servern via internet? Har inte klienterna möjlighet att köra HTTP mot valfri server ändå?"

Om jag förstår dig rätt här.... Klienterna kommer att kunna kommunicera över http på port 80 men webbtjänsterna hos partners kommer att ligga på en annan port. Där kommer de default blockera all trafik och måste öppna för specifika ipnummer.

I min värld så hade klienterna kommunicerat med applikationsservern på samma sätt som din webbserver gör, och jag hade valt WCF. Vilket protokoll som du väljer att köra i WCF beror ju på dina krav vid kommunikationen.

Men jag hade inte särskilt kommunikationen mellan den interna web servicen och interna klienterna, och på det sättet haft 2 olika vägar in i systemet, det kommer garanterat bara leda till problem och buggar. Alla anrop till din applikationsserver skall in genom samma väg oberoende om det är en klient eller din webbserver som anropar den.

Om du vill så kan du med WCF även definera 2 olika protokoll att anropa samma metod med. Så du iprincip kan slå ihop din webbserver och din applikationsserver (den behöver inte ha IIS:en installerad) där du låter dina externa klienter anropa via en webservices och de interna via en tcp-anslutning för bättre prestanda...

- M

Du menar så. Det är en god poäng att om de kommunicera på samma sätt minimerar vi buggarna. Dock tror jag inte att vår organisation är redo för WCF. Vi har inte den kompetensen och kan eventuellt inte kräva NET 3.0 hos våra kunder.

Du behöver inte ha en webserver på klienterna bara för att de ska kommunicera med servern den vägen, därmed inte sagt att det är den bästa lösningen. Det räcker med att servern har en webserver installerad (om nu inte servern ska kunna initiera kommunikationen, men i sådana fall är webservice inte rätt lösning...).

Om enda anledningen till att ha en lokal serverapplikation är att kunna kommunicera med webservicen över en icke standard-port så skulle jag övervägt att byta ut den mot en HTTP-proxy. Sparar massa utvecklingsarbete och potentiella felkällor...

/Johan

Det finns fler anledningar till att ha en serverapplikation. Vi vill kunna köra automatiserade jobb, kö upp jobb om kommunikationen ligger ner, etc. Dessutom blir det enklare att deploya om man inte behöver uppdatera alla klienter.

Men nu börjar jag luta mot att kommunicera via webbtjänster internt också. Jag fick för mig att klienterna behövde webbservrar, men de behöver de alltså inte.

Hur gör man bäst om man vill ha ett api mot hela internet och ett som bara ska vara åtkomligt för klienter i det egna nätet?

Om vi pratar webservice finns det ett antal lösningar, t.ex:

- Kontrollera med kod i webservicen avsändar-ip och blockera de som inte är interna.
- Lägga de olika api:erna i olika mappar/siter och begränsa på ip-nivå i IIS.
- Lägga de olika api:erna i olika siter som binder mot olika ip på webservern. Sedan bara tillåta access till det ena ip:t i brandväggen.

/Johan

"Vi har inte den kompetensen och kan eventuellt inte kräva NET 3.0 hos våra kunder."

Du behöver inte kräva .NET 3.0 hos era kunder. Om du bygger din applikation med WCF och väljer att göra gränssnittet som en webservices så kan vem som helst som kan implementera en webservice anropa din server. Java/ VB / Pyhton whatever, det är en standard webservices de ser inget annat.

Internt däremot så kan ni använda WCF för att kommunicera mellan era klienter och applikationsservern, du kan använda webservices där med och använda .NET 2.0 på klienterna, men fördelarna med WCF är så många så att om du sitter med ett nytt projekt och skall bygga det, så se till att införskaffa kunskapen om WCF och använd det, det kommer ni ha igen flera gånger om i ert projekt senare.

Fördelen med WCF är att du kan hosta dina "webservices" i vilken form du vill. Det kan vara i en webserver, i en konsol applikation eller som en windowstjänst. I 2008 så kommer det ännu bättre hostingmöjligheter.

Så mitt tips är, sitter du med nyutveckling så satsa på WCF det tar inte lång tid att få det mest grundläggande på plats. Johan lindfors har gjort några videos om WCF (gå till http://channel9.msdn.com/Sweden och klicka dig igenom de olika videos som finns ner till på sidan så hittar du mycket matnyttigt) som visar det mest grundläggande om hur du får igång det hela. Det är riktigt enkelt och det går snabbt, sedan tar det längre tid att bli riktigt bra och det är svårare att hitta information om man vill in och ändra i flödeshanteringen av meddelanden eller skapa egna bindingstyper (typ UDP)...

- M

Tack för ditt svar.

"Du behöver inte kräva .NET 3.0 hos era kunder. Om du bygger din applikation med WCF och väljer att göra gränssnittet som en webservices så kan vem som helst som kan implementera en webservice anropa din server. Java/ VB / Pyhton whatever, det är en standard webservices de ser inget annat."

Vi hostar inte kundernas lösningar idag. Både server och klienter installeras hos i kundens miljö.

"Så mitt tips är, sitter du med nyutveckling så satsa på WCF det tar inte lång tid att få det mest grundläggande på plats."

Vi har idag en klient som är skriven i .NET 2.0. Om man skulle utveckla två gränssnitt i WCF för kommunikation (ett i klienten och ett på servern), går det att integrera det i .NET 2.0-koden?

"Vi hostar inte kundernas lösningar idag. Både server och klienter installeras hos i kundens miljö."

Okej så både webserver och applikationsservern finns hos en kund hos er, denna kund har i sin tur kunder som kan få tillgång till systmet via webservern, rätt?

Tja, i det fallet så tycker jag att man kan kräva att applikationsservern kan ha .NET 3.0 installerat för att kunna köra er applikationsserver, men det är ju bara jag, ni kräver ju idag att de skall ha .NET 2.0 installerat!!

"Vi har idag en klient som är skriven i .NET 2.0. Om man skulle utveckla två gränssnitt i WCF för kommunikation (ett i klienten och ett på servern), går det att integrera det i .NET 2.0-koden? "

Nu hänger jag inte riktigt med, men WCF kräver .NET 3.0 så det går ju inte att köra på en 2.0 kod. Men 3.0 är kompatibellt med 2.0 så "nästan" inga förändringar behöver göras för att uppgradera er kod och därmed få tillgång till WCF. Men du kan göra följande.

Du kan ha kvar din 2.0 på klienten och installera 3.0 på applikationsservern och där använda WCF som kommunikationsprotokoll, som "binding" så väljer du att använda Webservices, och du kan ni från din .NET 2.0 klient att kommunicera med din WCF lösning via webservices, det är det som är det fina med WCF då får ett sätt att skriva din kod på, men med några enkla ändringar i din config-fil så kan du enkelt byta/lägga till ett protokoll som du kan kommunicera mot din applikationsserver, det kan exempel vis vara att använda MSMQ istället om du behöver det transaktionssäkert och asynkront.

Så med samma kod så kan du ha ett gränssnitt (typ NetTcp) för kommunikation internt inom företaget och mellan .NET program, så helt plötsligt så vill ett Java-program koppla upp sig mot din applikationsserver och då lägger du bara till webservices-gränssnittet i konfig filen och ger java utvecklare din url till webservicen (ingen ändring i koden behöver göras). Där efter så kommer chefen på att all kommunikation till applikationsservern måste vara transaktionssäkert och några ändringar i konfigfilen så har du en MSMQ kommunikation internt i huset och WS-E kommunikation till Java-program, återigen inga ändringar i koden behöver göras....

Kolla lite på filmerna så kommer du säkert förstå bättre...

- M

Det låter riktigt sweet! Tack för tipsen.