Webservices tends to be understood as the delivery of information by http using bundled XML as communication. As the w3c notes, "vendors of software see web services as way to repackage existing capability in a way which makes it interoperable with other systems"

As information systems have expanded, and networks, with the consequent storage of data proliferated there has been different mechanisms developed to access that data across wider systems. These include CORBA, RMI, Webservices and REST.

I have worked on CORBA systems, they tend to be heavy weight and solved a problem prior to the internet when HTTP based networks made data easy to access through the browser interface. CORBA is an effective mechanism to access data without caring about where it is located.

Java has it's own inbuilt version that solves the same issue; RMI, which enables the easy access of distributed objects across a distributed system. Again it knows where to ask where the data is through a naming system, similar to CORBA, though CORBA can be set up as a language/platform agnostic system. RMI is wedded to Java only.

In the Java world the definition of webservices is pretty narrow, and for J2EE it is an interface defined by a WSDL declaration where the data is bundled with the SOAP protocol. In the same vein as Microsoft's DCOM, CORBA's IIOP and RMI's JRMP, SOAP is a distributed object protocol. Unlike the other, it marshals and unmarshals an object's data using XML. Consequently different platforms can unmarshal SOAP transported data without caring what platform marshaled it or bundled it up.

Another benefit of SOAP is that it doesn't care what protocol or network is used to transport the SOAP packet. Given the dominance of HTTP in the modern web, this is the most common protocol used to transport SOAP packets on port 80. This has an upside and a downside, especially for network engineers tasked with security of the local network. SOAP packets can come in and out as they please, where-as services that run on other ports can be filtered or watched.

WSDL is the web services description language which defines the public interface and data for the web service. Because the WSDL is defined in XML and then compiled down to Java using an application like AXIS, it is complex and confusing to make up a WSDL document. Most J2EE vendors provide an application interface to help develop the WSDL.

Another issue with the WSDL is because it is difficult to write and make, a lot of public interfaces for webservices end up messy, ugly and downright awful to use. Unfortunately, in my experience, because of this many webservice interfaces have a lot of WTFness to them. However I have been using the flickr webservices API recently and it is very simple to use.

JAX-WS supports one way and return (request-response) messaging. The one way messaging is when the client does not expect a response, such as in asynchronous messaging. The request-response is the standard ask for something and get data in return. WSDL supports notification (trapping in SNMP parlance) and solicitation, however these two are not supported by JAX-WS.

The main purpose of JAX-WS is to easily make ejb3 stateless beans into distributed objects that can be hit by webservices. This is done through the java annotations of @WebService at the class level and @WebMethod at the argument level (if no methods are annotated with this, all are exposed). The annotations are in the javax.jws packages.

One of the issues with webservices is that they run across a network and carry all the vagaries of a non-reliable transmission system. Often webservice applications are developed in the safety and speed of an intranet and then have all sorts of issues on the internet, though the internet of 2009 is not the same one from 1999. But it does mean the safe transmission of data cannot be relied upon.

We pull down the webservices from other systems and then map them to Java objects using JAX-WS and JAXB. We use ant's wsimport to process the WSDLs and convert them to Java. We ran into the situation recently where we were getting this error;

Caused by: com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 63 counts of IllegalAnnotationExceptions
There's no ObjectFactory with an XmlElementDecl for the element {http://tempuri.org/}Service.
this problem is related to the following location:
at protected javax.xml.bind.JAXBElement org.tempuri.Service.getServiceResult

One of our vendors had placed their webmethods under the same namespace http://tempuri.org which can be long-handed to temp URI. From the tempura website; "Each XML Web Service needs a unique namespace in order for client applications to distinguish it from other services on the Web. By default, ASP.Net Web Services use http://tempuri.org/ for this purpose. While this suitable for XML Web Services under development, published services should use a unique, permanent namespace." Definitely non-ideal.

The main problem was that they had multiple WSDLs using the same tempuri namespace and the ObjectFactory that was generated from each WSDL was over-writing the previous one. Consequently the JAX-WS Java interfaces for the first WSDL processed was looking for its webmethod in the ObjectFactory and not finding it. The solution was to give those webservices or WSDLs a forced namespace in ant;

< wsimport destdir="${out.dir}" sourcedestdir="${web.dir}" package="package.other.than.tempuri.org" wsdl="${service.url}/${service.name}?WSDL"/ > 

This compiled the WSDLs down into a namespace or our choosing and stopped the clash of the ObjectFactories.