That's indeed a bit a jungle to understand web services. The wikipedia page is decent, but still lacks some elements.

I've flagged this answer as community wiki, so feel free to update it, or correct it. It's only a basis.

A bloated term:

First, the term web service is used to refer to many thing. While many people use it to refer to SOAP-based web service, the term can be used to denote any service provided through a web interface; this is a source of confusion.

Implementation and design style:

• SOAP-based -- SOAP is still the de-facto standard for web services. SOAP is protocol on top of HTTP that describes the exchange of message and exception. SOAP grew from something simple to something very complicated with all the WS-* standards that have been added later. The most important are: WS-Policy, WS-Security, WS-Addressing, WS-Transaction. Another important spec is MTOM for large message.
• RESTful -- The term RESTful relates to the fact that the service is stateless and all relevant information is passed as parameter. Also instead of using a protocol like SOAP, plain HTTP verbs are used, e.g. Get, Put, Delete, Update.
• Stateless -- WS are usually stateless. Business processed sometimes rely on so-called correlation identifiers (with WS-Addressing) that are used to match requests and response together; this is the same idea like storing a session identifier in a cookie because HTTP is stateless.
• Stateful -- There are some proposal to have stateful WS, but I don't know much about it.

Implementation and technology stacks:

• Servlet -- The lowest-level way to implement a WS: you basically parse the request and spit the HTTP response all by yourself.
• EJB -- Since EJB3, EJB can be exposed as web service very easily. Needs an EJB container, of course.
• Apache Axis -- Used to be a popular technology stack which is declining now.
• Apache CFX -- Another popular choice.
• JBossWS -- Yet another popluar choice.
• JAX-WS -- The official web service stack from Sun, very good. So far I know, this replaces JAX-RPC which was simply renamed JAX-WS.

Related concepts and jargon:

• WSDL -- Defines the contract/interface of the web service, in case of SOAP-based WS.
• Contract-first -- Refers to the fact that that a technology is able to support any WSDL provided upfront. On the contrary to an implementation technology which will generate the WSDL based on the implementation of the web service, in which case the WSDL can not always be customized as necessary
• Profile -- To simplify this mess, they've introduced profiles which are groups of related specifications/capabilities that need to be supported for interoperability. The main one is WS-I Basic Profile.
• UDDI and discovery -- It seems like some people thought the web service would be published in a public register so as to be discoverable by potential consumer. I don't think this vision gained much momentum.

That's indeed a bit a jungle to understand web services. The wikipedia page is decent, but still lacks some elements.

I've flagged this answer as community wiki, so feel free to update it, or correct it. It's only a basis.

A bloated term:

First, the term web service is used to refer to many thing. While many people use it to refer to SOAP-based web service, the term can be used to denote any service provided through a web interface; this is a source of confusion.

Implementation and design style:

• SOAP-based -- SOAP is still the de-facto standard for web services. SOAP is protocol on top of HTTP that describes the exchange of message and exception. SOAP grew from something simple to something very complicated with all the WS-* standards that have been added later. The most important are: WS-Policy, WS-Security, WS-Addressing, WS-Transaction. Another important spec is MTOM for large message.
• RESTful -- The term RESTful relates to the fact that the service is stateless and all relevant information is passed as parameter. Also instead of using a protocol like SOAP, plain HTTP verbs are used, e.g. Get, Put, Delete, Update.
• Stateless -- WS are usually stateless. Business processed sometimes rely on so-called correlation identifiers (with WS-Addressing) that are used to match requests and response together; this is the same idea like storing a session identifier in a cookie because HTTP is stateless.
• Stateful -- There are some proposal to have stateful WS, but I don't know much about it.

Implementation and technology stacks:

• Servlet -- The lowest-level way to implement a WS: you basically parse the request and spit the HTTP response all by yourself.
• EJB -- Since EJB3, EJB can be exposed as web service very easily. Needs an EJB container, of course.
• Apache Axis -- Used to be a popular technology stack which is declining now.
• Apache CXF -- Another popular choice.
• JBossWS -- Yet another popluar choice.
• JAX-WS -- The official web service stack from Sun, very good. So far I know, this replaces JAX-RPC which was simply renamed JAX-WS.

Related concepts and jargon:

