Open mkalam-alami opened 13 years ago
JGuillemotte
commented
12 years ago To resume : The sample easysoa-frascati-nuxeo.zip works well with a "dynamic" client, that is to say a client which WSDL classes are generated by FraSCAti, but not with a "static" client, which classes were generated with a tool like WSDL2JAVA. In th is case, there is differences between the WSDL published by FraSCAti and the original WSDL because FraSCAti don't use the SCA annotations in these classes.
JGuillemotte
commented
12 years ago I have tested the example Weather-mock. This examples works fine with a client developped with FraSCAti (because FraSCAti clients are generated at runtime) but ...
We find the following problem :
The clients used in the Smart travel demo have been developped with CXF and more particulary with the tool WSDl2JAVA. Lot of classes have been generated and there are some classes refer to services and port indicated in the original WSDl. So it is not possible to run the client with a service having a WSDL different from the original (services and port with differents names).
The goal is to obtains a full compatible mock with the existing clients (the clients works already with the original service) without to do any modification on them.
However, there are naming differences for the services names and the ports names between the original WSDl and the mocked WSDL :
Service name :
Port name :
Or in XML :
In the interface GlobalWeatherSoap, there is a JAX-WS annotation @WebService(targetNamespace = "http://www.webserviceX.NET", name = "GlobalWeatherSoap", serviceName = "GlobalWeather") where we can specify the service name, the portype name ... It seems that fraSCAti doesn't work with this annotation, or possibly with the implementation's as a single @WebService annotation, as in the working CXF-only sample :
@javax.jws.WebService(serviceName = "GlobalWeather",portName = "GlobalWeatherSoap",targetNamespace = "http://www.webserviceX.NET",endpointInterface = "net.webservicex.GlobalWeatherSoap")
To resume, the exemple works very well with a FraSCAti 'dynamic' client, that is to say a client which classes are generated at the runtime, but not with an already existing 'static' client which classes are generated with a tool like WSDL2JAVA.
An exemple of the problem can be found in the easysoa-samples-smarttravel-services-backup-sca project at : https://github.com/easysoa/EasySOA/tree/master/samples/easysoa-samples-smarttravel/easysoa-samples-smarttravel-services-backup-sca . To start it, type mvn -Dtest=*TestStarter install
We understand that this feature is not a core feature for FraSCAti but it can be useful, especially in the EasySOA project. We can for example generate easily mocked services for prototyping.
mdutoo
commented
12 years ago Found out the problem, using Fractal source and Eclipse debugging :
If the service interface is JAXWS-annotated, the Fractal BF WS connector makes sure CXF is handling it the JAXWS way (it's a JAXWS endpoint), but gives it a non-JAXWS annotated implementation ("servant"), which is the generated GlobalWeatherSoapFcInItf.java . The proof that this is the root of the problem is that when the JAXWS annotations are commented in the implementation of the working CXF-only sample, it stops working and starts providing a bad WSDL :
`
JGuillemotte
commented
12 years ago A new package has been added in HTTP discovery proxy to test the compatibility of JAX-WS provider/dispatcher API with FraSCAti.
The main class contains two test methods, working with a meteo mock service.
philippemerle
commented
12 years ago I have added support to the wsdlElement attribute for
<service ...>
Here the wsdlElement attribute allows to set the service name to GlobalWeather and the port name to GlobalWeatherSoap.
Thank you to try this new version and report us problems.
JGuillemotte
commented
12 years ago Hello Philippe, all.
I have tested this modification and it is ok but it is not enought to build a complete mock from a WSDL fully compatible with the original service.
To give you a sample : In Easysoa, we use the smarttravel sample. This sample works with online services. We have made mocks services from the 3 online services used in the smart travel sample.
Mock services versions :
Encountered problem :
The problem was the service and port names in the SCA version. The names were generated by FraSCAti and were differents from the originals. So the mock service is not fully compatible with the online service. This problem is solved by the recent support of "wsdlElement" attribute in the "binding.ws" composite tag.
Now we have a new problem concerning the i/o parameters manes. FraSCAti do not use the annotations in the CXF generated classes so we have a mocked service that use default parameters names : "arg0, arg1, arg2 ..." for the input parameters and "return" for the output parameter.
All the work i have made about this subject is available in the Easysoa "smart_travel_sample_sca_app" branch.
See more precisely the smart travel trip client. This client works with 3 mock services : currency, translate and meteo services.
----- Mail original -----
De: "philippemerle" reply@reply.github.com À: "Jeremie Guillemotte" jeremie.guillemotte@openwide.fr Envoyé: Jeudi 7 Juin 2012 15:08:20 Objet: Re: [EasySOA] FraSCAti can't mock a specific WSDL (because no JAXWS annotations support) (#23)
I have added support to the wsdlElement attribute for
applied to an SCA service. Now it is possible to set both service and port names when exporting an SCA service via an WS binding instead of using default generated names. See an example at http://websvn.ow2.org/filedetails.php?repname=frascati&path=%2Ftrunk%2Fexamples%2Fweather-mock%2Fsrc%2Fmain%2Fresources%2Fweather-mock.composite <binding.ws uri="/Weather" wsdlElement="http://www.webservicex.net#wsdl.port(GlobalWeather/GlobalWeatherSoap)" />
Here the wsdlElement attribute allows to set the service name to GlobalWeather and the port name to GlobalWeatherSoap.
Thank you to try this new version and report us problems.
Reply to this email directly or view it on GitHub: https://github.com/easysoa/EasySOA/issues/23#issuecomment-6175283
mdutoo
commented
11 years ago 20120704 update by pmerle :
The WSDL of the translate service uses WS-Addressing, which causes the problem. In this WSDL file, comment or remove all wsaw:Action attribute of wsdl:input and wsdl:output elements. Then this should work.
I will investigate later how WS-Addressing could be supported by FraSCAti.
mdutoo
commented
11 years ago CXF supports WS-Addressing using org.apache.cxf.cxf-rt-ws-addr which is enabled using a jaxws:feature, see doc. Could such a feature be enabled in FraSCAti and how, maybe in a custom implementation intent ??
mdutoo
commented
11 years ago WS-Addressing can now be enabled in FraSCAti / CXF using the right Intent: http://websvn.ow2.org/filedetails.php?repname=frascati&path=%2Ftrunk%2Ffrascati%2Fintents%2Fapache-cxf%2Fsrc%2Fmain%2Fjava%2Forg%2Fow2%2Ffrascati%2Fintent%2Fcxf%2FWSAddressingIntent.java
Report by mdutoo
The FraSCAti-deployed service mockup EasySOADemoTravel/meteo-sca-backup has not the same WSDL as the original one at http://www.webservicex.net/globalweather.asmx?WSDL . However the CXF mockup at easysoa-meteo-sca-backup, generated with Eclipse right-click on WSDL > SOA > Generate server, works all right. The reason (I guess) is that FraSCAti's binding.ws does not use CXF JAXWS frontend when exposing a JAXWS annotated java service implementation.
NB. I've seen a JAXWS strategy in FraSCAti code source, but only on stub (client) side. And when looking up JAXWS & FraSCAti on google, old SCOrWare stuff in the mailing list comes up...
UPDATE by jguillemotte:
The symptoms are :
They are further described along with the problem at https://github.com/easysoa/EasySOADemoTravel/blob/master/easysoa-meteo-sca-backup/readme.txt .
UPDATE by jguillemotte:
Reported in FraSCAti Jira at http://jira.ow2.org/browse/FRASCATI-57
UPDATE by philipemerle:
See the new FraSCAti example at http://websvn.ow2.org/listing.php?repname=frascati&path=%2Ftrunk%2Fexamples%2Fweather-mock%2F