It is equally important to to study from the right sources as it is to learn new technologies.
Here's the definition of a Web Service:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
This is a long reply because I doubt that a one-line, pithy, complete definition for "web service" - that is also useful and not confusing - can be given!
Below are some aspects that characterize web services, and some aspects that explain what web services are not:
1. A web service interface is a technique for one system to expose sections of useful data that is otherwise hidden away in proprietary data formats behind closed doors. This is the typical use case for a web service interface. A system has some data stored away in its databases, in some proprietary binary format. Each database uses a different format, thus making them
un-interoperable. How to make them interoperable in a secure way, without giving direct access to the database?
Answer: Use a translator that translates proprietary format to interoperable data format like XML and JSON. That translator is the web service interface.
2. A web service interface is meant for use by other systems (typically 3rd party systems outside of the organization), and *not* by people. If the data is to be consumed by a small set of inhouse developers, then probably a web service interface is a design overkill and a performance killer.
On the other hand, if business use cases envision the opening of the system as some kind of a platform for 3rd party sytems outside the organization (good example is twitter),
or the organization has very disparate systems using multiple programming languages and technologies but need to talk to one another,
then web services are the answer.
3. A "web service" is the term given to a particular type of interface exposed by some system. A "web service" cannot exist by itself - there has to be some system that exposes a web service.
To use an analogy, think of the wifi antenna or LAN cable slot in your computer. They're *interfaces* to network with other machines. By itself, a standalone wifi antenna or LAN slot is useless.
You can't say a wifi antenna communicates with another computer; you have to say one computer communicates with another computer through its wifi antenna.
Same concept with "web service". It's an interface exposed by some system so that other systems can communicate with it.
The system may expose other ways to communicate too, in addition to web service interfaces.
4. Data provided by a system through a web service interface should be structured and coherent. This is a corollary of the previous rule that its primary consumers are other systems. Computers are bad at understanding unstructured data.
For example, take this web page itself. It has text, elements and layout in such a way that our brains can understand easily.
Our brains understand that the first item is a "question", subsequent items are "answers", the word "Ranch hand" is a rating for a forum member, etc..
But if you show this page's HTML source or its screenshot to some system, it cannot consume it easily, if at all. What is "Ranch hand"?? The computer cannot understand it.
What is <h1> and what is the difference between one <h1> element and another ? How should it use them? None of these are clear or consistent across different web pages.
For structure and coherence, it should include some *metadata*. For example, If "Ranch hand" element has the metadata tag "rating", then a system that analyzes forums can
analyze any forum, come across the metadata tag "rating", and understand that that element is a rating, whether its value is "Ranch hand" or "Guru" or "2000 points" or whatever.
The only such metadata formats that have proven highly interperable, standardised and used extensively are XML and JSON, all of which are text formats. Though an interoperable binary format is feasible,
it has not been achieved.
5. A web service interface should use an interoperable data format. The data format should not constrain other systems to a particular programming language or technology.
Practically, the only such formats are XML and JSON. No other formats have reached their level of interoperability, and I think it's mainly due to corporate politics than any technical constraint.
6. A web service interface should use an interoperable networking protocol. This is obvious. The only such protocol that is standardised, well accepted, can overcome networking constraints like firewalls is HTTP. The vast majority of web services run over HTTP.
And because HTTP supports detailed response codes, it's possible to have a web service that uses just HTTP verbs and response codes to communicate.
7. A web service interface should output data which can be consumed *easily*. *easily* is a subjective term, but most of us have similar ideas about what is easy and convenient, and what is not.
For example, a java object can return data in java binary class format through RMI. That format is even well documented and standardized.
Theoretically, it can be consumed by any other system.
So why don't people call a RMI interface as a web service interface?
Why can't a .NET app communicate with a java app using RMI?
Because, it's not *easy* to do so. There are no class format interpreters written in other languages, or if there are, they're not widely used.
There is also not much scope for widespread acceptance of RMI format, mostly because of corporate politics. If Oracle says RMI should be accepted, MS will ask why RMI and why not .NET remoting,
and before you know it, they'll be filing patent cases!
There are technologies like corba, thrift, protocol buffers, etc that make binary interoperability *possible*, but none of them are as easy or convenient as XML and JSON. Those binary technologies may also
have issues when using scripting languages.
8. A web site or a web application is *not* a web service. But both can expose web service interfaces. A web site or a web application that displays HTML in a browser does satisfy some aspects:
- they are meant to be consumed by other systems, in this case web browsers.
- they use interoperable data format (HTML) and interoperable network protocol (HTTP)
But they don't
- satisfy the structured and coherent data aspect, and because of that, their HTML outputs cannot be consumed easily or consistently (which you realize when writing web scraping applications).
So a web site or web app can't be called a web service. However they can support web service interfaces which satisfy the above aspects.
Technologies: Conceptually, you need to know WSDL, SOAP, REST and HTTP.
WSDL and SOAP are essentially to make method calls in an interoperable way over the network.
The WSDL is a formalized description of the web service interface, that describes which methods, what arguments, types of those arguments, type and structure of return values, what exceptions are thrown, by a web service interface. It even describes things like authentication and authorization aspects for a web service formally.
The elements of the call - the args, the return, the exceptions, the security - all of them should be only in XML.
The WSDL description of a web service is itself is in XML with a standardised format, thus allowing any system in any language to consume a web service.
SOAP is the network wire format used by WSDL web services.
As an analogy to java, the WSDL is the class definition, and SOAP is the representation of objects.
A REST service is less formal than WSDL. In REST, the actions are described by HTTP protocol verbs like GET, POST, PUT and DELETE, and the return values are HTTP response codes. So it's kind of standardised by the fact
that a particular verb results in the same action regardless of the system. GET verb always reads some data on the resource specified by the GET URL, regardless of which system is supporting it.
But REST does not specify in any formal way the *structure of that output*. It'll be XML or JSON, but what is the structure of that XML or JSON? This is not formally specified (ie, it is not specified in a way that another system can understand and enforce it), but specified only informally through documentation to be read by developers of other systems.
While REST is based on HTTP, not all HTTP services can be called RESTful. A HTTP service is RESTful only if it honors the behaviors imposed by REST. Otherwise it's still a web service, but can't be termed RESTful.
Those are the conceptual aspects.
Once you understand them, you need to know the java standards that describe their use in java systems: JAX-WS and JAX-RS.
Once you understand those, get to know some of the frameworks that implement those standards, like Apache Axis, Apache CXF, Jersey, Glassfish Metro, and many many more.
Right now I'm working at a step-by-step guide on how to create a simple SOAP web-service, and also consume it in a practical application. I'll come up with an edit when they'll be done, so if you're still interested in web-services, activate the notifier on this topic, and you'll know. Regards!