PureMVC Architects Lounge

PureMVC Manifold => MultiCore Version => Topic started by: Jason MacDonald on October 08, 2008, 12:32:53

Title: Pipes Best Practice Question for Module-to-Module Communications
Post by: Jason MacDonald on October 08, 2008, 12:32:53
So I've been building a rather large application using Multi-core and pipes (Pure As3, no FLex) and so far have most of the basics working (shell-> module communications, dynamic modules loading etc).

The problem I'm trying to wrap my head around is when you have a DATA module, containing most of the Model/Domain logic for the whole app, that needs to communicate with the Shell's dynamically loaded modules either one-to-one or broadcast to multiple.

I get that I can have the Shell lay down pipes between the data module and all the loaded modules, or have all the modules query up through the Shell to the Data module and then have the data flow back in the reverse order. The issue I can't figure out how to solve is when a module needs a piece of data (value objects in my case) from the Data module but that vo needs to come back to the originating module requesting it only, and not across a broadcast data pipe. This alone wouldn't be too hard I suppose, but I have the flip side where a module requests that same piece of data only this time multiple modules need to react to the returned data. Essentially I need a way to direct traffic of data without having the modules know of each other. Some kind of switch that says "hey, send this data only to me, or send it back to everyone interested". How could you accomplish this without having the Data module knowing the existence of all the modules it's connected to? I can't see how the Data Module could send a message back to only the originator without the message contaning some kind of identifier of the originator.

I'm sure this is probably somehow related to the filter messages but I haven't been able to figure out how they work yet.

My first thought was to send the modules unique ID in the message header if it should come back to it alone (thus being able to check the header of a broadcast response for it's own key), or send the request without a key it if it doesn't care who gets the data back. But that means the Data Module would need to carry around that key somehow from the time the initial request comes through its in-pipe until the time the response message is sent. And this seems rather sloppy somehow especially if it's trying to handle multiple requests at once. Things like, where would you store such a key while the commands do their thing to gather the data needed from the proxies. And how would you map that key so when the data was ready you knew what to do with it. It just starts making my head spinning trying to manage all that. There must be a simpler way.

I hope the above explanation makes sense, my brain is a bit fried right now.

Title: Re: Pipes Best Practice Question for Module-to-Module Communications
Post by: puremvc on October 09, 2008, 05:38:16
Use the AsycToken pattern. Flex has this so I'm going to describe that process. You'll have to do a little work to get your token in pure Flash, but the flow is the same.

Have the requesting module send its name (this.multitonKey in any INotifier), as a property in the message.

Then have the service adapter module set that value on the AsyncToken returned from the service call. For flash only the pattern has prolly been implemented out there, but basically you need to make sure when you've sent of several calls that the return has a value that matches up with a value you sent. That way you know what to do with the returned value based on why you made the call to start with.

When the service returns, look at the token on the ResultEvent,(or in your case, value echoed back by the server in the response). That token has the name of the calling module on it. So the service adapter module just sends it out an output pipe conveniently named the same as this requester.

That's if the service adapter module has named pipes back to each requester (direct instead of broadcast).

Or you could send it back to the shell and let the she'll send it on a direct pipe.


Title: Re: Pipes Best Practice Question for Module-to-Module Communications
Post by: Jason MacDonald on October 10, 2008, 06:18:24
Thanks Cliff. I totally get the async-token, and I may have been misleading in trying to explain my dilemma. The data is already stored in the DataService Module, in it's proxy, all it's doing is returning the VO that are requested via pipes. The dataSerivce module loads a large XML file on start-up and divvies it up into smaller VO's for distribution to the modules on request. I guess my problem is I don't want to have the DataService Module handling a tons of named pipe because they are dynamically instantiated by the Shell. I don't like the idea of the DataService module having knowledge of the actors, albiet just through named pipes. And was trying to avoid shuttling tokens around from module->shell->data and back to track who should respond to what.

I guess there's no real magic solution and I'll have to have someone aware of all the actors [modules] to direct the data traffic. Probably the Shell since it's more tied to the app itself than the modules are.

Thanks for the feed back.

Title: Re: Pipes Best Practice Question for Module-to-Module Communications
Post by: puremvc on October 10, 2008, 07:07:38
Ok so even if the service call isn't involved as a result of the request communication between modules via pipes is async.

If the shell added I/O pipes between Module X (the data module) and modules A, B, and C, its not like the service module now 'knows' these modules, even if their multiton key happens to be used as the pipe name. It merely knows that it has pipes A, B, and C.

So a request Message shows up in its JunctionMediator asking for a certain VO. Ir retrieves the VO from cache and sends a Message back out to the pipe named in the message.

Thats about as anonymous as calling up a restaraunt and ordering takeout. You have to give them your name, but they don't open up a file on you and do a background check on you. Its just so they can give you the right bag later when you pick it up.


Title: Re: Pipes Best Practice Question for Module-to-Module Communications
Post by: Jason MacDonald on October 10, 2008, 07:40:01
Good point. That makes sense. I honestly think I tend to confuse myself more than is needed when trying to get clean separation.

Thanks again.