[jbossws-dev] Re: JBossWS 3.0.3 jira issues and stack comparison

[Richard Opalka]

I'll try summarize:

WSA on CXF:
  CXF endpoint needs extra CXF DD to be included in endpoint archive. 
This CXF DD includes WSA feature definition.
  CXF client needs extra config too to be used to configure CXF client. 
This client config specifies WSA feature is in place.
WSA on Metro:
  Programmers just need to specify <UsingAddressing/> WSDL extensibility 
element in contract and both Metro runtime
  and client are able to recognize this and act accordingly. Thus on 
Metro it's completely contract driven behavior.

WSRM and WSP on CXF:
   CXF endpoint needs extra CXF DD to be included in endpoint archive. 
This CXF DD includes WSPolicy referencing WSRM policy definition.
   CXF client needs extra config too to be used to confgure CXF client. 
This client config specifies CXF features to be used (e.g. WSRM, WSP, WSA)
WSRM and WSP on Metro
   Programmers just need to specify WSP extensibility element including 
both addressing and RM assertions in contract WSDL + provide 
wsit-ENDPOINT.xml file to activate that features.
   Metro client doesn't need extra configuration. It's again contract 
driven. But wsit-rt.jar must be on client classpath to let WSRM and 
other Metro WS-* features be functional on client side.

To recapitulate:
   CXF is just configuration driven.
   Metro is fully contract driven.

The question is: What's better approach?. Both of them have their 
pros/cons :)

Richard

Alessio Soldano wrote:
> Hi Richard,
>>> Finally, some thoughts I came up to rearding the stack comparison 
>>> topic (as you remember, last time in Munich we said we would have 
>>> unlocked wsse, wsrm, wsa, etc in all stacks and them evaluated them).
>>> In terms of WS-Security, the CXF stack doesn't offer something 
>>> really special we don't have in native. It has a proprietary 
>>> security configuration almost the same way we have, while the 
>>> documentation and testsuite is really poor on this topic. On the 
>>> contrary, our native stack documentation and available tests on 
>>> WS-Security are pretty good, imho, also thanks to the improvements 
>>> we did on the wiki in the last months. In terms of features 
>>> comparison, native and cxf are almost equal, with a slight 
>>> preference for native thanks to the better jaas integration with 
>>> jboss as.
>>> The Metro stack, instead, actually offers much more than what we 
>>> have in Native. I'm not talking about the WS-Trust, 
>>> WS-SecureConversation, etc. we don't have at all in Native. WSIT 
>>> supports WS-Security 1.1 and WS-SecurityPolicy, which basically 
>>> means more features than wsse 1.0 and a standard way of configuring 
>>> them all (through policies). Native of course is better integrated 
>>> with the jboss as, but we can work on this topic (see JBWS-2209 for 
>>> example).
>>> In short, imho moving to CXF wouldn't give us nothing more in terms 
>>> of ws-security, while moving to Metro would require us some further 
>>> work but might potentially give us a lot of new features (indeed we 
>>> already got WS-Security 1.1 and WS-SecurityPolicy covered by tests 
>>> in this 3.0.2 release). Of course wsse is only a (little) slice of 
>>> the whole cake...
>>> Did you come to some other conclusions?
>> I need to dive into both CXF and Metro stacks more and then I'll do 
>> the conclusions. Thus I have no opinion yet on this topic.
> Just to be clear... I meant some other conclusions (or feelings) in 
> other ws area you all have worked since last meeting in Munich, like 
> wsrm, wsa, etc. not in the ws-security field.
> Cheers
> Alessio


-- 
B.Sc. Richard Opalka
Senior Software Engineer
JBoss, a division of Red Hat

Mobile: +420 731 186 942
Mail: ropalka at redhat.com