Hi > 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/>
By that is obviously is not possible for WS-Security features as they need the bootstrapping details (location of keystore, etc). Are you suggesting to have it configured as a WS-Feature, thus having it invisible to the client ? I believe the combination is needed here : all what is needed for a client goes into a visible WS-Policy expression, everything else - into the other available configuration scopes. IMHO this is what should be the flow of reasoning on whether to use a WS-Policy or not. IMHO this is the best strategy. Another comment is that considering a WS-Policy expression as a configuration mechanism is just adds to the confusion. It's just not a configuration mechanism - IMHO at least. Its purpose is to help the client to make a decision or choice. More often than not WS-Policy expressions will contains the details which can be used to configure the server but there'll be cases when they won't contain any details the server can use to configure itself. I believe the more appropriate statement is that a WS-Policy expression may serve as a configuration mechanism for the server if it contains policy assertions understood by both a consumer and the service. few more comments : >> 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. As Andrea noted earlier, WS-Policy expressions can be attached to a variety of attachment points inside the WSDL (inline or referenced, possibly through the EPR) : message, portTypes(interfaces), operation(input/output/fault), binding, service, service/port(endpoint). Things can get merged between each other. So what the endpoint may advertize may in fact be an effective policy which was obtained through the merge of multiple policy expressions attached to say, <wsdl:service> and to <wsdl:service>/port and to wsdl:binding this <wsdl:service>/port refers to... >> Transports and bindings will need WSDL extensors, but is WSDL really the >> best place to put configuration? +1 to not putting server-specific only configuration details into the WSDL....WS-Policy expression though can be used as a WSDL extensor too :-). If this WSDL extensor helps the client to start interoperating then it's a good one (unless it puts say a userpassword in there :-)) Thanks, Sergey ----- Original Message ----- From: "Dan Diephouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, April 25, 2007 7:20 PM Subject: Re: Talking about configuration > 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 >
