Jag utvecklar för närvarande ett program som ska användas för att registrera försäljningar av varor, ett kassasystem helt enkelt.

Programmet kommer att bestå av en klientdel och en serverdel.

Servern ska ta emot anslutningar från klienten och sedan sköta registrering av data som klienterna skickar till en mysql-databas.

Bör jag använda webservices för detta för att slippa krånglig nätverkskod? Eller är det bättre att skicka serialiserade objekt eller xml över nätverket och skriva en hantering för detta på serversidan?
Eller finns det rentav någon annan metod som är ännu bättre?

Robin,

Du skulle kunna ta dig en titt på COM+ (Enterprise Services). Med dessa kan du skapa distribuerade lösningar (som ligger på olika maskiner t.ex) och kommunicera med dessa. De följer ACID principen för data integritet och du för möjlighet att använda distribuerade transaktioner och rollbaserad säkerhet.

Vad har de för fördelar gentemot webservices?

Det är som att jämföra äpplen med päron.

COM+ erbjuder tjänster för att hantera delade komponenter. En av de tjänsterna är distribuerade transaktioner för att stödja ACID över flera datakällor.

De distribuerade transaktionerna är minst sagt overkill om man arbetar mot en datakälla. Dessutom sänker de skalbarheten och prestandan i din applikation så man bör vara säker på att det är sista utvägen för att lösa sin uppgift.

Man bör veta att för varje COM+ tjänst man slår på för sina klasser, ökar man overhead. Ingen av COM+ tjänsterna är direkt ansvariga för att <b>distribuera</b> komponenter.

Traditionellt har dock DCOM använts i kombination med COM+ för distribution.

WebServices kan jämföras med DCOM, men inte med COM+ eftersom WebServices likt DCOM är framtagna för att kommunicera mellan applikationer och komponenter. WebServices går alltså inte att jämföra med COM+ eftersom WebServices bara erbjuder kommunikation och inga andra tjänster.

Det kan tom vara så att man låter sina WebService klasser använda COM+ tjänster.

För att svara på ursprungsfrågan.


Det finns flertalet föreslagna arkitekturer för att sköta distribuerade applikationer. Microsoft förordar mer och mer den arkitekturen de kallar SOA (Service Oriented Architecture) där WebServices har en central roll.

Man skall dock ha i åtanke att WebServices inte är framtaget för att vara så effektivt så möjligt. Det är en lösning på problemet med olika plattformar och kommunikation över brandväggar på internet.

WebServices är väldigt "pratigt" och arbetar med rekomendationer och standarder som inte är optimerade för prestanda eller skalbarhet. Det är helt enkelt ett sätt att säkertsälla interopabilitet mellan system.

Man skall alltså känna till att det inte är det snabbaste sättet att kommunicera men däremot det enklaste.

Om du bygger ett system där all kommunikation sker innanför samma brandvägg, inom samma domän, på samma plattform och mellan delar av en applikation; kanske man skall använda andra alternativ, som tex Remoting eller DCOM för att distribuera komponenter.

Tänk på vad som händer om nätverket går ner eller om någon snubblar över strömsladden till servern. Kassan bör kunna fungera även utan kontakt med servern om du skall göra det någorlunda seriöst. Det skulle aldrig fungera för en ICA-butik med 24 kassor att ha ett behov av konstant uppkoppling mot servern utan de måste kunna fortsätta att sälja även om servern är nere.

Tack för alla svaren! Nu har ni gett mig lite att fundera över.

Ang om systemet går ner hade jag tänkt lagra det temporärt som i xml som lagras lokalt och sen sparas över till databasen när anslutningen är återupprättad. Vad tror ni?

Det är så man brukar göra nuförtiden.

En äldre mer beprövad lösning är att använda MSMQ för kommunikation. Där kan man köa meddelanden som skickas när den hittar en anslutning till servern.