Re: [proposal] ConfigurationProvider/Bean configuration

[Dan Diephouse <da...@envoisolutions.com>]

Andrea, others - can you let me know if I'm missing something or if we can
go ahead and simplify the configuration layer? Thanks,
- Dan

On 12/6/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> Hi Andrea,
>
> On 12/6/06, Andrea Smyth <an...@iona.com> wrote:
> >
> > Dan Diephouse wrote:
> >
> > Hi Dan,
> >
> > The idea is to be able to supersede the information in the service model
> > with a non-default configuration bean, and only if the latter is not
> > available,  use a default bean. I.e. consider two very different sources
> > (service model on the one hand and bean provider/container on the other)
> > for non-default values.
> > I would consider the service model as something rather static, and beans
> > as more dynamic.
> > One could argue that a contract is a contract, and should not be
> > changed, but in practice it seems a useful thing to do at least in a
> > development environment:  it's easier to change a bean configuration
> > file locally than a wsdl in a possibly remote location.
>
>
> Part of the idea is that the bean configuration file sets properties on
> the the service model. So I could do:
>
> endpoint.setProperty(HttpServicePolicy.class , myEndpointPolicy);
>
> (this can be done in both the Java API and via Spring). And then if we
> support contextual lookups we can even do it at the message level:
>
> endpoint.put(HttpServicePolicy.class, myEndpointPolicy);
>
> Does that alleviate your concerns? I don't think the service model
> configuration beans always need to come from WSDL.
>
> BTW aside from transport policies, WS-policies such as the RMAssertion
> > are candidates where we may want to supersede the settings with beans
> > supplied by the container (the provider to obtain the assertion from the
> > service model is just not implemented/installed yet).
>
>
> So if an endpoint has its own policy the bus policy should override it?
> I'm not sure this makes sense to me. This for governance type scenarios
> where we want to make sure services are conforming to the global policy?
>
> I'm guess that we might actually want to support a bus first approach and
> a service model first approach. Again, it seems simpler to just code things
> in:
>
> WSRMPolicy policy;
> if (isBusFirst()) policy = getPolicyFromBus();
> else {
>   policy = getPolicyFromServiceModel()
>   if (policy == null) policy getPolicyFromBus();
> }
>
> // catch all
> if (policy == null) policy = getDefaultPolicy()
>
> Looking at this type of logic, I don't know that it even works well with
> the configurationprovider approach. Granted in the configurationProvider you
> could have an if "(isBusFirst()) return busPolicy; else return null" - but I
> don't really think thats more flexible ore more desirable than the above.
> The semantics are still hard coded in. And I don't see any use cases which
> aren't covered by setting the beans on the service model or
> message/exchange.
>
> Thoughts?
>
> - Dan
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog