Re: [jbossws-dev] WS-AT policy integration
by Alessio Soldano
Hi Paul,
On 11/09/2011 05:57 PM, Paul Robinson wrote:
> Alessio,
>
> Can you forward this to jbossws-dev as i don't have permission to email
> the group.
Sure
> Can you give me permission?
You can subscribe here
https://lists.jboss.org/mailman/listinfo/jbossws-dev , it's a public
mailing list
> On 09/11/11 13:28, Alessio Soldano wrote:
>> It might even be possible to have JBossWS-CXF associate
>> that interceptor to the Apache CXF policy engine, so that the
>> interceptor is automatically installed when the server policy requires
>> that... ?
> This could be a good idea. The way we have to specify the client side
> handler is pretty nasty at the moment:
>
> BindingProvider bindingProvider = (BindingProvider) client;
> List<Handler> handlers = new ArrayList<Handler>(1);
> handlers.add(new JaxWSHeaderContextProcessor());
> bindingProvider.getBinding().setHandlerChain(handlers);
>
> My understanding is that we used to be able to define a @HandlerChain on
> the client's SEI, but that feature was removed when you guys realised it
> went against the JAX-WS spec. Is this correct?
I remember some discussion on where exactly the @HandlerChain can be
used on client side...
> The @HandlerChain annotation was certainly nicer than the above method,
> but it was still something extra for the client developer to remember
> and understand. Plus it's absence causes a failure in the service which
> is unlikely to be intuitive to the client.
Right. In any case, afaiu you basically need a JAXWS handler to be added
to the handler chain for having the WS-AT processing happen. That's
certainly something doable automatically when detecting a given
assertion in the policy engine. I need to figure out the details, but
this should definitely be doable.
Btw, in order for improving the API, we might also check if it's
possible to mask the handler addition behind a JAXWS 2.1 feature the
user can pass in when building the client instead of having to go
through the binding provider.
> I don't know how widely used wsat:ATAssertion is on WSDLs for WS-AT
> enabled services, so I don't know how many users will benefit from this
> feature. But automatically generating the handler chain would seem like
> a good approach as:
>
> 1. We can automatically define the handler chain. Less burden on the
> developer.
> 2. We can detect that the client has tried to invoke the service without
> beginning a WS-AT transaction. This gives us control over how we notify
> the client application. Hopefully we can do this in a nice clear way. If
> we leave it up to the service to detect the lack of a transaction, we
> have no control over how the client is notified of the error. For
> example, a badly coded service may throw a NullPointerException (or even
> worse a generic soap fault) when it gets back a null TXID and tries to
> do something with it. It's going to be difficult for the developer to
> realise that a NPE or empty SoapFault from the service is due to them
> not beginning a transaction.
>
> This of course assumes that the service advertises the fact that it
> needs WS-AT, which I think would be good practice.
If using WS-Policy, yes that's indeed good practice. WS-Policy is
becoming more and more popular since it allows for advertising WS-*
functionalities into WSDL contracts. So being able to support the
policies for WS-AT would really be nice.
> On the server side I
> think there should be a simple way of having the wsat assertion added to
> the WSDL. From the WS-AT spec it looks like this feature is required.
> I'll check the XTS code base to see if its already been implemented.
OK, thanks. Basically that's the other half of the topic. I think I
remember that for instance Glassfish has an annotation (@Transactional
or something) to be used for having the server automatically generate
WS-AT assertions into the wsdl contract when that's not provided (code
first approach).
> My main goal with XTS is to improve usability; pretty much everything I
> have planned for XTS boils down to a usability improvement. WS-AT is
> getting some users, but WS-BA very few. We think this is down to the
> steep learning curve of WS-BA in particular. Therefore, this feature
> really interests me as it makes the Client API much more usable.
OK, I think we should probably define what to do and start by creating
some jiras.
>> Btw, the exception the user is getting is actually thrown by CXF on
>> client side, when processing the server wsdl to prepare the client stubs
>> for the invocation. So afaics from the logs, the Glassfish server is not
>> even reached atm.
> Ah ok, I didn't notice that. In that case we may need a new feature in
> CXF to support this. Maybe it's just a matter of creating a plugin that
> understands this assertion. Something for us to investigate.
That's tightly related with what I wrote above, the cxf policy engine
needs to be instructed with our ability of dealing with ws-at
assertions. And that customization is likely to have to be added in
jbossws-cxf.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
12 years, 5 months
JBossWS 4.0.0.CR1 has been released
by Alessio Soldano
JBossWS 4.0.0.CR1 has just been released and is available for download
in binary and source distributions! Since the beginning of the JBoss 4
effort we've been working on more than 150 issues, including many new
features. Have a look at the release notes for details [1][2] and try
the CRs! Feedback is welcome as always!
The release is mainly meant for JBoss Application Server 7 and has been
tested against AS 7.0.0, 7.0.1, 7.0.2 and the current 7.1.0 snapshot.
JBoss AS 6 support is still included, but might be removed by the time
JBossWS 4.0.0 goes final (hopefully soon).
In any case, we're planning to go final by the time JBoss AS 7.1.0.CR1
is released.
[1] http://download.jboss.org/jbossws/ReleaseNotes-jbossws-cxf-4.0.0.CR1.txt
[2]
http://download.jboss.org/jbossws/ReleaseNotes-jbossws-native-4.0.0.CR1.txt
--
Alessio Soldano
Web Service Lead, JBoss
12 years, 5 months
Fwd: Re: WS-AT policy integration
by Alessio Soldano
-------- Original Message --------
Subject: Re: WS-AT policy integration
Date: Wed, 09 Nov 2011 16:57:20 +0000
From: Paul Robinson <paul.robinson(a)redhat.com>
Reply-To: paul.robinson(a)redhat.com
To: Alessio Soldano <asoldano(a)redhat.com>
Alessio,
Can you forward this to jbossws-dev as i don't have permission to email
the group. Can you give me permission?
See below...
On 09/11/11 13:28, Alessio Soldano wrote:
>> By beginning a WS-AT
>> transaction on the Client and using the XTS client side interceptor, the
>> TX context will flow with the application soap message and hopefully be
>> accepted by the policy assertion.
> OK, good. I really need to refresh my memory a bit on the final user API
> provided by XTS. It might even be possible to have JBossWS-CXF associate
> that interceptor to the Apache CXF policy engine, so that the
> interceptor is automatically installed when the server policy requires
> that... ?
This could be a good idea. The way we have to specify the client side
handler is pretty nasty at the moment:
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
My understanding is that we used to be able to define a @HandlerChain on
the client's SEI, but that feature was removed when you guys realised it
went against the JAX-WS spec. Is this correct?
The @HandlerChain annotation was certainly nicer than the above method,
but it was still something extra for the client developer to remember
and understand. Plus it's absence causes a failure in the service which
is unlikely to be intuitive to the client.
I don't know how widely used wsat:ATAssertion is on WSDLs for WS-AT
enabled services, so I don't know how many users will benefit from this
feature. But automatically generating the handler chain would seem like
a good approach as:
1. We can automatically define the handler chain. Less burden on the
developer.
2. We can detect that the client has tried to invoke the service without
beginning a WS-AT transaction. This gives us control over how we notify
the client application. Hopefully we can do this in a nice clear way. If
we leave it up to the service to detect the lack of a transaction, we
have no control over how the client is notified of the error. For
example, a badly coded service may throw a NullPointerException (or even
worse a generic soap fault) when it gets back a null TXID and tries to
do something with it. It's going to be difficult for the developer to
realise that a NPE or empty SoapFault from the service is due to them
not beginning a transaction.
This of course assumes that the service advertises the fact that it
needs WS-AT, which I think would be good practice. On the server side I
think there should be a simple way of having the wsat assertion added to
the WSDL. From the WS-AT spec it looks like this feature is required.
I'll check the XTS code base to see if its already been implemented.
My main goal with XTS is to improve usability; pretty much everything I
have planned for XTS boils down to a usability improvement. WS-AT is
getting some users, but WS-BA very few. We think this is down to the
steep learning curve of WS-BA in particular. Therefore, this feature
really interests me as it makes the Client API much more usable.
> Btw, the exception the user is getting is actually thrown by CXF on
> client side, when processing the server wsdl to prepare the client stubs
> for the invocation. So afaics from the logs, the Glassfish server is not
> even reached atm.
Ah ok, I didn't notice that. In that case we may need a new feature in
CXF to support this. Maybe it's just a matter of creating a plugin that
understands this assertion. Something for us to investigate.
> That's why I suggested the user to try building the
> client from a local copy of the wsdl contract modified so that the cxf
> policy engine does not fail because of required ws-at.
This may not work. It's likely that the service will make the assumption
that it is being invoked in a WS-AT transaction. Totally reasonable
given that any invocations without a TX context should be blocked by the
policy assertion. The service will likely try to enlist participants in
a null transaction which will cause a failure.
>> I'd have to see the WSDL to know if there was an alternative.
>>
>> I can reply on the forum if you would like?
> Yes, please.
> Thanks
> Alessio
>
I'll go do that now.
Thanks,
Paul.
--
Paul Robinson
paul.robinson(a)redhat.com
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)
12 years, 5 months
Re: [jbossws-dev] WS-AT policy integration
by Alessio Soldano
Hi Paul,
On 11/09/2011 02:04 PM, Paul Robinson wrote:
> Alessio,
> I assume there is a wsat:ATAssertion present in the WSDL with
> optional=false. Hence the reason for the Exception.
yeah, that's pretty much my understanding too
> By beginning a WS-AT
> transaction on the Client and using the XTS client side interceptor, the
> TX context will flow with the application soap message and hopefully be
> accepted by the policy assertion.
OK, good. I really need to refresh my memory a bit on the final user API
provided by XTS. It might even be possible to have JBossWS-CXF associate
that interceptor to the Apache CXF policy engine, so that the
interceptor is automatically installed when the server policy requires
that... ?
Btw, the exception the user is getting is actually thrown by CXF on
client side, when processing the server wsdl to prepare the client stubs
for the invocation. So afaics from the logs, the Glassfish server is not
even reached atm. That's why I suggested the user to try building the
client from a local copy of the wsdl contract modified so that the cxf
policy engine does not fail because of required ws-at.
> If he wants to invoke the service in the scope of a transaction, then
> this is the way to go.
>
> XTS does support WS-AT. We have a demo application and some good
> documentation for him to follow.
Good
> I'd have to see the WSDL to know if there was an alternative.
>
> I can reply on the forum if you would like?
Yes, please.
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
12 years, 5 months
WS-AT policy integration
by Alessio Soldano
Hi Paul,
I've just read a message on the forum [1] from an user that's trying to
consume a Glassfish ws endpoint that's publishing a wsdl contract
containing WS-AT assertions.
Currently, the Apache CXF policy engine would basically look for a
viable policy alternative not containing the WS-AT assertions, as those
are not recognized.
Should the user actually be using JBoss XTS directly and how in this
scenario?
The Apache CXF policy engine is for sure configurable, however I'm not
sure which kind of integration between Apache CXF / JBossWS-CXF and
JBoss XTS we really need and can have here. Any thought?
Cheers
Alessio
[1] http://community.jboss.org/message/635620#635620
--
Alessio Soldano
Web Service Lead, JBoss
12 years, 5 months