• WSDL -- Defines the contract/interface of the web service, in case of SOAP-based WS.
• Contract-first -- Refers to the fact that that a technology is able to support any WSDL provided upfront. On the contrary to an implementation technology which will generate the WSDL based on the implementation of the web service, in which case the WSDL can not always be customized as necessary
• Profile -- To simplify this mess, they've introduced profiles which are groups of related specifications/capabilities that need to be supported for interoperability. The main one is WS-I Basic Profile.
• UDDI and discovery -- It seems like some people thought the web service would be published in a public register so as to be discoverable by potential consumer. I don't think this vision gained much momentum.

That's indeed a bit a jungle to understand web services. The wikipedia page is somehow decent, but still lacks elements.

I've flagged this answer as community wiki, so feel free to update it, or correct it. It's only a basis.

Implementation and design style

• RESTful -- The term RESTful relates to the fact that the service is stateless and all relevant information is passed as parameter. Also instead of using a protocol like SOAP, plain HTTP verbs are used, e.g. Get, Put, Delete, Update.
• SOAP-based -- SOAP is still the de-facto standard for web services. SOAP is protocol on top of HTTP that describe the exchange of message and execption.
• Stateless -- WS as usually stateless
• Stateful -- There are some proposal to have stateful WS, but I don't know much about it

Implementation and technology stacks:

• Servlet -- lowest-level to implement as WS: you basically get and spit the HTTP response all by yourself.
• EJB -- Since EJB3, EJB can be exposed as web service very easily. Needs an EJB container, of course.
• Axis -- Used to be a popular technology stack which is declining now
• JAX-WS -- the official web service stack from Sun, very good.

Related concepts and jargon:

• WSDL -- Defines the contract/interface of the web service, in case of SOAP-based WS.
• Contract-first -- Refers to the fact that that a technology is able to support any WSDL provided upfront. On the contrary to an implementation technology which will generate the WSDL based on the implementation in which case the WSDL can not alsways be customized as necessary

That's indeed a bit a jungle to understand web services. The wikipedia page is decent, but still lacks some elements.

I've flagged this answer as community wiki, so feel free to update it, or correct it. It's only a basis.

A bloated term:

First, the term web service is used to refer to many thing. While many people use it to refer to SOAP-based web service, the term can be used to denote any service provided through a web interface; this is a source of confusion.

Implementation and design style:

• SOAP-based -- SOAP is still the de-facto standard for web services. SOAP is protocol on top of HTTP that describes the exchange of message and exception. SOAP grew from something simple to something very complicated with all the WS-* standards that have been added later. The most important are: WS-Policy, WS-Security, WS-Addressing, WS-Transaction. Another important spec is MTOM for large message.
• RESTful -- The term RESTful relates to the fact that the service is stateless and all relevant information is passed as parameter. Also instead of using a protocol like SOAP, plain HTTP verbs are used, e.g. Get, Put, Delete, Update.
• Stateless -- WS are usually stateless. Business processed sometimes rely on so-called correlation identifiers (with WS-Addressing) that are used to match requests and response together; this is the same idea like storing a session identifier in a cookie because HTTP is stateless.
• Stateful -- There are some proposal to have stateful WS, but I don't know much about it.

Implementation and technology stacks:

• Servlet -- The lowest-level way to implement a WS: you basically parse the request and spit the HTTP response all by yourself.
• EJB -- Since EJB3, EJB can be exposed as web service very easily. Needs an EJB container, of course.
• Apache Axis -- Used to be a popular technology stack which is declining now.
• Apache CFX -- Another popular choice.
• JBossWS -- Yet another popluar choice.
• JAX-WS -- The official web service stack from Sun, very good. So far I know, this replaces JAX-RPC which was simply renamed JAX-WS.

Related concepts and jargon:

• WSDL -- Defines the contract/interface of the web service, in case of SOAP-based WS.
• Contract-first -- Refers to the fact that that a technology is able to support any WSDL provided upfront. On the contrary to an implementation technology which will generate the WSDL based on the implementation of the web service, in which case the WSDL can not always be customized as necessary
• Profile -- To simplify this mess, they've introduced profiles which are groups of related specifications/capabilities that need to be supported for interoperability. The main one is WS-I Basic Profile.
• UDDI and discovery -- It seems like some people thought the web service would be published in a public register so as to be discoverable by potential consumer. I don't think this vision gained much momentum.