Yeah, the issue isn't so much how i transport messages between machines NServiceBus/MassTransit do that job extremely well. The problem is around how one can multicast the message to machines within a given subnet. In that, say you have 20 Barristas and your order contains the property "QTY" ,..You order 20 Coffee's via 1x message. Lets say for arguments sake you want to keep each Barrista on an individual machine because of CPU cycles it takes to make coffee - Java Applet anyone (bwahhaha).
Anyway, doing IP Multicasting via MSMQ works well out of the box and assuming your router/machines aren't configured to ignore it (all do by default). You can then send the message to your bus whom then broadcasts to all machines on the network automatically (so all you then have to do is ensure each machine is listening on a specific Multicast IP : PORT. The problem below is that Multicasting via IP isn't feasible (i want to say reliable, but technically when setup it's reliable, its more SOE/Enterprise network security overloard that shuts this down). So instead of relying solely on multicasting one has to kind of make their own using Dijkstra's algorithm (etc)..(ie maintaining your own network casting based off hop locations that or simply a list of machines connected per machine). For instance in the office today I tested a basic Starbucks example out. My laptop (workgroup) sends message out to network machines (DOMAIN). 3 Machines are connected via LAN to the DOMAIN one via Wireless. One of the machines is also a virtual. (LAN) Virtual Machine - Domain - Failed. (LAN) Laptop - Workgroup - Success. (WIFI) Laptop - Workgroup - Success (LAN) Machine01 - Domain - Failed. (LAN) Machine02 - Domain - Success. (LAN) Machine03 - Domain - Success. (WIFI) Machine03 - Domain - Failed. I troubleshooted the problems (restarted MSMQ service each time i switched from LAN to WIFI etc) and it just kept reproducing the above? yet nothing really has changed on each machine (Firewall disabled, Fresh installs of Windows 7 etc). Yet all of the above succeeds when i do 1-to-1 MSMQ messaging!! My head hurts. --- Regards, Scott Barnes http://www.riagenic.com On Mon, Jul 11, 2011 at 10:55 AM, Stephen Liedig <[email protected]> wrote: > 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 <[email protected]> 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 <[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**** >>>>> >>>> >>>> >>> >> >
