camel-cxf should fully support cxf jbi transport
------------------------------------------------
Key: CAMEL-1818
URL: https://issues.apache.org/activemq/browse/CAMEL-1818
Project: Apache Camel
Issue Type: Improvement
Components: camel-cxf
Affects Versions: 1.6.0
Reporter: Ron Gavlin
I would like to incorporate the camel-cxf component into smx-camel and use
wsdl2java-generated stubs to send jbi requests and receive jbi responses from
smx-cxf-bc and smx-cxf-se endpoints. Essentially, what I can do today in the
smx-cxf-se container with proxies I would also like to be able to do in the
smx-camel.
The discussion on this topic with willem and ffang is pasted below.
<rong> willem: i have code currently running in smx-cxf-se that I would like
to move into smx-camel. The code in smx-cxf-se uses wsdl2java to proxy to a
smx-cxf-bc provider. If I bundle the camel-cxf component within smx-camel,
should I be able to port this code over from smx-cxf-se to smx-camel?
<rong> willem: of course, I would provide a jbi location uri as the
proxy address.
<willem> rong: wsdl2java generated artifacts can be used in
camel-cxf.
<rong> willem: so in this scenario, I am not explicitly using
camel-cxf at all. I presume it is being used behind the scenes to send a camel
CxfExchange which then gets converted into a jbi exchange on its way to the
smx-cxf-bc provider. Is that how you would understand it?
<rong> willem: the smx-cxf-bc provider allows me to share the same jbi
endpoint configuration across numerous camel routes defined in different
smx-camel sus.
<willem> rong: Do you still want to use the smx-cxf-bc for the
transport work ?
<willem> rong: are you using SMX 3?
<rong> willem: i see it as providing a single exit/entry point on the
bus that can be shared across numerous camel routes. Yes, I am still on smx3.
<willem> rong: do you just want route the jbi message to camel
and let camel call the POJO as the smx-cxf-se does?
<rong> willem: what advantage would defining a separate smx-camel su
with a route "from jbi to cxf" have over directly using the smx-cxf-bc provider?
<rong> willem: no, i have a service that choreographs multiple
external SOAP services. Today, the work is done in smx-cxf-se. It would be more
convenient to do the choreography work in camel where I can inline other
mediation/routing operations with the external SOAP service invocations.
<rong> willem: I know how the smx-cxf-se proxies to smx-cxf-bc
provider endpoints. However, it is not clear how the wsdl2java-generated
classes running in smx-camel would use camel-cxf behind the scenes to send a
jbi message to the smx-cxf-bc provider endpoint.
<willem> rong; If you just want to routing the raw message and
don't get the CXF interceptor get touch of the message, you could route the JBI
message into the camel.
<rong> willem: I am not sure I understand your comment. When I say
smx-cxf-bc provider, I am using the term "provider" in jbi speak, meaning it is
a proxy to an external service. So, I am not trying to route a message into
camel, I am trying to route a message out of camel to the "jbi provider". Does
that make sense?
<willem> rong: but for camel-cxf , it doesn't take the transport
and soap stack business apart. if you still want to the smx-cxf-se's marshal
and unmarshal work do inside the camel, you still need to route the message to
smx-cxf-se and camel-cxf can't do it.
<rong> willem: doesn't cxf's native support for the jbi transport mean
that the wsdl2java-generated stubs running in smx-camel do the jbi work for me.
I was thinking I was only using camel-cxf to essentially import the relevant
cxf jars. When the smx-cxf-se proxies to the smx-cxf-bc provider, is it doing
more for me than I realize?
<willem> rong: wsdl2java generated artifacts are for the mapping
between the xml message and Java objects, they can't handle the jbi transport
themselves. It need the CXF runtime to handle it.
<willem> rong : I don't know what the smx-cxf-se proxies does,
maybe I need to ask ffang to join this discussion.
<rong> willem: i was thinking the same thing...
<rong> ffang: ping
<ffang> rong:pong
<rong> ffang: i have been chatting with willem about moving some
integration logic from a smx-cxf-se component to smx-camel. Do you have a
moment to read our discussion history here and provide additional insight
regarding how proxies to smx-cxf-bc providers work in smx-cxf-se?
<ffang> rong: sure, basically, proxy in cxf se means, cxf se can hold
the proxy of provider endpoint inside jbi bus, then from within the cxf se
endpoint, can use this proxy to send message exchange to the provider endpoint
just like a normal java invocation, but the provider endpoint must has the wsdl
interface
<rong> ffang: So, ii am trying to determine if the smx-cxf-se itself
has magic to support proxying to smx-cxf-bc providers or if all the magic is
the cxf runtime's support for jbi destinations...
<ffang> rong: so you can from smx-cxf-se, use proxy of other cxf se
endpoint/ cxf bc provider/ jsr181 se endpoint, because all of these provider
endpoint has wsdl as interface
<willem> ffang: does smx-cxf-se still need to marshal and
unmarshal of the incoming and outgoing JBI message ?
<ffang> rong: in your scenario, if camel se(as a provider) has wsdl
interface, then it should be ok
<ffang> willem: yeah
<willem> ffang: Does the wsdl interface means SEI ?
<rong> ffang: so, in smx-camel, if i bundle the camel-cxf component to
incorporate the cxf runtime and I use wsdl2java-generated stubs with a jbi
locationUri pointing to the smx-cxf-bc provider (just like I do in smx-cxf-se
today), the code should port from smx-cxf-se to smx-camel?
<ffang> rong: yeah, cxf se proxy use cxf JBI destination underlying,
but it doesn't care the provider endpoint on the other side is cxf bc provider
or not, any provider has wsdl interface should be ok
<ffang> willem: yeah
<rong> ffang: but in this case, i wouldn't be using the cxf-se proxy.
i am running in smx-camel and trying to send a jbi request to smx-cxf-bc
provider using wsdl2java-generated classes.
<rong> ffang: is all the work i need being done in the cxf jbi
transport layer and not in the cxf-se?
<rong> ffang: the jbi proxy work, i mean
<ffang> rong: yeah, basically it's cxf runtime issue, I mean here
mainly involve ClientProxyFactoryBean(which is cxf client proxy) an cxf JBI
transport
<ffang> willem: can we use ClientProxyFactoryBean from camel-cxf now?
<rong> ffang: am I correct that the major drawback of using this
technique, i.e., ClientProxyFactoryBean, is that only synchronous invocations
are supported. OTOH, if I manually build the request rather than using
wsdl2java-generated classes, then I can asynchronously send the request,
correct?
<willem> ffang: camel-cxf uses ClientProxyFactoryBean to create
the proxy to send the request to out side of service.
<willem> ffang: I think the issue is how to initial the JBI
transport in normal CXF endpoint.
<willem> ffang: current camel-cxf endpoint can't consume the JBI
message directly.
<ffang> rong: yeah
<ffang> rong: actually no
<rong> willem: when the cxf runtime sees a jbi location uri, doesn't
it know to automatically perform this initialization? I would think camel-cxf
endpoint would play any role here, except making sure it brings with it the jbi
transport jars.
<ffang> rong: even we use sendSync in proxy to send out MessageChangr,
but for cxf client api level, we have asyn, so the asyn/sync of cxf client api
decouple with the underlying transport
<ffang> rong: think about cxf client can support async over http
transport, which is sync indeed
<rong> willem: s/would/would not
<willem> rong: yes, if you take a look at the
CxfSeProxyFactoryBean in cxf-se, cxf-se did some customization on the client
side.
<ffang> willem: it's easy do use JBI transport, just do like
cf.setAddress("jbi://" + "anything");
<rong> ffang: it looks like CxfSeProxyFactoryBean has a reasonable
amount of goodness to make proxies work with MTOM attachments, etc. Any idea
how much of this functionality would have to be integrated into cxf, camel-cxf,
or smx-camel? Would it make sense to move this into the cxf jbi library as a
helper class so that smx-cxf-se and camel can share it?
<ffang> rong: yeah, maybe some interceptors should move to cxf code
base, if these would be shared by camel-cxf also
<rong> willem, ffang: so it sounds to me like camel-cxf does not
currently fully support the cxf jbi transport. If you agree, I'll open a Camel
JIRA for this functionality to be added to the camel-cxf component.
<willem> rongļ¼ current camel JBI related work is done in
servicemix-camel component, I don't know if it is right for camel-cxf do
consume or produce any JBI related message.
<willem> rong: if you want to camel-cxf handle the JBI message
from smx-cxf-se and smx-cxf-bc, we need to do merge the JBI related work in to
camel-cxf.
<willem> rong: please feel free to fill that requirement.
<rong> willem: yes, i want camel-cxf to send jbi request and receive
jbi response from both smx-cxf-se & smx-cxf-bc. So, should that be a camel-cxf
JIRA?
<willem> rong: yes, camel-cxf can cover that.
<rong> willem, ffang: thanks for your assistance. i'll open a
camel-cxf JIRA then.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
