I'm using wsdl2java to generate service. Arguments for generation are following:
-p com.dummy.tst.service -u -f -sp -s -b -ssi -d xmlbeans -uri /some/path/service.wsdl -ss -g -sd -o /some/path/gen
After generation I've got a services.xml file with line like
<parameter name="ServiceClass">com.dummy.tst.service.TestSoapBindingImpl</parameter>
Then in gen directory I've got TestSoapBindingImpl.java with list of methods but every method is defined as follows
throw new java.lang.UnsupportedOperationException("Please implement " + this.getClass().getName() + "#myMethod");
And also there's a TestSoapBindingStub.java file which actually contains implemented methods. In axis-1 there was only one file with methods description and implementation and in axis-2 I've got 2 files.
What should I do with these files? Impl file, that is specified as default service methods container (in services.xml) contains only dummies, so I can't use deployed service and replacing TestSoapBindingImpl with TestSoapBindingStub in services.xml also does not lead to the desired result.
TestSoapBindingStub.java is for the client. It contains code to call the web service on a remote system.
On the service side, every time a request comes in, Axis2 will create an object of the type specified in services.xml as the ServiceClass. It will then call the requested function within the ServiceClass object, using the object that was provided by the client.
Using the code generated by wsdl2java, every call to the service will create an object of type om.dummy.tst.service.TestSoapBindingImpl, which as you've noted will throw an exception for each call. There are two approaches to make a working service.
You can use the TestSoapBindingImpl.java file that you have as a starting point. Remove the throws line from each function and fill in each function body with the code that you actually want to execute when a request comes in.
Alternately, you can use services.xml as a starting point. Define a class of your own to be the service class. Replace the reference to com.dummy.tst.service.TestSoapBindingImpl with a reference to the name of your own service class. wsdl2java probably generated a file named something like TestSoapBindingSkeleton.java which defines the interface which the service class should implement. Your custom service class should implement this interface.
The projects that I've been working on use approach #2. We write our own service class which implements the skeleton interface. When packaging the service into an AAR file, you include the services.xml file in the AAR. Our packaging rule performs a text substitution on the generated services.xml to update the ServiceClass with the name of our service class.
Related
I am very new to the building of web-services, so please forgive my ignorance.
I have been given some an .wsdl files with some .xsd files that it imports.
I am told that a web-service can be created from the .wsdl file by using wsdl2java from the apache axis2 project.
The web-service I am trying to build is expecting to have data pushed to it and I would like to test it that I have the process right for data to be pushed to a web-service that I created.
The basis for my actions have been from here, but not too sure how much of it is applicable.
I am on a MacOSX but also have access to an ubuntu system too.
the steps I have taken so far are:
cd /directory/of/wsdl/file
wsdl2java.sh -uri tmp.wsdl -d adb -s
This creates a build.xml file and src directory
I then try and run
ant
or
ant jar.client
After this I am not too sure what to do, in order to get the web-server running so that I could test it...any suggestions would be greatly appreciated.
Thanks in advance.
In SOAP web service:-
The basic concept in web service is that it has consumer and producer.
A consumer is one which consumes a web service and a producer is one which produces a web service. A producer publish its service so that consumer can consume it. It basically publishes a wsdl file so that you can create a client code or jar out of it and can directly call it from your code. You can use soap UI to call the web service directly as well. If you are looking for generating producer code from wsdl as well it will not be good enough since it will not provide business logic to you and you need to implement it by yourself. This is not a recommended approach. Generally first java implementation is written and based on it a wsdl is created from which client jars are created for the clients to use the web service in their code. For directly testing the producer soapui is used.
If you want to create producer it is a straight forward process. Need to create a dynamic project in eclipse-->create a class-->use #WebService(serviceName="xyz") on class and similarly on method level define #WebMethod. Deploy it as run on server and you are done with your Hello World Web service producer.
For creating the client:-
Lets take an example of a published wsdl on the net as :-
http://www.webservicex.net/geoipservice.asmx?WSDL
First you need to create the client jar or java classes as :-
wsimport -keep -s C:\wsdl http://www.webservicex.net/geoipservice.asmx?WSDL
Look at the documentation or look at the service name in the wsdl.
It will be GeoIPService.
Now in your class call the webservice method as:-
package com.soap.client;
import net.webservicex.GeoIP;
import net.webservicex.GeoIPService;
import net.webservicex.GeoIPServiceSoap;
public class SoapWebServiceClient {
public static void main(String[] args) {
GeoIPService ipService = new GeoIPService();
GeoIPServiceSoap gp = ipService.getGeoIPServiceSoap();
GeoIP ip = gp.getGeoIP("117.198.208.1"); //google.com
System.out.println(ip.getCountryName());
}
}
Now similarly for local wsdl you can create classes and jars by
using axis2 or simply wsimport
Put your wsdl and schemas in a folder as shown below:-
C:\wsdl>wsimport -keep -s C:\wsdl C:\wsdl
C:\wsdl>wsimport -clientjar client.jar C:\wsdl
It will create a client for you. Look at the service name and similarly can test the deployed service from java code as shown above.
For testing using soapui you use need to download it and create a new soap project. Give any name and browse to your local drive where all the schema and wsdl is present. It will create all the requests for your. You need to fill in the values in the request parameters ("?") and run the service. If everything went well it will display a result.
Note:-
wsimport is a command line tool for the JAX-WS reference implementation. The JAX-WS RI uses JAXB for data-binding.
Axis2 merely implements the JAX-WS API to some extent, so the Java artifacts generated can be quite different compared to those generated by the JAX-WS RI. Also Axis2 doesn't use JAXB but instead offers the choice of ADB (default), Apache XmlBeans, or JiBX for data-binding. The most popularly used are either xmlbeans or JAXB.
You lookup the wsdl file from publishing URL and reverse engineer the webservice to generate the types so use wsimport
wsimport -d . -p servicesource -keep tmp.wsdl
So there is a SOAP webservice. The targetNamespace in the WSDL dynamically changes based on customer's configurable string. Think of it like
targetNamespace="http://myservice."+ [CouldBeAnyString] + "domain.com"
I have two questions:
My basic research tells me that this is a pretty weird(bad?) practice for developing webservices. Thoughts ?
How does one write a client for such a webservice ? I have tested using jax-ws stub and it isn't compatible when targetNamespace changes. Any other suggestions ? I have been trying to understand dynamic client generation based on wsdl. Would prefer a nicer path though if one exists
Update:
I am only the client. Service is provided by someone else.
Same customer has multiple environments (eg test,production) where the service is hosted under different targetNamespaces
If the SOAPUI call works even if the targetNamespace has change, you could use a lightweight HTTP library called HTTPCLIENT.
With this library you don't need to generate client, since you are sending the SOAP envelope as a string, the way you would do via SOAPUI.
The downside is to work with Strings.
In theory, it is feasible to create such a Web Service client.
Steps:
Create Java artifacts based on the WSDL using wsimport.exe of JDK (see: http://www.mkyong.com/webservices/jax-ws/jax-ws-wsimport-tool-example as a reference)
For the purposes of the code displayed below, I have used the Calculator WSDL provided by Microsoft
Create a "Dynamic Web Project" via Eclipse J2EE
Copy the Java artifacts created in step #1, under src folder of the project created in step #2.
Create a new Class containing you main method. Normally you would have something similar to:
String wsdlLocation = "127.0.0.1:8088";//Normally you should retrieve that value dynamically
Url url = new URL(wsdlLocation + "?wsdl");// ?wsdl is actually needed
String namespaceURI = "http://Example.org";//Normally you should retrieve that value dynamically
String localPart = "CalculatorService";// as specified in WSDL file (see name attribute of service tag)
QName qname = new QName(namespaceURI, localPart);
CalculatorService service = new CalculatorService(url,qname);
ICalculator iCalculator = service.getICalculator();
int response = iCalculator.add(1, 2);
System.out.println(response);
Now for the tricky part:
If you have followed the example with the aforementioned WSDL, you should now have several Annotated Classes having hard-coded namespace (e.g. ICalculator is annotated with:
#WebResult(name = "result", targetNamespace = "..."))//where ... is similar to http ://example .org
Using Java reflection modify all the hard-coded values at runtime (see an example here: https://stackoverflow.com/a/14276270/2625635 on how to modify Annotations)
The aforementioned solution should do the trick.
Most client frameworks allow you to create an interface for calling your client (i.e. they create a contract interface). They also provide an implementation for that interface and it is the implementation that has specific annotations or extends "SOAP aware" classes, while the interface is clean of such details.
From what you posted I assume the clients have the same interface, it's just the implementation namespace that's different? If yes, then write your application to use the interface then build a jar for each environment's implementation. When you deploy on test servers deploy with the test jar, while on production deploy with the production jar (i.e. pick a different implementation for the same contract depending on the environment).
Even if the framework you use doesn't create an interface for you, you can create one yourself and hide the various implementations behind an adapter of some sort.
You can also do something like edubriguenti suggested but I wouldn't go as far as working with strings. Work with SAAJ instead.
i followed this article: http://www.mkyong.com/webservices/jax-ws/jax-ws-hello-world-example/
so i have:
HelloWorld http://pastebin.com/BJ3QA7pR
HelloWorldImpl http://pastebin.com/RM5SBZ5C
HelloWorldPublisher http://pastebin.com/H525WevK
which serves as the endpoint.
on the other side i have the client which i generated with wsimport:
HelloWorld http://pastebin.com/g07H1exf
HelloWorldImplService http://pastebin.com/f0YWMiYt
this runs fine in eclispe without alfresco being involved. however, i want to call the webservice from alfresco (from java backed web script for example)
i tried to copy the client side stuff to my amp file and calling it from a webscript but it fails!
Caused by: java.lang.IncompatibleClassChangeError: Class com.ibm.wsdl.DefinitionImpl does not implement the requested interface javax.wsdl.extensions.AttributeExtensible
Webscript http://pastebin.com/7JksRdtU
1 - is there a more elegant way to configure the access to the wsdl by defining a spring bean (spring-ws) or such
2 - why is it not working? full trace: http://pastebin.com/ak1qzygA
using alfresco community 5.0.a
thanks
You will see IncompatibleClassChangeError usually when the dependancy/library jar has changed. Hence the method/code dependant on the library has to be recompiled against the changes.
Guessing the problem here has much to do with some dependancy jar being mispicked or an older version of jar present or one jar prioritized over the other. A look into the jars containing 'com.ibm.wsdl.DefinitionImpl' class in your classpath should be of some help.
I have a model that is used to create a Web Service endpoint on a server. The same model is used for the client. However when a new operation is added to the server but the client still uses the older model, service creation fails with an exception like the following (line breaks added for clarity):
Exception in thread "main" javax.xml.ws.WebServiceException:
Method someNewMethod is exposed as WebMethod, but there is no
corresponding wsdl operation with name someNewMethod in the
wsdl:portType{http://example.com}MyService
I understand the problem but is it possible to ignore this? I'd like to be backwards compatible when consuming the Web service. As long as methods are merely added this should work just fine most of the time.
The problem occurs in the getPort method:
Service s = Service.create(
new URL("http://example.com/foo?wsdl"),
new QName("http://example.com", "MyService"));
MyService m = s.getPort(MyService.class);
Just for reference.
You can also annotate the method with
#WebMethod(exclude=true)
This will make sure the method is ignored for comparing with the wsdl.
Use an local WSDL File:
The client App has an local WSDL File of the service e.g inside the jar file.
The you get it with
URL wsdlURL = this.getClass().getClassLoader()
.getResource("MyWebService.wsdl");
That worked for a App that i wrote. The server later extended an additional WSDL attribute, while the client still uses the local one.
I just deleted the webservice reference and created again using the interface.
Your Service class contains a static constructor with a local wsdl file variable. Check if local wsdl file has the someNewMethod. If not download the wsdl file from original Url and save to local.
The soap address location value at the end of the wsdl is also important.
Sometimes https turns to http.
I have developed a webService using axis2 and spring. When I request the
wsdl file from the webservice I get the right wsdl file, but when I want to
use a defined operation of the webservice (using a java client),
I get the following exception:
[CODE]org.apache.axis2.AxisFault: The SERVICE_OBJECT_SUPPLIER parameter is
not specified.
In your services.xml file you need to define following two properties.
org.apache.axis2.extensions.spring.receivers.SpringServletContextObjectSupplier
beanname-that-expose-as-a-WS
Take a look http://axis.apache.org/axis2/java/core/docs/spring.html