[Alg/.NET] Service oriented architecture / smart clients

[whoami]

Ik ben begonnen met me te verdiepen in service oriented architecture / smart clients in .NET en ik vroeg me af of er hier mensen zijn die er ervaring mee hebben (al of niet in .NET).

Ik heb al een paar artikels gevonden op Internet, maar meer links naar goeie artikels / tutorials / guides zijn altijd welkom natuurlijk.

Daarnaast: wat zijn jullie ervaringen hiermee? Welke 'pitfalls' ben je tegengekomen, wat zijn de aandachtspunten, hoe zorg je voor 'offline access'; gebruik je hiervoor het Offline Application Block van MS (als je .NET gebruikt) en zoja, wat zijn je ervaring hiermee.
Hoe biedt je die services aan? Heb je hiervoor een business-tier die volledig op Webservices gebaseerd is, of heb je een 'gewone business tier' en daarnaast een tier die als een 'adapter' fungeert voor de business logica dmv webservices oid aanbiedt?
Hoe deploy je de applicatie(s)? Heb je hiervoor een loader-programma dat op de client staat en dat programma laadt dan de uiteindelijke applicatie die in een virtual directory staat op een webserver, gebruik je iets anders, ...

Kortom, heb je interessante links, bepaalde ervaringen, ideeën, .... post het hier.

[Macros]

Een klein groepje studenten (van mij) hebben afgelopen maanden in een paar vrije uurtjes een webpagina opgezet die hevig gebruik maakt van webservices. Persoonlijk vind ik het voor die taak een beetje overkill door de introductie van een extra laag die niet perse nodig is. Verder hadden ze nogal last van de statelessness van de verbinding tussen de webserver en de webservices server.

[whoami]

In dit geval misschien wel, maar waar ik het over heb zijn 'Rich clients' die dus op een local computer of op een portable device draaien, en die data manipuleren die op de server staat. De business logica staat ook op de server, en wordt dmv webservices aangeboden.

Webapplicaties zijn geen smart-clients.

