Kind of... i even did it via VS 2010 Ultimate Architecture thingies ;) .... and i'm ashamed to admit this but i just discovered Multicasting in MSMQ 3.0 ... so most of the below is kind of free out of the box. In my defense I re-wrote my own Multicasting so that has to win some geek points right?
This is why I should always stay in Photoshop. --- Regards, Scott Barnes http://www.riagenic.com On Fri, Jul 8, 2011 at 10:39 AM, Jorke Odolphi <[email protected]> wrote: > As a UX developer.. have you drawn a picture of it?**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Scott Barnes > *Sent:* Thursday, 7 July 2011 2:07 PM > *To:* ozDotNet > *Subject:* MSMQ Distributed Saga across multiple machines?**** > > ** ** > > I've got a bit of an architectural question (its .NET related).**** > > ** ** > > Using a Starbucks concept, say you have the following services. > CashierService, BaristaService, CustomerService and AuditService. Typical > workflow is that the Cashier, Barista and Customer all exist on their own > instances along with the guy monitoring their behaviors (lets say Starbucks > time in motion study is under way and audit guy is looking for a better way > to optimize everyone's work).**** > > ** ** > > Scenario**** > > ~~~~~~~~~~~~~~**** > > CustomerA walks into the store, orders their beverage of choice. Cashier > takes the order down and responds after x cycles with a price. Barista hears > the order (without asking Customer or Cashier) and begins making the > beverage under the likelihood of the transaction failing being quite low. > Customer then pays Cashier independent of Barista completion state and goes > and waits for the drink. Barista hands the drink to the customer and the > customer triggers a "complete" status by saying thank you to the Barista / > cashier "thanks guys, cya next time" (loud voice).**** > > ** ** > > Given the entire workflow is done via Saga, i'm wondering how this could > play out given each actor i guess represents a server/device?**** > > ** ** > > My thinking so far is the following:**** > > ~~~~~~~~~~~~~~**** > > Customer Sends Message to Cashier. Cashier then Echos the Message to > Barista and Audit (because it knows about these two given they belong to the > Starbucks context/domain). Barista sends acknowledgement to both Audit and > Cashier that the NewOrder was of a known type and begins the > CoffeeMakingWorkflow. Now, the transaction is governed by an AuditService > who's job is to verify the Saga as being complete through-out stages, > meaning the Cashier transacts with the customer and every time a new update > occurs it notifies Audit. Barista then does the same with both Cashier and > Customer but also notifies Audit when it's completed its conditions of > success (in this case, coffee was made and handed to customer). Audit then > does a quick "Ok Money taken, Order handed off.. yes, we're done" and gives > it an immediate final ApprovedForFinalDelivery stamp.**** > > ** ** > > Customer then does one last check "ie does the coffee exist in their hands" > and then tells both cashier and/or barista that they are satisfied with the > transaction. These two then both immediately notify the audit of a customer > confirmation and the audit basically takes the first confirmation and > ignores the rest (first to tell him wins a gold star sort of thing).**** > > ** ** > > Using MSMQ/ActiveMQ/ZeroMQ etc. Basically each time a node connects with > one another it sends the address of where they exist in the gird > (msmq://machinex/nodeX). Each node keeps a local copy of the URI and puts it > into its ping/pong heartbeat check queue (who's sole job is to maintain a > list of live connections for other services/workflows to use).**** > > ** ** > > Each machine has what i'd call a "gossip" service whereby its > entire existence is to re-echo inbound messages through the URI queue (kind > of a distributed multi-cast scenario - or it could very well be that :D). As > it echo's it adds its URI to the "ToldMessage" list (ie the packet gets > handed around the grid with basically a list of URI's that have already been > told the message - based off its CorrelationId). Each node does this until > they have heard the message in which case they ignore all future messages > being sent of them (in case you have a situation where two nodes assume > "BlahMachine" hadn't heard the message and so they in turn tell them (perks > of fire and forget?)**** > > ** ** > > Question:**** > > ~~~~~~~~~~~~~~~~**** > > Given I'm clearly a just a UX Developer, does the above hold water? or am I > just smoking way to many Pixels lately to fully grasp the awesomeness of > publish/subscription servicing across private/public cloud(s)?**** > > ** ** > > ** ** > > > --- > Regards, > Scott Barnes > http://www.riagenic.com**** >
