I need to write a web service client in Groovy. The author of the web service has proposed various unappealing blobs of Java code that I could use to call the service from my Grails application.
At this point, I think it might be better if I just ask them to give me the WSDL and I'll take care of the client code myself. I'm looking for suggestions about the best way to go about writing a Groovy web service client using only a WSDL document?
I expect most suggestions will involve using some tool to generate a client-side API that I'll call from my Grails app. If so, then it's important that I can integrate generation of this API into a Grails build, because the WSDL document will probably change frequently.
I've looked at using GroovyWS which provides a very simple way of calling web services. However, it seems to lack any concept of a contract which concerns me from the point-of-view of testing. I would like to define a contract (interface) for the web service, for which I provide a real implementation that the app will use and a mock implementation that my unit tests will use.
Given your desire for more stability than the very dynamic GroovyWS, I'd suggest the easy way:
Use JAX-WS to generate a Java client, compile that and use it from Groovy. It's all statically typed and the generate Java source is reasonably clean (definitely much better than older WS client frameworks such as Axis 1).
Of course that would require that you have access to the WSDL.
Related
Provided a WSDL I create a dynamic web service client. What I want is to expose the methods and the types of the parameters those methods have and test the code from a webpage. Bare in mind that the client is dynamic, so what I have to build must me able to work with different WSDLs.
What I want to do is what the Eclipse web service explorer does for testing a web service client from the provided user interface. How does it find the methods and the parameters? Does it parse the WSDL? I've searched for the source code, but I couldn't find anything relevant. I don't even know where to begin.
What I want is suggestions and some guidance of what I have to build, what is already provided out there (that I'm not aware obviously) and a place to begin. I'm not asking for code.
Essentially creating a generic web services client would involve the following:
Analyse the WSDL for service definitions i.e. the method names and their definitions. Remember your WSDL defines your service.
Analyse any XSD (embedded or linked) to retrieve the datatypes of the parameters etc.
As a suggestion why not look at the SOAP UI project which is really great as a generic web service test client. As it is open source you might be able to learn how they do it. Go have a look at the project here
Also go look at the Apache CXF framework. This framework will allow you to easily create a webservice client. See this tutorial for more information: how to create a client in CXF. CXF is also usable via javascript so it might be what you are looking for see this link
I would suggest that you try leveraging these tools before you try to invent one yourself as parsing WSDL's and XSD while NOT difficult to parse it going to take a substantial programming effort. CXF already has this covered for you if I read your question right.
I like Play 2.0 much (especially Scala API). But it lacks SOAP completely. Is there some not mindblowing way to provide SOAP WS (wsdl based) from Play 2.0?
Say, I'd want it to be accessible from some URL (e.g. /soap), preserving other pages to be HTML. Please, help, I have no clue (I'm java newb, and zillions of abbreviations for frameworks and libs make me confused).
PS To prevent possible unproductive treatments: I'm a java newb but not a newcomer programmer, so I know how SOAP, HTTP and other stuff are meant to work at protocol level.
I ran into the same problem - Apache CXF and Axis2 depend on the Servlet API, which the Play Framework doesn't have.
I created a custom transport plugin for Apache CXF which connects to Play's Controller API.
There is a tutorial about setting it all up in an empty project: http://www.imind.eu/web/2013/11/07/developing-soap-services-using-play-framework-2-2-x/
The plugin's source (and a sample Play application) is here: https://github.com/imindeu/play-cxf
If you trying to create a web service API for existing business logic that will be part of your Play service, then you should probably look using existing Java libraries that can do the SOAP magic for you (e.g. Axis2). Scala can use existing Java libraries without any problem.
However, most people would strongly recommend you look at a REST service rather than a SOAP service, if this is an option. Have a look at Play Mini to see how this is done.
UPDATE:
Ah, this may help you: https://github.com/mandubian/scala-xmlsoap-ersatz
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
I have a project coming up that will require me to call a SOAP web service from my java application. I'm wondering what toolsets I should look at to do this? All advice appreciated.
I've looked at jax-ws and Axis2 but these appear to be mostly for creators of web services instead of consumers and I only wish to consume.
Thanks!
First of all you need wsdl. Some service providers might distribute Java client classes, but WSDL is the safest approach.
Once you have it, run tool like wsdl2java for apache-cxf or analogous in apache-axis against it. It will create a bunch of Java classes (you only need the client side). These tools are also capable of generating server-side code, hence the impression you had that they aim service developers.
This is all you need - the client classes will handle XML marshalling/unmarshalling and HTTP connectivity for you. Just use appropriate stub implementing WS endpoint interface.
You can also use WebServiceTemplate from spring-ws portfolio.
Jax-WS comes with a tool called wsimport which you run against the .wsdl of the SOAP service. It generates a whole bunch of classes your client can use to interact with the service. After that it's just plain Java coding.
If you are using eclipse you may want to view this solution:
What is the easiest way to generate a Java client from an RPC encoded WSDL
If you want a rapid-functional client you can use JAX-WS tools to generate the code that you need to consume a Web Service. But sometimes this approach can generate non-portable code (like with Websphere tools) but you the productivity gain maybe worth it.
Spring Framework also offers tools to build and consume web services, but it requires some extra effort to develop the client and it may require some manual mapping of the input/output messages with technologies like JAXB or Castor. You can also directly read XML with Spring, it's a flexible framework that assures you portability between containers but it requires extra effort and time.
Every approach has it pros and cons. It's up to you to decide.
How can I interop easily between WCF and a Java app.?
WCF is a web service framework. Java also provides its own web service frameworks. They should be able to interoperate quite easily, although you'll need to ask a much more specific question if you want a better answer.
edit: The ProjectTango link you ask about says it all in the first paragraph:
... to ensure interoperability of
enterprise features, such as security,
reliable messaging, and atomic
transactions.
These are fancy additions to basic web services, and the specifications alone are not enough to ensure compatibility.
Basic web service interaction, which is all 99.9% of us ever need, will work just fine between WCF and Java.
Short Answer, Yes.
Long Answer, the interoperability depends on several factors. Basic interoperability is very easy. Only when you throw in factors such as security that things get complicated. We did some research on availabe Java web service frameworks and found out that the best suited one for our scenario is the metro stack along with netbeans 6.5 IDE. We achieved message secuity which has mandatory for the project using client/server mutual certificate authentication.
Some gotchas discovered in the process are:
- You have to add the webservices-rt.jar library from glassfish directory in netbeans project. (doesn't need glassfish to be running, just the jar file)
- WCF generates multifile WSDL files and netbeans cannot use them to generate proxy, although if netbeans is configured to use the URL (http://../?wsdl) it can generate the proxy.
- You have to put [IsRequired=true] on all datamembers in WCF. Java's handling of optional datamembers is quite complicated.
- Dictionaries as datamembers comes out as list
We have done this successfully on several projects. We use WCF basicHttpBinding, it is the simplest option if you just need to get it to work.
One of the things that can be a show stopper is if a service uses a platform specific datatype, like a Java vector or a .net dataset.
You can use JAX-WS services on the Java side, and then use WCF in .NET.
First create the JAX-WS services (glassfish libraries will allow you to do this). Create your POJO's, add the JAX-WS annotations, and deploy your WAR. Then, get the WSDL generated by your server and give it to VisualStudio. VisualStudio can generate the client for you.
That is the simple way, but your mileage will vary of course.