Hi
In the single jvm we could use local transport to send/receive the Camel
message, but we just need other transport the send/receive the Camel
message for separate jvms communication .
I have same idea we should just wrap the transport factory in the CXF,
and Camel not need to touch it. I am also working on it to make a simple
demo work.
For the CXFEndpoint part, I don't think the orginal design of CXF
endpointInfo with adress is enough,
It should hold enough information which we need to setup a CXF server or
client, such as sei class name , wsdl url etc.
The URI could be
cxf://http://localhost:1234/test?wsdl=file://local/helloworld.wsdl&serviceName=.....
But I don't think we can hold so many information in a single URI
string. eg. we just want to pass a service implementor's reference to
the ServiceFactoryBean.
James: Is there a way to use spring to wire up the endpoint information
for CXF?
In CXF we could use a jaxws syntax to setup the CXF server and client
<jaxws:server id="inlineSoapBinding"
serviceClass="org.apache.cxf.jaxws.service.Hello"
address="http://localhost:8080/test";>
<jaxws:serviceBean>
<bean ref="#helloworld"/>
</jaxws:serviceBean>
<jaxws:binding>
<soap:soapBinding mtomEnabled="true" version="1.2"/>
</jaxws:binding>
</jaxws:server>
....
<jaxws:client id="wsdlLocation"
serviceClass="org.apache.hello_world_soap_http.Greeter"
serviceName="s:SOAPService"
xmlns:s="http://apache.org/hello_world_soap_http";
address="http://localhost:8080/simpleWithAddress";
wsdlLocation="wsdl/hello_world.wsdl"/>
As you know CXF has two front end that we could use , one is simple
front end and the other is jaxws front end.
May be we need to do some work to auto discover which front end we need
to create the right CXF server or client.
BTW , we still need to set up the CXF interceptors for the CXF consumer
and CXF producer, which we can handler different message mode such as
POJO mode, Payload mode and Message mode :)
Now I am not clear about howto configure it :( and I don't think we can
do it in endpoint's URL.
Willem.
William Tam wrote:
I basically agree with one comment. I am not sure single vs seperated jvm
will be much of an implementation difference if we let CXF choose the right
transport factory based on the address. I would change the
LocalTransportFactory in CxfComponent and let CXF to solve to a factory for
us.
For example, if the endpoint URI is cxf:http://host:28080/test, the http
transport factory will be picked (by CXF). Or if the URI is
cxf:local://test, we will end up using the local transport factory. I think
that can be applied to both consumer and provider. I am doing some
experiment ...
- William
On 8/7/07, James Strachan <[EMAIL PROTECTED]> wrote:
On 8/7/07, Willem Jiang <[EMAIL PROTECTED]> wrote:
Hi All,
I'd like to do some work of CXF and Camel integration.
Awesome!
After talked with
James , I got two typical user scenario here:
I. Using the Camel as a mediation, CXF endpoints and Camel router are
in the separated JVMs
* Camel message -> CXF server
The message flow could be:
Camel consumer [Camel message] -> (processors ...) ->CXF producer (CXF
conduit) -> CXF server
* CXF client -> Camel message -> CXF server
The message flow could be:
CXF client -> Camel consumer [Camel message] -> (processors ...) ->CXF
producer(CXF conduit) ->CXF server
II. Camel is embedded into CXF as a transport implementor, CXF and Camel
are in the same JVM
It looks like Camel will take the charge of other camel endpoints life
cycle.
* For the CXF client which use the Camel transport
The message flow could be
CXF client [CXF message]-> Camel transport [Camel message]-> Camel
router
The Router part message flow could be
Camel consumer [Camel message] -> (processors ...) -> Camel Services
or other Camel Producer
* For the CXF Server which use the Camel transport
CXF Service (create destination message observer) -> Camel transport ->
Camel router
The Router part message flow could be
Camel consumer [Camel message] -> (processors ...) -> Camel producer
-> CXF message observer [CXF message]
Any thoughts?
That sounds about right to me. From a high level there are lots of
permuations for how Camel and CXF can work together;
i) CXF is the client, Camel is the server (using CXF to send messages
into some Camel component)
ii) Camel is the client, CXF is the server (i.e. binding camel
messages to CXF endpoints)
iii) Camel is inside CXF as a Transport (e.g. using Camel's XMPP, IRC
or email transport etc
iv) Camel is a mediation router inside CXF
Actually iii and iv are kinda the same; CXF client -> Camel processors
-> CXF endpoint
I think you've captured the various possible flows correctly. The next
challenge is implementing them :)
In terms of the code thats there in camel-cxf; the transport
implementation is kinda bogus; I tried basically porting the jms
transport of CXF to camel without much clue what I was doing, so you
might wanna trash that and start again :)
The other components; we kinda have 2 right now which is maybe not
ideal; one was an attempt at doing a direct POJO invocation (e.g. if
the message payload contains POJOs rather than InputStream) while the
other was trying to do a more usual InputStream/transport type
invocation. I guess Camel could work at various CXF injection points
(before marshalling, maybe during marshalling, after marshalling etc)
- so we might find we do need some flexibility in how a Camel message
binds to CXF and vice versa.
Please do experiment and see what you think; I'm not yet sure how the
Camel-CXF stuff should look, so I'm hoping we can keep experimenting
until we find we're close to what we really need
--
James
-------
http://macstrac.blogspot.com/
