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 <[EMAIL PROTECTED]> wrote:
Hi Andrea,
On 12/6/06, Andrea Smyth <[EMAIL PROTECTED]> 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
