I worry, like others have expressed, that a proliferation of configuration mechanisms threatens to create a crisis of complexity.
People who are going to use CXF to create services are not going to want to have three or four possible ways to configure things. They are going to want to know how it is supposed to be configured (aka the recommended way). For example, if I'm using the HTTP transport what is the right way to configure it in the general case: WS-Policy, Spring, WSFeature, or WSDL? How likely am I to need to stray from the recommended path? Offer people too many choices and they are likely to walk away in frustration. "All I want is a latte damn it!!" This is not an objection to any features, it is more like a request for information. Which is the golden path? > -----Original Message----- > From: Sergey Beryozkin [mailto:[EMAIL PROTECTED] > Sent: Friday, April 20, 2007 6:29 PM > To: Beryozkin, Sergey; [email protected] > Subject: Re: Some quick thoughts on WSFeature and Policies > > 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 > ----- Original Message ----- From: "Dan Diephouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, April 20, 2007 5:29 PM Subject: Re: Some quick thoughts on WSFeature and Policies > Re #1 - Couldn't sleep last night, so what you got instead was a tome on > configuration and policy! > > Both form support schema based configuration - WS-Policy vs Spring XML. > However the WSFeature stuff also allows the more flexible Spring <bean> > based approach. > > With the WS-Policy scenario what happens is you first write your schema. > Then you write interceptors which get inserted into the chain when your > policy assertion is active. This interceptor reads the policy the user > asserted and use it to configure future interceptors. > > With the WSFeature scenario you would first write your WSFeature bean. This > could have various properties (keystores, policies, schema generated config > types, other beans, etc). To enable nice XML you would have to write a > Spring namespace handler (or preferrably use a default one that does the > mapping automagically for you). Otherwise you can fall back to the <bean> > based approach. You could also use the WSFeature easily via the API with > Server/clientfactorybeans. (This could potentially be easy with ws-policy as > well. I'm not sure if this is just missing at the moment or I haven't seen > it yet) > > Does that make sense? > > - Dan > > On 4/20/07, Fred Dushin <[EMAIL PROTECTED]> wrote: >> >> Hi Dan, >> >> Question 1. Are you the 5th cylon? I don't think cylons sleep :) >> >> Not sure how this addresses your question, but I'd like to mention >> something about your WS-Security example. >> >> First, I agree that there is a gap in WS-SecurityPolicy when it comes >> to the specification of key material or user information (such as a >> name or password); that typically is "left to the implementation". >> >> But I want to make sure that the WS-Feature approach you are talking >> about doesn't tie us down to schema-generated types, when it comes to >> programmatic configuration of features. For example, you have some >> example code: >> >> > ServerFactoryBean sf = new ServerFactoryBean(); >> > >> > feature = new WSSecurityFeature(); >> > feature.setTrustKeyStore(...); >> > ... >> > sf.addWSFeature(feature); >> > >> > Or in XML: >> > >> > <jaxws:endpoint ...> >> > <features> >> > <wssec:security> >> > .... >> > </wssec:security> >> > </features> >> > </jaxws:endpoint> >> >> (and equivalently with your policy snippet) >> >> Does this mean that I would be limited, in my feature.setTrustKeyStore >> (...) operation to passing in a string, e.g., a file path to a >> keystore on disk, or (recursively), a schema-generated struct that >> contains a string? >> >> I have a real problem with that approach, which I can illustrate with >> an anecdote. It turns out that Apple, for example, ships a Keystore >> implementation that provides a front-end to the user's KeyChain -- >> this is a place to *securely* place keys, passwords, notes -- >> whatever you want, really. But the thing about this is, you don't >> load the keystore off the file system -- you get to it through >> operating system calls. But all of the ugly nitty gritty details >> about how this is done are hidden by the keystore implementation. As >> a Java programmer, you just to a Keystore.getInstance() with the >> right parameters. I presume Windows users have similar access their >> user-level keys and certificates. >> >> So this is a case-in-point where you might have a POJO you want to >> use to initialize a feature, as it were -- as aI suspect there are >> others. I don't know enough about our code generators to know if you >> can put a POJO on a schema-generated type without violating any >> implicit contracts. Maybe you can, maybe you can't. Maybe the fact >> that you can now is an implementation detail that will change in the >> future. (If anyone knows the answers to these questions, please >> advise!) >> >> So that's the only constraint I would like to see on WS-Features -- >> the ability to use POJOs with them, and not to be forced down to the >> LCD that is XML schema. >> >> -Fred >> > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
