Sorry Scott, multicasting is not a prerequisite for nservicebus. It may be for MassTransit I'm not sure. I'm sure you have seen this post:
http://elegantcode.com/2009/10/09/exploring-nservicebus/ HTH. - Steve On 10 July 2011 22:24, Scott Barnes <scott.bar...@gmail.com> wrote: > 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 <slie...@gmail.com> 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 <scott.bar...@gmail.com> 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 <jor...@microsoft.com>wrote: >>> >>>> As a UX developer.. have you drawn a picture of it?**** >>>> >>>> ** ** >>>> >>>> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >>>> ozdotnet-boun...@ozdotnet.com] *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**** >>>> >>> >>> >> >
