Steve,

Yeah i've just re-discovered the "ooh that's what they were talking about"
moments.. I'm on a network right of passage / quest atm so thanks for all
your patience as each day I'm discovering how Microsoft has failed and then
how solutions like NServiceBus/MassTransit etc have all picked up the ball
on their behalf. Yes, the distribution model on the surface appears to be
the below already code-complete however I still need to test how it handles
the configuration dynamically. Reason being is i deal with Mining companies
who's up-time in both network (global vs local) and machine status aren't
known for being perfect (given the logistical and remoteness of the mines).

For me thats a concern as although each site and its gateways have
 respective role they play in this vision I have is I want the ability to
allow Cashier to take over the role of Barista should Barista call in sick
:) ..in that the code base gets installed on each site but only 20% of it is
switched on. Then if a node fails, the 20% increases to 40% but the
messaging is parked in a queue for when the node comes back online to
process (ensuring a consistent transaction is still isolated in the intended
parts).

I'm hoping the Distribution models in MassTransit is sufficient but failing
that I'll probably go NServiceBus - just ones free, the other costs and
raising Capex/Opex forms isn't fun even if the cost is low.

---
Regards,
Scott Barnes
http://www.riagenic.com


On Mon, Jul 11, 2011 at 1:08 PM, Stephen Liedig <[email protected]> wrote:

> Hi Scott,
>
> I think you need to re-evaluate NServicebus again. The functionality you
> describe can be achieved via nsb saga implementation and using
> the distributor who's job it is to "load balance" messages to your
> respective endpoints. It also doesn't involve monitoring cpu cycles or
> anything else. As far as your your sub domains are concerned these can be
> treated as different sites and could interact via the gateway (
> http://www.nservicebus.com/Gateway.aspx).
>
> Regards,
>
> Steve
>
>
> On 11 July 2011 09:07, Scott Barnes <[email protected]> wrote:
>
>> 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****
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to