You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Lowry <lo...@gmail.com> on 2014/07/10 17:21:44 UTC
cxf transform feature for Declarative transform in camel route
I have a camel route that starts with a cxfEndpoint1 (consumer) that works as
a CXF server and represents the interface defined in wsdl1. The route is a
pass-through route that sends to a backend web service using CXFEndpoint2
(producer) pointing to wsdl2.
The interface for wsdl1 (incoming) is slightly different (different element
names, and namespace) than the outgoing wsdl2 interface. We need to
introduce transformation in between that transforms message.
I'd like a strategy for introducing transformation that is declarative and
doesn't force me to write java DOM code or XSLT. I found the CXF transform
feature and it looked promising. I'm using it in my route. But i'm having
some issues.
Is it designed for such a use-case? The problem i have is that the
transform seems to occur on entry before the message "hits" CXFEndpoint1. So
if I apply the transform feature to the CXFEndpoint1 (listener), and the
transform defines namespace or element changes (goal is to conform the
message to wsdl2) then I get an exception that the operation name or
namespace is incorrect. I'm guessing its because by transforming the
message at CXFEndpoint1 at an interceptor that occurs before the message is
validated against WSDL1, so it breaks.
So i'm coming to the conclusion that the transform feature is not a good way
to achieve my goal of a generic all-purpose declarative tranfomration
strategy in a camle pass through route from one CXFEndpoint (consumer) to
another CXFEndpoint (producer).
Can someone deny or confrm my thoughts on this, or recommend an approach to
do this type of declarative mapping / tranform simimilar to CXF transform
feature that would allow me to accomplish?
--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf transform feature for Declarative transform in camel route
Posted by Lowry <lo...@gmail.com>.
Thanks a lot.
Using the generic provider (without WSDL) to disable the operation check on
message sounds like our best way to utilize the CXF transform feature as a
generic transformation mechanism within our camel routes. We'll give that a
try. Thanks for your help!
--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295p5746483.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf transform feature for Declarative transform in camel route
Posted by Aki Yoshida <el...@gmail.com>.
Hi Lowry,
good to hear that the suggested workaround worked for you.
Regarding your question of using WSDLs at the server side endpoint,
the purpose of using a WSDL is to do the operation checking and some
special handling based on the determined operation and also to provide
a way for the consumer to get the typed interface information (i.e.,
retrieving the WSDL from the endpoint). In your case, you need neither
of these, so you could just simply set up your endpoint using the
generic provider mode (i.e., omitting the wsdlURL and serviceClass
properties of the endpoint).
In this case, the message will be transformed using dxf's transform
feature and directly transferred to your camel route where you can do
further modification necessary and set the operationName header to
match the operation at the outbound endpoint.
regards, aki
2014-07-11 17:23 GMT+02:00 Lowry <lo...@gmail.com>:
> Hi Aki,
> Yes, you understand my scenario and my struggles well. The setup you
> describe does seem to be an option.
> client(wsdl1) --> EP1(wsdl2)/trans--camel-route- EP2(wsdl2)-->
> service(wsdl2)
> The only issue i have with this is that, while the incoming request (WSDL1
> versus WSDL2) is pretty similar, the response from backend service (WSDL2)
> is quite different from the response expected by client (WSDL1).
> Response requires quite a bit of manipulation. After invoking the backend
> service, the response adhering to WSDL2 propogates back through my route.
> Transforming the response from WSDL2 to WSDL1 requires some enrichment from
> external system and more work than the CXF Transform feature is capable of.
> So much manipulation that I'd like to be able to perform some of this from
> the camel route - after the call to backend service (but before message
> passes back through EP1 and response sent back to client.)
>
> With the setup you describe, If I do this tranformation in Camel route, I
> assumed things would blow up when modified response hits EP1 on the way back
> to client, but i found that is not the case. The EP1 will pass the response
> back (malformed according to WSDL2) to client without the operation/binding
> mis-matching I see on the way in if i send a malformed request. So i think
> the solution you suggest works for my scenario. Thanks!
>
> I'm curious, In order to use of CXF transform easier within Camel.. Is there
> any way to disable requirement that operation/binding match in CXFEndpoint
> on incoming requests? That way i could disable this requirement at the
> Endpoint so i could freely apply tranform into any format at the endpoint
> and it wouldn't blow up. Otherwise I can only transform into something that
> conforms with the WSDL the endpoint is tied to. Although in doing so I
> realize I may be abusing somewhat the use-case this feature is intended for.
> Thanks,
> -Lowry
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295p5746339.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf transform feature for Declarative transform in camel route
Posted by Lowry <lo...@gmail.com>.
Hi Aki,
Yes, you understand my scenario and my struggles well. The setup you
describe does seem to be an option.
client(wsdl1) --> EP1(wsdl2)/trans--camel-route- EP2(wsdl2)-->
service(wsdl2)
The only issue i have with this is that, while the incoming request (WSDL1
versus WSDL2) is pretty similar, the response from backend service (WSDL2)
is quite different from the response expected by client (WSDL1).
Response requires quite a bit of manipulation. After invoking the backend
service, the response adhering to WSDL2 propogates back through my route.
Transforming the response from WSDL2 to WSDL1 requires some enrichment from
external system and more work than the CXF Transform feature is capable of.
So much manipulation that I'd like to be able to perform some of this from
the camel route - after the call to backend service (but before message
passes back through EP1 and response sent back to client.)
With the setup you describe, If I do this tranformation in Camel route, I
assumed things would blow up when modified response hits EP1 on the way back
to client, but i found that is not the case. The EP1 will pass the response
back (malformed according to WSDL2) to client without the operation/binding
mis-matching I see on the way in if i send a malformed request. So i think
the solution you suggest works for my scenario. Thanks!
I'm curious, In order to use of CXF transform easier within Camel.. Is there
any way to disable requirement that operation/binding match in CXFEndpoint
on incoming requests? That way i could disable this requirement at the
Endpoint so i could freely apply tranform into any format at the endpoint
and it wouldn't blow up. Otherwise I can only transform into something that
conforms with the WSDL the endpoint is tied to. Although in doing so I
realize I may be abusing somewhat the use-case this feature is intended for.
Thanks,
-Lowry
--
View this message in context: http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295p5746339.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: cxf transform feature for Declarative transform in camel route
Posted by Aki Yoshida <el...@gmail.com>.
2014-07-10 23:04 GMT+02:00 Sergey Beryozkin <sb...@gmail.com>:
> HI,
>
> On 10/07/14 16:21, Lowry wrote:
>>
>> I have a camel route that starts with a cxfEndpoint1 (consumer) that works
>> as
>> a CXF server and represents the interface defined in wsdl1. The route is a
>> pass-through route that sends to a backend web service using CXFEndpoint2
>> (producer) pointing to wsdl2.
>>
>> The interface for wsdl1 (incoming) is slightly different (different
>> element
>> names, and namespace) than the outgoing wsdl2 interface. We need to
>> introduce transformation in between that transforms message.
>>
>> I'd like a strategy for introducing transformation that is declarative and
>> doesn't force me to write java DOM code or XSLT. I found the CXF transform
>> feature and it looked promising. I'm using it in my route. But i'm
>> having
>> some issues.
>>
>> Is it designed for such a use-case? The problem i have is that the
>> transform seems to occur on entry before the message "hits" CXFEndpoint1.
>> So
>> if I apply the transform feature to the CXFEndpoint1 (listener), and the
>> transform defines namespace or element changes (goal is to conform the
>> message to wsdl2) then I get an exception that the operation name or
>> namespace is incorrect. I'm guessing its because by transforming the
>> message at CXFEndpoint1 at an interceptor that occurs before the message
>> is
>> validated against WSDL1, so it breaks.
>>
> You can have individual Transform interceptors used instead of the feature,
> and have them run in a CXF Phase which would be done after a WSDL11
> validation, not sure what phase that should be, but you can do a fine-level
> control of when the feature is applied
>
I am not very sure if there is some issue in the operation/binding
matching in the way how Lowry uses the WSDLs and I think he might want
to configure his route differently to avoid any issue while using the
out of the box transform feature.
Basically, he has
client --> EP1 --camel-route- EP2 --> service
and his original set up was something like this
client(wsdl1) --> EP1(wsdl1)/trans--camel-route- EP2(wsdl2)--> service(wsdl2)
and he was having the binding/operation mismatch issue at EP1.
my suggestion would be to use wsdl2 and EP1 so that the transformed
message matches the assigned wsdl.
client(wsdl1) --> EP1(wsdl2)/trans--camel-route- EP2(wsdl2)--> service(wsdl2)
we have to make sure that the client is using wsdl1 that that has been
retrieved and available locally.
in the future, we might want to consider providing a feature to
dynamically modify the assigned wsdl using the transform rules ;-)
regards, aki
> HTH, Sergey
>
>
>
>
>> So i'm coming to the conclusion that the transform feature is not a good
>> way
>> to achieve my goal of a generic all-purpose declarative tranfomration
>> strategy in a camle pass through route from one CXFEndpoint (consumer) to
>> another CXFEndpoint (producer).
>>
>> Can someone deny or confrm my thoughts on this, or recommend an approach
>> to
>> do this type of declarative mapping / tranform simimilar to CXF transform
>> feature that would allow me to accomplish?
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
Re: cxf transform feature for Declarative transform in camel route
Posted by Sergey Beryozkin <sb...@gmail.com>.
HI,
On 10/07/14 16:21, Lowry wrote:
> I have a camel route that starts with a cxfEndpoint1 (consumer) that works as
> a CXF server and represents the interface defined in wsdl1. The route is a
> pass-through route that sends to a backend web service using CXFEndpoint2
> (producer) pointing to wsdl2.
>
> The interface for wsdl1 (incoming) is slightly different (different element
> names, and namespace) than the outgoing wsdl2 interface. We need to
> introduce transformation in between that transforms message.
>
> I'd like a strategy for introducing transformation that is declarative and
> doesn't force me to write java DOM code or XSLT. I found the CXF transform
> feature and it looked promising. I'm using it in my route. But i'm having
> some issues.
>
> Is it designed for such a use-case? The problem i have is that the
> transform seems to occur on entry before the message "hits" CXFEndpoint1. So
> if I apply the transform feature to the CXFEndpoint1 (listener), and the
> transform defines namespace or element changes (goal is to conform the
> message to wsdl2) then I get an exception that the operation name or
> namespace is incorrect. I'm guessing its because by transforming the
> message at CXFEndpoint1 at an interceptor that occurs before the message is
> validated against WSDL1, so it breaks.
>
You can have individual Transform interceptors used instead of the
feature, and have them run in a CXF Phase which would be done after a
WSDL11 validation, not sure what phase that should be, but you can do a
fine-level control of when the feature is applied
HTH, Sergey
> So i'm coming to the conclusion that the transform feature is not a good way
> to achieve my goal of a generic all-purpose declarative tranfomration
> strategy in a camle pass through route from one CXFEndpoint (consumer) to
> another CXFEndpoint (producer).
>
> Can someone deny or confrm my thoughts on this, or recommend an approach to
> do this type of declarative mapping / tranform simimilar to CXF transform
> feature that would allow me to accomplish?
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/cxf-transform-feature-for-Declarative-transform-in-camel-route-tp5746295.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com