Scott, I have one word for you - *NServiceBus*.
It won't help you draw any nice pictures, but will answer your need for distributed applications using MSMQ. Regards, Steve On 8 July 2011 08:53, Scott Barnes <[email protected]> wrote: > 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**** >> > >
