You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by xtof <ch...@hp.com> on 2007/09/18 11:45:34 UTC
Example of request reply
Hello,
I'm quite new to Camel, and I'm trying to understand how implementing a
gateway between 2 Web Services. It requires to implement a request-reply
mechanism but I cannot find any example.
Could you help?
Thank.
Christophe
--
View this message in context: http://www.nabble.com/Example-of-request-reply-tf4473066s22882.html#a12753590
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Example of request reply
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
No, here is not sample or unit test to show cxf+pojo.
But you can take a look at the CxfProducerTest, it shows how to process
pojo invocation as a soap request.
Willem.
Guillaume Nodet wrote:
> Hmm, I guess I missed the point that the CXF component was relying
> on the pojo component for the actual service.
> It makes more sense now.
> Is there any example / unit test showing cxf + pojo ? I did not find
> any and that's why I was a bit confused...
>
> On 9/19/07, Willem Jiang <wi...@gmail.com> wrote:
>
>> Hi Nodet,
>>
>> Please see my comments in the line:
>> Guillaume Nodet wrote:
>>
>>> Yeah, i'm trying to dig into it.
>>> What i'd like to do is use cxf just for soap processing.
>>> Ideally, i'd like to have:
>>>
>>> from(soap("http://localhost:8192/service")).
>>> process(xx).
>>> to(soap("http://myhost:8080/another")).
>>> process(yy)
>>>
>>> which would not do any service invocation at all.
>>> and this would require the DSL to be enhanced, but it would be like the
>>> following (with the current dsl).
>>>
>>> Ideally, i'd like to be able to write:
>>>
>>> from("http://localhost:8192/service").
>>> process(new SoapConsumerServerProcessor()).
>>> process(xxx).
>>> process(new SoapProviderClientProcessor()).
>>> to("http://myhost:8080/another").
>>> process(new SoapProviderServerProcessor()).
>>> process(yy)
>>> process(new SoapConsumerClientProcessor())
>>>
>>> which means:
>>> * receive an http request,
>>> * perform any soap handling (ws-*) and set the content of the soap message
>>> as the body of the in message
>>> * process xxx
>>> * wrap the message in a soap envelope
>>> * send the soap request to the target service
>>> * unwrap the soap response
>>> * process yyy
>>> * wrap the message as a soap response
>>> * send it back as the http response
>>>
>>> This is for the SOAP handling part.
>>>
>>>
>> Current camel-cxf component supports the PAYLOAD message model endpoint
>> which can consume and produce soap body message or the xml binding message.
>> But they are just working as SoapConsumerServerProcessor and
>> SoapProviderClientProcessor.
>> So it really need to write different processeor to handling the SOAP
>> bindings work.
>> I think we can leverage the CXF interceptors chain to do that.
>>
>>> I'd like to be able to expose JAXWS pojo inside camel, but without any soap
>>> handling, so that while inside camel, you would not use any soap stuff and
>>> you could invoke the bean with plain xml / pojo.
>>>
>>> So at the end, you could write:
>>> from(soap("http://localhost:8080")).to("cxf:
>>> org.apache.camel.component.cxf.HelloService")
>>>
>>>
>> Current cxf can consumer the soap request and delegate the request to a
>> POJO service.
>>
>> from("cxf://http://localhost:8080/hello?serviceClass=org.apache.camel.component.cxf.HelloService&dataFormat=POJO).to("pojo:org.apache.camel.component.cxf.HelloService");
>>
>>
>>> or something like that and that would expose the service over http.
>>>
>>>
>> Yes , you could send a POJO invocation request to the cxfProducer to
>> help you invoke a SOAP service.
>>
>>> Now, my understanding of the cxf component is the following:
>>> * the consumer consumes soap requests using the cxf transports, performs
>>> the soap processing, unmarshal the data as a list of parameters (this
>>> depends on the DataFormat) and send it to the bus
>>> * the producer receives a message which contains the raw message or the
>>> list of unmarshaled parameters, invokes the bean and send the response back.
>>>
>>>
>> Yes , they are POJO DataFormate 's job.
>>
>>> * i don't understand how to call an external service using camel-cxf
>>> from(xxx).to("cxf:http://remotehost:8080/service")
>>>
>>>
>> CxfProducerTest [1] shows that , if from(xxx) can give the CxfProducer a
>> POJO invocation , that will be OK
>> [1]https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfProducerTest.java
>>
>>> * the DataFormat controls where the marshaling occurs (on the consumer or
>>> on the producer side)
>>>
>>>
>> Current PayLoad Data Format just implement the
>> SoapConsumerServerProcessor and SoapProviderClientProcessor, the other
>> two Processors need to be implemented.
>>
>>> * there is no way to use jaxws to call a service inside camel using a
>>> client proxy
>>>
>>>
>> I don't quite understand the client proxy . Did it mean Jaxws client proxy?
>> If so , I don't think current camel-cxf componet can help to do that
>> ,because there it no soap processor to handle the binding.
>>
>>> I think creating a CXF binding and a transport (it seems the current one is
>>> not used) as we did for JBI may be a way to solve these problems.
>>>
>>>
>> I agree , but how can the CXF binding be put into camel context.
>> Now , I just think processor can do that.
>>
>>> Thoughts ?
>>>
>>>
>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>>>
>>>
>>>> Hi Nodet
>>>>
>>>> Yes, and it can perform more than service invocation part. you can find
>>>> more information by check camel-cxf component code :)
>>>>
>>>> Cheers,
>>>> Willem.
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>
>>>>> Hi Willem!
>>>>> Does the cxf component performs any soap processing using cxf ? Or is it
>>>>> just the marshaling / service invocation part ?
>>>>> I'd like to leverage cxf for soap processing...
>>>>>
>>>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi ,
>>>>>> I am working on camel-cxf component which will help you to do some
>>>>>> router work between 2 Web Services. My big patch just been applied in
>>>>>> the trunk, you can take a look at the unit test of camel-cxf component.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
>>>>
>>>>
>>>>>> I will add a Web Service router example some time this week :)
>>>>>>
>>>>>> Willem.
>>>>>> xtof wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm quite new to Camel, and I'm trying to understand how implementing
>>>>>>>
>>>>>>>
>>>> a
>>>>
>>>>
>>>>>>> gateway between 2 Web Services. It requires to implement a
>>>>>>>
>>>>>>>
>>>> request-reply
>>>>
>>>>
>>>>>>> mechanism but I cannot find any example.
>>>>>>> Could you help?
>>>>>>>
>>>>>>> Thank.
>>>>>>> Christophe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>> Willem.
>>
>>
>
>
>
Re: Example of request reply
Posted by Guillaume Nodet <gn...@gmail.com>.
Hmm, I guess I missed the point that the CXF component was relying
on the pojo component for the actual service.
It makes more sense now.
Is there any example / unit test showing cxf + pojo ? I did not find
any and that's why I was a bit confused...
On 9/19/07, Willem Jiang <wi...@gmail.com> wrote:
> Hi Nodet,
>
> Please see my comments in the line:
> Guillaume Nodet wrote:
> > Yeah, i'm trying to dig into it.
> > What i'd like to do is use cxf just for soap processing.
> > Ideally, i'd like to have:
> >
> > from(soap("http://localhost:8192/service")).
> > process(xx).
> > to(soap("http://myhost:8080/another")).
> > process(yy)
> >
> > which would not do any service invocation at all.
> > and this would require the DSL to be enhanced, but it would be like the
> > following (with the current dsl).
> >
> > Ideally, i'd like to be able to write:
> >
> > from("http://localhost:8192/service").
> > process(new SoapConsumerServerProcessor()).
> > process(xxx).
> > process(new SoapProviderClientProcessor()).
> > to("http://myhost:8080/another").
> > process(new SoapProviderServerProcessor()).
> > process(yy)
> > process(new SoapConsumerClientProcessor())
> >
> > which means:
> > * receive an http request,
> > * perform any soap handling (ws-*) and set the content of the soap message
> > as the body of the in message
> > * process xxx
> > * wrap the message in a soap envelope
> > * send the soap request to the target service
> > * unwrap the soap response
> > * process yyy
> > * wrap the message as a soap response
> > * send it back as the http response
> >
> > This is for the SOAP handling part.
> >
> Current camel-cxf component supports the PAYLOAD message model endpoint
> which can consume and produce soap body message or the xml binding message.
> But they are just working as SoapConsumerServerProcessor and
> SoapProviderClientProcessor.
> So it really need to write different processeor to handling the SOAP
> bindings work.
> I think we can leverage the CXF interceptors chain to do that.
> > I'd like to be able to expose JAXWS pojo inside camel, but without any soap
> > handling, so that while inside camel, you would not use any soap stuff and
> > you could invoke the bean with plain xml / pojo.
> >
> > So at the end, you could write:
> > from(soap("http://localhost:8080")).to("cxf:
> > org.apache.camel.component.cxf.HelloService")
> >
> Current cxf can consumer the soap request and delegate the request to a
> POJO service.
>
> from("cxf://http://localhost:8080/hello?serviceClass=org.apache.camel.component.cxf.HelloService&dataFormat=POJO).to("pojo:org.apache.camel.component.cxf.HelloService");
>
> > or something like that and that would expose the service over http.
> >
> Yes , you could send a POJO invocation request to the cxfProducer to
> help you invoke a SOAP service.
> > Now, my understanding of the cxf component is the following:
> > * the consumer consumes soap requests using the cxf transports, performs
> > the soap processing, unmarshal the data as a list of parameters (this
> > depends on the DataFormat) and send it to the bus
> > * the producer receives a message which contains the raw message or the
> > list of unmarshaled parameters, invokes the bean and send the response back.
> >
> Yes , they are POJO DataFormate 's job.
> > * i don't understand how to call an external service using camel-cxf
> > from(xxx).to("cxf:http://remotehost:8080/service")
> >
> CxfProducerTest [1] shows that , if from(xxx) can give the CxfProducer a
> POJO invocation , that will be OK
> [1]https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfProducerTest.java
> > * the DataFormat controls where the marshaling occurs (on the consumer or
> > on the producer side)
> >
> Current PayLoad Data Format just implement the
> SoapConsumerServerProcessor and SoapProviderClientProcessor, the other
> two Processors need to be implemented.
> > * there is no way to use jaxws to call a service inside camel using a
> > client proxy
> >
> I don't quite understand the client proxy . Did it mean Jaxws client proxy?
> If so , I don't think current camel-cxf componet can help to do that
> ,because there it no soap processor to handle the binding.
> > I think creating a CXF binding and a transport (it seems the current one is
> > not used) as we did for JBI may be a way to solve these problems.
> >
> I agree , but how can the CXF binding be put into camel context.
> Now , I just think processor can do that.
> > Thoughts ?
> >
> >
> > On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >
> >> Hi Nodet
> >>
> >> Yes, and it can perform more than service invocation part. you can find
> >> more information by check camel-cxf component code :)
> >>
> >> Cheers,
> >> Willem.
> >>
> >> Guillaume Nodet wrote:
> >>
> >>> Hi Willem!
> >>> Does the cxf component performs any soap processing using cxf ? Or is it
> >>> just the marshaling / service invocation part ?
> >>> I'd like to leverage cxf for soap processing...
> >>>
> >>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >>>
> >>>
> >>>> Hi ,
> >>>> I am working on camel-cxf component which will help you to do some
> >>>> router work between 2 Web Services. My big patch just been applied in
> >>>> the trunk, you can take a look at the unit test of camel-cxf component.
> >>>>
> >>>>
> >>>>
> >> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> >>
> >>>> I will add a Web Service router example some time this week :)
> >>>>
> >>>> Willem.
> >>>> xtof wrote:
> >>>>
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I'm quite new to Camel, and I'm trying to understand how implementing
> >>>>>
> >> a
> >>
> >>>>> gateway between 2 Web Services. It requires to implement a
> >>>>>
> >> request-reply
> >>
> >>>>> mechanism but I cannot find any example.
> >>>>> Could you help?
> >>>>>
> >>>>> Thank.
> >>>>> Christophe
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >
> >
> Willem.
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Example of request reply
Posted by Willem Jiang <wi...@gmail.com>.
Hi Nodet,
Please see my comments in the line:
Guillaume Nodet wrote:
> Yeah, i'm trying to dig into it.
> What i'd like to do is use cxf just for soap processing.
> Ideally, i'd like to have:
>
> from(soap("http://localhost:8192/service")).
> process(xx).
> to(soap("http://myhost:8080/another")).
> process(yy)
>
> which would not do any service invocation at all.
> and this would require the DSL to be enhanced, but it would be like the
> following (with the current dsl).
>
> Ideally, i'd like to be able to write:
>
> from("http://localhost:8192/service").
> process(new SoapConsumerServerProcessor()).
> process(xxx).
> process(new SoapProviderClientProcessor()).
> to("http://myhost:8080/another").
> process(new SoapProviderServerProcessor()).
> process(yy)
> process(new SoapConsumerClientProcessor())
>
> which means:
> * receive an http request,
> * perform any soap handling (ws-*) and set the content of the soap message
> as the body of the in message
> * process xxx
> * wrap the message in a soap envelope
> * send the soap request to the target service
> * unwrap the soap response
> * process yyy
> * wrap the message as a soap response
> * send it back as the http response
>
> This is for the SOAP handling part.
>
Current camel-cxf component supports the PAYLOAD message model endpoint
which can consume and produce soap body message or the xml binding message.
But they are just working as SoapConsumerServerProcessor and
SoapProviderClientProcessor.
So it really need to write different processeor to handling the SOAP
bindings work.
I think we can leverage the CXF interceptors chain to do that.
> I'd like to be able to expose JAXWS pojo inside camel, but without any soap
> handling, so that while inside camel, you would not use any soap stuff and
> you could invoke the bean with plain xml / pojo.
>
> So at the end, you could write:
> from(soap("http://localhost:8080")).to("cxf:
> org.apache.camel.component.cxf.HelloService")
>
Current cxf can consumer the soap request and delegate the request to a
POJO service.
from("cxf://http://localhost:8080/hello?serviceClass=org.apache.camel.component.cxf.HelloService&dataFormat=POJO).to("pojo:org.apache.camel.component.cxf.HelloService");
> or something like that and that would expose the service over http.
>
Yes , you could send a POJO invocation request to the cxfProducer to
help you invoke a SOAP service.
> Now, my understanding of the cxf component is the following:
> * the consumer consumes soap requests using the cxf transports, performs
> the soap processing, unmarshal the data as a list of parameters (this
> depends on the DataFormat) and send it to the bus
> * the producer receives a message which contains the raw message or the
> list of unmarshaled parameters, invokes the bean and send the response back.
>
Yes , they are POJO DataFormate 's job.
> * i don't understand how to call an external service using camel-cxf
> from(xxx).to("cxf:http://remotehost:8080/service")
>
CxfProducerTest [1] shows that , if from(xxx) can give the CxfProducer a
POJO invocation , that will be OK
[1]https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfProducerTest.java
> * the DataFormat controls where the marshaling occurs (on the consumer or
> on the producer side)
>
Current PayLoad Data Format just implement the
SoapConsumerServerProcessor and SoapProviderClientProcessor, the other
two Processors need to be implemented.
> * there is no way to use jaxws to call a service inside camel using a
> client proxy
>
I don't quite understand the client proxy . Did it mean Jaxws client proxy?
If so , I don't think current camel-cxf componet can help to do that
,because there it no soap processor to handle the binding.
> I think creating a CXF binding and a transport (it seems the current one is
> not used) as we did for JBI may be a way to solve these problems.
>
I agree , but how can the CXF binding be put into camel context.
Now , I just think processor can do that.
> Thoughts ?
>
>
> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>
>> Hi Nodet
>>
>> Yes, and it can perform more than service invocation part. you can find
>> more information by check camel-cxf component code :)
>>
>> Cheers,
>> Willem.
>>
>> Guillaume Nodet wrote:
>>
>>> Hi Willem!
>>> Does the cxf component performs any soap processing using cxf ? Or is it
>>> just the marshaling / service invocation part ?
>>> I'd like to leverage cxf for soap processing...
>>>
>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>>>
>>>
>>>> Hi ,
>>>> I am working on camel-cxf component which will help you to do some
>>>> router work between 2 Web Services. My big patch just been applied in
>>>> the trunk, you can take a look at the unit test of camel-cxf component.
>>>>
>>>>
>>>>
>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
>>
>>>> I will add a Web Service router example some time this week :)
>>>>
>>>> Willem.
>>>> xtof wrote:
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm quite new to Camel, and I'm trying to understand how implementing
>>>>>
>> a
>>
>>>>> gateway between 2 Web Services. It requires to implement a
>>>>>
>> request-reply
>>
>>>>> mechanism but I cannot find any example.
>>>>> Could you help?
>>>>>
>>>>> Thank.
>>>>> Christophe
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
>
Willem.
Re: Example of request reply
Posted by Guillaume Nodet <gn...@gmail.com>.
On 9/20/07, Willem Jiang <wi...@gmail.com> wrote:
> Hi Nodet,
>
> Comments are in the line.
> Guillaume Nodet wrote:
> > On 9/19/07, Willem Jiang <wi...@gmail.com> wrote:
> >
> >> Hi ,
> >>
> >> I agree to keep the binding as a separate object in the pipeline.
> >> And I suggest to add the in and out flage to the binding .
> >> form("http://soapendpoint").binding(soap, in).to("pojo.service")
> >> and
> >> from("direct").binding(soap, out).to("http://localhost:/cxfservice");
> >>
> >
> > We need to agree on the terms we use I suppose.
> > In my mind, binding relates to databinding (xml / pojo marshaling).
> > So soap is not a binding in this sense.
> >
> Yes.
> > Let aside the databinding, I think this would be a bit too verbose.
> > Concision usually means that the route definition is easier to read
> > and understand.
> >
> > What about:
> > from("soap:http://localhost:8080/service").
> > to(requestTransformer).
> > to("soap:http://host:8181/Service/").
> > to(responseTransformer);
> >
> > versus: (feel free to replace soap(in) by binding(soap,in) or whatever)
> > from("http://localhost:8080/service").
> > soap(in).
> > to(requestTransformer).
> > soap(out)
> > to("http://host:8181/Service/").
> > to(responseTransformer);
> >
> > Also, I'm not even sure that this syntax makes sense. The soap(in) /
> > soap(out) are really interceptors and they must be called around the
> > transport endpoints. Will the soap(out) be called with the response
> > from the http provider, or will the responseTransfomer be called
> > before ?
> >
> >
> I think soap(out) just works as the processor of the pipe line, in the
> process method , it waits for the response message
> (if the request is not one way request) and then does the response
> unmarshel work.
Well, I think this is the problem. Processors are not interceptors
and are only called once. Interceptors may be more suitable, but
they will intercept everything after them. In the above example, the
soap(out) will only be able to intercept the response after it has
been processed by the transformer.
We could do the following using processors (not interceptors):
from("http://localhost:8080/service").
soap(in).
to(requestTransformer).
soap(out)
to("http://host:8181/Service/").
soap(out).
to(responseTransformer).
soap(in);
which becomes very verbose and very error prone imho.
> >> BTW, I don't want to mix the binding and transport in a same URI,
> >> It will make the component 's URI handling work more complex.
> >>
> >
> > This is a trade between DSL complexity and URI complexity I suppose.
> > URI are quite easy to read usually, even complex ones.
> >
> > failover://(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
> >
> > The soap component code itself would maily delegate to another
> > component for the endpoint creation and just add interceptors to
> > handle soap requests.
> >
> En,I admit the DSL formate is really easier to be understood.
> But I don't know how to parser these DSL"soap:jms:myQueue.... "
> Could you give me an example in camel?
Sure, I've just added a ref: protocol and component so that you can
reference existing endpoints or look them up in the registry.
See http://svn.apache.org/viewvc?view=rev&revision=577424
You just have to create a component for the soap protocol which
removes the "soap:" part and any "soap.*" properties from the uri.
Then it delegates to the container for creating the underlying
endpoint and wrap it for soap processing.
>
> Willem.
> > Thoughts ?
> >
> >
> >> Willem.
> >>
> >> Guillaume Nodet wrote:
> >>
> >>> For the binding side, spring came up with oxm.
> >>> See http://static.springframework.org/spring-ws/site/reference/html/oxm.html
> >>> I'm not sure if we can reuse it or not, because it's only xml / pojo,
> >>> but it has support for jaxb1, jaxb2, xmlbeans, jibx, xstream and castor,
> >>> so it may be interesting to have a look at it.
> >>>
> >>> The idea of using composed uri is nice. But it may be easier to use
> >>> from("soap:jms:myQueue")
> >>> instead. That way we could create a soap component that will mainly
> >>> delegate everything to the underlying transport and mainly decorate
> >>> the endpoint with the soap processing... I guess we can use the uri
> >>> to configure properties:
> >>> soap:jms:myQueue?soap.wsdl=mylocation.wsdl
> >>> The soap component would extract all soap.* properties and use the
> >>> remaining of the uri to create the transport (jms:myQueue).
> >>>
> >>> Thoughts ?
> >>>
> >>> On 9/19/07, James Strachan <ja...@gmail.com> wrote:
> >>>
> >>>
> >>>> Sounds like a great idea! One thing I've always thought we needed was
> >>>> some kind of 'binding' abstraction. So you could do something like
> >>>>
> >>>> from(someFileOrHttpOrJmsUri).
> >>>> binding(someBinding).
> >>>> to(someFileOrHttpOrJmsUri);
> >>>>
> >>>> where someBinding = JAXB2, jibx, xstream, Java Serialisation,
> >>>> CORBA/IIOP, some binary wire encoding, SOAP 1.1/1.2 or whatever. Just
> >>>> like we have pluggable languages/expressions, components, transformers
> >>>> I figured bindings is another thing we should have a library of.
> >>>>
> >>>> We've got the POJO transformation stuff, but bindings are a tad
> >>>> different and am thinking we need to add some kinda abstraction for
> >>>> this maybe?
> >>>>
> >>>> I guess another option is you could combine the endpoint + binding
> >>>> together into a single logical endpoint and URI.
> >>>>
> >>>> from("jms+soap:myQueue").to("http+xml://foo/bar")
> >>>>
> >>>> but thats maybe a tad trickier to get going - its maybe simpler just
> >>>> having some binding abstraction first then we can tinker with it in
> >>>> different ways later on. As I'm thinking we might need to configure
> >>>> the binding in different ways (e.g. tinker with the soap interceptors
> >>>> - or configure properties of the binding, so keeping it a separate
> >>>> object in the pipeline for now is probably easiest).
> >>>>
> >>>>
> >>>> On 9/18/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>> Yeah, i'm trying to dig into it.
> >>>>> What i'd like to do is use cxf just for soap processing.
> >>>>> Ideally, i'd like to have:
> >>>>>
> >>>>> from(soap("http://localhost:8192/service")).
> >>>>> process(xx).
> >>>>> to(soap("http://myhost:8080/another")).
> >>>>> process(yy)
> >>>>>
> >>>>> which would not do any service invocation at all.
> >>>>> and this would require the DSL to be enhanced, but it would be like the
> >>>>> following (with the current dsl).
> >>>>>
> >>>>> Ideally, i'd like to be able to write:
> >>>>>
> >>>>> from("http://localhost:8192/service").
> >>>>> process(new SoapConsumerServerProcessor()).
> >>>>> process(xxx).
> >>>>> process(new SoapProviderClientProcessor()).
> >>>>> to("http://myhost:8080/another").
> >>>>> process(new SoapProviderServerProcessor()).
> >>>>> process(yy)
> >>>>> process(new SoapConsumerClientProcessor())
> >>>>>
> >>>>> which means:
> >>>>> * receive an http request,
> >>>>> * perform any soap handling (ws-*) and set the content of the soap message
> >>>>> as the body of the in message
> >>>>> * process xxx
> >>>>> * wrap the message in a soap envelope
> >>>>> * send the soap request to the target service
> >>>>> * unwrap the soap response
> >>>>> * process yyy
> >>>>> * wrap the message as a soap response
> >>>>> * send it back as the http response
> >>>>>
> >>>>> This is for the SOAP handling part.
> >>>>>
> >>>>> I'd like to be able to expose JAXWS pojo inside camel, but without any soap
> >>>>> handling, so that while inside camel, you would not use any soap stuff and
> >>>>> you could invoke the bean with plain xml / pojo.
> >>>>>
> >>>>> So at the end, you could write:
> >>>>> from(soap("http://localhost:8080")).to("cxf:
> >>>>> org.apache.camel.component.cxf.HelloService")
> >>>>>
> >>>>> or something like that and that would expose the service over http.
> >>>>>
> >>>>> Now, my understanding of the cxf component is the following:
> >>>>> * the consumer consumes soap requests using the cxf transports, performs
> >>>>> the soap processing, unmarshal the data as a list of parameters (this
> >>>>> depends on the DataFormat) and send it to the bus
> >>>>> * the producer receives a message which contains the raw message or the
> >>>>> list of unmarshaled parameters, invokes the bean and send the response back.
> >>>>> * i don't understand how to call an external service using camel-cxf
> >>>>> from(xxx).to("cxf:http://remotehost:8080/service")
> >>>>> * the DataFormat controls where the marshaling occurs (on the consumer or
> >>>>> on the producer side)
> >>>>> * there is no way to use jaxws to call a service inside camel using a
> >>>>> client proxy
> >>>>>
> >>>>> I think creating a CXF binding and a transport (it seems the current one is
> >>>>> not used) as we did for JBI may be a way to solve these problems.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>>
> >>>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>> Hi Nodet
> >>>>>>
> >>>>>> Yes, and it can perform more than service invocation part. you can find
> >>>>>> more information by check camel-cxf component code :)
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Willem.
> >>>>>>
> >>>>>> Guillaume Nodet wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Hi Willem!
> >>>>>>> Does the cxf component performs any soap processing using cxf ? Or is it
> >>>>>>> just the marshaling / service invocation part ?
> >>>>>>> I'd like to leverage cxf for soap processing...
> >>>>>>>
> >>>>>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hi ,
> >>>>>>>> I am working on camel-cxf component which will help you to do some
> >>>>>>>> router work between 2 Web Services. My big patch just been applied in
> >>>>>>>> the trunk, you can take a look at the unit test of camel-cxf component.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> >>>>>>
> >>>>>>
> >>>>>>>> I will add a Web Service router example some time this week :)
> >>>>>>>>
> >>>>>>>> Willem.
> >>>>>>>> xtof wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Hello,
> >>>>>>>>>
> >>>>>>>>> I'm quite new to Camel, and I'm trying to understand how implementing
> >>>>>>>>>
> >>>>>>>>>
> >>>>>> a
> >>>>>>
> >>>>>>
> >>>>>>>>> gateway between 2 Web Services. It requires to implement a
> >>>>>>>>>
> >>>>>>>>>
> >>>>>> request-reply
> >>>>>>
> >>>>>>
> >>>>>>>>> mechanism but I cannot find any example.
> >>>>>>>>> Could you help?
> >>>>>>>>>
> >>>>>>>>> Thank.
> >>>>>>>>> Christophe
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> Cheers,
> >>>>> Guillaume Nodet
> >>>>> ------------------------
> >>>>> Blog: http://gnodet.blogspot.com/
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> James
> >>>> -------
> >>>> http://macstrac.blogspot.com/
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Example of request reply
Posted by Willem Jiang <wi...@gmail.com>.
Hi Nodet,
Comments are in the line.
Guillaume Nodet wrote:
> On 9/19/07, Willem Jiang <wi...@gmail.com> wrote:
>
>> Hi ,
>>
>> I agree to keep the binding as a separate object in the pipeline.
>> And I suggest to add the in and out flage to the binding .
>> form("http://soapendpoint").binding(soap, in).to("pojo.service")
>> and
>> from("direct").binding(soap, out).to("http://localhost:/cxfservice");
>>
>
> We need to agree on the terms we use I suppose.
> In my mind, binding relates to databinding (xml / pojo marshaling).
> So soap is not a binding in this sense.
>
Yes.
> Let aside the databinding, I think this would be a bit too verbose.
> Concision usually means that the route definition is easier to read
> and understand.
>
> What about:
> from("soap:http://localhost:8080/service").
> to(requestTransformer).
> to("soap:http://host:8181/Service/").
> to(responseTransformer);
>
> versus: (feel free to replace soap(in) by binding(soap,in) or whatever)
> from("http://localhost:8080/service").
> soap(in).
> to(requestTransformer).
> soap(out)
> to("http://host:8181/Service/").
> to(responseTransformer);
>
> Also, I'm not even sure that this syntax makes sense. The soap(in) /
> soap(out) are really interceptors and they must be called around the
> transport endpoints. Will the soap(out) be called with the response
> from the http provider, or will the responseTransfomer be called
> before ?
>
>
I think soap(out) just works as the processor of the pipe line, in the
process method , it waits for the response message
(if the request is not one way request) and then does the response
unmarshel work.
>> BTW, I don't want to mix the binding and transport in a same URI,
>> It will make the component 's URI handling work more complex.
>>
>
> This is a trade between DSL complexity and URI complexity I suppose.
> URI are quite easy to read usually, even complex ones.
>
> failover://(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
>
> The soap component code itself would maily delegate to another
> component for the endpoint creation and just add interceptors to
> handle soap requests.
>
En,I admit the DSL formate is really easier to be understood.
But I don't know how to parser these DSL"soap:jms:myQueue.... "
Could you give me an example in camel?
Willem.
> Thoughts ?
>
>
>> Willem.
>>
>> Guillaume Nodet wrote:
>>
>>> For the binding side, spring came up with oxm.
>>> See http://static.springframework.org/spring-ws/site/reference/html/oxm.html
>>> I'm not sure if we can reuse it or not, because it's only xml / pojo,
>>> but it has support for jaxb1, jaxb2, xmlbeans, jibx, xstream and castor,
>>> so it may be interesting to have a look at it.
>>>
>>> The idea of using composed uri is nice. But it may be easier to use
>>> from("soap:jms:myQueue")
>>> instead. That way we could create a soap component that will mainly
>>> delegate everything to the underlying transport and mainly decorate
>>> the endpoint with the soap processing... I guess we can use the uri
>>> to configure properties:
>>> soap:jms:myQueue?soap.wsdl=mylocation.wsdl
>>> The soap component would extract all soap.* properties and use the
>>> remaining of the uri to create the transport (jms:myQueue).
>>>
>>> Thoughts ?
>>>
>>> On 9/19/07, James Strachan <ja...@gmail.com> wrote:
>>>
>>>
>>>> Sounds like a great idea! One thing I've always thought we needed was
>>>> some kind of 'binding' abstraction. So you could do something like
>>>>
>>>> from(someFileOrHttpOrJmsUri).
>>>> binding(someBinding).
>>>> to(someFileOrHttpOrJmsUri);
>>>>
>>>> where someBinding = JAXB2, jibx, xstream, Java Serialisation,
>>>> CORBA/IIOP, some binary wire encoding, SOAP 1.1/1.2 or whatever. Just
>>>> like we have pluggable languages/expressions, components, transformers
>>>> I figured bindings is another thing we should have a library of.
>>>>
>>>> We've got the POJO transformation stuff, but bindings are a tad
>>>> different and am thinking we need to add some kinda abstraction for
>>>> this maybe?
>>>>
>>>> I guess another option is you could combine the endpoint + binding
>>>> together into a single logical endpoint and URI.
>>>>
>>>> from("jms+soap:myQueue").to("http+xml://foo/bar")
>>>>
>>>> but thats maybe a tad trickier to get going - its maybe simpler just
>>>> having some binding abstraction first then we can tinker with it in
>>>> different ways later on. As I'm thinking we might need to configure
>>>> the binding in different ways (e.g. tinker with the soap interceptors
>>>> - or configure properties of the binding, so keeping it a separate
>>>> object in the pipeline for now is probably easiest).
>>>>
>>>>
>>>> On 9/18/07, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>
>>>>
>>>>> Yeah, i'm trying to dig into it.
>>>>> What i'd like to do is use cxf just for soap processing.
>>>>> Ideally, i'd like to have:
>>>>>
>>>>> from(soap("http://localhost:8192/service")).
>>>>> process(xx).
>>>>> to(soap("http://myhost:8080/another")).
>>>>> process(yy)
>>>>>
>>>>> which would not do any service invocation at all.
>>>>> and this would require the DSL to be enhanced, but it would be like the
>>>>> following (with the current dsl).
>>>>>
>>>>> Ideally, i'd like to be able to write:
>>>>>
>>>>> from("http://localhost:8192/service").
>>>>> process(new SoapConsumerServerProcessor()).
>>>>> process(xxx).
>>>>> process(new SoapProviderClientProcessor()).
>>>>> to("http://myhost:8080/another").
>>>>> process(new SoapProviderServerProcessor()).
>>>>> process(yy)
>>>>> process(new SoapConsumerClientProcessor())
>>>>>
>>>>> which means:
>>>>> * receive an http request,
>>>>> * perform any soap handling (ws-*) and set the content of the soap message
>>>>> as the body of the in message
>>>>> * process xxx
>>>>> * wrap the message in a soap envelope
>>>>> * send the soap request to the target service
>>>>> * unwrap the soap response
>>>>> * process yyy
>>>>> * wrap the message as a soap response
>>>>> * send it back as the http response
>>>>>
>>>>> This is for the SOAP handling part.
>>>>>
>>>>> I'd like to be able to expose JAXWS pojo inside camel, but without any soap
>>>>> handling, so that while inside camel, you would not use any soap stuff and
>>>>> you could invoke the bean with plain xml / pojo.
>>>>>
>>>>> So at the end, you could write:
>>>>> from(soap("http://localhost:8080")).to("cxf:
>>>>> org.apache.camel.component.cxf.HelloService")
>>>>>
>>>>> or something like that and that would expose the service over http.
>>>>>
>>>>> Now, my understanding of the cxf component is the following:
>>>>> * the consumer consumes soap requests using the cxf transports, performs
>>>>> the soap processing, unmarshal the data as a list of parameters (this
>>>>> depends on the DataFormat) and send it to the bus
>>>>> * the producer receives a message which contains the raw message or the
>>>>> list of unmarshaled parameters, invokes the bean and send the response back.
>>>>> * i don't understand how to call an external service using camel-cxf
>>>>> from(xxx).to("cxf:http://remotehost:8080/service")
>>>>> * the DataFormat controls where the marshaling occurs (on the consumer or
>>>>> on the producer side)
>>>>> * there is no way to use jaxws to call a service inside camel using a
>>>>> client proxy
>>>>>
>>>>> I think creating a CXF binding and a transport (it seems the current one is
>>>>> not used) as we did for JBI may be a way to solve these problems.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>>
>>>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> Hi Nodet
>>>>>>
>>>>>> Yes, and it can perform more than service invocation part. you can find
>>>>>> more information by check camel-cxf component code :)
>>>>>>
>>>>>> Cheers,
>>>>>> Willem.
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Willem!
>>>>>>> Does the cxf component performs any soap processing using cxf ? Or is it
>>>>>>> just the marshaling / service invocation part ?
>>>>>>> I'd like to leverage cxf for soap processing...
>>>>>>>
>>>>>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi ,
>>>>>>>> I am working on camel-cxf component which will help you to do some
>>>>>>>> router work between 2 Web Services. My big patch just been applied in
>>>>>>>> the trunk, you can take a look at the unit test of camel-cxf component.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
>>>>>>
>>>>>>
>>>>>>>> I will add a Web Service router example some time this week :)
>>>>>>>>
>>>>>>>> Willem.
>>>>>>>> xtof wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I'm quite new to Camel, and I'm trying to understand how implementing
>>>>>>>>>
>>>>>>>>>
>>>>>> a
>>>>>>
>>>>>>
>>>>>>>>> gateway between 2 Web Services. It requires to implement a
>>>>>>>>>
>>>>>>>>>
>>>>>> request-reply
>>>>>>
>>>>>>
>>>>>>>>> mechanism but I cannot find any example.
>>>>>>>>> Could you help?
>>>>>>>>>
>>>>>>>>> Thank.
>>>>>>>>> Christophe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>>
>>>>>
>>>>>
>>>> --
>>>> James
>>>> -------
>>>> http://macstrac.blogspot.com/
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
Re: Example of request reply
Posted by Guillaume Nodet <gn...@gmail.com>.
On 9/19/07, Willem Jiang <wi...@gmail.com> wrote:
> Hi ,
>
> I agree to keep the binding as a separate object in the pipeline.
> And I suggest to add the in and out flage to the binding .
> form("http://soapendpoint").binding(soap, in).to("pojo.service")
> and
> from("direct").binding(soap, out).to("http://localhost:/cxfservice");
We need to agree on the terms we use I suppose.
In my mind, binding relates to databinding (xml / pojo marshaling).
So soap is not a binding in this sense.
Let aside the databinding, I think this would be a bit too verbose.
Concision usually means that the route definition is easier to read
and understand.
What about:
from("soap:http://localhost:8080/service").
to(requestTransformer).
to("soap:http://host:8181/Service/").
to(responseTransformer);
versus: (feel free to replace soap(in) by binding(soap,in) or whatever)
from("http://localhost:8080/service").
soap(in).
to(requestTransformer).
soap(out)
to("http://host:8181/Service/").
to(responseTransformer);
Also, I'm not even sure that this syntax makes sense. The soap(in) /
soap(out) are really interceptors and they must be called around the
transport endpoints. Will the soap(out) be called with the response
from the http provider, or will the responseTransfomer be called
before ?
>
> BTW, I don't want to mix the binding and transport in a same URI,
> It will make the component 's URI handling work more complex.
This is a trade between DSL complexity and URI complexity I suppose.
URI are quite easy to read usually, even complex ones.
failover://(tcp://localhost:61616,tcp://remotehost:61616)?initialReconnectDelay=100
The soap component code itself would maily delegate to another
component for the endpoint creation and just add interceptors to
handle soap requests.
Thoughts ?
>
> Willem.
>
> Guillaume Nodet wrote:
> > For the binding side, spring came up with oxm.
> > See http://static.springframework.org/spring-ws/site/reference/html/oxm.html
> > I'm not sure if we can reuse it or not, because it's only xml / pojo,
> > but it has support for jaxb1, jaxb2, xmlbeans, jibx, xstream and castor,
> > so it may be interesting to have a look at it.
> >
> > The idea of using composed uri is nice. But it may be easier to use
> > from("soap:jms:myQueue")
> > instead. That way we could create a soap component that will mainly
> > delegate everything to the underlying transport and mainly decorate
> > the endpoint with the soap processing... I guess we can use the uri
> > to configure properties:
> > soap:jms:myQueue?soap.wsdl=mylocation.wsdl
> > The soap component would extract all soap.* properties and use the
> > remaining of the uri to create the transport (jms:myQueue).
> >
> > Thoughts ?
> >
> > On 9/19/07, James Strachan <ja...@gmail.com> wrote:
> >
> >> Sounds like a great idea! One thing I've always thought we needed was
> >> some kind of 'binding' abstraction. So you could do something like
> >>
> >> from(someFileOrHttpOrJmsUri).
> >> binding(someBinding).
> >> to(someFileOrHttpOrJmsUri);
> >>
> >> where someBinding = JAXB2, jibx, xstream, Java Serialisation,
> >> CORBA/IIOP, some binary wire encoding, SOAP 1.1/1.2 or whatever. Just
> >> like we have pluggable languages/expressions, components, transformers
> >> I figured bindings is another thing we should have a library of.
> >>
> >> We've got the POJO transformation stuff, but bindings are a tad
> >> different and am thinking we need to add some kinda abstraction for
> >> this maybe?
> >>
> >> I guess another option is you could combine the endpoint + binding
> >> together into a single logical endpoint and URI.
> >>
> >> from("jms+soap:myQueue").to("http+xml://foo/bar")
> >>
> >> but thats maybe a tad trickier to get going - its maybe simpler just
> >> having some binding abstraction first then we can tinker with it in
> >> different ways later on. As I'm thinking we might need to configure
> >> the binding in different ways (e.g. tinker with the soap interceptors
> >> - or configure properties of the binding, so keeping it a separate
> >> object in the pipeline for now is probably easiest).
> >>
> >>
> >> On 9/18/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >>
> >>> Yeah, i'm trying to dig into it.
> >>> What i'd like to do is use cxf just for soap processing.
> >>> Ideally, i'd like to have:
> >>>
> >>> from(soap("http://localhost:8192/service")).
> >>> process(xx).
> >>> to(soap("http://myhost:8080/another")).
> >>> process(yy)
> >>>
> >>> which would not do any service invocation at all.
> >>> and this would require the DSL to be enhanced, but it would be like the
> >>> following (with the current dsl).
> >>>
> >>> Ideally, i'd like to be able to write:
> >>>
> >>> from("http://localhost:8192/service").
> >>> process(new SoapConsumerServerProcessor()).
> >>> process(xxx).
> >>> process(new SoapProviderClientProcessor()).
> >>> to("http://myhost:8080/another").
> >>> process(new SoapProviderServerProcessor()).
> >>> process(yy)
> >>> process(new SoapConsumerClientProcessor())
> >>>
> >>> which means:
> >>> * receive an http request,
> >>> * perform any soap handling (ws-*) and set the content of the soap message
> >>> as the body of the in message
> >>> * process xxx
> >>> * wrap the message in a soap envelope
> >>> * send the soap request to the target service
> >>> * unwrap the soap response
> >>> * process yyy
> >>> * wrap the message as a soap response
> >>> * send it back as the http response
> >>>
> >>> This is for the SOAP handling part.
> >>>
> >>> I'd like to be able to expose JAXWS pojo inside camel, but without any soap
> >>> handling, so that while inside camel, you would not use any soap stuff and
> >>> you could invoke the bean with plain xml / pojo.
> >>>
> >>> So at the end, you could write:
> >>> from(soap("http://localhost:8080")).to("cxf:
> >>> org.apache.camel.component.cxf.HelloService")
> >>>
> >>> or something like that and that would expose the service over http.
> >>>
> >>> Now, my understanding of the cxf component is the following:
> >>> * the consumer consumes soap requests using the cxf transports, performs
> >>> the soap processing, unmarshal the data as a list of parameters (this
> >>> depends on the DataFormat) and send it to the bus
> >>> * the producer receives a message which contains the raw message or the
> >>> list of unmarshaled parameters, invokes the bean and send the response back.
> >>> * i don't understand how to call an external service using camel-cxf
> >>> from(xxx).to("cxf:http://remotehost:8080/service")
> >>> * the DataFormat controls where the marshaling occurs (on the consumer or
> >>> on the producer side)
> >>> * there is no way to use jaxws to call a service inside camel using a
> >>> client proxy
> >>>
> >>> I think creating a CXF binding and a transport (it seems the current one is
> >>> not used) as we did for JBI may be a way to solve these problems.
> >>>
> >>> Thoughts ?
> >>>
> >>>
> >>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >>>
> >>>> Hi Nodet
> >>>>
> >>>> Yes, and it can perform more than service invocation part. you can find
> >>>> more information by check camel-cxf component code :)
> >>>>
> >>>> Cheers,
> >>>> Willem.
> >>>>
> >>>> Guillaume Nodet wrote:
> >>>>
> >>>>> Hi Willem!
> >>>>> Does the cxf component performs any soap processing using cxf ? Or is it
> >>>>> just the marshaling / service invocation part ?
> >>>>> I'd like to leverage cxf for soap processing...
> >>>>>
> >>>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>> Hi ,
> >>>>>> I am working on camel-cxf component which will help you to do some
> >>>>>> router work between 2 Web Services. My big patch just been applied in
> >>>>>> the trunk, you can take a look at the unit test of camel-cxf component.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> >>>>
> >>>>>> I will add a Web Service router example some time this week :)
> >>>>>>
> >>>>>> Willem.
> >>>>>> xtof wrote:
> >>>>>>
> >>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I'm quite new to Camel, and I'm trying to understand how implementing
> >>>>>>>
> >>>> a
> >>>>
> >>>>>>> gateway between 2 Web Services. It requires to implement a
> >>>>>>>
> >>>> request-reply
> >>>>
> >>>>>>> mechanism but I cannot find any example.
> >>>>>>> Could you help?
> >>>>>>>
> >>>>>>> Thank.
> >>>>>>> Christophe
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>> --
> >>> Cheers,
> >>> Guillaume Nodet
> >>> ------------------------
> >>> Blog: http://gnodet.blogspot.com/
> >>>
> >>>
> >> --
> >> James
> >> -------
> >> http://macstrac.blogspot.com/
> >>
> >>
> >
> >
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Example of request reply
Posted by Willem Jiang <wi...@gmail.com>.
Hi ,
I agree to keep the binding as a separate object in the pipeline.
And I suggest to add the in and out flage to the binding .
form("http://soapendpoint").binding(soap, in).to("pojo.service")
and
from("direct").binding(soap, out).to("http://localhost:/cxfservice");
BTW, I don't want to mix the binding and transport in a same URI,
It will make the component 's URI handling work more complex.
Willem.
Guillaume Nodet wrote:
> For the binding side, spring came up with oxm.
> See http://static.springframework.org/spring-ws/site/reference/html/oxm.html
> I'm not sure if we can reuse it or not, because it's only xml / pojo,
> but it has support for jaxb1, jaxb2, xmlbeans, jibx, xstream and castor,
> so it may be interesting to have a look at it.
>
> The idea of using composed uri is nice. But it may be easier to use
> from("soap:jms:myQueue")
> instead. That way we could create a soap component that will mainly
> delegate everything to the underlying transport and mainly decorate
> the endpoint with the soap processing... I guess we can use the uri
> to configure properties:
> soap:jms:myQueue?soap.wsdl=mylocation.wsdl
> The soap component would extract all soap.* properties and use the
> remaining of the uri to create the transport (jms:myQueue).
>
> Thoughts ?
>
> On 9/19/07, James Strachan <ja...@gmail.com> wrote:
>
>> Sounds like a great idea! One thing I've always thought we needed was
>> some kind of 'binding' abstraction. So you could do something like
>>
>> from(someFileOrHttpOrJmsUri).
>> binding(someBinding).
>> to(someFileOrHttpOrJmsUri);
>>
>> where someBinding = JAXB2, jibx, xstream, Java Serialisation,
>> CORBA/IIOP, some binary wire encoding, SOAP 1.1/1.2 or whatever. Just
>> like we have pluggable languages/expressions, components, transformers
>> I figured bindings is another thing we should have a library of.
>>
>> We've got the POJO transformation stuff, but bindings are a tad
>> different and am thinking we need to add some kinda abstraction for
>> this maybe?
>>
>> I guess another option is you could combine the endpoint + binding
>> together into a single logical endpoint and URI.
>>
>> from("jms+soap:myQueue").to("http+xml://foo/bar")
>>
>> but thats maybe a tad trickier to get going - its maybe simpler just
>> having some binding abstraction first then we can tinker with it in
>> different ways later on. As I'm thinking we might need to configure
>> the binding in different ways (e.g. tinker with the soap interceptors
>> - or configure properties of the binding, so keeping it a separate
>> object in the pipeline for now is probably easiest).
>>
>>
>> On 9/18/07, Guillaume Nodet <gn...@gmail.com> wrote:
>>
>>> Yeah, i'm trying to dig into it.
>>> What i'd like to do is use cxf just for soap processing.
>>> Ideally, i'd like to have:
>>>
>>> from(soap("http://localhost:8192/service")).
>>> process(xx).
>>> to(soap("http://myhost:8080/another")).
>>> process(yy)
>>>
>>> which would not do any service invocation at all.
>>> and this would require the DSL to be enhanced, but it would be like the
>>> following (with the current dsl).
>>>
>>> Ideally, i'd like to be able to write:
>>>
>>> from("http://localhost:8192/service").
>>> process(new SoapConsumerServerProcessor()).
>>> process(xxx).
>>> process(new SoapProviderClientProcessor()).
>>> to("http://myhost:8080/another").
>>> process(new SoapProviderServerProcessor()).
>>> process(yy)
>>> process(new SoapConsumerClientProcessor())
>>>
>>> which means:
>>> * receive an http request,
>>> * perform any soap handling (ws-*) and set the content of the soap message
>>> as the body of the in message
>>> * process xxx
>>> * wrap the message in a soap envelope
>>> * send the soap request to the target service
>>> * unwrap the soap response
>>> * process yyy
>>> * wrap the message as a soap response
>>> * send it back as the http response
>>>
>>> This is for the SOAP handling part.
>>>
>>> I'd like to be able to expose JAXWS pojo inside camel, but without any soap
>>> handling, so that while inside camel, you would not use any soap stuff and
>>> you could invoke the bean with plain xml / pojo.
>>>
>>> So at the end, you could write:
>>> from(soap("http://localhost:8080")).to("cxf:
>>> org.apache.camel.component.cxf.HelloService")
>>>
>>> or something like that and that would expose the service over http.
>>>
>>> Now, my understanding of the cxf component is the following:
>>> * the consumer consumes soap requests using the cxf transports, performs
>>> the soap processing, unmarshal the data as a list of parameters (this
>>> depends on the DataFormat) and send it to the bus
>>> * the producer receives a message which contains the raw message or the
>>> list of unmarshaled parameters, invokes the bean and send the response back.
>>> * i don't understand how to call an external service using camel-cxf
>>> from(xxx).to("cxf:http://remotehost:8080/service")
>>> * the DataFormat controls where the marshaling occurs (on the consumer or
>>> on the producer side)
>>> * there is no way to use jaxws to call a service inside camel using a
>>> client proxy
>>>
>>> I think creating a CXF binding and a transport (it seems the current one is
>>> not used) as we did for JBI may be a way to solve these problems.
>>>
>>> Thoughts ?
>>>
>>>
>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>>>
>>>> Hi Nodet
>>>>
>>>> Yes, and it can perform more than service invocation part. you can find
>>>> more information by check camel-cxf component code :)
>>>>
>>>> Cheers,
>>>> Willem.
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>> Hi Willem!
>>>>> Does the cxf component performs any soap processing using cxf ? Or is it
>>>>> just the marshaling / service invocation part ?
>>>>> I'd like to leverage cxf for soap processing...
>>>>>
>>>>> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> Hi ,
>>>>>> I am working on camel-cxf component which will help you to do some
>>>>>> router work between 2 Web Services. My big patch just been applied in
>>>>>> the trunk, you can take a look at the unit test of camel-cxf component.
>>>>>>
>>>>>>
>>>>>>
>>>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
>>>>
>>>>>> I will add a Web Service router example some time this week :)
>>>>>>
>>>>>> Willem.
>>>>>> xtof wrote:
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm quite new to Camel, and I'm trying to understand how implementing
>>>>>>>
>>>> a
>>>>
>>>>>>> gateway between 2 Web Services. It requires to implement a
>>>>>>>
>>>> request-reply
>>>>
>>>>>>> mechanism but I cannot find any example.
>>>>>>> Could you help?
>>>>>>>
>>>>>>> Thank.
>>>>>>> Christophe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>>
>
>
>
Re: Example of request reply
Posted by Guillaume Nodet <gn...@gmail.com>.
For the binding side, spring came up with oxm.
See http://static.springframework.org/spring-ws/site/reference/html/oxm.html
I'm not sure if we can reuse it or not, because it's only xml / pojo,
but it has support for jaxb1, jaxb2, xmlbeans, jibx, xstream and castor,
so it may be interesting to have a look at it.
The idea of using composed uri is nice. But it may be easier to use
from("soap:jms:myQueue")
instead. That way we could create a soap component that will mainly
delegate everything to the underlying transport and mainly decorate
the endpoint with the soap processing... I guess we can use the uri
to configure properties:
soap:jms:myQueue?soap.wsdl=mylocation.wsdl
The soap component would extract all soap.* properties and use the
remaining of the uri to create the transport (jms:myQueue).
Thoughts ?
On 9/19/07, James Strachan <ja...@gmail.com> wrote:
> Sounds like a great idea! One thing I've always thought we needed was
> some kind of 'binding' abstraction. So you could do something like
>
> from(someFileOrHttpOrJmsUri).
> binding(someBinding).
> to(someFileOrHttpOrJmsUri);
>
> where someBinding = JAXB2, jibx, xstream, Java Serialisation,
> CORBA/IIOP, some binary wire encoding, SOAP 1.1/1.2 or whatever. Just
> like we have pluggable languages/expressions, components, transformers
> I figured bindings is another thing we should have a library of.
>
> We've got the POJO transformation stuff, but bindings are a tad
> different and am thinking we need to add some kinda abstraction for
> this maybe?
>
> I guess another option is you could combine the endpoint + binding
> together into a single logical endpoint and URI.
>
> from("jms+soap:myQueue").to("http+xml://foo/bar")
>
> but thats maybe a tad trickier to get going - its maybe simpler just
> having some binding abstraction first then we can tinker with it in
> different ways later on. As I'm thinking we might need to configure
> the binding in different ways (e.g. tinker with the soap interceptors
> - or configure properties of the binding, so keeping it a separate
> object in the pipeline for now is probably easiest).
>
>
> On 9/18/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > Yeah, i'm trying to dig into it.
> > What i'd like to do is use cxf just for soap processing.
> > Ideally, i'd like to have:
> >
> > from(soap("http://localhost:8192/service")).
> > process(xx).
> > to(soap("http://myhost:8080/another")).
> > process(yy)
> >
> > which would not do any service invocation at all.
> > and this would require the DSL to be enhanced, but it would be like the
> > following (with the current dsl).
> >
> > Ideally, i'd like to be able to write:
> >
> > from("http://localhost:8192/service").
> > process(new SoapConsumerServerProcessor()).
> > process(xxx).
> > process(new SoapProviderClientProcessor()).
> > to("http://myhost:8080/another").
> > process(new SoapProviderServerProcessor()).
> > process(yy)
> > process(new SoapConsumerClientProcessor())
> >
> > which means:
> > * receive an http request,
> > * perform any soap handling (ws-*) and set the content of the soap message
> > as the body of the in message
> > * process xxx
> > * wrap the message in a soap envelope
> > * send the soap request to the target service
> > * unwrap the soap response
> > * process yyy
> > * wrap the message as a soap response
> > * send it back as the http response
> >
> > This is for the SOAP handling part.
> >
> > I'd like to be able to expose JAXWS pojo inside camel, but without any soap
> > handling, so that while inside camel, you would not use any soap stuff and
> > you could invoke the bean with plain xml / pojo.
> >
> > So at the end, you could write:
> > from(soap("http://localhost:8080")).to("cxf:
> > org.apache.camel.component.cxf.HelloService")
> >
> > or something like that and that would expose the service over http.
> >
> > Now, my understanding of the cxf component is the following:
> > * the consumer consumes soap requests using the cxf transports, performs
> > the soap processing, unmarshal the data as a list of parameters (this
> > depends on the DataFormat) and send it to the bus
> > * the producer receives a message which contains the raw message or the
> > list of unmarshaled parameters, invokes the bean and send the response back.
> > * i don't understand how to call an external service using camel-cxf
> > from(xxx).to("cxf:http://remotehost:8080/service")
> > * the DataFormat controls where the marshaling occurs (on the consumer or
> > on the producer side)
> > * there is no way to use jaxws to call a service inside camel using a
> > client proxy
> >
> > I think creating a CXF binding and a transport (it seems the current one is
> > not used) as we did for JBI may be a way to solve these problems.
> >
> > Thoughts ?
> >
> >
> > On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> > >
> > > Hi Nodet
> > >
> > > Yes, and it can perform more than service invocation part. you can find
> > > more information by check camel-cxf component code :)
> > >
> > > Cheers,
> > > Willem.
> > >
> > > Guillaume Nodet wrote:
> > > > Hi Willem!
> > > > Does the cxf component performs any soap processing using cxf ? Or is it
> > > > just the marshaling / service invocation part ?
> > > > I'd like to leverage cxf for soap processing...
> > > >
> > > > On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> > > >
> > > >> Hi ,
> > > >> I am working on camel-cxf component which will help you to do some
> > > >> router work between 2 Web Services. My big patch just been applied in
> > > >> the trunk, you can take a look at the unit test of camel-cxf component.
> > > >>
> > > >>
> > > https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> > > >> I will add a Web Service router example some time this week :)
> > > >>
> > > >> Willem.
> > > >> xtof wrote:
> > > >>
> > > >>> Hello,
> > > >>>
> > > >>> I'm quite new to Camel, and I'm trying to understand how implementing
> > > a
> > > >>> gateway between 2 Web Services. It requires to implement a
> > > request-reply
> > > >>> mechanism but I cannot find any example.
> > > >>> Could you help?
> > > >>>
> > > >>> Thank.
> > > >>> Christophe
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Example of request reply
Posted by James Strachan <ja...@gmail.com>.
Sounds like a great idea! One thing I've always thought we needed was
some kind of 'binding' abstraction. So you could do something like
from(someFileOrHttpOrJmsUri).
binding(someBinding).
to(someFileOrHttpOrJmsUri);
where someBinding = JAXB2, jibx, xstream, Java Serialisation,
CORBA/IIOP, some binary wire encoding, SOAP 1.1/1.2 or whatever. Just
like we have pluggable languages/expressions, components, transformers
I figured bindings is another thing we should have a library of.
We've got the POJO transformation stuff, but bindings are a tad
different and am thinking we need to add some kinda abstraction for
this maybe?
I guess another option is you could combine the endpoint + binding
together into a single logical endpoint and URI.
from("jms+soap:myQueue").to("http+xml://foo/bar")
but thats maybe a tad trickier to get going - its maybe simpler just
having some binding abstraction first then we can tinker with it in
different ways later on. As I'm thinking we might need to configure
the binding in different ways (e.g. tinker with the soap interceptors
- or configure properties of the binding, so keeping it a separate
object in the pipeline for now is probably easiest).
On 9/18/07, Guillaume Nodet <gn...@gmail.com> wrote:
> Yeah, i'm trying to dig into it.
> What i'd like to do is use cxf just for soap processing.
> Ideally, i'd like to have:
>
> from(soap("http://localhost:8192/service")).
> process(xx).
> to(soap("http://myhost:8080/another")).
> process(yy)
>
> which would not do any service invocation at all.
> and this would require the DSL to be enhanced, but it would be like the
> following (with the current dsl).
>
> Ideally, i'd like to be able to write:
>
> from("http://localhost:8192/service").
> process(new SoapConsumerServerProcessor()).
> process(xxx).
> process(new SoapProviderClientProcessor()).
> to("http://myhost:8080/another").
> process(new SoapProviderServerProcessor()).
> process(yy)
> process(new SoapConsumerClientProcessor())
>
> which means:
> * receive an http request,
> * perform any soap handling (ws-*) and set the content of the soap message
> as the body of the in message
> * process xxx
> * wrap the message in a soap envelope
> * send the soap request to the target service
> * unwrap the soap response
> * process yyy
> * wrap the message as a soap response
> * send it back as the http response
>
> This is for the SOAP handling part.
>
> I'd like to be able to expose JAXWS pojo inside camel, but without any soap
> handling, so that while inside camel, you would not use any soap stuff and
> you could invoke the bean with plain xml / pojo.
>
> So at the end, you could write:
> from(soap("http://localhost:8080")).to("cxf:
> org.apache.camel.component.cxf.HelloService")
>
> or something like that and that would expose the service over http.
>
> Now, my understanding of the cxf component is the following:
> * the consumer consumes soap requests using the cxf transports, performs
> the soap processing, unmarshal the data as a list of parameters (this
> depends on the DataFormat) and send it to the bus
> * the producer receives a message which contains the raw message or the
> list of unmarshaled parameters, invokes the bean and send the response back.
> * i don't understand how to call an external service using camel-cxf
> from(xxx).to("cxf:http://remotehost:8080/service")
> * the DataFormat controls where the marshaling occurs (on the consumer or
> on the producer side)
> * there is no way to use jaxws to call a service inside camel using a
> client proxy
>
> I think creating a CXF binding and a transport (it seems the current one is
> not used) as we did for JBI may be a way to solve these problems.
>
> Thoughts ?
>
>
> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >
> > Hi Nodet
> >
> > Yes, and it can perform more than service invocation part. you can find
> > more information by check camel-cxf component code :)
> >
> > Cheers,
> > Willem.
> >
> > Guillaume Nodet wrote:
> > > Hi Willem!
> > > Does the cxf component performs any soap processing using cxf ? Or is it
> > > just the marshaling / service invocation part ?
> > > I'd like to leverage cxf for soap processing...
> > >
> > > On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> > >
> > >> Hi ,
> > >> I am working on camel-cxf component which will help you to do some
> > >> router work between 2 Web Services. My big patch just been applied in
> > >> the trunk, you can take a look at the unit test of camel-cxf component.
> > >>
> > >>
> > https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> > >> I will add a Web Service router example some time this week :)
> > >>
> > >> Willem.
> > >> xtof wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> I'm quite new to Camel, and I'm trying to understand how implementing
> > a
> > >>> gateway between 2 Web Services. It requires to implement a
> > request-reply
> > >>> mechanism but I cannot find any example.
> > >>> Could you help?
> > >>>
> > >>> Thank.
> > >>> Christophe
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
James
-------
http://macstrac.blogspot.com/
Re: Example of request reply
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, i'm trying to dig into it.
What i'd like to do is use cxf just for soap processing.
Ideally, i'd like to have:
from(soap("http://localhost:8192/service")).
process(xx).
to(soap("http://myhost:8080/another")).
process(yy)
which would not do any service invocation at all.
and this would require the DSL to be enhanced, but it would be like the
following (with the current dsl).
Ideally, i'd like to be able to write:
from("http://localhost:8192/service").
process(new SoapConsumerServerProcessor()).
process(xxx).
process(new SoapProviderClientProcessor()).
to("http://myhost:8080/another").
process(new SoapProviderServerProcessor()).
process(yy)
process(new SoapConsumerClientProcessor())
which means:
* receive an http request,
* perform any soap handling (ws-*) and set the content of the soap message
as the body of the in message
* process xxx
* wrap the message in a soap envelope
* send the soap request to the target service
* unwrap the soap response
* process yyy
* wrap the message as a soap response
* send it back as the http response
This is for the SOAP handling part.
I'd like to be able to expose JAXWS pojo inside camel, but without any soap
handling, so that while inside camel, you would not use any soap stuff and
you could invoke the bean with plain xml / pojo.
So at the end, you could write:
from(soap("http://localhost:8080")).to("cxf:
org.apache.camel.component.cxf.HelloService")
or something like that and that would expose the service over http.
Now, my understanding of the cxf component is the following:
* the consumer consumes soap requests using the cxf transports, performs
the soap processing, unmarshal the data as a list of parameters (this
depends on the DataFormat) and send it to the bus
* the producer receives a message which contains the raw message or the
list of unmarshaled parameters, invokes the bean and send the response back.
* i don't understand how to call an external service using camel-cxf
from(xxx).to("cxf:http://remotehost:8080/service")
* the DataFormat controls where the marshaling occurs (on the consumer or
on the producer side)
* there is no way to use jaxws to call a service inside camel using a
client proxy
I think creating a CXF binding and a transport (it seems the current one is
not used) as we did for JBI may be a way to solve these problems.
Thoughts ?
On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>
> Hi Nodet
>
> Yes, and it can perform more than service invocation part. you can find
> more information by check camel-cxf component code :)
>
> Cheers,
> Willem.
>
> Guillaume Nodet wrote:
> > Hi Willem!
> > Does the cxf component performs any soap processing using cxf ? Or is it
> > just the marshaling / service invocation part ?
> > I'd like to leverage cxf for soap processing...
> >
> > On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
> >
> >> Hi ,
> >> I am working on camel-cxf component which will help you to do some
> >> router work between 2 Web Services. My big patch just been applied in
> >> the trunk, you can take a look at the unit test of camel-cxf component.
> >>
> >>
> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> >> I will add a Web Service router example some time this week :)
> >>
> >> Willem.
> >> xtof wrote:
> >>
> >>> Hello,
> >>>
> >>> I'm quite new to Camel, and I'm trying to understand how implementing
> a
> >>> gateway between 2 Web Services. It requires to implement a
> request-reply
> >>> mechanism but I cannot find any example.
> >>> Could you help?
> >>>
> >>> Thank.
> >>> Christophe
> >>>
> >>>
> >>
> >
> >
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Example of request reply
Posted by Willem Jiang <wi...@gmail.com>.
Hi Nodet
Yes, and it can perform more than service invocation part. you can find
more information by check camel-cxf component code :)
Cheers,
Willem.
Guillaume Nodet wrote:
> Hi Willem!
> Does the cxf component performs any soap processing using cxf ? Or is it
> just the marshaling / service invocation part ?
> I'd like to leverage cxf for soap processing...
>
> On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>
>> Hi ,
>> I am working on camel-cxf component which will help you to do some
>> router work between 2 Web Services. My big patch just been applied in
>> the trunk, you can take a look at the unit test of camel-cxf component.
>>
>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
>> I will add a Web Service router example some time this week :)
>>
>> Willem.
>> xtof wrote:
>>
>>> Hello,
>>>
>>> I'm quite new to Camel, and I'm trying to understand how implementing a
>>> gateway between 2 Web Services. It requires to implement a request-reply
>>> mechanism but I cannot find any example.
>>> Could you help?
>>>
>>> Thank.
>>> Christophe
>>>
>>>
>>
>
>
>
Re: Example of request reply
Posted by Guillaume Nodet <gn...@gmail.com>.
Hi Willem!
Does the cxf component performs any soap processing using cxf ? Or is it
just the marshaling / service invocation part ?
I'd like to leverage cxf for soap processing...
On 9/18/07, Willem Jiang <wi...@gmail.com> wrote:
>
> Hi ,
> I am working on camel-cxf component which will help you to do some
> router work between 2 Web Services. My big patch just been applied in
> the trunk, you can take a look at the unit test of camel-cxf component.
>
> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> I will add a Web Service router example some time this week :)
>
> Willem.
> xtof wrote:
> > Hello,
> >
> > I'm quite new to Camel, and I'm trying to understand how implementing a
> > gateway between 2 Web Services. It requires to implement a request-reply
> > mechanism but I cannot find any example.
> > Could you help?
> >
> > Thank.
> > Christophe
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Example of request reply
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
Current CXF component sample POJO model shows your can invoke a
WebService with a method name and arguments list. You can find more
information about form the camel-cxf module's unit test[1] here.
[1]https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfProducerTest.java
Willem.
Ravi116 wrote:
> Hi,
> Is the web services example available now as part of snapshot download ?
> I am new to camel and cxf. My simple use case is to publish a message to a
> active mq topic and have it route the message to a cxf web service. Here is
> the sample code below -
>
> private static String serviceEndpointURI = "cxf://" + SERVICE_ADDRESS + "?"
> + SERVICE_CLASS + "&dataFormat=POJO";
> ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("vm://localhost?broker.persistent=false");
> context.addRoutes(new RouteBuilder() {
>
> public void configure() throws Exception {
> from("test-jms:queue:test.queue").to(serviceEndpointURI);
> }
> });
> CamelTemplate template = new CamelTemplate(context);
> context.start();
> for (int i = 0; i < 10; i++) {
> template.sendBody("test-jms:queue:test.queue", "Test Message: "
> + i);
> }
> Thread.sleep(1000);
> context.stop();
>
> Will the code above work ?
> Ravi
>
>
>
>
>
> willem.jiang wrote:
>
>> Hi ,
>> I am working on camel-cxf component which will help you to do some
>> router work between 2 Web Services. My big patch just been applied in
>> the trunk, you can take a look at the unit test of camel-cxf component.
>> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
>> I will add a Web Service router example some time this week :)
>>
>> Willem.
>> xtof wrote:
>>
>>> Hello,
>>>
>>> I'm quite new to Camel, and I'm trying to understand how implementing a
>>> gateway between 2 Web Services. It requires to implement a request-reply
>>> mechanism but I cannot find any example.
>>> Could you help?
>>>
>>> Thank.
>>> Christophe
>>>
>>>
>>
>>
>
>
Re: Example of request reply
Posted by Ravi116 <ra...@countrywide.com>.
Hi,
Is the web services example available now as part of snapshot download ?
I am new to camel and cxf. My simple use case is to publish a message to a
active mq topic and have it route the message to a cxf web service. Here is
the sample code below -
private static String serviceEndpointURI = "cxf://" + SERVICE_ADDRESS + "?"
+ SERVICE_CLASS + "&dataFormat=POJO";
ConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("vm://localhost?broker.persistent=false");
context.addRoutes(new RouteBuilder() {
public void configure() throws Exception {
from("test-jms:queue:test.queue").to(serviceEndpointURI);
}
});
CamelTemplate template = new CamelTemplate(context);
context.start();
for (int i = 0; i < 10; i++) {
template.sendBody("test-jms:queue:test.queue", "Test Message: "
+ i);
}
Thread.sleep(1000);
context.stop();
Will the code above work ?
Ravi
willem.jiang wrote:
>
> Hi ,
> I am working on camel-cxf component which will help you to do some
> router work between 2 Web Services. My big patch just been applied in
> the trunk, you can take a look at the unit test of camel-cxf component.
> https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
> I will add a Web Service router example some time this week :)
>
> Willem.
> xtof wrote:
>> Hello,
>>
>> I'm quite new to Camel, and I'm trying to understand how implementing a
>> gateway between 2 Web Services. It requires to implement a request-reply
>> mechanism but I cannot find any example.
>> Could you help?
>>
>> Thank.
>> Christophe
>>
>
>
>
--
View this message in context: http://www.nabble.com/Example-of-request-reply-tf4473066s22882.html#a13020650
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Example of request reply
Posted by Willem Jiang <wi...@gmail.com>.
Hi ,
I am working on camel-cxf component which will help you to do some
router work between 2 Web Services. My big patch just been applied in
the trunk, you can take a look at the unit test of camel-cxf component.
https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfRouterTest.java
I will add a Web Service router example some time this week :)
Willem.
xtof wrote:
> Hello,
>
> I'm quite new to Camel, and I'm trying to understand how implementing a
> gateway between 2 Web Services. It requires to implement a request-reply
> mechanism but I cannot find any example.
> Could you help?
>
> Thank.
> Christophe
>
Re: Example of request reply
Posted by Guillaume Nodet <gn...@gmail.com>.
Basically, if you write
from("http://localhost:8080/myService").to("
http://remotehost:8080/targetService")
it should work. Unfortuntately, the http component is not finished and it
won't write the response iirc. But you can try with the http component
based on jakarta http core using
from("jhc:http://localhost:8080/myService").to("jhc:
http://remotehost:8080/targetService")
On 9/18/07, xtof <ch...@hp.com> wrote:
>
>
> Hello,
>
> I'm quite new to Camel, and I'm trying to understand how implementing a
> gateway between 2 Web Services. It requires to implement a request-reply
> mechanism but I cannot find any example.
> Could you help?
>
> Thank.
> Christophe
> --
> View this message in context:
> http://www.nabble.com/Example-of-request-reply-tf4473066s22882.html#a12753590
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/