cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Talking about configuration
Date Wed, 25 Apr 2007 18:20:21 GMT
On 4/25/07, Johnson, Eric <Eric.Johnson@iona.com> wrote:
>
> I've been thinking about how we talk about configuration....
>
> It looks like we have five different ways to do configuration:
> 1. Plain Spring based configuration
> 2. WSDL extensors
> 3. Feature based configuration which Dan D. recently added
> 4. WS-Policy framework based configuration which Andrea added
> 5. Programmatic
>
>
> From a cxf-developer's POV, this level of flexibility is probably a
> great thing. However, from an enduser POV it is a tad overwhelming. So
> is there a way to simplify the discussion to just a few best practice
> statements...
>
> From what I can see of the Dan's Feature stuff it provides a way of
> simplifying the Spring XML and shields the user from a bunch of
> implementation details. So, when addressing the enduser does it make
> sense to even call this a different mechanism? All the enduser wants to
> know is what XML bits to put into the configuration and where it should
> go.
>
> It sounds like there are a number of features/cases where WS-Policy
> should be the preferred mechanism. I'm thinking WS-RM and WS-Addressing
> or other things that an endpoint wants to advertise.
>
> Transports and bindings will need WSDL extensors, but is WSDL really the
> best place to put configuration?
>
> So I guess what I'm suggesting is that the Spring/Feature stuff is
> advertised to user's as a single mechanism and as the best practice. The
> exception would be features where WS-Policy is the best approach for
> reasons of interop. WSDL extensors are the least preferred option.
> This could provide some clarity to a user.


I agree with 99% of this. *Features are part of the Spring and API
configuration mechanisms, not a separate mechanism

My one exception might be, "Use Policy to configure a feature if a) that
feature needs policy assertions anyway and b) that assertion is completely
sufficient to configure that feature." For instance, the <Addressing/>
policy assertion could be sufficient to add in WS-Addressing to the service.
Maybe thats what you meant to by your exception in the previous paragraph?

Cheers,
- Dan


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message