camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Tam" <email.w...@gmail.com>
Subject Re: Proposal for the CXF and Camel integration
Date Tue, 07 Aug 2007 22:12:22 GMT
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 <james.strachan@gmail.com> wrote:
>
> On 8/7/07, Willem Jiang <willem.jiang@gmail.com> 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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message