cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: Some quick thoughts on WSFeature and Policies
Date Fri, 20 Apr 2007 22:29:05 GMT
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


Mime
View raw message