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

Reply via email to