Hi William and Willem,
thanks for both your explanations. In sum I understand the value of the
cxf component. Still it is quite confusing for users that there are so
many solutions to choose from.
I will try to understand each better and see if I can improve documentation.
As you may have seen I also do some refactorings in the camel-cxf
project. Please feel free to review my changes and say if you donĀ“t like
any of my changes.
Christian
Am 15.06.2011 16:42, schrieb William Tam:
I really don't think so. The CXF component have unique and important
features that simply cannot be replaced by other components in camel-cxf.
Camel transport is a CXF transport that can be plugged into CXF stack.
It is a building block for other components (e.g. cxfbean) and other
use case, but it does not replace CXF component all at
Cxfbean uses Camel transport to host JAXWS/JAXRS POJO and that's it.
The message received cannot be routed to another Camel component and
cannot be used to invoke an external REST/SOAP service.
Cxfrs is the REST's counterpart of cxf. It is quite verbose. By your
logic, we should remove it as well.
As you can see, cxf fills a huge hole in terms of features.
CXF component features:
- consumer (server) to listen for SOAP requests and turn requests into
either POJO, XML parts, or RAW HTTP message. The message is then
routed to other Camel component.
- producer (client) to invoke an external SOAP with given message
(again, it can be POJO, XML parts, or RAW HTTP).
CXF component follows the standard Camel pattern (Consumer/Producer
etc) nicely. The setting up CXF endpoint is pain in the butt but that
is because of how CXF endpoint is setup. That (cxf endpoint setup) is
really the verbose parts of the configuration which do not have
default values.
Can the verbose issue be addressed? Anything that is verbose should be
removed? "The original CXF way" is a CXF user experience. You said CXF
experience is a good thing in Camel Transport' but not in CXF?
On 06/15/2011 09:31 AM, Christian Schneider wrote:
Hi all,
currently we have several ways of using / offering a CXF service with
camel:
- Camel transport for CXF
- cxf: component
- cxfbean: component
- cxfrs: component
The camel transport is useful as it is a very thin layer compared to
the other variants. Additionally it allows to reuse experience from
cxf on how to setup an endpoint.
The cxfbean: component is quite convenient so it makes sense to have it.
The cxfrs: component also seems to be quit econvenient for users.
The cxf: component is very verbose and seems to be used almost
exactly as the original cxf way to describe a service. So I propose
to remove this component. As a migration path I propose users use
either the camel transport for cxf or the cxfbean component.
What do you think?
Christian
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com