[jira] Issue Comment Edited: (CAMEL-1818) camel-cxf should fully support cxf jbi transport

["Willem Jiang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52942#action_52942 ] 

Willem Jiang edited comment on CAMEL-1818 at 7/24/09 1:34 AM:
--------------------------------------------------------------

Hi Rong,

After digging the cxf jbi transport code for while, I found there is an issue for using the cxf jbi transport in camel-cxf.

CXF JBI has a delivery channel property which is got from servicemix ComponentContext and it means you need to deploy the CXF JBI endpoint into the ServiceMix container to get the JBI transport work.

But for camel-cxf component , it knows nothing about the servicemix and  the delivery channel.

So we need to figure out a way how to set delivery channel to the CXF JBI transport first, currently I have no idea to implement this in CXF.

BTW, servicemix-camel component support to route the message between the camel endpoint and servicemix endpoint, maybe we can route the message directly to smx-cxf-se & smx-cxf-bc from the camel endpoint by using the servicemix-camel component.

Willem


      was (Author: njiang):
    Hi Rong,

After digging the cxf jbi transport code for while, I found there is issue for use to use cxf jbi transport in camel-cxf.
CXF JBI has a delivery channel property which is got from servicemix ComponentContext and it means you need to deploy the CXF JBI endpoint into the ServiceMix container to get the JBI transport work.

But for camel-cxf component , it knows nothing about the servicemix and  the delivery channel.

So we need to figure out a way how to set delivery channel to the CXF JBI transport first, currently I have no idea to implement this issue.

BTW, servicemix-camel component support to route the message between the camel endpoint and servicemix endpoint, maybe we can route the message directly to smx-cxf-se & smx-cxf-bc from the camel endpoint by using the servicemix-camel component.

Willem

  
> 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.