I want to force modules to communicate through passing data back and forth and by announcing events. I do not want to allow a model inside of a module to be used by the application or by any other module. However, I would still like to be able to use wirebox dependency injection to compose a model (for use inside its module).
Has anyone else tried to do this? Any tips?
how would i access a service layer in another model within my current model?
i could inject the request context, controller and whatever else into my model and use runEvent() but then i start coupling the controller level with your model. also, i wouldnt want to start passing around event-centric function inside my models. just like i wouldnt want to mess with session items in my model. keep them decoupled.
if you can keep all of the logic on the controller level, you can raise events and runEvent() and start placing things inside the request context as you pass it around.
Maybe some explanation is in order. We are considering modules as a step towards a Services Oriented Architecture (services on a network communicating through messages like http or message queues rather than in memory objects). If I can prevent modules from exposing all of their internals for other modules to fiddle with and force them to pass messages back and forth (even if they are in memory) then I’m hoping that will teach us something about what a SOA would look like for us.
So ideally, I would want other modules to make an http request to an api. If that’s a bridge too far, I would be satisfied with simply exposing only one object that represents the public api of the module. Not sure which would be best, but it could be a model, handler, or plugin component.
i write API’s as an entire application of its own. its handlers use module models, or events. whatever is called for.
also, all my modules talk with each other if needed. of course, now theyre coupled but thats how the cookie crumbles.
i start announcing events when logic calls for it. if the logic says “whomever is subscribed will listen but who cares what they do”.
with what you explaining, your modules are islands of their own which to me means a big multi-app system. like… SOA’s talking to other SOA’s.
but your scope might call for that.
For the record there’s nothing with modules being dependant on the API of another module if they’re separated simply for organizational purposes or because they’re developed independently. If you want to have your modules be distributed to the point where a certain “service” could be running on a separate server or servers, I would recommend looking into either REST endpoints or message queues based on needs. (I think both you and I know someone who is a fan of those 
Interceptors are powerful and even asynchronous, but they assume the subscriber is in-process.
If the remote call needs to be made synchronously as a requirement for the initial request to finish I would lean towards an API exposed perhaps via a local “client” service that abstracts the REST/HTTP aspect of it.
If these services are for offline data synchronization, logging, or async operations in general I’d recommend looking at message queues, perhaps even fired via interceptors. You’d need to weight if the layer of abstraction and moving parts is worth the trade off.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Brad,
I’m not really expecting to deploy ColdBox modules as RESTful services. I’m just hoping we can learn about the logical boundaries within our application and what our services might be in a SOA. I completely agree that modules may rightly depend on the public APIs of other modules, I’m just trying to find a way to limit that public api as much as possible.
I think I’m close to a solution with configuring a new Injector for the module. I’ll post back if it works out.
Thanks for the advice, as always.