Hi Deepal!
I can not understand the difference between engaging and switch on a module , as far as module is concern we have two state on that 1. if the module is there in the repository it is available to engage , but none of its handler there in any flow 2. Available module can be engaged to any level , then its handlers will fit into flows depending on configuration.
Yup, and I'm talking about a third level of optionality here, which is about the configuration and behavior of the module in question.
If a module is engaged that really means that its handlers are going to be deployed into active execution chains, both for inflow and outflow. With configuration switches (i.e. properties), you can control the behavior of engaged modules. So for instance, I can tell the security module which profile to use... or perhaps I could tell the addressing module to send headers by default or not. The code in the handlers asks the MessageContext for the properties and behaves accordingly.
In this particular case (turning off addressing), if we had the ability to engage modules separately on the inflow and outflow (can we do that?), it would be possible to get the desired behavior, but then in order to send the headers we'd need to do an explicit module engagement on the outflow side, and it seems a lot simpler to me to just set a property. Then that property would get set either manually by the client code/config, or automatically when addressing headers were received by the inflow.
I agree with you that at any level it should be able to override higher level module engagement.
Uh oh, that's certainly not what I meant (see below :))...
If module has engaged globally , a service foo should be able to say that he does not want that module to be there in that service.
I don't think that's a good idea. If we were to do that, we wouldn't be able to support enforcement of engine-wide policies like security, because individual services would be able to turn them off.
--Glen
