cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Shakirin <>
Subject RE: Calling CXF processing without generating services or clients
Date Tue, 04 Mar 2014 17:10:08 GMT

As I understand you would like to use CXF as framework to compose, transform SOAP messages
and apply security features on it.
However you are going to use own component to physically send the message (internal HTTP transport

I would consider to implement custom transport in this case. CXF will be responsible to create
SOAP message, applying security features, etc - but you can implement own transport factory,
conduit and destination to physically transfer the messages. For more information you can
find in this blog:

It is not necessary to have WSDL and generated code/annotated to create CXF client and services.

You can use generic Dispatch based clients and Provider<T> based services and work with
messages on low level (SAAJ, Source). AEGIS data binding (
provides a facility to marshal/unmarshal java classes without annotations.

In result you will have high level business logic to process requests and responses and invoke
JAX-WS API, then CXF will process messages using interceptor chain and call you custom transport
component to transfer the messages.
Does it make sense for you?


> -----Original Message-----
> From: Engelhardt. Julian []
> Sent: Dienstag, 4. März 2014 14:30
> To:
> Subject: Calling CXF processing without generating services or clients
> Hello everybody,
> I am currently evaluating CXF as a transport framework for one of our
> products. Since this will be an implementation of the AS4 protocol, there is no
> WSDL or such which I can use to generate a Service or Client. Also, the
> component I am working on will be part of a bigger product which has internal
> HTTP transport mechanisms I will have to use. So I think it will not be possible
> to take the “standard” approach. This leads to the question I would like to hear
> your thoughts about:
> How can I use CXF to compose, transform (encrypt, sign, compress, etc.) and
> send a SOAP message without generating a service or a client from a WSDL,
> annotated classes or such?
> Since the developed component will only support AS4, there is not much
> variable configuration apart from URL, processing steps (interceptor chain) and
> content of the message.
> Currently, I am looking for a solution on the client side, however I would
> appreciate any tip. The option that I think would be possible is to create a
> ClientImpl object which I configure from within my code. However, I haven’t
> found a good way to set the content of the message, apart from inserting it via
> an own interceptor (this is not the way CXF does it itself, right?) and it seems
> like there is very much configuration to be done for which I might be able to
> use the configuration mechanisms of CXF. Can you recommend a component or
> approach which will provide a better entry point for this kind of
> implementation?
> Sincerely,
> Julian Engelhardt
> SEEBURGER AG - Edisonstr. 1, D 75015 Bretten, Germany
> mailto:<> -
> SEEBURGER AG            Vorstand/Seeburger Executive Board:
> Sitz der Gesellschaft/Registered Office:                Bernd Seeburger, Axel Haas,
> Michael Kleeberg
> Edisonstr. 1
> D-75015 Bretten         Vorsitzender des Aufsichtsrats/Chairperson of the
> Seeburger Supervisory Board:
> Tel.: 07252 / 96 - 0            Dr. Franz Scherer
> Fax: 07252 / 96 - 2222
> Internet:               Registergericht/Commercial
> Register:
> e-mail:               HRB 240708 Mannheim
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und
> kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material
> enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des
> Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der
> SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail
> irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung,
> Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder
> die SEEBURGER AG noch der Absender ( Engelhardt. Julian ) übernehmen die
> Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren
> Anhänge auf Viren zu prüfen.
> The present email addresses only the addressee which it targets and may
> contain confidential material that may be protected by the professional secret.
> The opinions reflected herein are not necessarily the one of the SEEBURGER
> AG. If you are not the addressee, you have accidentally got this email and are
> not enabled to use, publish, forward, copy or print it in any way. Neither
> SEEBURGER AG , nor the sender (Engelhardt. Julian) are liable for viruses,
> being your own responsibility to check this email and its attachments for this
> purpose.

View raw message