Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: communication between application instances via FMS  (Read 8683 times)
inconduit
Newbie
*
Posts: 9


View Profile Email
« on: March 02, 2009, 09:22:35 »

i've got a multiuser interface that communicates via FMS. would it be possible to serialize notifications and broadcast them to other application instances, via Flash Media Server? i want to avoid a lot of building classes to translate what comes in from FMS, and just pass the message along.

thanks for the help so far
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 03, 2009, 06:25:00 »

I don't think you'd want to use a notification for that purpose. The body is just an Object. Its handy for tossing things around inside a running app but for app to app (or module to module) communications, the IPipeMessage (defined in the pipes utility) would be a better bet. Its far more versatle, and doesn't make any assumptions about the recipient in terms of having the same notification names defined for the same purposes.

-=Cliff>
Logged
inconduit
Newbie
*
Posts: 9


View Profile Email
« Reply #2 on: March 04, 2009, 10:57:26 »

thanks for the response cliff, i really appreciate it.

i've been reading about pipes utility, and conceptually i understand it within the multicore context.  at an abstract level, it makes sense to me to treat different application instances as modules, but in practice i don't know where to begin with it.

i will have application instances running on different computers, but will want to synchronize their states in part, or in whole.  it's not clear to me how or if i could easily establish VM to VM communication with pipes over a network - i do use Flash Media Server so i figure that will be the delivery method, but can't quite see yet how that would be accomplished with Pipes.

what i envision is that the execution of a Command would occur in one VM (triggered by a Notification), and then dispatch that Notification over the network to other subscribed VMs, and then those VMs would trigger execution of the same Command as though it were triggered within their own VM.  i suppose it would be some sort of application mirror.

what i'm trying to avoid is writing code for each Notification to serialize and deserialize/demux it to send/receive across the network to another VM.  i'd like to send a Notification out to inject into another identical VM and have that VM treat the Notification as though it were issued by itself.

the IPipeMessage (defined in the pipes utility) would be a better bet. Its far more versatle, and doesn't make any assumptions about the recipient in terms of having the same notification names defined for the same purposes.

you've suggested using an IPipeMessage as the message currency, but i'm okay with the recipient (another application instance) making assumptions about identical notification names for the same purposes, since i'm just trying to synchronize multiple application instances.  should i still consider using an IPipeMessage? how could i establish a Pipe across a network to an app instance running on another computer (via Flash Media Server)?

i'm sorry if it sounds like i've just repeated my first question, but i felt like i didn't describe it well enough.  any further ideas would be greatly appreciated.

thanks
« Last Edit: March 04, 2009, 12:55:20 by inconduit » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: March 05, 2009, 06:13:19 »

What I'm suggesting is a MultiCore app that uses IPipeMessages internally and when it needs to communicate with other instances of itself, it does so by passing IPipeMessages across the line as well.

Notifications are simply not suited for this purpose, as the payload body is not strongly typed. If you go with notes you'll find yourself making custom ones or doing funky things to marshall/unmarshall them. IPipeMessage is more robust and meant for this sort of thing.

I'd have a module in charge of comminicating with the other systems, sending and receiving messages on behalf of the app.

Its up to you, that's just my 2 cents.

-=Cliff> 
Logged
inconduit
Newbie
*
Posts: 9


View Profile Email
« Reply #4 on: March 05, 2009, 12:10:38 »

thanks again cliff.

can you clear this up for me?  a Message (implementing IPipeMessage) has a few more attributes than a Notificiation, and the body in both is an object, so i'm just not seeing how an IPipeMessage is more versatile / strongly typed than a Notification. 

I just don't see how using an IPipeMessage will help me avoid marshalling/unmarshalling the body payload compared to a Notification.  and i really still can't see how i could send an IPipeMessage across the line more easily. 

can you give me a simple example?  i'm sorry i'm being so thick on this.  i've read joshua orstrom's little tutorial on understanding pipes, and i get the overall structure, but even in his example he's doing marshalling /unmarshalling of messages to notifications between the modules and the application.


Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: March 05, 2009, 06:18:14 »

Generally you'll make subclasses of PipeMessage and give them typed properties. With a notification you can do this as well, but to use typed notifications, you must eschew the sendNotification convenience method (which builds a standard notification and sends it), and instead create your own custom notification instances and send them using facade.notifyObservers().

And on reciept, you don't need to unmarshall the pipe message into a notification, just tunnel the pipemessage itself to the internal recipient actor in the body of a standard note. That recipient then gets the equivalant of a VO; a typed object that it casts and uses. The benefit over just using a VO is that you can also pass then through pipes in your app. This let's you abstract your service into a module which you can replace with a mock service module.

To each his own, though. If you don't want to use pipes and pipe messages, you don't have to, its just the way I'd go personally.

-=Cliff>
Logged
Pages: [1]
Print