On 4/25/07, Johnson, Eric <[EMAIL PROTECTED]> 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
