camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willem Jiang (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (CAMEL-1818) camel-cxf should fully support cxf jbi transport
Date Fri, 24 Jul 2009 09:08:33 GMT

     [ https://issues.apache.org/activemq/browse/CAMEL-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Willem Jiang resolved CAMEL-1818.
---------------------------------

    Resolution: Won't Fix

> 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
>            Assignee: Willem Jiang
>
> 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.


Mime
View raw message