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.