Hi Some more musings on this subject :-) In my last post in this thread I said WS-Policy should not be considered as one of the main configuration mechanisms. I need to clarify it a bit more. As I said the service configuration which is possible through the use of WS-Policy expressions is a possible side-effect. If, by exposing a WS-Policy expression (which is really targeted at the client first of all) one can achieve all the relevant service configuration at the same time then it's good and should be welcomed IMHO. This is really possible when the same details are equally understood by a consumer and a service provider. MTOM, WSA, other simple assertions come to mind here. But in other cases it's not possible to have all the configuration inside a policy expression, WS-Security would be a classical example. Again, this is fine, because the service bootstrapping details are private to the service, while whatever goes into the publicly exposed policy expression is meant for a client first of all. At the same time, one can apparently use a WS-Feature mechanism (I apologize if I've misunderstood it) to basically wrap all the relevant WS-Security details in one place. But if I were to choose, in this specific case, between : 1. having a WS-Policy assertion to have all the security details for, say, a given endpoint, and using some other mechanism (bean config perhaps) to complete the configuration by specifying the related security bootstrap details 2. having a WS-Feature nicely wrapping all the details in one place
then I'd vote for the 1st option because it helps to automate the interaction between the client and the service. IMHO the criteria which can help to choose between different configuration options is simple : * if this configuration can be wrapped in the WS-Policy expressions such that it can mean something for a client then this option takes the priority; * otherwise use whatever configuration option you have at your disposal and which fits best in a given scenario. In some cases both approaches can be combined (WS-Policy + WS-Feature ?, WS-Policy + bean config), again WS-Security related config would be the good example. I'd also like to stress again that IMHO it might be helpful to look at a WS-Policy expression as a mechanism to advertise the capabilities and help the client to make the decision on how to interact with the service, at design or runtime times. Doing so might help to chose between the config mechanisms. Sometimes a WS-Policy expression may not even contain any configuration.Again, this is absolutely fine, as long as it's of some use to a client Thanks, Sergey Hi I'm not it sure whether it can help this discussion or not, but IMHO it would be better if WS-Policy was not considered as a configuration mechanism equal to other ones. IMHO the main reason the service uses WS-Policy assertions is to tell the outside world what is it that the client needs to be able to do/know in order to succeed in consuming this service, let the client choose the right service through the intersection, etc. WS-Policy assertion is good if it's understood by both the consumer and the provider. The sideeffect for the service is that these WS-Policy assertions might (or might not) help to configure the service somehow along the way, but that's not the goal of the WS-Policy per se, to configure the service. So IMHO if, one exposes the WS-Policy assertion then its primary goal should be help the client; if, by doing so, one can configure the service along the way, then it's fine, and if not then let some other mechanisms to complete the related configuration. For ex, lets take one of the WS-Security policy assertions as an example. It's meant to be attached to one of the attachment points inside the WSDL. The main goal here is to tell the client how it needs to, say, secure a given message. It's not a limitation of this security assertion in that it doesn't bootstrap the service with the related key material config, simply because this is not what this assertion was created for. So the bootstrapping can be completed through some other mechanisms. Cheers, Sergey
