Jag sitter med ett system som har en Server och en del klienter där jag använder WCF som kommunikations protokoll. Det verkar resurskrävande med en kö per klient om inte annat. För att svara på din andra fundering, Ja det måste nog bli något sådant, eftersom jag kom på att olika klienter kan flyttas runt och kommer alltså inte ha samma ip-adress längre, och att då spara undan den information och försöka lägga ner information på en kö till en ip-adress som inte finns längre verkar ju inte så vettigt... ja det går alldeles utmärkt, det är bara att adda två endpoints till din service. f-ö är egentligen bästa platsen att disskutera WCF det här: Jag har kommit en bit, men får följande fel: <services> Ja fast då får jag ju 2 proxys också på klient sidan, och det ville jag ju undvika. Så en proxy på klienten kan ha 2 olika bindings på olika kontrakt. nej varför då? Två rader kod ;) "Två rader kod ;) "Arkitektur för offline klient med WCF.
Eftersom det kan finnas flera klienter samtidigt och om någon data i en klient ändras och sparas ner till servern (med köer) så bör de andra klienter få denna information också (typ ett event om att en ny produkt har sparas, och så skickar man med produkten som information i eventet). Nu är det så att klienterna kan gå "offline" tillfälligt eller medvetet. Detta event med att det kommit en ny produkt når då inte dessa klienter, eftersom de är "offline" och de tappar denna information.
Man skulle ju kunna lösa det genom att varje gång som systemet har varit "offline"/avstängt så går den till servern och efterfrågar ALL data för att få helt korrekt information. Men säg att systemet bara råkar gå offline i 2 minuter , pga av någon drar ut nätverkskablen. Då är det rätt "onödigt" att hämta all data igen (det blir ju en del) om det bara är lite eller ingen data som har ändrats.
Det jag funderade på var helt enkelt att varje klient som kopplar upp sig emot servern ger servern en egen kö som servern kan lägga alla förändringar på, och när klienten är online så läser den kön och processar förändringen, skulle klienten gå offline, så sparas förändringarn på kön och när klienten kommer online igen så börjar man processa meddelanden i kön.
Verkar var en smidig lösning eftersom den även kommer fungera som ett eventsystem när klienten är online och spara alla meddelande så länge de är offline och inga förändringar missas.
Mitt problem är nu att jag kan ha flera klienter bakom en router, vilket gör att de alla får samma IP-address som servern skall anropa mot och det ger problem med att man måste öppna upp i routerna på port-nivå och att systemet skall hantera portnummer för att servern skall kunna kommunicera tillbaka till klienten.
Är det någon som har en bra lösning på det problemet, jag vill helst slippa att behöva gå in i routern och öppna nya portar om en ny klient skall installeras. Eller om det finns en annan smartare lösning som inte innebär att klienten ligger och pollar med jämna tidsintervall efter förändringar på servern. (det kanske blir så illa att det är den enda lösnignen, men om jag slipper den är jag glad...)
- MSv: Arkitektur för offline klient med WCF.
Varför inte bara låta klienten spara undan en tidpunkt då den senast fick kontakt med servern och när den går online igen så frågar den efter förändringar som hänt efter den tidpunkten?Sv:Arkitektur för offline klient med WCF.
om du inte skall polla så är du tvungen att använda call-back contracts vilket är enklast med tcp då behöver du inte öppna en port för varje klient utan det sköts i tcp/ips vanliga duplex kommunikation.Sv: Arkitektur för offline klient med WCF.
Så det får nog bli dels call-backs så länge som klienten är online, och när den har varit offline så får den gå och hämta alla förändringar som har hänt efter det att klienten gick offline, får bara komma på något bra sätt att spara undan den information och dessutom sätta någon max-timeline som det är okej att varit offline, och har man varit offline längre än så, så får man hämta alla data igen...
Jag har dock en annan fråga. Jag vill använda mig av köer för att spara ner information till servern medans jag vill använda nettcp för att göra vanliga anrop för att hämta data.
Så här:
SaveOrder() skall gå över en kö
Order GetOrder() skall gå över nettcp.
Kan jag på något sätt lägga dessa i 2 olika interface och där beskriva i config-filen att det ena interfacet har netmsmqbinding och det andra har nettcpbinding men ändå bara exponera 1 interface till min klient, typ så här,
<code>
public interface ISave
{
[OperationContract()]
void SaveOrder();
}
public interface IGet
{
[OperationContract()]
Order GetOrder();
}
[ServiceContract()]
public interface MyService: ISave, IGet
{}
</code>
Så min klient har ingen som helst anning om att det är 2 protokoll som används undertill. Fördelen här blir ju att klienten inte kan välja fel protokoll, den är tvingad till att använda netmsmq när den vill spara något till services...
- MSv:Arkitektur för offline klient med WCF.
<services>
<service name="MyService">
<endpoint address="" binding="netMsmqBinding" contract="IPost" />
<endpoint address="" binding="netTcpBinding" contract="IGet" />
</service>
(pseudo)Sv:Arkitektur för offline klient med WCF.
http://forums.microsoft.com/Forums/ShowForum.aspx?ForumID=118&SiteID=1Sv: Arkitektur för offline klient med WCF.
A binding instance has already been associated to listen URI 'http://localhost:8731/Design_Time_Addresses/WcfServiceLibrary2/Service1/'. If two endpoints want to share the same ListenUri, they must also share the same binding object instance. The two conflicting endpoints were either specified in AddServiceEndpoint() calls, in a config file, or a combination of AddServiceEndpoint() and config.
Så det verkar som jag kan ha 2 olika interface om jag har samma binding, men inte om jag vill ha olika bindings....
- MSv:Arkitektur för offline klient med WCF.
<service name="MyService">
<endpoint address="http://localhost:8731/Service/Post" binding="netMsmqBinding" contract="IPost" />
<endpoint address="http://localhost:8731/Service/Get" binding="netTcpBinding" contract="IGet" />
</service>
typSv: Arkitektur för offline klient med WCF.
Men jag misstänker att man inte kan göra så... det skulle ju varit för enkelt om WCF kunde döljt den logiken för mig i sin proxy klass...
- MSv:Arkitektur för offline klient med WCF.
Eller ja du kan inte ha en och samma <b>automatgenererade</b> proxy men du kan ju ganska enkelt slänga ihop en egen.Sv:Arkitektur för offline klient med WCF.
public class ServiceClient :IGet, ISet
{
private ISet set;
private IGet get;
public ServiceClient()
{
set = new ChannelFactory<ISet>("SetEndpoint").CreateChannel();
get = new ChannelFactory<IGet>("GetEndpoint").CreateChannel();
}
public obj Get(int id) {
return get.Get(id);
}
public void Set(int id, int val)
{
set.Set(id, val);
}
}
är ju en av de enklare varianterna, behöver du credentiels osv kan du ju skapa två automatiska, skapa en över den, implementera interfacen på den och skapa en instans av varje client i den. Sv: Arkitektur för offline klient med WCF.
inte i mitt riktiga exempel där är de fler metoder än så... Just nu blir det 2 clienter, om jag orkar så gör jag om det till 1, men det blir nog inte förren metoderna är helt klara, de ändras fortfarande och nya kommer till....
- M