Re: (switch to dev) Re: Having a web service automatically activate when data is placed into a queue

[Willem Jiang <wi...@gmail.com>]

Glen Mazza wrote:
> 2008-04-20 (日) の 05:37 -0400 に Glen Mazza さんは書きました:
>   
>> 2008-04-19 Willem Jiang wrote:
>>     
>>> Hi Glen,
>>>
>>> My comments are in the mail.
>>>
>>> Glen Mazza wrote:
>>>       
>>>> Hello again, I have a few more questions.  I'm using a CXF-based web
>>>> service provider running on Tomcat, using CXF's JAX-WS front end.  Its
>>>> WSDL is located on my machine as follows:
>>>> http://localhost:8080/doubleit/services/doubleit?wsdl.
>>>>
>>>> Questions about the CXF component page[1]:
>>>>
>>>> 1.) Using this type of URI:  "cxf://address?options", which of the
>>>> options--wsdlURL, serviceClass, serviceName, portName--do I have to
>>>> provide?  It seems strange to need to provide any of these options,
>>>> because the first can be obtained via "?wsdl" by default, the second is
>>>> not necessarily known by the client, and the third and fourth are
>>>> readable from the WSDL--perhaps these options are needed only by CXF's
>>>> simple frontend?  
>>>>   
>>>>         
>>> Yes , the endpoint's address can get from the WSDL , but if the WSDL has 
>>> more than two ServiceNames or PortNames, you need to specify the right 
>>> one that you want.
>>> The URI "cxf://address?options" is common pattern for cxf endpoint ( not 
>>> only the CXF provider  but also CXF consumer), and camel-cxf component 
>>> can't know which frontend will be used if it do not check the annotation 
>>> from the serviceClass, so the serviceClass and address in required 
>>> parameter for the camel-cxf component, the others parameters are optional.
>>>       
>
> I need a little bit more clarification here.  If "cxf://address?options"
> is being used for a CXF consumer (not the provider), is the only reason
> why the serviceClass is needed is to determine whether the simple or
> jaxws frontend is being used?  If so, I would like to say that Camel
> should default to the jaxws frontend if no serviceClass is given.  The
> reason why I think this is because if you're using a CXF consumer you
> won't always have access to the SEI implementation class of the web
> service provider, so an ability to configure a CXF consumer without
> providing the SEI impl. would be beneficial I think.
>
> Thanks,
> Glen
>
>
>
>   
The Service Class is not only give us hit about which frontend  that we 
should use, but also help us to set up the message marshal and unmarshal 
context.
when the CXF consumer work in the POJO data format model, all the 
incoming request message will go through the data binding interceptors.
If we do not specify the Service Class here , CXF's data binding 
interceptors will not build the right context from the type classes 
which are referenced by the Service Class.

If the consumer are working in the RawMessage or the PAYLOAD data format 
, SEI could a optional parameter.

Cheers,
Willem