A New Approach to Inter-Core communication

[conrad]

***** 19/01/2010: I have updated the shell, based on comments from Cliff, new shell is now attached, please read my new post for details of the changes - I think it is even cleaner and lighter now - original post is inaccurate now, but idea remains the same *****

Hi all,

I haven't posted here before, but I have been using PureMVC for well over a year now. I have delivered a lot of apps using the multicore version (large and small), and have used Pipes and Junctions on one big project.

My thoughts on Pipes and Junctions was that it was too complicated and not very PureMVC (sorry Cliff).

I tried to think of another way of doing decoupled module communication and have come up with a system that works at the facade level.

It uses the idea of 'Supervisor' and 'Supervised' facades (although a facade can be both).

A supervisor facade (of which there should be only one) is the router and uses exactly the same Observer pattern as the mediators in order to pass information.

Supervised facades have a 'listSystemNotificationInterests' and a 'handleSystemNotification' method analogous to the mediator methods with similar names.

Facade instances can then call the 'sendSystemNotification' method to send fire and forget inter module messages. There is also a SystemCommand that extends SimpleCommand and has a sendSystemNotification method.

To me this is more intuitive and PureMVC like.

I have attached to attached a project that explains this better (I hope).

The Shell app is the main one and at startup it load a logger swf (which is a puremvc core). The shell is a supervisor facade and the logger is a supervised facade. It is listening for SystemNotification.LOG messages from any other cores that load.

If you press the 'Load Module A' button, then a second module loads up that has a supervised facade. When it starts up it uses a SystemCommand to send a log notification out to the system. The logger catches this and displays the message.

What do people think of this - are there better ways to do what I have done? Is this a valid way to implement inter core communication?


Conrad

[puremvc]

I notice the SupervisingFacade has it's own observer notification system.  This overloads the Facade with responsibilities that fall a bit outside its realm. The Facade isn't supposed to add new functionality but rather to expose the functionality of other actors in a complex system in one place.

That said, I didn't look much further into it, but it certainly might be a functional way of doing things. Try it out a bit and see how you like it in a non-trivial project. See if it poses any problems with memory reclamation when cores are added and removed (be sure to get rid of those observers in the supervising facade).

Also, the framework I mentioned in the other discussion is moving closer to being available. See http://imajn.net for more info and to sign up for the upcoming beta program.

-=Cliff>

[conrad]

Thanks Cliff,

I see your concern about adding the Observer notification system to objects registered with the supervising facade. I also particularly don't like the way in which a supervised facade finds the supervisor (and I wrote the thing :-))

However we have tried it in a small application and it was extremely easy to use, so being a pragmatist we are going with it for the moment.

I have signed up for the Imajn beta, and it sounds very interesting. Hope I get accepted.

Anyway I shall try to sort out the issues you mention and see if I can't make it a little neater.


Conrad

[conrad]

Hi Cliff,

in my beta application I stated that

"In this time I have written one large modular application using it"

and I just wanted to be clear that what I meant was

"In this time I have written one large modular application using it, AND a whole host of non-modular and smaller ones"

:-)

Thanks

Conrad

[conrad]

OK,

I have update the system, and made it even more PureMVC like. There are no longer two types of facade - instead there is just a base SystemFacade. This does not have responsibilities for observer-notifier work, but instead delegates it to a Supervisor. The Supervisor is a bit like View, but it deals with IWorker's instead of IMediator's. IWorker's are registered with the supervisor by any facade/module that extends SystemFacade that wants to listen to system wide notifications.

The first facade to be created that extends SystemFacade creates the single static Supervisor - this would normally be the Shell.

The IWorker's are just like IMediator's - they have names and get registered with a notification system (the Supervisor). However their job is to listen to system wide notifications and translate them into notifications that mean something to the loaded module/core.

Reworking it this way has also made it easy to create a removeWorker method, however as I cannot override removeCore, I can not make this happen automatically when the core is unloaded - the call will have to be in the code of the core itself - however this is not too bad.

Please see the latest attached Shell.zip and let me know your thoughts on this new one :-)

[reduxdj]

OK, I am curious, I have had issues with pipes, where I have to send a message to know when the junctions are created and input output pipes have been connected.  I wish it could be handled in one method, when the module is ready and can interact with framework?

Does your solution provide an easy mechanism to know when your module is complete and hooked up to the framework? 

Thanks,
Patrick

[tinwatchman]

Does your solution provide an easy mechanism to know when your module is complete and hooked up to the framework?

Well, technically, couldn't you just use Facade.hasCore? Provided all of your modules are Multicore?

[puremvc]

OK, I am curious, I have had issues with pipes, where I have to send a message to know when the junctions are created and input output pipes have been connected.  I wish it could be handled in one method, when the module is ready and can interact with framework? Does your solution provide an easy mechanism to know when your module is complete and hooked up to the framework?

Well, technically, couldn't you just use Facade.hasCore?

This only tells you the core is there, it doesn't tell you anything about its state, e.g., readiness to communicate with other cores.

While a core might initialize itself quickly, some cores might take awhile, so logically, no matter what methodology you use to communicate between cores, you need some sort of protocol, whether it be sending a Message off down a pipe, raising an event, exposing a property, or whatever. And even after the core is initialized and ready for business, in its lifecycle, it might go through periods when it is not accepting outside input. So you may need to implement a busy/ready protocol.

-=Cliff>