axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
Subject Re: [axis2] turning off WS-A
Date Tue, 04 Oct 2005 04:35:17 GMT
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

Mime
View raw message