Het is dus de bedoeling dat er zowel online als offline kan gewerkt worden (hoe doe je dit, ga je de data lokaal opslaan en de business logic er al op toepassen, en dan later online synchroniseren, of ga je de data gewoon opslaan, en dan later online inlezen en verwerken?) etc.... (alle andere puntjes die ik in m'n startpost gezet heb).

[Alarmnummer]

whoami schreef op 02 juni 2004 @ 10:23:
In dit geval misschien wel, maar waar ik het over heb zijn 'Rich clients' die dus op een local computer of op een portable device draaien, en die data manipuleren die op de server staat. De business logica staat ook op de server, en wordt dmv webservices aangeboden.

Webapplicaties zijn geen smart-clients.

Het is dus de bedoeling dat er zowel online als offline kan gewerkt worden (hoe doe je dit, ga je de data lokaal opslaan en de business logic er al op toepassen, en dan later online synchroniseren, of ga je de data gewoon opslaan, en dan later online inlezen en verwerken?) etc.... (alle andere puntjes die ik in m'n startpost gezet heb).

Ik denk dat het uitermate complex gaat worden als je dit gaat doen. Hoe moet je omgaan als 2 gebruikers ofline dezelfde data gaan bewerken en later weer online gaan? Stel dat er 0 euro om mijn rekening stond en jij stort 10 en macros stort 20. Wat staat er dan uiteindelijk? 10? 20? 30?

Een mogelijke oplossing zou zijn om met een message oriented architectuur te gaan werken. Je hebt relatief domme clients die messages kunnen maken en eventueel lokaal storen. Op het moment dat ze online komen, worden die messages naar de message-server verstuurd en verwerkt. Dan heb je in ieder geval die problemen niet meer.

Verder is het denk ik ook erg afhankelijk van de situaties welke oplossing je gaat kiezen. Ik heb niet genoeg informatie van je gekregen om een betere oplossing te bedenken.

[edit]
voor het geval mensen geld willen storten op mijn bankrekening om dit te testen be n ik eventueel bereid om mijn bankrekeningnr te geven.

[ Voor 7% gewijzigd door Alarmnummer op 02-06-2004 10:34 ]

[whoami]

Alarmnummer schreef op 02 juni 2004 @ 10:28:
[...]

Ik denk dat het uitermate complex gaat worden als je dit gaat doen. Hoe moet je omgaan als 2 gebruikers ofline dezelfde data gaan bewerken en later weer online gaan? Stel dat er 0 euro om mijn rekening stond en jij stort 10 en macros stort 20. Wat staat er dan uiteindelijk? 10? 20? 30?

Hmm, hier heb je wel een punt. Al is het wel zo dat dit probleem waarschijnlijk alleen optreedt als zowel ik en Macros terzelfdertijd, op dezelfde seconde synchroniseren. De kans dat dit gebeurd is natuurlijk heel klein.

Een mogelijke oplossing zou zijn om met een message oriented architectuur te gaan werken. Je hebt relatief domme clients die messages kunnen maken en eventueel lokaal storen. Op het moment dat ze online komen, worden die messages naar de message-server verstuurd en verwerkt. Dan heb je in ieder geval die problemen niet meer.

Dit zou idd een betere oplossing zijn.

Verder is het denk ik ook erg afhankelijk van de situaties welke oplossing je gaat kiezen. Ik heb niet genoeg informatie van je gekregen om een betere oplossing te bedenken.

Een concreet probleem is er (nog) niet. Ik ben gewoon geinteresseerd in de materie en wil er al eea over lezen/leren, ooit zal ik er wel mee te maken hebben.

[MaxxRide]

whoami schreef op 02 juni 2004 @ 10:37:
[...]

Hmm, hier heb je wel een punt. Al is het wel zo dat dit probleem waarschijnlijk alleen optreedt als zowel ik en Macros terzelfdertijd, op dezelfde seconde synchroniseren. De kans dat dit gebeurd is natuurlijk heel klein.

Dat ligt eraan wat je overstuurd natuurlijk. Stuur je het beginsaldo op en sturen de client beide het gewijzigde saldo op (en dus niet saldo = saldo+10 of saldo = saldo+20 ). Dan is het maar net welke dit als laatste doet.

[whoami]

Idd, dat had ik net ook bedacht.

[Alarmnummer]

whoami schreef op 02 juni 2004 @ 10:37:
Hmm, hier heb je wel een punt. Al is het wel zo dat dit probleem waarschijnlijk alleen optreedt als zowel ik en Macros terzelfdertijd, op dezelfde seconde synchroniseren. De kans dat dit gebeurd is natuurlijk heel klein.

Leg dat maar aan mij uit als ik niet genoeg geld van jullie heb gekregen! Ik denk niet dat ik het jullie in dank af zou nemen In sommige gevallen is het misschien niet ernstig als er iets verloren gaat, maar in andere gevallen (zoals met geld) kun je enorme problemen krijgen.

Stel dat je een server je website hebt staan, en je wilt het ofline ook kunnen bewerken. Dan zou jouw html-editor stiekum een lokaal copy hiervan kunnen maken, en op het moment dat je online komt alles weer synchroniseren. In dit geval is het erg klein dat er 2 mensen op dezelfde data bezig zijn, want tenslotte ben jij een van de weinig mensen die met je eigen site bezig is.

Dit zou idd een betere oplossing zijn.

Een ander groot voordeel aan MOM (message oriented middleware) is dat het ook transactioneel is. Je kunt dus een distrubutes transactie maken waarin je de mom server ook maakt. Je kunt van een complexe actie ondeelbaar maken en zeker weten dat je een alles of niets situatie krijgt.

Een concreet probleem is er (nog) niet. Ik ben gewoon geinteresseerd in de materie en wil er al eea over lezen/leren, ooit zal ik er wel mee te maken hebben.

*geeft beker water* (kan je je borst mee nat maken)

[Alarmnummer]

Pinda schreef op 02 juni 2004 @ 10:39:
[...]
Dat ligt eraan wat je overstuurd natuurlijk. Stuur je het beginsaldo op en sturen de client beide het gewijzigde saldo op (en dus niet saldo = saldo+10 of saldo = saldo+20 ). Dan is het maar net welke dit als laatste doet.

Als jij het lokaal gaat wijzigen, dan staat lokaal gewoon de uiteindelijke data. Bij whoami staat dan 10 en bij macros 20. Op het moment dat ze gaan synchroniseren, wat moet de database dan gaan doen? Alle waarden bij elkaar optellen?

[ Voor 9% gewijzigd door Alarmnummer op 02-06-2004 10:45 ]

[whoami]

Alarmnummer schreef op 02 juni 2004 @ 10:42:
[...]


[...]

Een ander groot voordeel aan MOM (message oriented middleware) is dat het ook transactioneel is. Je kunt dus een distrubutes transactie maken waarin je de mom server ook maakt. Je kunt van een complexe actie ondeelbaar maken en zeker weten dat je een alles of niets situatie krijgt.

Heb je (of iemand anders ) hier soms interessante linkjes oid over?

[Alarmnummer]

whoami schreef op 02 juni 2004 @ 10:48:
[...]
Heb je (of iemand anders ) hier soms interessante linkjes oid over?

Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions

*kijkt ff bij whoami op de hd... hmm.. ik zie hem tussen je andere ebooks staan*

[ Voor 6% gewijzigd door Alarmnummer op 02-06-2004 10:53 ]

[MaxxRide]

Alarmnummer schreef op 02 juni 2004 @ 10:44:
[...]

Als jij het lokaal gaat wijzigen, dan staat lokaal gewoon de uiteindelijke data. Bij whoami staat dan 10 en bij macros 20. Op het moment dat ze gaan synchroniseren, wat moet de database dan gaan doen? Alle waarden bij elkaar optellen?

Ik wil hier alleen maar aangeven dat het resultaat onvoorspelbaar is en dat dit dus geen goede oplossing is. Ik ben het dus met je eens

Je zult niet het eindresultaat moeten opsturen maar de actie die je wilt ondernemen. Ik neem aan dat de MOM dit doet (hier ben ik niet zo heel bekend mee, eens even wat over lezen )

[whoami]

Als je offline werkt, dan zal je toch zowiezo een kopie oid v/d data nodig hebben; hoe wil je anders de gegevens etc bekijken enzo?
Dan kan je de 'lokale' DB aanpassen EN een message oid maken dat je dan verwerkt op de centrale DB vanzodra je online bent. Daarna kan je dan je lokale DB opnieuw laten syncen zodat de situatie op je lokale DB == centrale DB.

Maar, stel dat je online bent. Dat zal je op de een of andere manier moeten detecteren (of, je bent online en plots valt de verbinding weg, ook dat moet gedetected kunnen worden), dan heb je die message queuing eigenlijk niet nodig. Hoe zou je de verwerking dan doen? Of zou je toch zowiezo via messages werken?

Ik zal vanavond ofzo eens op m'n HD kijken, en kijken of dat boek er idd al bij staat.

[ Voor 28% gewijzigd door whoami op 02-06-2004 11:08 ]

[Alarmnummer]

Pinda schreef op 02 juni 2004 @ 10:59:
Je zult niet het eindresultaat moeten opsturen maar de actie die je wilt ondernemen. Ik neem aan dat de MOM dit doet (hier ben ik niet zo heel bekend mee, eens even wat over lezen )

Je kunt MOM natuurlijk net zo inrichten als je wilt, maar ik zou idd ook gewoon een bericht posten met daarin het over te maken bedrag. Dan kan de server zelf wel uitzoeken wat hij er verder mee gaat doen (validatie: geld van een rekening afhalen terwijl er niet genoeg staat) en dan de verwerking ervan.

MOM wordt volgens mij op dit moment nog veel te veel ondergewaardeerd. Met MOM heb je veel minder te maken met threads, je kunt erg eenvoudig alles transactioneel maken en in veel gevallen heb je de complexiteit van synchrone communicatie niet eens nodig. Ik denk dat MOM in de toekomst een veel grotere rol gaat spelen.

Een ander voordeel aan Message based werken, is dat je de internals van allerlei componenten niet naar buiten hoeft vrij te geven (jij maakt een bericht en het zal jou een worst zijn hoe de verwerking ervan uit ziet) en een systeem is daardoor makkelijker te beveiligen te onderhouden. In Software Fortresses: Modeling Enterprise Architectures staat hier veel over vermeld.

[ Voor 4% gewijzigd door Alarmnummer op 02-06-2004 11:09 ]

[Alarmnummer]

whoami schreef op 02 juni 2004 @ 11:06:
Als je offline werkt, dan zal je toch zowiezo een kopie oid v/d data nodig hebben; hoe wil je anders de gegevens etc bekijken enzo?
Dan kan je de 'lokale' DB aanpassen EN een message oid maken dat je dan verwerkt op de centrale DB vanzodra je online bent. Daarna kan je dan je lokale DB opnieuw laten syncen zodat de situatie op je lokale DB == centrale DB.

De volgende situatie: ik heb 20 euro op mijn rekening staan, en ik mag niet rood staan. Jij een macros gaan offline (met die 20 euro in jullie db copy). Stel dat jij 20 gaat afboeken en macros ook, dan zal in jullie db er 0 euro komen te staan en de berichten worden klaargezet. Als jullie weer online komen en de berichten worden verwerkt, wat dan? Heb ik dan -20 euro op mijn rekening staan? Of zal een van jullie afboeken mislukken? Verder loop je ook het risico dat je beslissing neemt over verouderde informatie.

Maar, stel dat je online bent. Dat zal je op de een of andere manier moeten detecteren (of, je bent online en plots valt de verbinding weg, ook dat moet gedetected kunnen worden), dan heb je die message queuing eigenlijk niet nodig. Hoe zou je de verwerking dan doen? Of zou je toch zowiezo via messages werken?

Ik zou sowieso via messages werken en de Message server onderdeel laten uitmaken van je transactie.

Stel dat jij geld over gaat boeken van jouw rekening naar mijn rekening, dan zou je daar 2 berichten voor kunnen gebruiken. Stel dat je nu het bericht van afboeken van jouw rekening hebt verstuurd en bericht van storten op mijn rekening nog niet, en dan krijg je een crash. Wat dan? Dan ben jij geld kwijt, en ik heb er geen geld bij. Als je er een transactie van maakt, dan is het een alles of niets situatie en worden dus 2 berichten gepost, of geen (in dit geval dus geen).

[ Voor 18% gewijzigd door Alarmnummer op 02-06-2004 11:20 ]

[whoami]

Alarmnummer schreef op 02 juni 2004 @ 11:17:
[...]


De volgende situatie: ik heb 20 euro op mijn rekening staan, en ik mag niet rood staan. Jij een macros gaan offline (met die 20 euro in jullie db copy). Stel dat jij 20 gaat afboeken en macros ook, dan zal in jullie db er 0 euro komen te staan en de berichten worden klaargezet. Als jullie weer online komen en de berichten worden verwerkt, wat dan? Heb ik dan -20 euro op mijn rekening staan? Of zal een van jullie afboeken mislukken? Verder loop je ook het risico dat je beslissing neemt over verouderde informatie.

Lokaal zal er dan idd bij alletwee 0 staan, maar je message kan natuurlijk ook een datum oid bevatten.
De message wordt doorgestuurd en verwerkt op de centrale server. Indien er onder 0 gegaan wordt, dan wordt die transactie (de laatste) gerollbacked.

Er kan idd met verouderde informatie gewerkt worden, maar wat stel je dan voor?

Stel dat jij geld over gaat boeken van jouw rekening naar mijn rekening, dan zou je daar 2 berichten voor kunnen gebruiken. Stel dat je nu het bericht van afboeken van jouw rekening hebt verstuurd en bericht van storten op mijn rekening nog niet, en dan krijg je een crash. Wat dan? Dan ben jij geld kwijt, en ik heb er geen geld bij. Als je er een transactie van maakt, dan is het een alles of niets situatie en worden dus 2 berichten gepost, of geen (in dit geval dus geen).

Waarom zou je dat met 2 messages doen? Wat als er één message verloren gaat?
Waarom zou je niet een van-rekening-nr en een naar-rekening-nr in je message opnemen, en bij de verwerking van die message de van-rekeningnr afboeken en het saldo v/d naar-rekening verhogen?

[MaxxRide]

Ook bij dit laatste geval kan er wat misgaan. door het gebruik van een transactie kun je altijd een roll-back uitvoeren als er tussendoor iets misgaat. Pas als alles goed gaat wordt de transactie geconfirmed (weer een staaltje fijn nederlands).

Door gebruik van 2 messages heb je twee atomaire berichten welke je later weer kunt gebruiken (namelijk om te storten en om af te schrijven).

[Alarmnummer]

whoami schreef op 02 juni 2004 @ 11:24:
Er kan idd met verouderde informatie gewerkt worden, maar wat stel je dan voor?

Niets Ik wil alleen duidelijk maken dat het behoorlijk complex is en dat de oplossing volledig van de situatie af zal hangen.

Waarom zou je dat met 2 messages doen?

Het is een mogeliijkheid en in dit geval is misschien een enkele oplossing beter, maar er zijn ook wel situaties te bedenken dat je toch met 2 berichten gaat werken.

Wat als er één message verloren gaat?

Dat mag in principe niet gebeuren. Een message server die is transactioneel en moet zijn inhoud ook op kunnen slaan. De messageserver moet op zijn gat kunnen gaan (en eventueel wat werk verloren), maar een systeem mag nooit in een inconsitente toestand komen. Kortom: een message server moet de ACID eigenschappen ondersteunen (en dus ook de D van durability).

Waarom zou je niet een van-rekening-nr en een naar-rekening-nr in je message opnemen, en bij de verwerking van die message de van-rekeningnr afboeken en het saldo v/d naar-rekening verhogen?

Ik wou alleen duidelijk maken wat het voordeel van transactionele MOM is Het ging me niet om dit concrete voorbeeld.. zeurkous....

[ Voor 5% gewijzigd door Alarmnummer op 02-06-2004 11:34 ]

[whoami]

Pinda schreef op 02 juni 2004 @ 11:29:
Ook bij dit laatste geval kan er wat misgaan. door het gebruik van een transactie kun je altijd een roll-back uitvoeren als er tussendoor iets misgaat. Pas als alles goed gaat wordt de transactie geconfirmed (weer een staaltje fijn nederlands).

Je kan het verwerken van dat ene bericht ook in een transactie uitvoeren:

code:

db.StartTransaction();
try
{
     message.AfboekenVanNr();
     message.VerhogenNaarNr();

     db.Commit();
}
catch
{
   db.RollbackTransaction();
}

Door gebruik van 2 messages heb je twee atomaire berichten welke je later weer kunt gebruiken (namelijk om te storten en om af te schrijven).

[/quote]
Maar, maak je het hier niet ingewikkelder mee? Hoe ga je nl. bepalen welke 2 messages erbij elkaar horen tot die ene transactie?
De transactie bestaat nl. uit het afboeken v/e saldo en het verhogen van een saldo.
Enkel het afboeken of enkel het verhogen is geen transactie.

[MaxxRide]

whoami schreef op 02 juni 2004 @ 11:32:

Maar, maak je het hier niet ingewikkelder mee? Hoe ga je nl. bepalen welke 2 messages erbij elkaar horen tot die ene transactie?
De transactie bestaat nl. uit het afboeken v/e saldo en het verhogen van een saldo.
Enkel het afboeken of enkel het verhogen is geen transactie.

Je zou de berichten kunnen voorzien van een transactienummer (en b.v. aangeven hoeveel berichten er nog komen, of hoeveel berichten er nog komen, een begin en eind van een transactie aangeven; er zijn vast wel manieren voor bedacht om een transactie op te bouwen van elementarie onderdelen).

Waarom zou enkel het afboeken van een saldo geen transactie kunnen zijn? Je zou kunnen denken aan het checken van het saldo en evt. een rollback doen als het saldo onvoldoende is. Je kunt de message zowel stand-alone als, als onderdeel van een grotere transactie beschouwen (zoals het geval van een overschrijving).

[whoami]

Pinda schreef op 02 juni 2004 @ 11:44:
[...]


Waarom zou enkel het afboeken van een saldo geen transactie kunnen zijn?

Omdat je het saldo niet kunt afboeken, zonder daarbij zeker te zijn dat er ergens een ander saldo verhoogd wordt. Waar gaat het geld anders naartoe?
In dit geval bestaat de transactie uit het afboeken en het verhogen van 2 rekeningen.

Je zou kunnen denken aan het checken van het saldo en evt. een rollback doen als het saldo onvoldoende is. Je kunt de message zowel stand-alone als, als onderdeel van een grotere transactie beschouwen (zoals het geval van een overschrijving).

Als je een saldo checked, heb je nog niets aangepast, en hoeft er ook nog niets gerollbacked te worden.

We zijn wel een beetje aan het afwijken.

Hoe zit het met webservices? Waar komen ze aan te pas? Komen ze uberhaupt van pas in dergelijke situaties? Wat doe je mbt deployment? etc...

[MaxxRide]

whoami schreef op 02 juni 2004 @ 11:51:


Omdat je het saldo niet kunt afboeken, zonder daarbij zeker te zijn dat er ergens een ander saldo verhoogd wordt. Waar gaat het geld anders naartoe?
In dit geval bestaat de transactie uit het afboeken en het verhogen van 2 rekeningen.

Er valt te denken aan het opnemen van geld bij een geldautomaat. Hierbij komt uiteraard nog andere administratie (geld wordt uit de automaat gehaald etc). Maar misschien een onduidelijk voorbeeld.

Als je een saldo checked, heb je nog niets aangepast, en hoeft er ook nog niets gerollbacked te worden.

Point taken. Slecht voorbeeld, maar ik hoop dat je begrijpt wat ik bedoel (Er kan een bericht worden teruggestuurd etc)

We zijn wel een beetje aan het afwijken.

Hoe zit het met webservices? Waar komen ze aan te pas? Komen ze uberhaupt van pas in dergelijke situaties? Wat doe je mbt deployment? etc...

Je hebt gelijk, wel een interessante discussie btw

[whoami]

*kick*

Zijn er nog mensen met verfrissende ideeën ?

Ik heb nog wat docjes gelezen over smart clients, maar geen enkel document sneedt het onderwerp message - queueing aan.
Het waren dan wel voorbeeld applicaties waarbij er een verbinding gemaakt werd met een webservice, en dat er dan met die data probleemloos offline gewerkt kon worden (er hoefden ook geen gegevens van de offline cliënt later naar een DB terugvloeien).
Ik ga binnenkort eens eea uitproberen mbt message queue-ing etc...

Hoe zit het trouwens met deployment, upgrades, security, etc...