Develop Reference

Calling a rest client from a net beans project

I am new to Java GUI, I have knowledge of core Java.
I have to call a REST client from my NetBeans project, give values to it, and receive its output in the same project.
Please point me to some helpful resources.

This tutorial covers the basics using Twitter's REST api which should be stable enough for you to be confident that any errors you see are in your implementation and not the API.
"In this tutorial, you create a NetBeans platform application that consumes the Twitter What Are You Doing service, displaying a list of your Twitter friends' status messages. First you create the platform application. You select the libraries needed in the application. Then you create a NetBeans module. Finally, you add a RESTful client and some basic display elements to the module. The client uses OAuth authorization."
https://netbeans.org/kb/72/websvc/jersey-rcp-client.html

You could try looking at the Oracle documentation on JAX-RS clients, which is how you can access REST resources using Java.
http://docs.oracle.com/javaee/7/tutorial/doc/jaxrs-client.htm
In addition, client libraries like RestEasy and Jersey can help make your life even easier.
When dealing with RESTful webservices, you'll also want to know how the request bodies map to your Java objects. Are you using XML, JSON, a combination? It will help to know that as well so that you know if you need an XML mapping framework or a JSON mapping framework. You can just parse the strings, but depending on how complex it is, that might get really messy!

What is the best way to write a java client for a web service?

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.

groovy web service client

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.

Java Web Services - Is Axis Necessary?

Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?

Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )

The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.

An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.

As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).

You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.

Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.

wcf and java interop

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.