Used it, preferred MassTransit .. these help with distribution of services etc and also relies on Multicasting to be in place. The problem im having is for some reason when you have a mix of Workgroups with Domains multicasting seems to just fail (still troubleshooting specifically as to why). I figured at worse case assuming multicasting is just above my .net intellect / paygrade :D i'd revert back to a home made version of multicasting (ie keep track of which clients socket into the grid manually).
--- Regards, Scott Barnes http://www.riagenic.com On Sun, Jul 10, 2011 at 9:53 PM, Stephen Liedig <[email protected]> wrote: > 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**** >>> >> >> >
